Every couple of months a founder asks me whether they should hire a QA team. The latest one was a startup whose whole team was provided by a consulting firm: a backend team, a frontend team, and a QA team. Regressions kept happening. Not because the engineers were bad, but because the founders pressed the team hard with deadlines all the time, and changed direction multiple times, leaving no room for cleaning up, introducing better abstractions, or paying tech debt.
So the consulting firm offered more QAs (in addition to the ones already writing integration tests and doing manual QA) to write the unit tests the development team didn't have time to build.
Like, I've seen this dynamic before, but when someone is trying to outsource unit tests it's very difficult for me to not picture the "we'll dig our way out" Simpsons meme.
That startup is an extreme case, but the reasoning that got them there is quite common. A startup grows, bugs increase, and someone (usually a founder, or a VP fresh from a bigger company) looks around at what "real companies" do and concludes they need a QA team. They hire some testers, maybe a QA lead, they add a "Ready for QA" column to the board. Three months later, releases that used to ship in days take weeks, and nobody is happier.
Most of the time, the company didn't have a quality problem, and the new QA team just made it worse.
The Doom Loop
Years ago I worked at a startup that had a proper QA team, and they were good: they would take pride in discovering edge cases the development team hadn't thought of, and in being super thorough with their test process.
It would take weeks for them to approve a release, which kept making the feedback loop slower. So the engineering and product teams would counter by including more work items in each release, which made testing even slower, and finding the code that broke something even more difficult because of the bigger batches of work. Which, of course, went to "prove" that we needed even more QA, and even slower releases.
And the worst part is that nobody was doing anything wrong: the testers were being thorough, the developers were trying to ship, and the loop kept feeding itself anyway.
Separate QA does something else: developers stop feeling responsible for quality. Why test edge cases when that's literally what the testers are paid to do? Why write thorough tests when QA will catch the bugs anyway? Testing becomes low-status work, the thing you throw over the wall. Follow that logic long enough and you get to my client, where the developers didn't even own their unit tests.
Meanwhile the tickets would go back and forth: dev finishes a feature, QA finds a bug, dev fixes it, QA finds another one, the fix breaks something from two weeks ago, and it keeps going until someone decides it's "good enough" and ships it anyway.
There's also a cost that doesn't show up in any ticket. When you write the code and the tests, the problem and the solution live in the same brain, and the loop (write, test, fail, fix) takes minutes. When the bug report comes from another team days later, you already moved on, so you patch it and move on again. Compare that with catching the problem while you're still designing, when you can "define the error out of existence", as John Ousterhout puts it.
What Big Tech Actually Does
There's this assumption that successful tech companies have armies of testers, that if you want to play in the big leagues you need dedicated QA. Microsoft pioneered the SDET role (Software Development Engineer in Test) in the 1990s and kept a 2:1 ratio of developers to SDETs. It was their thing. In 2014 they killed it, because teams shipping daily couldn't wait for a separate test role. Gergely Orosz described the transition:
"The Skype for Web team became a lot more productive by removing the SDET role."
They threw away tens of thousands of old tests written by the separate test team, rebuilt their test pyramid, and ended up improving quality, velocity, and engineer satisfaction at the same time. They didn't lay their testers off either: the former SDETs moved into software engineering roles and turned out to be unusually good engineers, with a knack for spotting edge cases. People who've spent years breaking software know where bugs hide. (If you already have QA people, that's the move: redeploy them.)
Uber and Netflix never had dedicated QA roles for their software teams, and neither has Meta. Google has an EngProd org that builds testing infrastructure, but the testing itself is done by the engineers who write the code. The ones still holding on to dedicated QA are Apple and Amazon, mostly for hardware and slow release cycles. So when a startup hires a QA team because "that's what companies do", it's copying a model that the companies it admires already abandoned.
QA Is a Mindset
Luca Rossi says QA is a mindset, not a role. I love that. It's about deciding what deserves attention, and that changes based on your product stage.
Pre-product-market-fit, the product changes constantly. Tests easily become a liability rather than an asset. Every test you write might need to be rewritten next week when you iterate or pivot.
Before writing a test I ask two things: how critical is this feature, and how often will it change. Stable behavior on an implementation that keeps evolving is the sweet spot, where the test catches regressions every time you refactor. And when behavior and implementation are both changing every week, the test is a liability: you'll spend more time updating it than it saves you.
The best teams I've worked with look more or less like this:
Engineers own quality. Whoever writes the code writes the tests, ships the feature, watches it in production, and fixes it when it breaks. There's no wall to throw anything over, so nothing gets thrown.
Bugs get fixed fast, even the low-priority ones. It's the broken windows theory applied to code: one unfixed bug signals that bugs are acceptable, and invites the next one. There's a practical bonus too: when your known defects are close to zero, every new bug stands out.
Integration tests over end-to-end tests. E2E is slow, it generates false positives that need a human to check them, and investigating a failed run often costs more than testing the thing manually. Integration tests catch most of what matters at a fraction of the maintenance. As Guillermo Rauch (fellow Argentine, Vercel founder, and the mind behind Next.js and v0) put it: "Write tests. Not too many. Mostly integration."
Testing in production, on purpose. Charity Majors, one of the loudest voices on observability:
"Testing in production is a superpower. It's our inability to acknowledge that we're doing it, and then invest in the tooling and training to do it safely, that's killing us."
Her point is that a staging environment can't reproduce production: real users, real infrastructure, real timing. So you make production safe to test in: feature flags, progressive rollouts, engineers on call for their own code, managers that think in error budgets instead of zero errors.
And the whole company gets involved. When I worked at Cascade, the product was a strategy product for big corporations, and we would use it internally too: to align work among our teams, to plan the OKR cycle, and to measure how the work of every engineer and product manager would contribute to organizational objectives. Living inside your own product means you feel something is broken before your customers do.
When Formal QA Makes Sense
Look, don't get me wrong: QA teams aren't always a mistake. There are contexts where they make sense:
- Highly regulated industries. Healthcare, aviation, automotive, where bugs cause compliance violations or physical harm.
- Core banking and payment infrastructure. Systems that actually move money between accounts. If you sit on top of Stripe or Mercado Pago, your payment provider handles the scary parts, and your bugs cause bad UX, not financial losses.
- Hardware products. Where you can't push an update after the device ships.
- Slow release cycles. If you ship quarterly or annually, a QA phase is less costly.
- Legacy codebases with little automated testing. If you inherited a mess with no tests, dedicated QA might be necessary while you dig out.
Notice what's not on the list: startups trying to find product-market fit.
The Question You Should Actually Ask
When a founder asks me whether they should hire a QA team, I ask what the problem is. "We're shipping too many bugs" is a symptom, not a problem, and hiring testers is the most expensive way of treating a symptom: not only you pay more salaries, you pay again in slower feedback loops. The causes live somewhere else, in planning, in training, in the architecture, in who owns quality. A QA team fixes none of them, and it actively makes it worse, because now somebody else officially owns quality.
There's a story in Art & Fear about a ceramics teacher who split his class in two: one half would be graded on the quantity of pots produced, the other half on quality. The best pots came out of the quantity group. While they churned out pots and learned from their mistakes, the quality group sat theorizing about perfection and ended up with little more than grandiose theories and a pile of dead clay.
So no, my client didn't need testers writing the developers' unit tests. The team needed room to make more pots.
