In startups, quality doesn’t come from formal test processes. It starts with close observation of the customer: founders and product owners test early, from the user’s point of view. As the team grows, it needs a dedicated tester role that works as an active part of the development process rather than as a final quality gate.
Key Takeaways
- Testing is not an end in itself: if nobody in the company loses sleep over product quality, you won’t be able to establish effective testing.
- Code generated by AI tools contains more defects on average, and proportionally more critical ones, than hand-written code, which raises the need for professional software testing instead of lowering it.
- Startups that grow from seedling to scalable company understood software quality early, while a purely casual attitude to quality survives only in rare cases and for short periods.
- Technical debt works like taxes: if you don’t invest in testability and code quality early, you pay a much higher price later as complexity grows.
- Agile testers are most effective as equal members of the development team, not as a pure quality gate that everything gets pushed through at the end.
Startup Software Testing Starts With Testability, Not Processes
Startup software testing doesn’t begin with a ready-made test framework. In a young company, quality comes from a deliberate decision during the design phase. Anyone setting up a new software system can build in testability from the start, much like security. Whether testing is then automated or manual is a question of capacity and often secondary in the beginning.
What matters is the mindset behind it. If a system is built to be testable later on, the effort stays manageable once complexity grows. If testability is ignored, the catch-up work grows with every additional line of code.
Daniel Krauss, co-founder of Flix, sees it this way: the idea that testing plays no role at all in startups no longer holds up. A few years ago that may have been different. By now, most people know that testing is a core part of good software development.
Why B2C Versus B2B Matters More Than a Company’s Age
Whether a company is young or established says less about how it tests than who it builds for. For decades, classic enterprise software shaped the structures many people still associate with testing. B2C products work differently.
For an app in the App Store, quality quickly decides whether the product takes off or fails. The feedback is immediate. That closeness forces a different way of dealing with defects than in a supply chain where the finished product is several steps away.
Daniel describes the contrast from his own experience. In the automotive supplier industry, the finished vehicle is three steps further down the line. It takes real effort to connect the metrics of individual components to the end product so that the customer is satisfied in the end. In a B2C startup, that bridge is much shorter.
Testing Is Not an End in Itself, and Should Never Become One
Testing without quality awareness doesn’t work. If you’re looking for a fig leaf, or testing because that’s just what people do, you miss the point. The goal is to assess the quality of a product and to raise it through a good development process.
Florian Fieber, board member of the German Testing Board, offers a simple test:
“First I ask: who among you can’t sleep if the product doesn’t work? If nobody raises their hand, then everything is actually fine. Then we don’t have a problem at all.”
(Florian Fieber)
Without someone who genuinely cares about product quality, meaningful testing is hard to establish. In that respect, a startup is no different from a large company. What decides it is how much quality actually matters to the team.
Metrics Mean Nothing Without a Goal
Zero percent test coverage means working software is a matter of luck. Reaching one hundred percent doesn’t necessarily make sense either. Test coverage isn’t a goal in itself, it’s a helper value. The real question is what you want to achieve with it.
Classic metrics such as lines of code in programming or test coverage in testing aren’t worthless. They show the extremes. But measuring them alone is misleading. Depending on the context, a completely different number may be the right one.
Startups often use metrics that follow customer feedback more closely than formal coverage. A more formally organized, document-heavy industry such as automotive supply will count test cases and measure coverage. An organization built for speed and learning is more likely to measure what actually reaches the customer.
How Testing Culture at Flix Grew From the Customer’s Perspective
At Flix, testing didn’t come out of the technical corner but from the customer’s point of view. In the early days the founders tested themselves, later the product owners did so in an agile setting. They downloaded the app, clicked through it and reported back what didn’t work.
Purely technical tasks stayed with engineering. The dedicated role of the agile tester, on the other hand, grew more out of the customer’s perspective than out of the idea of writing a test case against a piece of software.
The short, informal email of the early days has turned into a defined process through which feedback flows back. That kind of professionalization doesn’t apply to every three-person outfit, but you can see it clearly in companies with 30, 40 or 50 people. The driving force is the realization that one bad release can put you out of business very quickly.
Learning Through Pain Works Differently in a Startup Than in a Corporation
In a small company, quality problems can quickly become life-threatening, because the product is still a seedling. At the same time, they can often be fixed quickly, because there are few dependencies. So the depth of the pain stays limited.
Formal processes make sense where defects are expensive and hard to reverse. If you have to recall 100,000 cars in the automotive world, you have a real problem. Both worlds have their place, depending on what a defect costs.
Florian turns the familiar image of the baby turtle that makes it to the sea on its head. Instead of saying the survivors understood quality, you can argue just as well: the ones who get quality right are the ones who make it to the sea in the first place.
Testers Need a Voice Because They’re Outnumbered
Testing has to be anchored in roles, otherwise it depends on individual goodwill. A developer in the flow doesn’t automatically think about how to keep quality consistent while building. That takes people who keep an eye on the critical points.
The role takes backbone. Most teams have more developers than testers. Whoever tests is outnumbered and has to be willing to speak up, including to management.
At Flix, an early head of testing who was also a principal engineer shaped this role. She pushed the topic forward and didn’t mince words with management. In this view, treating testers as second-class developers is outdated. It’s about different strengths, not rank.
From Startup to Grown-Up Company: When New Disciplines Join
Many startups grow like an onion around a strong development team. Often one of the founders is a developer. Up to a point, that focus carries the company. Then it hits its limits.
With size, other disciplines come into play that were underestimated before:
- Architecture as a task of its own alongside implementation
- Requirements management
- Testing as a separate area of expertise
- Project management and supporting organizational processes
This is where it’s decided whether a startup makes it to adulthood. As long as the team is small, a founder can help with testing. As the organization grows, it needs a systematic, professional approach as a discipline of its own. The two complement each other, they don’t replace each other.
Change Isn’t the Pain, Losing Sight of the Customer Is
Growth in itself doesn’t hurt. If you see change as a flow, you experience it as moving forward, not as a burden. Discomfort usually only comes when people reflexively file every change under pain.
It gets painful somewhere else. When the focus on the customer gets lost and process is stacked on process on process, things start existing for their own sake. The result really is unpleasant.
One simple question that anyone on the team can ask helps against this: why are we actually doing this? Here, too, it’s up to the testers to raise their hand regularly and call out nonsense. A culture set deliberately brings the whole team along.
What the Agile Tester Role Means at Flix
At Flix, the agile tester is a player on the development team, not a goalkeeper at a quality gate. The name came from the team itself and expresses that the role is a core part of the development process and can adapt.
Agile doesn’t mean arbitrary here. It means being able to respond to changing requirements and still deliver an agreed result. The tester is part of the team, not the door everyone has to squeeze through at the end.
In Flix’s distributed architecture, development teams typically have six to eight people, sometimes up to ten. A team like this consists of a product owner, an agile tester and a range of developer profiles, from classic developers to data and AI specialists to DevOps. Close coordination with the product owner is at the heart of the role.
The Methodical Foundation Stays, the Tools Change
Yesterday’s tools no longer fit today, but the methods and strategies still do. That is exactly what makes method-focused training valuable. The Certified Tester scheme focuses on fundamentals, principles and the test process, independent of development method, approach or company size.
These core ideas apply anywhere. How early to test isn’t a new insight. Today it’s called shift left, but it’s an idea that has been part of testing for decades. The details differ by technology, tool and product, and the core idea stays the same.
At Flix, continuing education runs on personal responsibility. Team-specific topics are decided by each team. Broader questions that affect all agile testers are discussed together. Keeping up with the times is necessary, because a growing part of the world runs on software, so there is more and more to test that didn’t exist a few years ago.
Vibe Coding Belongs in Prototyping, Not in Enterprise Architecture
AI-assisted tools raise productivity, and vibe coding is a separate matter. At Flix, developers work with tools such as Claude Code to smooth over shortcomings in development with AI support. That makes sense. Taking something thrown together on the fly and putting it live, untested, into an enterprise architecture does not.
Daniel draws a parallel to earlier tools such as Dreamweaver, which could generate a lot of code, but with poor results. Being able to produce more doesn’t automatically make the result better. If anything, it shifts work to the people who have to use such tools sensibly.
For rapid prototyping and requirements engineering, the benefit is real. Product owners can build faster and better prototypes, even without deep technical knowledge. That cuts down the back-and-forth about what is actually wanted. For production code in a more complex product, skepticism remains. Still, diving in and exploring what works is the right attitude. Rejecting it would be the mistake.
Software Is More Than Code, Which Is Why the Need for Testing Is Growing
The common mistake is a developer-centered view that reduces software to writing code. Software is a product of technical components and people. Building it takes more than generating code quickly.
AI-based tools are picking up serious speed, and that’s not vibe coding but their serious use in development. For routine tasks and quick fixes, much of the work gets done remarkably fast.
Florian doesn’t see this as a reason for testers to worry, quite the opposite. In many observations, generated code shows more defects, and relatively more critical defects, than code written by people. That means a big wave of partly poor code is rolling toward software testing. From an economic point of view, that’s questionable. From a testing point of view, it means: anyone who thought testers were no longer needed needs them all the more.
Frequently Asked Questions
Is Test Automation Worth It in the Early Stages of a Product?
Whether testing is automated or manual is initially a question of capacity and is often of secondary importance at the outset. It’s more important to consider testability right from the design phase, much like security. A system with testing capability keeps the effort manageable as complexity increases. If testability is ignored, the backlog grows with every additional line of code.
Why Does Testing for B2C Products Differ from Traditional Enterprise Software?
For an app in the App Store, quality directly determines whether the product is accepted; feedback comes back immediately. In the automotive supply industry, on the other hand, the finished vehicle is three steps away, and it takes effort to link the metrics of individual components to end-customer satisfaction. The target audience influences testing behavior more than the age of the company.
At what size does a startup need a dedicated testing role?
In the early stages, founders do the testing themselves; later, in an agile context, product owners take over from the customer’s perspective. A dedicated testing role isn’t necessary in every three-person startup, but it becomes evident in companies with 30, 40, or 50 employees. The driving force behind this: A bad release can quickly put you out of business.
How high should test coverage be?
Zero percent means that functioning software is a matter of luck and chance. However, achieving 100 percent doesn’t always make sense. Test coverage is a metric, not a goal. Metrics like lines of code or coverage highlight extremes but can be misleading if they’re the only things measured. Depending on the context, a completely different number might be the right one.
Why isn’t it enough for developers to test their own code?
A developer in the zone doesn’t automatically think about how to ensure consistent quality while creating code. This requires people who monitor critical points and roles that institutionalize this process; otherwise, testing depends on the goodwill of individuals. In most teams, testers are outnumbered and must speak up, even to management.
Should a tester be the final approval step before release?
No. As a “quality gate” through which everything is forced at the end, the role is weaker than when it’s embedded within the team itself. At Flix, the Agile Tester is an equal partner on the development team, coordinates closely with the Product Owner, and responds to changing requirements without compromising the intended outcome. Teams consist of six to eight, sometimes ten, people.
Does AI-generated code make testers obsolete?
No, in fact, the need is increasing. In many observations, generated code contains more errors and, relatively speaking, more critical errors than code written by humans. This means a large wave of (in some cases) poor-quality code is heading toward software testing. Being able to produce more doesn’t improve the outcome; it simply shifts the workload to those who have to test it.
Where does Vibe Coding make sense, and where doesn’t it?
For rapid prototyping and requirements engineering, the benefits are real: product owners can build prototypes faster even without deep technical knowledge, which reduces the back-and-forth about actual requirements. On the other hand, deploying untested, automatically generated code in a live enterprise architecture is not a good idea. The serious use of AI-powered tools in development should be kept separate from this.
