Searching for a software development company in London returns hundreds of firms whose websites say almost identical things: agile delivery, bespoke solutions, digital transformation, trusted partner. The marketing is nearly indistinguishable. The delivery is not.
What follows is a practical evaluation process — the questions that separate capable suppliers from confident ones, and the terms worth negotiating before you sign.
First, decide what kind of supplier you need
“Agency” covers several different business models, and picking the wrong type is a more common error than picking the wrong firm.
| Type | Best for | Watch out for |
|---|---|---|
| Full-service agency (30–200 staff) | Large, multi-discipline projects needing design, delivery and PM | Higher rates; your project may be staffed by juniors |
| Boutique studio (3–20 staff) | Focused builds where you want senior people actually writing code | Limited capacity; key-person risk |
| Offshore / nearshore firm | Budget-constrained work with clear, stable specifications | Timezone friction; specification must be tight |
| Freelance contractor | Well-defined single-workstream projects | No cover for illness; no second opinion |
Match the model to your reality. If your requirements are still forming, an offshore fixed-spec arrangement will fight you. If your spec is genuinely stable, paying London rates for discovery you do not need is waste.
The questions that actually reveal capability
Most evaluation questions invite rehearsed answers. These ones do not.
“Tell me about a project that went badly and what you changed afterwards.” Every firm with real delivery history has one. A supplier who claims otherwise is either new or not being straight with you. What you are listening for is a specific, unflattering, concrete answer — and evidence they changed a process because of it.
“Who exactly will write the code, and can I meet them?” The classic agency failure mode is selling with seniors and delivering with juniors. Ask for names, seniority, and whether they are shared across other accounts. Get the answer in writing.
“What is the riskiest part of my project?” A supplier who has genuinely thought about your brief will name something specific — a hard integration, an unclear data model, an unproven volume assumption. “Nothing, it's all straightforward” means they have not looked properly.
“What happens if we want to stop after phase one?” The answer tells you whether you are buying software or entering a dependency. You want: you own the code, you get the repository, we document the handover.
“How will I know progress is real?” Good answer: working software in a staging environment you can use, every one or two weeks. Weak answer: percentage-complete reports and status decks.
What to check before the meeting
- Companies House. Free, instant, and revealing: incorporation date, filing history, and whether accounts are overdue. A firm about to fail files late.
- Real, verifiable work. Ask for live URLs or shipped apps, not just case-study PDFs. Then use them.
- References you choose. Ask for three past clients and pick which to call — not the one they nominate. Ask each: what went wrong, and how did they handle it?
- Team stability. High churn on LinkedIn means the people who understand your system may not be there in a year.
Comparing quotes without being misled
Quotes for the same brief routinely vary by a factor of three. Before assuming the cheapest is the bargain, normalise them:
- List exclusions side by side. Discovery, design, testing, deployment, documentation, handover, post-launch support, project management — who includes what?
- Convert to day rate and days. A £30,000 quote at 40 days versus £45,000 at 75 days are not the same purchase.
- Ask what would make it cost more. Honest suppliers name conditions. Suppliers who say “nothing” issue change requests later.
- Check the payment schedule. Milestone-linked payments align incentives. Large upfront percentages transfer all the risk to you.
If you want an independent sanity check on the number before you compare, our cost estimator gives a neutral range by project type and complexity.
Contract terms worth insisting on
IP assignment on payment. You own the code once you have paid for it. This should be explicit, not implied.
Repository access from day one. Not at the end. You should be able to see commits as they happen, and you keep access if the relationship ends.
Infrastructure in your name. Hosting, domains, and app store accounts should belong to your company, with the agency granted access. The reverse is a hostage situation waiting to happen.
A defined exit. What handover includes: documentation, credentials, a walkthrough, and a support window. Agree it while everyone is friendly.
Named-person continuity. If a key developer leaves, what is the replacement and ramp-up commitment?
Warning signs
Walk away from: a fixed price quoted without discovery on a complex brief; unwillingness to name the delivery team; reluctance to give you repository access; case studies with no verifiable live product; pressure to sign before you have finished due diligence; and any arrangement where the supplier owns your hosting or domain.
One more, subtler signal: an agency that agrees with everything. The supplier who pushes back on part of your brief — who says “that feature will cost more than it earns you, here is a cheaper way to test it” — is showing you exactly the judgement you are paying for.
A sensible way to start
De-risk the relationship before committing the whole budget. Commission a small paid discovery phase — typically one to two weeks — producing a technical approach, a scoped backlog, and a firmer estimate. You end up with a document you own and can take elsewhere, and you have watched them work before signing for six months. Most good agencies will suggest this themselves.