How to choose a software development company

Red flags

I have hired and managed developers through agencies, as contractors and as employees. The warning signs tend to show up before any contract is signed, if you know where to look.

• A detailed quote before anyone asks who your customer is. A supplier who prices features without asking what problem they solve will build exactly what you asked for, including the mistakes.
• "Our team", with no names. You meet the senior people in the sales meeting, and someone you have never met does the work.
• Accounts in the supplier's name. Code repositories, domain names, cloud hosting or app store accounts set up by the supplier, for the supplier.
• Testing as an optional extra. Testing is part of building software properly, not an upgrade.
• Every answer is yes. A good supplier pushes back on scope and tells you what to leave out.
• Nothing to see until the end. Most of the payment due early, and no working software shown until the final delivery.
• No access to the code as it is written. You should be able to see progress in your own repository at any time.

One red flag is not always a deal breaker. Two or three together usually are.

Questions to ask

Ask these in the first serious conversation. The answers matter, and so does how comfortable the supplier is giving them.

• Who exactly will work on this, how senior are they, and how much of their week is ours? You are buying people's time and judgement, so know whose.
• How do changes reach production? Listen for code review, automated tests and a separate test environment. "We are careful" is not a process.
• How will we see progress? Working software every week or two beats a status report.
• What would you leave out of the first version? This shows whether they think about your customers or only about the build.
• What happens to the code and the accounts if we part ways? The only good answer is "they are already yours".
• Who looks after it after launch, and what does that cost? Software needs updates, monitoring and fixes for as long as it runs.
• Can we speak to a past client? Good suppliers have one or two ready, and are happy for you to call them.

How to compare quotes that differ tenfold

Quotes that differ tenfold are rarely quoting for the same thing. Before comparing prices, put the assumptions side by side:

A cheap quote usually leaves out testing, documentation, deployment and anything you did not think to mention. An expensive quote usually adds discovery, design and support, and sometimes features you do not need yet. Neither is right or wrong in itself. What matters is which assumptions match what you need.

Fixed price or time and materials? Fixed price is fair when the scope is small and clear, because the supplier can price the risk. Time and materials is fair when you are still discovering what to build, because nobody can honestly fix a price for the unknown. A sensible middle path is a fixed-price discovery phase, then time and materials with an agreed cap. That is also why an Innovation Build has a fixed length of four weeks: the scope is cut to fit the time, not the other way round.

Who owns the code and the accounts

This is easy to leave until it is too late, and easiest to get right at the start.

Under UK law, the author of a work is its first owner, and a computer program counts as a literary work. If an employee writes code in the course of their employment, their employer owns it unless they agree otherwise. Code written by a contractor or an agency is a different matter: it belongs to them unless they assign it to you. An assignment of copyright only takes effect if it is in writing and signed by, or on behalf of, the person assigning it.

Source: Copyright, Designs and Patents Act 1988, section 11 (first ownership) (opens in a new tab), correct as of 5 October 2026. Source: Copyright, Designs and Patents Act 1988, section 3 (computer programs as literary works) (opens in a new tab), correct as of 5 October 2026. Source: Copyright, Designs and Patents Act 1988, section 90 (assignment in writing) (opens in a new tab), correct as of 5 October 2026.

So the contract needs a clear, signed assignment of intellectual property to your company. I am not a lawyer, and a solicitor should check the wording, but the principle is not negotiable.

The accounts matter as much as the code. From day one, these should be in your company's name, with the supplier given access as a user:

• The code repository
• Domain names and DNS
• Cloud hosting
• App store developer accounts
• Email sending, analytics and any other paid service the product depends on

If a supplier already holds them, ask for the transfer now, while the relationship is good. Make a list of every account, who owns it and who can sign in. Get a written assignment for the work done so far. None of this needs to be confrontational. A good supplier will expect it.

When you need senior oversight, not more developers

Adding developers fixes a capacity problem. Many projects that feel slow have a direction problem instead, and more developers make that worse, faster.

Signs the problem is direction, not capacity:

• Deadlines slip even though everyone is busy.
• Features ship, but customers do not use them.
• Every estimate turns out to be a surprise.
• The same bugs keep coming back.
• You and your supplier disagree about what was agreed.

A fractional CTO works alongside your agency or freelancers on your side of the table. That means writing clear briefs, checking the work, making the architecture decisions and holding suppliers to what was agreed. I have run teams that mixed employees, agencies and contractors, and the mix works when someone senior owns the direction.

If you are not sure what you have, check before adding people. A Product Review tells you whether it is the right product, whether it is built well and whether it is ready, with a costed plan for what to fix first.