How to vet a freelance developer before you hire
"Check their portfolio and read reviews" is the advice everyone gives and almost nobody finds useful, because it doesn't tell you what to actually look for. Here's what predicts a good engagement in practice.
1. Ask them to explain a past technical decision, not just show the result
Don't ask "what have you built" — ask "walk me through a decision you made on a recent project and why you made it that way." A developer who actually did the work can go deep here. Someone who was tangential to a project (or whose portfolio isn't fully their own work) usually can't sustain specifics beyond the first answer.
2. Give them a real, small piece of your actual problem
Instead of a generic take-home test, describe one real piece of your actual project and ask how they'd approach it. Their answer tells you more about fit than any portfolio review — you'll see how they think about tradeoffs specific to your situation, not a rehearsed answer.
3. Ask directly about communication cadence, before you need it
"How will you update me on progress?" — vague answers ("I'll keep you posted") are a weaker signal than specific ones ("daily WhatsApp note, or a demo at each milestone"). Set the expectation explicitly before work starts, not after a week of silence.
4. Verify they understand your engagement model, not just the technical scope
Confirm they're clear on how billing actually works — hourly logging, fixed-price milestones, whatever you've agreed — before the first day of work, in writing. Misalignment here is one of the most common sources of disputes, and it's entirely preventable upfront.
5. Ask what happens if something goes wrong
A specific, calm answer ("we scope carefully, but if a bug slips through I fix it at no charge within a reasonable window") is a good sign. Defensiveness or a vague non-answer to this question is worth noting.
The single best predictor across all of this: does this person ask you good questions back? Genuine expertise shows up as informed curiosity about your specific problem, not a rehearsed pitch.
FAQ
They can help, but references are self-selected by definition — weight them less than a live conversation where you can ask follow-up questions.
Not always, but combined with vague answers to scoping questions, it often is. Judge the answers, not just the price.
Code ownership terms and the engagement model (rate, billing cadence, what "done" means for each deliverable) — before any work starts.
Want to put these questions to us directly?
Ask anything from this list on a real scoping call — we'd rather you vet us properly than take our word for it.
Ask on WhatsApp