How to Hire a Developer to Build Your MVP
Shortlisting, comparing proposals, spotting the agency that sells with seniors and delivers with juniors, and getting ownership in writing — the full hiring process, written from the side that receives the brief.
The hardest part of hiring a developer isn't finding one. It's that every candidate sounds equally confident, the quotes differ by 5x, and you have no way to tell which difference is skill and which is sales.
I'm on the receiving end of these briefs. I've seen what a good one looks like and what happens to founders who send a bad one to ten people and pick the cheapest reply. This guide is the process I'd use if I were doing the hiring: how to shortlist, how to make proposals comparable, what to actually read in them, and what has to be signed before money moves.
If you haven't scoped yet, do that first — the founder's MVP guide covers it. Hiring before you've cut scope means paying someone to help you decide what to build, at build rates.
Decide what you're actually buying
"A developer" is four different products:
| Option | What you get | Where it goes wrong |
|---|---|---|
| Agency | A team, a process, continuity, a project manager | Sold by seniors, built by juniors; overhead you fund |
| Freelancer / solo dev | Direct access to the person building it, less overhead | Single point of failure; capacity limits |
| Technical co-founder | Someone with real skin in the game | Slow to find, permanent, hard to reverse |
| Offshore team | Lower rate | Time-zone lag, communication cost, quality variance |
None is universally right. Agency, freelancer or technical co-founder works through which fits which situation — including the offshore question, where the real variable turns out to be time-zone overlap rather than skill or rate.
Write one spec and send the same one to everyone
This is the highest-leverage thing in the entire process and almost nobody does it.
Write a single page containing:
- The core user workflow, start to finish, in plain sentences.
- Who the users are and roughly how many you expect in month one.
- Anything that must integrate (payments, email, a CRM, an existing system).
- Your hard constraints — deadline, budget range, platform.
- The success criterion: what makes this a win.
Send that identical page to three candidates. Now the proposals are comparable, and — more usefully — the differences between them are information about the candidates, not about the brief. When one person's estimate is triple another's for the same page, one of them has understood something the other hasn't. Your job is to find out which.
Read proposals for what's excluded
Most founders read proposals for price and timeline. Read them for exclusions and assumptions instead.
A proposal worth taking seriously states:
- What's included, specifically.
- What's explicitly not included.
- The assumptions the estimate rests on.
- How change requests get priced and approved.
- What you receive at the end.
A proposal that's all inclusions and no exclusions isn't a plan, it's a brochure. The clarity of the proposal predicts the clarity of the project — that correlation has held every time I've seen it from either side.
Red flags in a development proposal is the detailed list.
Judge the thinking, not the tech answers
You can't assess code. You can assess reasoning, and reasoning is the better predictor anyway.
The single best question to ask:
"If you had to cut 40% of this feature list, what would you remove and why?"
A weak candidate says "whatever you prefer." A strong one names three features and explains which assumption each one fails to test. Someone who enthusiastically agrees to your entire wish list in the first meeting is telling you they will build whatever you say — which sounds like service and is actually the most expensive trait a developer can have.
The questions to ask before you hire has the full set, including what good and bad answers sound like for each.
Verify the work, not the portfolio
Screenshots prove nothing. Ask for:
- Live products you can use yourself. A URL you can open and click through.
- Which parts they personally built. On team projects, "we built this" can mean almost anything.
- Two founder references who'll take a call. Hesitation here is the answer.
When you get the references, ask about behaviour under pressure, not general satisfaction: Did they stay on budget? Did they push back when you were wrong? What happened when something broke? Would you hire them again?
How to vet a developer when you can't code is the full method, including how to sanity-check technical claims without technical skills.
Find out who is actually going to build it
Agencies commonly sell with senior engineers and staff with junior ones. This is normal and not automatically bad — it's only bad when it's undisclosed.
Ask directly:
- Who is the lead engineer on this?
- Will they be on it for the whole project?
- Who attends the weekly calls?
- What happens if that person leaves mid-build?
Get names. A team that won't tell you who's writing your code is telling you something.
Settle ownership before the first payment
Non-negotiable, and cheaper to fix now than ever again:
- A present-tense IP assignment — the developer hereby assigns rights to your company, not "will assign."
- Source code, designs, documentation, database schemas, and infrastructure config all named explicitly.
- Any pre-existing libraries the developer owns disclosed, with a perpetual licence to you for what's included.
- Accounts created under your company from day one — GitHub, cloud, domain, database, third-party services — with the developer given access, not the reverse.
That last one is the practical protection that matters more than the paperwork. If everything is already in your name, a bad ending is an access revocation instead of a legal problem.
Who owns the source code goes through this properly. It is not legal advice — get a lawyer for the contract itself — but it tells you what to insist on.
Structure payment in milestones
Never pay everything upfront. Never agree to pay everything at the end either — that's an unreasonable ask and good developers won't want it.
Milestones tied to reviewable deliverables, with each one small enough that walking away costs you one milestone rather than the project. And make sure the final payment sits after handover, not before it. The handover checklist is what "handover" should mean.
Don't buy the cheapest quote
A $15,000 MVP that validates the idea is cheaper than a $7,000 MVP that has to be rebuilt. This isn't a line to justify higher rates — the failure mode is specific and common: an underpriced build gets delivered as something that technically demos but can't be extended, so the second developer quotes a rewrite and you've paid twice.
If the cheapest quote is dramatically lower, the honest move is to ask that candidate what they're assuming that the others aren't. Sometimes they've genuinely found a simpler path. Sometimes they haven't read the spec. The answer tells you which.
One thing worth paying for separately
If you're non-technical, paying an independent senior engineer for a few hours to review the proposals before you sign is one of the highest-return expenses available to you. They will catch unrealistic estimates, ownership terms that should be renegotiated, and architecture choices that will cost you later — none of which you can see, and all of which are cheap to fix pre-signature.
Hire that person separately from whoever is bidding. Their value is in not being a candidate.
The short version
Cut scope first. Send one identical spec to three people. Read the exclusions. Ask what they'd remove. Check live products and call the references. Get ownership and accounts in your company's name before money moves. Pay in milestones. Don't buy on price.
If you'd like a proposal reviewed, or a straight answer on whether your scope is realistic for your budget, get in touch — including if the answer turns out to be that you don't need a custom build yet.