Start with the work you need done
A developer can be excellent and still be the wrong fit for your next stage. Building a prototype, taking over an existing application, and operating a mature product call for different experience. Write down the users, the business problem, the current state of the software, and the decisions you need help making.
Be clear about the role around the code. Does the engagement include product discovery, interface design, deployment, and handover? Who will make product decisions and review the work? A shared understanding here makes the rest of the evaluation more useful.
- Describe one important user journey from beginning to end.
- List existing systems and constraints the developer will inherit.
- Identify the responsibilities your own team can cover.
Look closely at something they have shipped
Ask for a walkthrough of a relevant product. The most useful part is the explanation: what the developer owned, what was difficult, which choices changed during the build, and what happened after launch. A polished screenshot is the start of that conversation.
Ask them to distinguish their own contribution from the team’s work. Discuss a difficult edge case, a trade-off, and a decision they would approach differently today. A clear account of constraints and learning gives you more evidence than a list of technologies.
| Ask to see | Then ask |
|---|---|
| One product journey they worked on | Which parts did you own, and what made this journey difficult? |
| A decision made during the build | What alternatives did you consider, and why did you choose this one? |
| A change after the first release | What did feedback or operating the product teach you? |
Use your own problem to discuss judgment
Share a real, bounded part of the project and ask how they would approach it. Explain what you know and where you are uncertain. Notice whether they ask about users, workflows, existing systems, and what success would look like.
You are looking for an understandable chain of reasoning. Why this approach? What alternatives were considered? Which assumptions need to be tested? An unfamiliar technical term should lead to a useful explanation, not end the discussion. A paid discovery session can be an appropriate next step when the problem needs deeper investigation.
Agree how you will see progress
A good engagement gives you regular opportunities to make informed decisions. Ask how working software will be demonstrated, where decisions will be recorded, and how changes to scope will be discussed. A progress update should tell you what changed, what was learned, and what needs your input.
Agree a review rhythm that fits the work. Some milestones can be judged through a working interface; others need a technical explanation or a test result. Make those expectations visible before the build gets busy.
Discuss the handover before the build
Find out where code and infrastructure will live, who controls the accounts, and what your team will need to run the product. Ask about documentation, deployment, maintenance, and the process for responding to defects. The commercial agreement should make responsibilities and ownership clear.
If your own team cannot assess the technical side, consider an independent technical reviewer for a significant engagement. Give that person a focused brief: assess the proposed approach and the risks relevant to this product.
Questions to take into the conversation
Use these questions to make the discussion concrete. The aim is to understand how you would work together, with enough evidence to make the next decision.
- What similar problem have you worked through, and what did you personally own?
- Which assumptions in our brief would you test first?
- What would you need from us each week?
- How will we review progress and agree changes?
- What does a production-ready release mean for this product?
- What will our team receive at handover?
- How would support work after launch?