You Probably Don’t Need a Full-Time QA. But You Still Need QA
AI has changed how fast small teams can build.
A founder can now go from an idea to a working product in weeks — sometimes days. AI can write code, review it, generate tests, fix obvious issues, and help teams ship faster than ever.
And because of that, I keep hearing some version of:
“Do we even need QA anymore? AI can test the app.”
I think that's the wrong conclusion.
AI may reduce how much manual work is needed, but it doesn't remove the need for someone to independently question whether the product actually works the way a real user expects it to.
Because your customer isn't AI.
Your customer doesn't care how clean the code is.
They care that clicking Sync actually syncs something.
That changing a plan updates the correct price.
That an error tells them what went wrong instead of silently doing nothing.
That going back, changing their mind, refreshing the page, or doing something slightly differently doesn't break the entire flow.
Those are often the problems that hurt trust the most.
And they're not always obvious from looking at the code.
But I don't think every startup needs a full-time QA either.
This is where I think QA is changing.
Small teams shipping early products often don't have 40 hours of meaningful QA work every single week.
There might be a huge amount to test before launch.
Then very little for a few days.
Then another release that needs 15–20 hours of testing.
Then a quieter week again.
Hiring someone full-time just to keep running the same regression suite doesn't always make sense.
But going from:
“We don't need a full-time QA.”
to:
“We don't need QA.”
is a very different decision.
I think the better model for small teams is becoming:
QA Audit
Before launch, or before a major release, bring in someone with no internal assumptions about how the product is supposed to work.
Let them explore it like a new user, question the flows, try unexpected paths, and find the things the team stopped noticing months ago.
QA on Demand
Don't buy 40 hours every week because that's how QA has traditionally been hired.
Need 5 hours this week? Use 5.
Shipping a major feature next week? Maybe you need 20.
Nothing meaningful changed? Maybe you need none.
QA when the risk justifies it.
That's actually one of the reasons I'm building QAura around audits and on-demand QA instead of trying to sell every startup a full-time QA engineer.
AI is absolutely changing QA.
I just don't think the end result is no QA.
I think it's:
QA Audit. QA on Demand. Just don't choose no QA at all.
"Someone with no internal assumptions about how the product is supposed
to work" is the part that resonates most, testing my own tools solo, I
keep clicking through the flow I designed, which means I'm the worst
person to catch where a new user would actually get confused. I know
too much about what "should" happen.
The variable-workload point also matches what I'd guess is true for
most small teams, some weeks are all edge-case-hunting before a release,
other weeks there's nothing new to break. Paying for 40 flat hours
either way seems like the wrong shape for that reality regardless of
whether AI is in the picture.
Curious how a QA-on-demand model handles regression testing though,
audits and on-demand hours are great for "does this new feature work,"
but "did this change quietly break something three features away"
usually needs someone who already knows the product's history, not a
fresh pair of eyes each time.
Fair point, and it's the real tradeoff here.
For "does this new thing work," fresh eyes help,someone new is more likely to break it in a way the team wouldn't think to try.
For "did this quietly break something three features away," you're right, a different person each time doesn't work. In practice, on demand doesn't mean a new tester every time. It's the same person engaged only when there's something worth testing, so the product history still builds up, just without paying for the dead weeks.
The other part is regression is where automation earns its keep. A lightweight suite built during an audit, then reused and expanded each time, handles a lot of the "did we break X" question on its own. That frees the human hours for judgment calls automation can't make.
The distinction between “no full-time QA” and “no QA” is easy to overlook. Curious what kinds of issues founders tend to discover first when someone external tests the product.
Great question. A few patterns show up almost every time:
Permission/role leaks — a user can see or do something they shouldn't (like accessing another account's data by changing a URL or ID). Internal teams rarely test this because they're always logged in as themselves.
Silent failures — an action looks like it worked (button clicked, page moved on) but nothing actually happened behind the scenes. The team doesn't catch it because they know the correct flow, so they never do the "wrong" thing that triggers it.
Edge cases in money/billing flows — canceling and re-subscribing, changing plans mid-cycle, refunds, these get tested once during build, then never touched again as the product evolves around them.
Broken "undo" paths — going back, refreshing mid-flow, changing your mind halfway through a form. Founders build for the happy path; testers try to break it on purpose.
The pattern behind all of these: the team is too close to their own product to accidentally do the "wrong" thing a real user does naturally. That's really the whole value of bringing in someone external, they don't know the "right way" to use it.
That pattern of “wrong” usage exposing things the team never sees is interesting. The billing and permission examples especially make sense because the happy path can hide a lot. If you’re open to continuing the conversation, what’s the best email to reach you at?
Same email we have talked before 😂
Ah yes 😂 I sent you an email a few weeks ago — might be worth checking your inbox when you get a chance.