Ship your MVP before you make a single hire
The default order is hire, then build. Reversing it lowers your risk, saves your runway, and means that if you do hire, you hand them a working product instead of a blank page.
Summarize this article with AI
ChatGPT
Claude
PerplexityKey takeaways
- Building before hiring lowers risk, stretches runway, and de-risks the eventual hire.
- An MVP is the fastest honest test of the idea, not a fragile prototype or a six-month platform.
- Ship in weekly sprints with live demos, then make the hiring call from real usage.
The conventional sequence is to raise a bit, hire an engineer, and have them build the thing. It feels responsible. It's also the slowest and riskiest path at the exact moment you can least afford either.
Why build-first wins
- You learn before you commit. A shipped MVP tells you what users actually do. That's the single most valuable input into who, or whether, to hire.
- Your runway lasts longer. Weeks of build cost a fraction of a year of salary plus the hiring cycle that precedes it.
- You de-risk the hire. When you do bring someone in, they inherit a real product with real usage, not a vague spec and an empty repository.
- You can change your mind cheaply. If the idea needs a hard pivot, you pivot a project, not a person's employment.
Weeks to real user feedback
~26 wk
Hire, then build
Hiring cycle plus ramp before line one ships
~4 wk
Build first
A focused MVP in front of real users
What an MVP actually needs to be
Minimum and viable, both words doing work. It does the one thing that proves the idea, built well enough to put in front of real users and charge them if appropriate. It is not a no-code prototype that collapses under the tenth customer, and it is not a six-month platform. The skill is knowing what to leave out, which is exactly what experience buys you.
How we do it
We scope the smallest version that tests the real question, then ship in weekly sprints with a live demo at the end of each one. You see working software, not status decks, and you can redirect us the moment usage tells you something. We've put full platforms into production in days when the scope was tight and the decisions were fast.
The goal of an MVP is not to be small. It's to be the fastest honest test of whether the thing is worth building all the way.
Once it's live and learning, you're in a completely different position to make the hiring call. You know the stack, the scope, and the kind of engineer the next phase actually needs. That's a decision made from evidence instead of a guess made from a blank page.
