Choosing a development partner is a decision most agencies make under time pressure, usually because a project has already been sold. That is the worst possible moment to be evaluating anyone, and it is why so many of these relationships end after one build.
The standard advice — look at their portfolio, read their reviews, check how long they have been trading — is not wrong, but it is weak. A portfolio shows you finished work under ideal conditions. It tells you nothing about what happens when an API changes mid-build or a client sends content three weeks late. What follows are the questions that discriminate better.
Ask what happens when a deadline is at risk
This is the single most useful question you can ask, and the answer is almost never in a proposal. Deadlines slip on web projects. The variable is not whether it happens but how you find out.
A good answer describes a specific mechanism: who tells you, how early, and what information comes with it. A weak answer is a reassurance that it does not happen. Push once, and if the second answer is still a reassurance, you have learned something important — you will be finding out about problems from your client.
Ask who owns the code and what happens if you stop working together
You want to hear that the repository is yours, the credentials are yours, and nothing is built on a proprietary framework only that partner can maintain. Proprietary frameworks are usually presented as a technical advantage. They are a commercial lock, and the cost lands on you the day you want to leave.
The practical version of this question: could another developer pick this project up next week and be productive within a week? If the honest answer requires the original builder to explain things, the documentation is decorative.
Ask for a fixed quote before you price it to your client
This one is commercial rather than technical, and it decides whether you can sell confidently. If you know the build cost before you quote, you know your margin at the point of sale. If you find out afterwards, you are absorbing the difference.
Open-ended time and materials arrangements can be appropriate for genuinely undefined work, but they move the risk of a bad estimate onto you. For a scoped website build there is no good reason you should carry that.
Ask what gets checked before anything reaches you
Your name goes on the work. That only works if the quality bar is written down rather than assumed. A partner who has thought about this can tell you specifically, without preparing:
- Which browsers and devices, and whether layouts are checked between breakpoints or only at them
- Whether Core Web Vitals are measured before handover or asserted afterwards
- Whether every form is actually submitted and every redirect actually followed
- Whether keyboard navigation and visible focus states are tested at all
- Which of the above gets dropped when a deadline is tight, and honestly, something usually does
Ask how they use AI, and listen for the shape of the answer
This is now a genuinely useful discriminator, because the answers split three ways. Some teams do not use AI tooling at all, which increasingly shows up in cost and turnaround. Some use it and pretend not to. Some use it deliberately and can tell you where.
The third answer is the one you want, and it should be specific. AI compresses the mechanical work — scaffolding, refactoring across many files, writing tests against existing behaviour, reading unfamiliar codebases and API documentation. It does not compress deciding what to build, choosing an architecture that survives the second round of requirements, or being accountable when something breaks in production.
Be sceptical of a productivity percentage. If a partner claims a specific number, ask how it was measured. Most of the figures circulating in this market are marketing rather than data. Our own position on where AI helps and where engineers stay accountable is deliberately specific about the split, because the vague version of this claim is worth nothing.
Ask about the second project, not the first
Anyone can do one good build. What you actually need is the fifth one to look like the first, delivered by whoever is available, with the same conventions and the same handover documentation, so your team is not relearning a codebase every time.
Ask whether the same people will work on your projects, whether there are documented conventions, and what happens when the person who built your last site is busy. A partner who has never thought about consistency across repeat work will produce five different sites.
Test with something small and real
The most reliable evaluation is a genuine project, small enough that being wrong is survivable and real enough that the answer means something. A pilot tells you what a proposal cannot: how they communicate mid-build, whether the estimate held, what the handover documentation actually looks like, and whether the quality checks they described happened.
Pick something with a real deadline and at least one awkward requirement. A perfectly clean brief tests nothing.
If you want to see how these questions are answered in practice, our approach to white label development for agencies sets out the NDA position, the communication rules and the quality checks in detail, and our agency model covers how a partnership moves from a first pilot to something ongoing.
