Hiring

How to choose a software development company

Comparing software development companies against a checklist

Every software development company says the same things: senior engineers, agile delivery, transparent communication, on time and on budget. None of it is falsifiable, which is exactly why everyone says it.

Useful evaluation means shifting from what you are told to what you can check. This is the list we would use if we were the ones buying.

Verify the company exists as it claims to

Start with the boring checks, because they are fast and they occasionally end the process on their own.

  • Look the company up in the public register. In the UK that is Companies House, which is free and shows incorporation date, filing history and whether accounts are overdue.
  • Check that the company you were quoted by is the company that will sign. Studios often contract through a different legal entity — that is normal, but it should be stated before you sign, not discovered afterwards.
  • Ask how long the team you met has worked together. A studio assembled per-project behaves very differently from one with a stable team, and neither is disqualifying, but the answer changes what you should expect.

Ask about the last project that went badly

This single question sorts studios faster than any other. Every team that has shipped anything has a project that overran, lost a key person, or shipped something the client did not want.

A good answer is specific and includes what they changed as a result. An answer of "we have never had one" means either they have not shipped much, or they are willing to tell you something untrue in a sales conversation — and you have learned something useful either way.

The questions that reveal how they actually work

When do I see working software?

The right answer is measured in days, not months. If the first demo is week six, you are buying a plan rather than a product, and you will not find out whether the plan was right until most of the budget is spent.

Who owns the code, and when?

You should own everything from the first commit — repository, cloud accounts, domains, CI. If ownership transfers "on final payment", that is leverage being built into the contract. Ask specifically about accounts as well as code: owning a repository you cannot deploy is not ownership.

What happens when scope changes?

Scope always changes. What matters is whether there is a defined process — a change order with a price and a date — or whether it is handled by goodwill until goodwill runs out. Fixed price should mean fixed price, so ask exactly what triggers a change order. Fixed price versus time and materials is worth understanding before this conversation.

Who is actually writing the code?

Meet them. It is common for the people in the sales call not to be the people on the project, and it is entirely reasonable to ask to speak to the engineers who would do the work. A studio that will not arrange this is telling you something.

What does handover look like?

Ask what you receive on the last day, and what happens if you take the project in-house afterwards. A team that has thought about being replaceable is usually a team worth keeping.

How to read the proposal

Cheap quotes are usually cheap because something was left out. These are the lines most often missing, and none of them are optional in reality.

LineWhy it mattersTypical share of build
Discovery and scopingA fixed price without it is a guess5–10%
QA and testingOtherwise you are the test team15–20%
Deployment and monitoring"It works on staging" is not shipped5–10%
Post-launch sprintReal users always force changes15–20%

A quote that is 40% below the others is rarely 40% more efficient. Compare what is included before you compare totals, and treat a missing line as a cost you will pay later rather than a saving.

Signals worth taking seriously

  1. They tell you something you did not want to hear during the sales process. A studio that says your scope is too big before you have paid them will say it again when it matters.
  2. They ask about your users and your commercial constraints, not just your feature list. Feature-list-only conversations produce feature-list-only software.
  3. They will connect you with a past client and leave the room.
  4. Their written scope is specific enough that you could hand it to someone else.
  5. They are clear about what they are not good at.

And the reverse: pressure to sign quickly, unwillingness to put estimates in writing, a portfolio of screenshots with no named clients, and "we do everything" in response to any question about specialism.

A shortlist is three, not ten

Talk to three studios with the same written scope. Ten conversations produce noise and decision fatigue; one produces no comparison at all. Three is enough to see the spread in price and interpretation, which is the information you are actually buying.

If it helps to see what a specific answer to these questions looks like, how we work sets out our process, and our case studies describe what was broken, what changed and where it ended up — including the parts that were harder than expected.

Frequently asked questions

How do I choose a software development company?

Shortlist three, give each the same written scope, and evaluate what you can verify rather than what you are told. Check the public company register, ask when you will first see working software, confirm you own the code and cloud accounts from the first commit, ask what triggers a change order, and ask about a project that went badly. Compare what each quote includes before comparing totals.

What should I ask a software development agency before signing?

When do I see working software running? Who owns the code and the cloud accounts, and from when? What triggers a change order? Who is actually writing the code, and can I meet them? What do I receive at handover? Tell me about a project that went badly and what you changed afterwards.

Why is one quote much cheaper than the others?

Almost always because something was left out. The lines most often missing are discovery and scoping, QA, deployment and monitoring, and the post-launch sprint — together roughly 40–60% of a realistic build. Ask every studio to price the same written scope so you are comparing the same work rather than different interpretations of it.

Should I own the code from the start?

Yes. Repository, cloud accounts, domains and CI should be in your name from the first commit. Ownership that transfers on final payment is leverage written into the contract. Ask about accounts specifically as well as code — owning a repository you cannot deploy is not meaningful ownership.

References

  1. Find and update company informationCompanies House

Keep reading

Planning the scope and cost of an MVP build
MVP

MVP Development Cost in the UK

Most MVP quotes are wrong for the same reason: they price a feature list instead of a decision. Here are the real UK ranges and what actually moves them.

Comparing a proof of concept, a prototype and an MVP
MVP

MVP vs Prototype vs Proof of Concept

Ordering the wrong one is the most expensive mistake in early product work. Each answers a different question — and only one of them is meant to have users.

An AI layer added alongside an existing product's services
AI

Adding AI to an Existing SaaS Product

The hard part is not the model. It is choosing which job to give it, and building the parts around it that decide whether anyone trusts the output.

Let's put it into production.

Book a 30-minute call — you'll walk away with a scope, a timeline and a fixed price.

Book a call