A product team of twelve. Six engineers, a designer, a product manager, and a founder who still answers support tickets on Sundays. The first QA hire is in the plan for next quarter.
It was in the plan for last quarter, too.
Meanwhile, releases go out every Thursday. Most of them are fine. Then one Thursday, a change to the pricing page breaks checkout for customers paying in euros, and it's a customer who notices. In the retro, someone asks the question that matters: "Who checked checkout before we shipped?"
The honest answer is that everyone assumed someone had.
This post is about the months before that first QA hire. Not about avoiding it — about covering the real risk while you wait, and setting things up so that when your QA engineer starts, they walk into a head start rather than an archaeology project.
The gap is longer than anyone plans for
The first QA hire almost always arrives later than intended. The role gets defined, re-scoped, approved, advertised, interviewed for. Three months becomes six without anyone deciding it should.
That's fine, as long as the gap is treated as a real period with a real plan. The problem is when it's treated as a pause, and the plan is "we'll sort testing out once the QA engineer is here".
Two things go wrong in that pause. Risk accumulates in the flows nobody is watching. And the knowledge a QA engineer will need — what matters, what's covered, what breaks — never gets written down, so the first hire spends their first two months reconstructing it.
Start with a risk list, not a test plan
The most valuable hour you can spend before a QA hire is writing down what would hurt most if it broke.
Not a test plan. Not a coverage target. A short, ranked list of the flows where a failure would cost money, trust or a customer:
| Flow | Why it matters | Risk |
|---|---|---|
| Checkout and payment | Every failure is lost revenue, and customers notice before you do | Critical |
| Sign-up and login | If people can't get in, nothing else matters | Critical |
| The core workflow | The one thing customers pay you for | Critical |
| Permissions and roles | A wrong permission is a data leak, not a bug | High |
| Emails and notifications | Silent failures that nobody reports | Medium |
| Data export | Rarely used, badly missed when broken | Medium |
Ten to fifteen rows is enough. Rank them honestly — Critical, High, Medium, Low — and put the list somewhere everyone can see it.
This list is the first thing your QA hire will ask for. Having it ready saves them a week. Having it wrong is fine; they'll improve it. Not having it at all means they have to interview the whole company to find out what matters.
Cover the top of the list, properly
With a ranked list, the question stops being "how much testing do we need?" and becomes "is each critical flow actually covered?"
For every flow marked Critical, aim for three things:
- A written test case in plain language. Describe what the user is trying to do and what should happen, not where they click. "Pay for an order with a saved card and receive a confirmation" survives a redesign; "click the blue button top right" doesn't.
- A small automated check that runs on every deploy. Not a full suite — one end-to-end path per critical flow, so a broken checkout fails the build instead of reaching a customer.
- A short pre-release checklist for what automation doesn't catch. Five minutes of a person actually using the flow on the build that's about to ship.
Ten critical flows covered well beats two hundred shallow tests. It's also a far better starting point for a QA engineer, who can build a real strategy on top of solid foundations rather than untangling a pile of tests nobody trusts.
Give each piece of QA work an interim owner
Some QA work doesn't belong to any one feature, so it drifts. Until your QA engineer joins, give each of these a named person, and say out loud that it's temporary:
- The release call. Who decides a build is ready, and what they check before saying so.
- Regression. Who makes sure last month's features still work, not just this week's.
- Test environments and data. Who keeps staging usable and the test accounts working.
- The flaky test. Who investigates it, instead of everyone re-running it.
Interim owners aren't a replacement for QA. They're a way of making sure nothing is silently unowned while you hire — and every one of these is a responsibility you'll hand to your QA engineer with a clear history attached.
Write it down the way a QA engineer will need it
The difference between a QA hire who is productive in week one and one who is productive in month three is almost entirely what was written down before they arrived.
A good handover is not long. It covers:
- The risk list, with what's covered for each flow and how.
- Known bugs and known workarounds — including the ones everyone has learned to live with.
- Environments and test accounts: where things run, how to log in as each role, what data exists.
- Recent incidents: what escaped, and why.
- Where the requirements live, and which ones have acceptance criteria worth testing against.
Signs it's time to hire now
The interim plan buys time. It doesn't make the hire optional, and a few signals say the time has run out:
- Releases are held back by nerves, not facts. People delay shipping because they're not sure, and nobody can say what would make them sure.
- The same kind of bug escapes twice. One escape is bad luck. The same class of escape twice means nobody owns that class of risk.
- Engineers spend release day testing. When building stops every Thursday so the team can click through the product, you're already paying for QA — just without the expertise.
- A customer asks for test evidence and it takes days. Enterprise customers, security reviews and regulated markets all ask. Answering well is a QA discipline.
- Flaky tests have become background noise. Once red builds stop being read, the automation you do have has stopped protecting you.
- The risk list keeps growing faster than the coverage. That's the clearest sign of all.
If three or more of these are true, the interim period is over.
What an interim plan can't do
It's worth being honest about the limits, because they're exactly what a QA engineer brings.
It only checks what somebody thought to check. A risk list and a checklist cover the failures you can imagine. Exploratory testing — deliberately finding the ones nobody imagined — is a skill, and it's the one that catches the bugs customers would have found.
It doesn't design tests across the edges. Boundary values, odd combinations, error paths, the second customer doing the same thing at the same time. Test design is a discipline, not a checklist.
Nobody sees the whole release. Interim owners each watch one piece. A QA engineer sees how the pieces interact, which is where most expensive bugs live.
Checklists get rubber-stamped. Five minutes of checking becomes one minute, then a tick. Without someone whose job is quality, the process slowly empties out while still looking complete.
Options for covering the gap
There's no single right answer, and most teams combine a few:
- Bring the hire forward. If the signals above are already true, the cheapest option is usually to stop waiting.
- A QA partner or a contract QA engineer for the interim. Experienced QA from day one, with the handover to your permanent hire built in.
- Tooling that turns your requirements into test cases and runs them. It speeds up coverage of the risk list, and gives your QA hire a head start when they join — as long as someone reviews what it produces.
- The interim plan above, done deliberately. A ranked risk list, covered critical flows, named owners and a written handover.
QA coverage before your first QA hire isn't a substitute for the hire. It's the down payment on it. The teams that get the most from their first QA engineer are the ones who started the work before that person arrived — so that on day one, the question isn't "what does this product do?" but "where should we take quality next?"
