Hiring the wrong developer does not just cost you the project fee. It costs the months you spent, the launch you missed, and often a codebase the next person recommends throwing away.
I have inherited enough of those projects to recognise the patterns. This is what to look for, what to ask, and when to walk.
First: Be Honest About What You Are Buying
Before evaluating anyone, decide which of these you actually need — they attract different people at different prices:
- A pair of hands. You know exactly what to build and need someone to build it. Cheapest. Works only if your specification is genuinely complete.
- A technical partner. You know the business problem, not the solution. You need someone to push back, propose an architecture, and tell you when you are wrong. Costs more and is usually what founders actually need.
- A team. The work is bigger than one person. Now you are hiring for coordination as much as coding.
Most disappointment comes from paying for the first while expecting the second.
What to Actually Ask
Skip the technology quiz. You cannot evaluate the answers, and it tells you nothing about how they work. Ask these instead:
"Walk me through the hardest technical decision on a recent project."
You are listening for trade-offs. "We chose X because Y, though it meant giving up Z" is what experience sounds like. A feature list is not an answer.
"What would you do differently if you built it again?"
Everyone with real experience has an answer. "Nothing" means they have not reflected, or they are managing you.
"What could go wrong with my project?"
This is the most revealing question on the list. Someone who has shipped things will immediately name three risks. Someone who says "nothing, it is straightforward" has either not thought about it or is telling you what you want to hear — and both cost you later.
"What do you need from me to keep this on schedule?"
Good developers know that project delays are frequently client-side: slow feedback, late content, changing requirements. Someone who names this upfront is someone who has managed projects, not just written code.
"Show me something you built that is live."
Not screenshots. A URL you can open. Then ask what part of it was specifically theirs, because portfolios often include team projects.
The Seven Red Flags
1. They agree to everything.
Every real project has trade-offs. A developer who never pushes back either has not understood the requirements or intends to renegotiate once you are committed. Healthy disagreement early is a very good sign.
2. The quote is dramatically below everyone else.
Occasionally you find someone building their portfolio. Far more often it means inexperience, work being subcontracted to someone cheaper, or a deliberate underbid that becomes change requests later. If one quote is a third of the others, ask what they think the scope is — the answer usually explains the gap.
3. No questions about your business.
Someone who jumps straight to technology without asking who your users are or how you make money will build exactly what you said and not what you needed.
4. Vague timelines.
"A few weeks" is not an estimate. You want milestones with dates and demonstrable deliverables. Not because the dates will all hold, but because the exercise of producing them proves they have thought the work through.
5. They will not use your repository.
Code must live in an account you control from day one. Anyone insisting on holding it until final payment is creating leverage over you. Milestone payments are the fair way to manage payment risk, not hostage-taking your codebase.
6. No contract, or a contract with no IP clause.
It must state explicitly that you own the deliverables. Without it, ownership can default to the author in many jurisdictions. This becomes a serious problem exactly when it is most expensive — during due diligence, or a dispute.
7. Communication is already slow.
If replies take days before you have paid anything, that is the best it will ever be. Responsiveness during the sales conversation is the most reliable predictor of responsiveness during the project.
What a Fair Arrangement Looks Like
- Staged payments. 20–30% to start, then tied to deliverables you can see. Neither side carries all the risk.
- Your repository, from day one. You should be able to see progress commit by commit.
- A written scope with an explicit "not included" section. That second list prevents most disputes.
- A change process. Additions are fine — they should just have a stated cost and time impact rather than arriving free and unacknowledged.
- Explicit IP assignment in writing.
- An agreed handover: documentation, credentials, deployment instructions. Decide this at the start, not at the end.
Your Side of the Bargain
Uncomfortable but true: a meaningful share of failed projects fail on the client side. If you want a good outcome:
- Decide before you brief. Changing direction in week six is expensive in a way that changing it in week one is not.
- Respond quickly. A developer blocked waiting for your feedback is still costing you time.
- Share your real budget. Withholding it wastes both parties' time and produces proposals aimed at the wrong target.
- Accept that additions cost money. "While you are in there, could you also..." is a new requirement, not a favour.
The Shortest Useful Test
If you take one thing from this: ask what could go wrong with your project, and hire the person who gives you the most uncomfortable answer.
The developer who tells you your timeline is unrealistic, your scope is too large, or your idea has a flaw is the one who has done this before. The one who tells you it is all straightforward is the one you will be replacing in four months.
If you are evaluating people for a build right now, have a look at what I have shipped or send me your brief — I will tell you honestly what I think could go wrong with it, whether or not you end up working with me.