How to Vet a Developer Before You Hire Them
A nontechnical owner's guide to evaluating whether a freelancer, agency, or technical partner can safely own a real business outcome.
Who this is for
Established owners hiring for a business-critical website, software product, AI system, automation, integration, or rescue project without an internal technical leader.
You cannot reliably judge code in an interview, but you can evaluate reasoning, evidence, ownership, risk handling, communication, and the structure of a small paid test.
The short answer
Do not select from confidence and portfolios alone. Give candidates the same real scenario, ask how they reduce uncertainty and protect your control, verify references and artifacts, then start with a bounded paid assessment or milestone.
What to do in the first hour
- 1.Write the business outcome, current situation, important constraints, and unacceptable risks in one page. Avoid prescribing a full technical solution you cannot evaluate.
- 2.Decide which role you need: task execution, specialist advice, project delivery, or continuing technical ownership. A good candidate for one may be poor for another.
- 3.Prepare the same representative problem for every candidate so comparisons are fair.
- 4.Set your account-ownership, security, documentation, and communication expectations before pricing begins.
Diagnose before you buy another solution
Strong candidates ask about users, operations, data, existing systems, decision authority, failure cost, and success evidence before proposing technology. They can explain tradeoffs plainly and identify what they do not yet know.
Portfolios show that something existed, not who did the hard work or whether it operated well. Ask the candidate to walk through a difficult decision, a production failure, their individual contribution, and what they would do differently.
For rescue work, evaluate inspection discipline. The candidate should request read-only evidence and avoid certainty before seeing code, data, deployment, and contracts.
A practical recovery plan
Use a structured conversation
Ask every candidate to restate the business problem, identify the riskiest assumptions, propose a first milestone, explain acceptance evidence, describe ownership after launch, and name conditions that would change their recommendation.
Verify relevant proof
Contact references for comparable responsibility, not just similar technology. Ask whether the candidate surfaced bad news early, protected business access, completed handoff, handled incidents, and remained accountable after launch.
Run a small paid test
Commission a technical sanity check, architecture review, prototype of the hardest boundary, or repair of one contained workflow. Judge the artifact, reasoning, communication, and cleanliness of control—not speculative free work.
Contract for control
Use company-owned accounts and repositories, individual access, confidentiality, intellectual-property terms, milestone acceptance, change control, security expectations, backup and rollback requirements, and a practical termination handoff.
Match responsibility to economics
A cheap task marketplace can be reasonable for isolated, low-risk work with strong internal oversight. It is usually false economy for ambiguous, cross-system ownership where the buyer cannot technically supervise quality.
Questions to ask before approving more work
- What would you verify before telling me what to build?
- Tell me about a project where your first technical idea was wrong.
- How do you test authorization, data integrity, provider failure, and rollback?
- What access and documentation will the company have every week?
- What work should we deliberately not do?
Red flags
- — The candidate agrees with every requested feature without questioning outcomes.
- — They guarantee a precise timeline before discovery despite major unknowns.
- — They require production accounts, domains, or repositories to remain in their name.
- — They cannot distinguish logging in from authorization to another customer's data.
- — Their main proof is speed, AI usage, or a list of technologies rather than operated outcomes.
When to bring in specialist help
For sensitive or regulated work, have security, privacy, compliance, and legal specialists review requirements and contracts. Background and reference checks should follow applicable law and be proportional to the access being granted.