How our startup survives without a QA team
No QA team does not mean no QA. Here is the setup that lets a small team ship with confidence: Vitest, Playwright, and an AI agent with Chrome DevTools MCP doing the manual pass.
We are a small startup with no dedicated QA team. That sounds risky until you look at how the work actually gets checked. “No QA team” is not the same as “no QA.” Quality is not a person we hand things to at the end, it is built into the workflow. Three things make that work: Vitest, Playwright, and an AI agent with Chrome DevTools MCP.
Engineers own quality, so it cannot be thrown over a wall
The first shift is cultural. Without a QA team to catch our mistakes, the person who writes a feature is the person responsible for proving it works. There is no throwing it over a wall for someone else to test. That sounds like pressure, but it is actually freeing: quality stops being a separate phase and becomes part of building. The tooling below is what makes that responsibility realistic instead of exhausting.
Vitest is the wide, fast base
Most bugs are logic bugs, and most logic bugs are cheap to catch with a fast unit test. Vitest runs on our Vite pipeline, so tests are quick enough to keep running while we code. This is the bottom of the pyramid: lots of small tests covering component behavior and edge cases, with near-instant feedback. A QA team should never have been spending its time on things a unit test catches in milliseconds anyway.
Playwright guards the flows that must not break
On top of that, Playwright covers the critical user journeys end to end in a real browser: booking, auth, the paths where a regression actually costs us. We keep these hermetic, with mocked network, seeded data, and isolated state, so they fail only when something is genuinely broken rather than at random. These are the tests that would otherwise be a human clicking through the same flow before every release, except they run on every commit and never get bored or skip a step.
The AI agent is our manual-QA pass
Here is the part that replaces the rest of what manual testing did. With Chrome DevTools MCP, the AI agent drives the app in a real browser: it navigates the feature, reads the console for errors, watches the network requests, and checks what actually rendered. Before a change merges, the agent does the exploratory pass a tester used to: does the flow work, are there console errors, did the API call succeed, does it look right. It is tireless, it runs the same thorough check every time, and it does it in minutes.
It also keeps the tests honest. AI is good at the tedious parts of testing: writing the unit test for a new branch, adding a Playwright case for a flow, spotting the assertion we forgot. That is how coverage keeps up with a fast-moving codebase instead of rotting the moment things get busy.
What this does not replace
I want to be honest about the limits. This setup catches broken behavior, regressions, console errors, and failed requests extremely well. It does not replace human judgment about whether a feature is actually good: is the flow confusing, is the copy clear, does it feel right on a real phone. So we still dogfood our own product and watch real usage, and our analytics tell us where people actually get stuck. AI and tests handle “does it work.” Humans still own “is it good.”
Why it works for a startup specifically
A QA team is a great thing to have and a hard thing to afford early. What we have instead is quality built into how every engineer works, backed by a fast test base, hermetic end-to-end coverage, and an AI agent that does the patient manual pass on every change. For a small team that has to move quickly, that combination is not a compromise. It is genuinely how we ship with confidence and very few people.