Agency evaluations are almost always run backwards. Three hours of pitch deck, case studies, and methodology slides, then twenty minutes at the end with someone technical who asks about the stack.
Invert it. You can assess engineering capability in about an hour if you ask for artefacts rather than claims, and the artefacts are far harder to fake than a case study written in the passive voice.
Here is the sequence I would run.
1. Ask for a real pull request and read the review comments
Fifteen minutes, and it is the highest-signal thing available.
Ask them to bring a genuine PR from a recent project — sanitised as needed — and walk you through it, including the review discussion.
What you learn, none of which appears in a proposal:
- What their actual standard is, versus their stated standard. Everyone claims code review. Not everyone leaves substantive comments.
- Whether reviews are engineering or ceremony. "LGTM 👍" on a 600-line diff tells you review is a process gate rather than a quality mechanism.
- How disagreement is handled. A junior pushing back on a senior, and the discussion resolving on technical grounds, is one of the strongest positive signals you can observe.
- Whether they understand code they did not type. This is the one that matters most in 2026. There is a substantial difference between an engineer using AI assistance to move faster within a design they hold in their head, and one accepting generated code they cannot fully explain. The second produces a codebase that looks fine at handover and becomes unmaintainable within a year.
Ask about a specific block: why this approach here? Confident, specific reasoning is what you want. Vagueness about their own recent code is disqualifying, and it is a much better test of AI-tooling discipline than asking whether they use it.
2. Test strategy, with numbers
Ten minutes.
"What is your test strategy, and what was coverage on your last three projects?"
Good answer: specific figures, plus an opinion about what not to test. Maturity shows up as deliberate omission — "we don't unit-test thin controllers, we cover those at integration level" is the answer of someone who has thought about cost versus value.
Bad answer: a promise of comprehensive testing with no numbers. That is a sales response, and it usually means coverage is whatever it happened to be.
Follow-up worth asking: what breaks most often in the first month after a launch, and what did you change in your process because of it? A real answer describes a specific class of bug and a specific process change.
3. Architecture ownership, by name
Five minutes, and it settles a question that causes real damage later.
"Who makes architecture decisions on my project, and will they still be on it in month six?"
You want a name, and you want that name in the statement of work with a committed percentage. Senior people in the pitch and different people on the project is the single most common reason agency engagements disappoint, and it is a contracting failure rather than a market condition.
If they are proposing distributed delivery, the sharper version: where does the person making architecture calls physically sit, and how many hours of overlap will my team have with the engineers writing code? Four or more hours of overlap with genuine local technical authority works well. An account manager fronting a remote team with no technical decision-maker in your time zone is the arrangement most likely to disappoint, because nobody available to you can actually decide anything.
4. The failure question
Ten minutes.
"Describe a project that went badly and what you changed afterwards."
An agency with no bad project has either not done many or is not being straight with you. The useful answers are specific and slightly uncomfortable, and they end in a process change rather than a personnel change.
Listen for whether the lesson was institutionalised. "We now require X before starting Y" indicates an organisation that learns. "We were unlucky with that client" indicates one that does not.
5. Handover, asked early
Five minutes.
"What does handover look like if we bring this in-house next year?"
Ask this in the first technical conversation, not during contract negotiation. A good answer covers documentation, runbooks, a transition period, and does not get defensive. Discomfort here is informative — it suggests a commercial model that depends on you not being able to leave.
Related: who owns the code, the frameworks, and anything embedded in your repository. A licence-back to their internal framework is a dependency wearing the costume of efficiency.
6. Ask what is wrong with your brief
Ten minutes, and the best predictor in the whole process.
"What in my brief do you think is wrong?"
The strongest agencies push back before contract, not after. Total agreement in a first conversation means either nobody is being honest or nobody has read it carefully, and in both cases the disagreement is merely deferred to a point where it costs money.
I have never regretted hiring the team that challenged the brief. I have regretted the pleasant meetings.
7. AI tooling boundaries
Five minutes.
"How do you use AI tooling in delivery, and what do you not use it for?"
You want a considered boundary. Not enthusiasm — "we use it for everything" describes a team that has not yet been burned. Not prohibition — that is a team declining a real productivity improvement and charging you for the difference.
Good answers distinguish implementation from judgement: fast on scaffolding, integration code, test fixtures, migrations; deliberate and human on data model design, security boundaries, and anything where the failure mode is silent.
References: two questions only
When you take references, most of the value is in two questions:
- Did the estimates hold?
- Did the team in month six match the team in the pitch?
The second one surfaces more than any amount of case-study reading, because it tests the failure mode that no amount of technical assessment can detect in advance.
Full guide with 2026 UK rate tables, IR35 context, compliance requirements, and a six-week selection process: Software Development Agency UK: How to Choose the Right One in 2026.
We are on the other side of these conversations regularly at TechCirkle — custom software development and app development in the UK.
Frequently Asked Questions
What is the single most useful thing to ask an agency for?
A real pull request from a recent project, walked through including the review comments. It reveals their actual code review standard, whether review is engineering or ceremony, how technical disagreement is handled, and — most importantly now — whether engineers genuinely understand code they did not type themselves.
How can I tell if an agency uses AI tooling responsibly?
Ask them to explain a specific block in their own recent pull request. Confident, specific reasoning about why that approach was chosen indicates a team using assistance within a design they hold; vagueness about their own recent code indicates accepted output they cannot explain, which produces codebases that look fine at handover and degrade within a year.
What does a good answer about test strategy sound like?
Specific coverage figures for recent projects plus an opinion about what deliberately is not tested — for example covering thin controllers at integration level rather than with unit tests. A promise of comprehensive testing with no numbers is a sales answer and usually means coverage is whatever it happened to be.
Why insist on named architecture ownership?
Because senior staff in the pitch and different staff on the project is the most common reason these engagements disappoint, and it is a contracting failure rather than a market condition. Get the name in the statement of work with a committed percentage and a right to reject substitutions.
How do I evaluate a distributed or offshore delivery model?
Ask where the person making architecture decisions physically sits and how many hours of overlap your team will have with the engineers writing code. Four or more hours with genuine local technical authority works well. An account manager fronting a remote team with no local decision-maker means nobody available to you can actually decide anything.
Should I be concerned if an agency agrees with everything in my brief?
Yes. It means either nobody is being candid or nobody has read it closely, and the disagreement resurfaces later when it costs money. Asking what they think is wrong with your brief is the best single predictor in the process — the teams that challenge it are consistently the better hires.
When should I ask about handover and IP?
In the first technical conversation, not during contract negotiation. Good answers cover documentation, runbooks, and a transition period without defensiveness. Watch specifically for a licence-back to their internal framework rather than full assignment, which creates a dependency presented as efficiency.
Top comments (0)