Many founders, even in the testing space, ship products with obvious quality issues.
When I talk to them about testing, I often hear:
As testers, how do we make a strong business case for investing in testing early? Or do you also think testing isn’t essential for startups and early-stage companies?
I’d like to hear the perspectives of Club members.
I usually say something like this but in a nicer way that I can write down (and this works 90% of the time):
“Great! Can you write this on an email to me that “we don’t need it right” now so you take responsibility for it when things go wrong?”
And then they will obviously refuse and go into defensive mode, and you got them right where you want 
Then you start suggesting things you can do depending on the project.
EDIT: When I start writing, I keep writing Disclaimer, long post
Hi 
This is very important conversation & especially for new comers in testing to understand these conversations could be something that they might hear in their journey I was so lucky enough in my almost decade of testing experience the companies I worked with and working equally understand the importance of testing early and testing tools for that matter.
As a testers how do we make strong business case?
There is I believe only one way to make your business case strong is to show Data, speak statistically rather based on assumptions. i-e:
When there is data, it holds lots of values in the eyes of stakeholders. Correct data also shows whats that matter. There are different tools to capture such data.
Quite opposite actually. Testing is equally essential for startups and early stage as much as it is any established company. For established companies they need continuous monitoring based on Automation Maturity model.
I believe startups can adopt Automation Maturity Model lite as well on the scale of 1-5 where do they stand in terms of manual or automation and whats the need of the business. Because sometimes doing automation can be costly as compare to manual testing. I’d choose manual in that case and that too early as well in the cycle.
Thats my dream regardless of any company size or team, everyone take testing as core fundamental rather as granted! 
(This is another take away from my Podcast with Rosie)
I very much agree with @aimantirmizi , objective data is the most powerful tool to communicate. But I also at times along with @kristof have to communicate my concerns in a more assertive way, if what we do is treated almost with disrespect, even unconsciously.
A common quote I’ll give in the organisation to sceptics is “Well I didn’t create the role and hire myself. The business created the role, so if you don’t see the value you should really speak to my boss about that and I’ll be happy if you do”. I’m not going to be drawn into a discussion where I’m trying to justify my team or my personal existence a sit will become a dual 
.
But also our role makes a lot of us quite skilled tactical communicators. In those situations where there is scepticism around the need for testing, I’ll take the opportunity to prove it. I’ve always said, testers start testing by questioning. We can usually find a lot of issues in design and even the direction of the product roadmap. Being tactical communicators, once we’ve proven our point just let it sit there, don’t try and rub it in. You don’t need to force them to conclude testing is needed as you can end up defensive, just be prepared to repeat the proving process until there is a natural acceptance of the value the business is getting from a testers perspective.
An example of that was where, the team were building a prototype and didn’t feel they needed testing. So I volunteered when they thought they had something to have an informal look at it - as if I’m doing them a favour. I did a PQIP analysis of the prototype and the feedback that devs and product got from it was so powerful, the next phase of the prototype they asked us to do the same. Again very powerful feedback, to which I suggested “You know, we could do this earlier”.
yea sometimes I have to be very passive aggresive to get things done, otherwise they’ll just dust it off.
Which is very unfortunate but my “last resort” 
Thats the thing, if I feel there is intentional disrespect there, I’m not going to debate it - I’m going to end it leaving the ball in their court. I won’t make their problem, my problem. Like you say, its very rare and a last resort but when needed its a powerful message to coach people to engage with us the right way.
[quote=“parwalrahul, post:1, topic:86418”]
Or do you also think testing isn’t essential for startups and early-stage companies?
[/quote]
I think one of the things we have to do as Quality professionals is show why testing is important to the business and this is true whether it’s a start-up or an established business.
The challenge is telling the story of quality in a language that the business understands.
I had a hard time in my last role as the first QA in start-up because I didn’t quite know how to do this but also, I don’t think I was quite the right person for what the business needed at that time.
I think testing is important from an early stage, especially if you’re trying to sell a product as you need to get that customer buy-in and customers don’t want to invest in something that isn’t quality.
The way I would approach this is to link testing directly to business impact:
Bugs cost more later – fixing issues in production takes more time, money, and stress.
First impressions matter – new users who hit broken features may never return.
Poor quality slows growth – instead of building new features, the team fixes old problems.
Testing in a startup doesn’t need to be heavy or expensive. It’s about catching obvious issues before users do. That could mean:
A few automated tests for critical features.
Quick smoke tests before every release.
A simple checklist to confirm core flows work.
When founders see testing as protecting customers and the brand, not as “extra work,” they understand its value.
Often, convincing founders to invest in testing early is more about speaking their language: risks, costs, and customer trust. I usually put it like this:
Cost of Fixing – Any bug that glides into a live environment is far more costly to fix than if found at the beginning. Early testing saves in downstream cost.
Reputation Risk – For startups, your first users are your brand ambassadors. Hit them with obvious issues, and you may have also hit their trust and momentum.
Speed without Rework – Testing does not slow down development, it rather prevents the dramatically slow stop-start of putting out fires after release.
Rather than recommending a full-blown QA team from day one, I talk about right-sizing the testing: critical-path coverage first, automated smoke checks run on CI/CD, and a light triage system for bugs. Testing grows easier when it’s part of the workflow from the outset rather than attached later.
Hence, yes, early-stage companies must test; it just needs to be seen as investment for speedier growth and fewer hideous surprises than as testing for the sake of quality.
I would start with a scenario based approach. Asking them to assume that I am the founder or the CEO and I have developed a product that has visible quality issues. The end users are the other party and the app holds crucial information. Will they still use the product. Most likely, the answer is no.
Now think of another scenario. Would anyone sit in an airplane or a car that has known quality issues. The answer is again no because it risks their life. If people are not willing to risk their life with poor quality, then is it justifiable for a company to risk user trust by releasing a product with quality issues.
Having a lean team is one challenge. Not prioritizing quality is another.
A founder can always delay the release if safeguarding the user experience is kept as the top priority. There are plenty of examples where products launched with quality issues ended up meeting an unexpected fate. Threads by Meta is one such exampe. It was released with massive hype but eventually did not get the level of attention that was expected. While quality may not be the only reason, it shows how execution matters as much as the idea.
This is why instead of just convincing, I would prefer to show them what testing can bring to their product. A good visualization of the impact is far more powerful than words.
This.
IMO, these three topics tackles all aspects of the Project Management: time, cost and scope/quality.
What I do find hard to provide is objective data to support this:
If a manager said that they were not going to invest in testing because “We’re a lean team.” I would engage them in a discussion about what is “Lean”. It is a phrase that is much misused. “Lean” is an American description of Japanese production systems. The phrase comes from the work of an MIT researcher, who said that Japanese companies could do more than mass manufacturing with less resources. “Lean” includes improving quality, and testing helps to improve quality. “Lean” reduces cost by reducing waste. Improving quality reduces waste because there are fewer bugs. We have much to learn from Japan, and starting a conversation can be a way to help a manager see the value in testing.
Context is important. If this is a product that once released will have compliance or extremely high robustness expectations? Or is it like Pokémon GO where it’ll be massive despite being completely unstable & buggy because it has real user value? This helps frame the discussion.
Understand their objectives and ask how they’ll measure success and whether the product is good enough. Surely we need to test to discover this information?
I’d also be asking about expectations. I assume that at a minimum we need to know we’re delivering requirements so what’s the plan? What would be the implications of shipping and it doesn’t do the essentials? Are we okay with that risk?
Finally talk about tech debt. We’d most likely have to fix issues in time so what is our plan? How much later is later?
I often hear founders say, “We’ll test later” or “We’re too lean for this.” I get it — early-stage teams juggle a lot. But skipping testing early isn’t just about bugs; it’s about learning the wrong lessons from your users. A broken flow or confusing feature can mask what truly works.
To help founders see the value, I usually focus on:
Framing testing in business terms — it’s about saving time, avoiding costly mistakes, and protecting reputation.
Showing small, tangible wins — even one quick test that catches a major issue can shift perspectives.
Highlighting learning, not perfection — testing early gives clearer, more reliable feedback, helping the team make smarter product decisions.
For me, testing early isn’t about slowing down; it’s about moving faster with clarity. Investing in testing early isn’t just a “tech thing” — it’s a business decision
I’ve been trying to educate all kinds of business managers and execs about what quality is, why it matters, and why they need to invest in it for decades now! It is difficult and we should never give up.
I was lucky to work for a startup which was on the brink of failing. The business model depended on the software, and the software wasn’t getting delivered. This was back in 2003. The co-founders were smarter than any others I’ve met. They didn’t know anything about software, so they asked their friends who did. As a result, they hired Mike Cohn, and actually listened to him and agreed with everything he said. We got the time, training and support to learn and build a quality product. That company is still a success today.
I recommend the book Leading Quality by Ronald Cummings-John and Owais Peer. They had a failed startup and realized their problem was quality. It’s helpful in learning to talk the language of the biz people.
Sorry to digress but I got excited to learn about this Automation Maturity Model, but couldn’t find any helpful resources. Do you have some you can share?
Hi Elias, there was a case study from Atlassian, I will find the link and share with you. Meanwhile, I am sharing the image below where you might get some idea how the model should look like. This is the framework I have created that suited to my organisation.
They like costs. They specifically like cost saving.
You can build a cost calculation tool to show them the hourly cost impact of doing it later.
Thanks @aimantirmizi!
I found Maturity Assessment - Tricentis, but I don’t think that’s what you’re referring to.
In any case, the table you shared is a good starting point. Kind of like the TMMI levels but focused on test automation.
Just ask them how much they pay for insurances and if this seems fine to them.
Or as @martin.hynie said in his presentation “Convert uncertainties in risks” and show “how bad it can be”.
“We’ll focus on it later.” > “Later like when it’s too late ?”
“We don’t need it right now.” > “If you don’t need it right now, so when ? Once your product is shipped to prod ?”
But mine would be “Customers being testers often cost more than certified professional testers. If you know, you know.”.
