We watch this pattern repeat constantly: a founder hires a sharp generalist, gets a working AI MVP in three to six weeks, and then keeps that same person (or hires their clone) to take it to real scale, and it stalls. The skills that get an MVP shipped fast, breadth, speed, comfort with duct tape, are not the skills that keep a system reliable at ten thousand users with real cost and latency constraints, and treating them as the same hire is one of the most common and avoidable mistakes we see.
Why the same person often isn't the right fit for both
An MVP hire is optimized to answer 'can we make this work at all, fast.' That means tolerating hacks, skipping evals, hardcoding what should eventually be configurable, because speed to signal is the whole point. A v2 hire is optimized to answer 'can this survive real users, real volume, and real cost pressure,' which rewards exactly the instincts an MVP builder was told to suppress: writing evals before changing prompts, thinking about fallback paths, caring about the p95 latency, not just the demo latency.
How the brief should change
| Dimension | MVP hire | v2 hire |
|---|---|---|
| Primary skill | Breadth: can prototype across the stack fast | Depth: strong in evals, observability, or infra specifically |
| Time horizon | Days to weeks per iteration | Weeks to months, with regression discipline |
| Cost awareness | Secondary to proving the concept | A first-class constraint, tracked per request |
| Failure tolerance | High, fix forward fast | Low for production paths, must have fallback and monitoring |
| Best background | Startup generalist, fast shipper | Has taken at least one AI system through real scale before |
Deciding whether to keep your MVP builder
- Ask honestly: do they enjoy the reliability and cost-optimization work, or are they itching for the next zero-to-one build?
- Look at what they shipped in the MVP: was there any evidence of eval-mindedness even under time pressure? That's a good sign they can flex.
- If they're your only technical person, consider pairing them with a scale-focused hire rather than replacing them outright.
- Don't let loyalty or sunk cost make this decision for you, a mismatched v2 hire burns far more time than a hard conversation now.
Interviewing differently for the v2 hire
Test what actually predicts v2 success: hand the candidate a system with a subtly degraded output (say, an eval score that dropped without an obvious code change) and watch how they investigate. Strong v2 candidates reach for data and logs first; MVP-style generalists often reach for the prompt first, because that's the instinct that served them well at MVP stage. Neither instinct is wrong in the abstract, but only one of them is right for this hire.
A practical sequencing rule
- If your MVP is under three months old and barely has real users, don't hire the v2 profile yet, you'll bore them.
- If you have real usage and are seeing cost, latency, or reliability complaints, that's the signal to open the v2 brief.
- Write the v2 job description around the specific failure you're currently having, not a generic 'senior AI engineer' title.
- Use a scorecard that weighs evals, observability and cost tradeoffs explicitly, see our hiring scorecard template for the structure.
