You've got budget for one seat. The instinct is to reach for a developer, because that's what "building a product" sounds like. But knowing when to hire UX vs QA vs a developer isn't a default you pick — it's a diagnosis, and the symptoms are already sitting in your metrics and your support inbox.
Key takeaways
To decide whether to hire a developer, UX designer, or QA engineer first, diagnose which absence is costing you the most right now: a developer when work is understood but isn't shipping, UX when people can't use what already works, and QA when releases keep breaking in production.
The advice to "just hire a developer first" survives because it feels safe, not because it's true. The reason no fixed order holds up is that real team composition varies too wildly for any benchmark to dictate one.
Look at two data points that should be reconcilable and aren't. In a 2020 Nielsen Norman Group survey, the most common team ratio was 1 researcher to 5 designers to 50 developers, roughly 1:5:50, across 377 respondents [A1]. Fifty developers for every designer. Meanwhile, most Big Tech teams run no dedicated QA role at all, pushing quality onto the engineers who write the code; the exceptions are Apple and hardware teams where a bad ship can't be patched [C2]. So the "correct" staffing ranges from fifty devs per designer at one end to zero QA at the other. A number that swings that far can't hand you an order.
What survives the variance is directional, not precise: nearly everyone ends up with far more developers than designers, and QA headcount is genuinely optional depending on how you ship. So drop the search for a benchmark and judge on two axes instead: which absence is costing you the most right now, and how cheaply you can reverse the decision if you read it wrong. The rest of this is that diagnostic.
Decide by symptom, not by chart: hire a developer when work is understood but isn't shipping, UX when people can't use what already works, and QA when releases keep breaking in production. Whichever pain you recognize most is the role to hire first.
Each gap shows up as a distinct class of symptom. You don't need a framework to tell them apart; you need to be honest about which pain you actually recognize.
You're missing a developer when the thing doesn't exist fast enough. Features get designed, spec'd, agreed on — and then sit. The backlog grows faster than it clears. Every change routes through one person who has become the bottleneck for the whole product. The work is understood; it just isn't shipping.
You're missing UX when the thing exists but people can't use it. Users sign up and never reach the point where the product does anything for them. Support tickets skew toward "how do I…" rather than "it's broken." Churn clusters in the first days, before anyone's had time to outgrow you. And your demos only work because a human is narrating the flow — which means the flow can't narrate itself.
You're missing QA when the thing works until it doesn't, and you learn too late. Every release quietly breaks something that worked last week. Bugs reach you through annoyed users instead of a failing check. Your engineers spend more of the week firefighting regressions than building anything new, and nobody wants to deploy on a Friday. The quality work is happening — it's just happening in production, on your customers.
Read those honestly and usually one of them stings more than the others. That's your signal. The next four sections take each case seriously, including the one where the answer is "none of the above."
Sometimes the boring default is correct. If the product barely exists (a landing page, a prototype, a core that hasn't shipped), then there's nothing to design your way into and nothing to test. You can't fix an activation flow for a product with no activation, and you can't catch regressions in a codebase that hasn't stabilized enough to have any.
Pre-core, ship the thing first. A developer is the right first seat, and often the only one that makes sense, until there's a working product to react to. Forcing UX rigor or a QA process onto a team that hasn't put a core in front of real users is process for its own sake. The diagnostic below only starts to matter once something is live enough to generate symptoms.
Here's the trap that costs the most, because it disguises itself. An activation and comprehension problem looks exactly like a marketing problem from the top of the funnel: traffic comes, signups happen, growth stalls, so the reflex is to pour money into ads. You're buying more people to pour into a bucket that leaks at the same seam.
The numbers say that seam is common. Across 62 B2B companies, average user activation was 37.5%, with a median around 37% [B1]. Nearly two-thirds of the people who sign up never reach the product's value, and that's a design problem, not a traffic problem: the friction between signup and first value is what holds the number down. If that's your leak, another dollar of traffic doesn't fix anything; it just runs more people past the same wall.
The design-first camp goes further and argues you shouldn't wait for the symptom at all. Amplify Partners' Joshua Goldenberg, asked when to hire your first designer, says "As early as you can — the sooner, the better," because delaying just compounds design debt [D1]. High Alpha's Kolby McElvain made the same case back in 2017: "Hire a designer as one of your first employees" [D2]. Older advice, but it rhymes with the modern activation data. You don't have to buy the maximalist version to act on the symptom. If users can't figure out a product that technically works, the missing discipline is UX, and no amount of engineering throughput closes that gap.
The thing about not having QA is that you're already paying for QA — you just don't see the invoice, because it's charged to your developers' time. Every hour an engineer spends firefighting a regression is a quality-assurance hour, bought at builder rates and delivered after the bug already shipped.
The underlying principle is old and directionally sound: defects cost more the later you catch them, a pattern separately supported by NIST and Capers Jones. The popular "up to 100× more expensive in production" figure gets quoted as gospel, but it traces back to 1981 IBM training material and was never peer-reviewed, so treat the multiplier as a direction, not a measurement [C1]. The direction is enough to make the point: catching it after your users do is the expensive path.
Be honest about the other side, though. This is a judgment call, not a law. Most Big Tech teams run no dedicated QA and push quality onto engineers with tests and tooling, and they ship fine [C2]. So QA-first isn't a reflex; it's the right call in a specific situation — you ship fast and keep breaking production, especially if you're shipping AI-generated or vibe-coded features onto a codebase with no test net to catch what the model got subtly wrong (more on that in our vibe-coding piece). If that's you, the uninvoiced QA bill is already your largest line item.
The steelman that a symptom diagnosis has to survive: maybe the bottleneck isn't dev, UX, or QA at all. Maybe the product works, activates, and holds up — and nobody can find it.
Distribution is frequently the real first moat. As one analysis puts it, startups that win early aren't always better built, they're simply easier to find; roughly 22% of startups fail from ineffective marketing, and Steve Blank's line still lands: "There are no facts inside your building, so get outside" (Hira Ehtesham, Wellows, 2026) [F1]. If your activation is healthy, your releases are stable, and you still aren't growing, then adding a product-team seat is polishing a constraint that isn't binding. A diagnosis done honestly sometimes concludes: the missing role isn't on this team at all. Say so when it's true — it's the difference between a diagnostic and a sales funnel.
Turn the symptoms into a number. For each gap, put a figure on what it's costing you right now: revenue you're not closing because features don't ship, customers churning in week one because they never activated, engineering hours burned on regressions instead of roadmap. Then add the most expensive gap first. Not the most theoretically important one; the one bleeding the most today.
This works only because the decision is reversible, which is the entire point of doing it on-demand. The alternative, a full-time hire, commits you before you've learned anything: technical roles take a median of 75 days to fill [E1], and the process burns roughly $9,000 to $25,000 in scattered recruiter time, ads, tools, and interview hours [E2], all spent before you find out whether you even sequenced the roles right.
So make the small, reversible move. Pick the one symptom that's actually acute, hand that discipline a single real task, and judge the output; that's what the one-task trial is for. Then add the second seat once the first is clearly working and the pain has moved somewhere new. DevOD is built for exactly this: Dev, QA, and UX engineers on one subscription, and you add or change roles any month — $3,495/mo for a single stream, cancel any time, no lock-in — so "which one first" stops being a bet you're stuck with and becomes a sequence you adjust as you learn.
Which is the reframe worth keeping. Don't add the role a staffing chart would pick for the average company. Add the one whose absence you can feel.
Should you hire a developer, designer, or QA engineer first? There's no universal first role. Hire against the symptom that's costing you most: a developer when work is understood but isn't shipping, UX when a working product is hard to use, and QA when releases keep breaking in production.
How do you know if you need a UX designer? You need UX when the product technically works but users can't use it: signups never reach value, support tickets skew toward "how do I…", and churn clusters in the first days. Across 62 B2B companies, average user activation was just 37.5% [B1], so most sign-ups never reaching value is common.
When should a startup hire a QA engineer? Hire QA when you ship fast and keep breaking production, especially when shipping AI-generated or vibe-coded features onto a codebase with no test net [C1]. It's a judgment call, not a law. Most Big Tech teams run no dedicated QA role and push quality onto engineers instead [C2].
Is it ever right to hire a designer before a developer? Some argue yes: Amplify Partners' Joshua Goldenberg advises hiring your first designer "As early as you can" [D1], and High Alpha's Kolby McElvain said to "hire a designer as one of your first employees" [D2]. But if the product barely exists, a developer is usually the right first seat — there's nothing yet to design your way into.
What if the real problem isn't the product team? Sometimes it isn't. If your activation is healthy and your releases are stable but you still aren't growing, the missing role may be distribution (roughly 22% of startups fail from ineffective marketing [F1]), not dev, UX, or QA.
