Amine
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
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.
"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.
This is the highest-leverage thing in the entire process and almost nobody does it.
Write a single page containing:
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.
Most founders read proposals for price and timeline. Read them for exclusions and assumptions instead.
A proposal worth taking seriously states:
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.
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.
Screenshots prove nothing. Ask for:
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.
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:
Get names. A team that won't tell you who's writing your code is telling you something.
Non-negotiable, and cheaper to fix now than ever again:
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.
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.
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.
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.
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.
Four different products, not four prices for the same thing. What each option is actually good at, how each one fails, what an agency's overhead buys you, and where offshore genuinely fits.
Sixteen items, and how to verify each one without being able to read code. The test that proves a handover is real — and why commit history matters more than founders expect.
You can't read the code, so stop trying. Judge product thinking, process, and what they refuse to build — the eight things that actually predict whether a build succeeds, and how to check each one without technical skills.