How to choose a software development company in the UK

Every software company's website says the same four things. Experienced team. Agile delivery. Bespoke solutions. Client-focused. Read six of them in a row and you will not be able to tell them apart, which is the problem: the thing you are trying to judge is the thing none of them will show you.

We are a software company, so take this with the appropriate pinch of salt. But we have also been on the buying side, and the questions below are the ones that actually separate people. Most of them are uncomfortable to ask, which is exactly why they work.

Ask to see something running Not a portfolio. Not a case study PDF. A URL you can open, or a screen share of the thing working, with real data in it.

Anyone can commission a portfolio page. Screenshots are cheap and mock-ups are cheaper. A live system is not, because it has to survive being looked at: the loading states, the empty states, what happens when you type something wrong into a form. That is where you see whether someone finishes things.

If the answer is "everything we build is under NDA", be careful. Some of it will be. All of it is unusual, and it is also the easiest possible thing to say.

Six questions, and what the answers tell you "Who is actually writing the code?" You want names and locations, not a team size. Plenty of UK agencies sell a London day rate and subcontract the work on. That is not automatically wrong, but you should know before you sign, not after, because it determines who you can talk to when something breaks at four in the afternoon.

"What happens when we change our minds in week six?" Everyone says Agile. The useful follow-up is mechanical: does a change go through a change request with a new fee, or is it absorbed? Both are legitimate. Not being told which one applies is not.

"What do you do that you would not put on the invoice?" Testing, documentation, code review, deployment scripts. If these are line items you can decline, you will be offered a cheaper quote that quietly removes the parts that make software maintainable. Ask what is included by default.

"Show me how you would hand this over." The answer tells you whether you are buying an asset or renting a dependency. Where does the code live? Whose hosting account? Whose domain? Who holds the keys? If the honest answer is that leaving would be difficult, price that in.

"What did you get wrong on your last project?" A team that cannot answer this either has not shipped much or is not being straight with you. Every real project has a decision someone would take back. You are listening for whether they noticed.

"What would make you turn this job down?" Anyone who would take any work at any budget is telling you something about how they will treat yours.

Reading a portfolio properly Look for the shape of the work, not the polish of the presentation.

Sector, honestly weighted. Similar industry helps, but it matters most where the rules are hard — finance, health, anything handling children's data. For a booking system or an internal tool, general competence beats sector familiarity.

The joins. Most business software fails at integrations, not features. Ask what they have connected to: payment providers, accounting systems, couriers, HMRC's Making Tax Digital endpoints. That is where the difficult work lives.

Longevity. Ask which of their projects is still running and who maintains it. Software that was delivered and then abandoned tells you about the relationship, not the code.

Something you can break. Open a live one on your phone. Fill in a form wrong. Rotate the screen. Three minutes of that is worth more than an hour of slides.

Security and GDPR: what to actually ask "We are GDPR compliant" is not an answer, because compliance is a property of your system and your processes, not of your supplier. Ask questions with concrete answers:

Where will the data physically live? UK or EU region, named. If they cannot tell you the region, they have not thought about it. Who on your team can see production data, and is that logged? The answer should be "almost nobody" and "yes". What is in place before launch? Encryption in transit and at rest, hashed passwords, rate limiting on anything public, backups that have actually been restored from at least once. What is the plan for a breach? UK GDPR gives you 72 hours to notify the ICO. That is a process, and it needs to exist before you need it. What data are we collecting that we do not need? A supplier who pushes back on collecting more is worth keeping. Data you do not hold cannot leak. Ask for the answers in writing. It is a reasonable request, and how someone reacts to it is informative.

Contracts: the three shapes, and the catch in each Fixed price gives you a number you can take to whoever signs the cheque. The catch is that the scope has to be pinned down first, so every change is a negotiation. It suits work that is genuinely well understood. It suits nobody who is still figuring out what they want.

Time and materials bills for hours worked. It is honest about the fact that software is discovered rather than specified, and it is the right shape for exploratory work. The catch is that the budget is open at the top unless you cap it. Always cap it.

Retainer buys ongoing capacity and, usually, a response time. It is the right shape once something is live. The catch is paying for a month in which nothing happened — which is, of course, exactly what you are paying for.

On support, get the response window in writing and be clear on what counts as urgent. "Twenty-four hours" means nothing if the clock only runs on weekdays and your business trades on Saturdays. And check the difference between response and resolution, because they are not the same promise.

What the money looks like Ranges vary enormously with scope, but for context, UK quotes tend to sit somewhere in these bands:

A focused internal tool that replaces a spreadsheet: low tens of thousands A customer-facing product with accounts, payments and an admin side: mid five figures upwards Anything touching regulated data or legacy integration: more, and the discovery matters more than the build estimate Treat any number given before a discovery conversation as a guess dressed as a quote. The useful signal is not the figure — it is whether the breakdown shows you what you are buying, line by line, before you commit.

Five things that should give you pause A quote with one number on it. You cannot approve, reduce or question a single figure. No questions asked back. A supplier who does not interrogate your brief will build exactly what you said, which is rarely what you meant. Pressure to sign this week. Discounts with expiry dates are a sales tactic, not a pricing model. Vagueness about who owns the code. This should be one sentence in the contract. If it takes a paragraph to explain, read it twice. Only good news in the update. Every project has weeks that go badly. Reports that never mention one are not reports. Frequently asked questions How do I check technical ability if I am not technical? You do not need to read code. Ask them to explain a past technical decision and why they chose it over the alternative. Clarity is the signal — anyone who genuinely understands a thing can explain it without jargon. If you want more certainty, pay an independent developer for two hours to sit in on one call.

Should I use a UK company or go offshore? Offshore can work well and is often cheaper per hour. The costs that do not appear on the quote are coordination: overlapping hours, the round trip on every question, and who is accountable if it goes wrong. If your project has a lot of unknowns, the time-zone overlap is worth real money. If the spec is settled and stable, it matters much less.

How long should it take? Most small-to-medium builds land between three and six months from first conversation to live. Be more suspicious of a very short estimate than a long one — the short one usually means testing and handover have quietly left the plan.

What happens after launch? Something always needs fixing in the first fortnight; that is normal, and it should be covered. Beyond that, agree what maintenance means before you need it. Software that nobody touches for a year is not stable, it is unattended — dependencies age and security patches stop being applied.

Can I start small? Yes, and you generally should. A paid discovery phase, or one small piece of the whole, tells you more about how someone works than any number of reference calls. It is the cheapest way to find out you have picked the wrong partner.

The short version Ask to see something running. Ask who writes the code. Ask what happens when you change your mind, what it costs to leave, and what they got wrong last time. Get the security answers in writing, cap the budget, and start with something small enough that being wrong is survivable.

If a supplier is good, none of these questions will bother them. Several of them will improve their answer.