Vetting is pattern matching — here are the patterns
A weak developer does not look weak in a sales call; they look great in a sales call. The questions below are chosen because they cannot be answered well without having actually done the work. Use them on anybody — including anyone you find through this site.
Process questions
1. "Walk me through your last project — what went wrong?"
Good: specific, owns at least one mistake, describes the correction. Bad: nothing went wrong, or everything went wrong because of the client.
2. "How do you handle scope changes mid-project?"
Good: a concrete mechanism — change requests priced before work, written approval. Bad: "we're flexible" (you will pay for that flexibility in an undefined way).
3. "What happens after launch?"
Good: a support window, a handover pack, an explicit maintenance posture. Bad: silence, or "that's extra" without structure.
4. "Who exactly does the work?"
Good: named people and their roles, however many or few. Bad: "the team," indefinitely.
Technical questions (no technical knowledge required)
5. "How will you make the site fast?"
Good: mentions measurable budgets (LCP under 2.5s) and a plan for images, code and hosting. Bad: "we optimise" or a plugin name, offered as a complete answer.
6. "What happens to our Google rankings when we relaunch?"
Good: redirect mapping, content parity, monitoring — volunteered without prompting. Bad: this question being treated as novel.
7. "Show me a site you built that runs a real business."
Good: live URLs you can check on your phone, ideally with contactable owners. Bad: screenshots, NDA walls around everything, or only demo work.
8. "What would you never build on this platform?"
Good: instant, specific limits — every strong developer knows where their tools stop being the right answer. Bad: the platform can do anything.
9. "How do you back up and test restores?"
Good: automated backups plus actual restore drills. Bad: backups exist; restore has never been tested. An untested backup is a hope, not a backup.
Ownership and exit questions
10. "Who owns the code and when?"
Good: you do, on payment — said without flinching. Bad: ownership transfers on final payment of the maintenance retainer, or licensing structures that surface late.
11. "If we part ways mid-project, what do we walk away with?"
Good: repo access from day one, so the answer is "everything so far." Bad: access granted on completion — this single answer has ended businesses.
12. "What's in your standard contract?"
Good: can summarise it from memory — milestones, IP, liability caps, cancellation. Bad: has never read it.
Reference questions
13. "Can I speak to your last two clients?"
Good: yes, unprompted caveats about NDAs aside. Bad: references available only after signing.
14. "What would those clients say was your weakness?"
Good: an honest, survivable answer. Bad: "nothing comes to mind."
The three red flags that end evaluations
- No version control / no repo access. Non-negotiable. A developer who cannot show you a Git repository in 2026 is not a developer you can exit cleanly, ever.
- Quotes without a written spec. Fixed prices with nothing fixed in writing is not a quote; it is a mood.
- Bad-mouths every past client. You are hearing your future from the other side.
Scorecard version: every "good" answer above is a point. Twelve-plus is a conversation worth having. Below eight, keep looking — the rates are known, and at these prices, vetting is the cheapest quality control you will ever buy.