How to choose a software development partner in the UK

Most advice on choosing a development partner is written by development partners, which is why it always concludes that you should look for communication, transparency and cultural fit. Nobody has ever put those on a shortlist and had them narrow it.

Here is what actually separates the supplier who delivers from the one who does not, in an order you can work through in about two weeks.

Decide what you are buying before you talk to anyone

There are three genuinely different purchases, and confusing them is the most expensive mistake in this process.

• A new product, where nothing exists yet and the requirements will change as you learn. What you need is a supplier who works in phases and can say what each phase excludes.
• Someone else’s half-finished codebase, where the previous team has gone. What you need is a supplier who does takeovers regularly, because the first month is archaeology and most teams are bad at it.
• An existing product that works and needs running, where the risk is not the build but the release process, the on-call and the slow accumulation of things nobody owns.

Suppliers are rarely equally good at all three. A firm that is excellent at new builds can be poor at inheriting code, because inheriting code rewards patience over speed and the incentives point the other way. Ask which of the three they do most, and listen for a straight answer rather than "all of them".

Onshore, nearshore and offshore is the wrong first question

It gets asked first because it is the easiest thing to have an opinion about. The variable that actually predicts outcomes is whether the people who scoped the work are the people who do the work.

At larger firms these are different populations by design: a principal or delivery lead runs discovery and writes the proposal, then the build goes to whoever is on the bench that month. That is not dishonesty, it is how a company of three hundred staffs projects. But it means the judgement you bought in the sales process is not the judgement that ships the code.

The question that surfaces this: "Will the people in this room be writing the code, and if not, when do I meet the ones who will?" A supplier who answers plainly, including "no, and here is how we handle the handover", is more trustworthy than one who implies continuity it cannot provide.

Read the code they have written, not the case studies they have written

Case studies are marketing documents. They are written after the fact by someone who was not in the difficult meetings, and the metric quoted is the one that moved.

Ask for something harder:

• A repository you can have someone technical look at, or a code sample from a real project with the client’s details removed.
• A pull request from a project that went wrong, and what the review comments said.
• The name and number of a client whose project did not go to plan. Every supplier with a real history has one. A supplier who says they do not either has no history or is managing you.

If you have no in-house technical person, this is the moment to pay an independent engineer for two hours. It is the cheapest insurance available in the entire process, and it will tell you more than six sales calls.

The estimate is a test, and most suppliers fail it

When you get a number back, the number is not the interesting part. What is interesting is what surrounds it.

A good estimate names its own assumptions and says which ones have been checked. It has a list of things this phase deliberately does not include. It says what would make the estimate wrong — specific things, like "we have assumed your payment provider’s sandbox behaves like production, and we have not verified that."

A weak estimate is a feature list with a total at the bottom and a confident tone. It will be wrong in the same direction every time, because nobody wrote down what they were unsure about, so nobody could plan for it.

We wrote about the numbers themselves separately, in our guide to what custom software actually costs. The short version: the band matters much less than whether the supplier can tell you why they are in it.

Check the boring things, because they are the ones that bite

Who owns the code

It should be you, in your own accounts, from the first commit. Not "on final payment", not in the supplier’s GitHub organisation, not on a cloud account they administer. If the relationship ends badly, ownership on paper is worth nothing if the deploy keys are somewhere you cannot reach.

What happens at the end

Ask what the offboarding looks like. A supplier who has thought about how you leave has thought about the relationship honestly. One who has never been asked will improvise, and you will find out what that means at the worst possible moment.

Who answers at 2am

For anything with real users, find out now. "We are UK hours" is a legitimate answer. Discovering it during an outage is not.

The contract’s change process

Every project changes. The question is whether changing it requires a renegotiation or is a normal Tuesday. Fixed-price contracts make change expensive and adversarial, which is why they so often end with both sides arguing about scope instead of building.

The UK-specific parts

A few things genuinely differ here and are worth checking rather than assuming.

• If you are handling personal data, UK GDPR and the Data Protection Act apply, and where the data physically sits matters. Ask where the databases and the backups live, not just where the company is registered.
• If you are selling to the public sector, ask whether they have delivered through a government framework. That experience is not interchangeable with commercial delivery and cannot be improvised.
• R&D tax relief may apply to qualifying development work. It is not the supplier’s job to claim it for you, but a supplier who has been through the process before can keep records in a way that makes your accountant’s job much easier.
• Check the company at Companies House. Filing history, how long they have existed, whether accounts are overdue. It takes four minutes and occasionally ends the conversation.

A shortlist that works

Three suppliers, not eight. Eight produces a spreadsheet nobody reads and a decision made on the last conversation you had.

1. Write down what you are buying, in the terms above — new build, takeover, or running something that exists.
2. Ask each for a scoping conversation, not a proposal. Notice who asks the harder questions rather than who is most enthusiastic.
3. Ask all three the same five questions and compare the answers side by side: what would make this estimate wrong, what does this phase exclude, who writes the code, who owns it, and what happens when we stop working together.
4. Pay one of them for a short paid discovery before committing to a build, if the project is large enough to justify it. A supplier unwilling to be evaluated on a small paid piece of work is telling you something.

The supplier you want is usually the one who made the project sound harder than you hoped. That is not pessimism. It is the only reliable signal that someone has done this before.

Where we sit in this

We are a custom software and AI development company, and we do all three of the purchases above — phased builds, takeovers of code someone else started, and running products after launch. We are also not the right answer for everyone reading this: if you need a two-hundred-person firm with a public-sector framework, that is a real requirement and we are not it.

If you want a straight read on which of the three you are actually buying, and what it would take, tell us what exists today and what you are trying to build.