How to choose a software development company

Choosing a development company is a purchase most businesses make two or three times in their life, against sellers who make it every week. That asymmetry is the whole problem. You are shown finished work, quoted a rate, and asked to judge on impressions, and impressions are the one thing every firm in the market has already optimised.

What follows is the set of checks we would run if we were on the buying side. Some of them are uncomfortable to ask. All of them are cheap compared with the cost of finding out in month five.

1. Ask what happens to the code if you leave

Start here, because the answer reorganises everything else. Who owns the repository, where does it live, and what exactly do you receive on the day the relationship ends. A firm that answers immediately and specifically has done this before. A firm that treats it as a strange question is telling you that leaving is not a path they have built.

The good answer sounds boring: the repository is in your organisation account from the first commit, you have admin, and the handover is nothing more than removing their access. Anything that involves a migration, an export or a transition project at the end is a lock-in cost you are paying for in advance without seeing it on the quote.

2. Ask about the last project that went badly

Every firm with real history has one. The purpose is not to catch anyone out, it is to hear how they describe failure. Answers that put the entire cause on the client are a preview of the postmortem you will get. Answers that name a specific decision they made, and what they changed afterwards, are the ones worth trusting.

If a firm claims nothing has ever gone wrong, either they are new or they are managing you. Both are worth knowing.

3. Check whether they will scope before they quote

A fixed number produced from a two-page brief is not a price, it is a bid for the right to renegotiate later. The firms that finish on budget are usually the ones that insist on a paid scoping step first and are willing to lose the deal over it. That step is where the unknowns get converted into either a decision or an explicit risk, which is the argument in how to scope a software project before anyone writes code.

You should expect to pay for scoping. You should also expect to own the output and be free to take it elsewhere, which is the test of whether it was scoping or a sales artefact.

4. Ask what they do about supply chain risk

This is the check almost nobody runs and it has moved sharply up the list. Modern applications are mostly other people's code, and the industry's own risk ranking now reflects that: in the OWASP Top 10 for 2025, Software Supply Chain Failures appears as A03, alongside long-standing entries like Broken Access Control at A01 and Security Misconfiguration at A02.

So ask the direct version: how do you decide which third-party packages go into my system, and how will I know when one of them has a problem after you have gone. A firm with a real answer will describe dependency review and an update path. A firm without one will talk about how experienced the developers are, which is not the same thing and never has been.

5. Meet the people who will do the work

Not the founder, not the account manager. The person who will write the code and the person who will still be there in month six. Agencies rotate staff, which is legitimate, but you should know whether you are buying a named team or a slot in a queue.

One useful question: what else will this person be working on at the same time. Nobody is full-time on one project and pretending otherwise is how timelines slip quietly.

6. Ask what it costs to run, not just to build

The build price is the number everyone compares and the least useful one. Running cost is where a cheap build becomes an expensive decision, and it is estimable in advance rather than mysterious, as we set out in what a web app costs per month to run.

7. Sanity check the timeline against reality

If two firms quote six weeks and one quotes four months, the four month quote is not necessarily the slow one. It may be the only one that has counted the parts nobody demos: environments, data migration, review cycles on your side, and the fortnight that disappears into approvals. Most overruns are not engineering failures, they are the predictable consequences described in why software projects take so long, and a firm that has priced them in will say so out loud.

For a rough sense of what a realistic range looks like before you receive any quote at all, honest ranges for building a web app is a better anchor than the first number you are given.

What none of this tells you

These checks find the firms that will finish and hand over something maintainable. They do not tell you whether the thing is worth building, and that is the more expensive question. A well-executed system nobody needed is a worse outcome than a delayed one that mattered.

They also do not settle price. Development pricing is genuinely hard to compare across firms because the shapes differ, and the reasoning our colleagues at bdg-labs.com use in how to price a B2B service without guessing at the number is worth reading from the buyer's side too. It tells you what the person quoting you is actually solving for.

The short version

• Own the repository from commit one, and confirm it in writing.
• Pay for scoping and own the output.
• Ask how third-party dependencies are chosen and updated.
• Get the monthly running cost, not only the build price.
• Treat a much longer timeline as possible honesty rather than obvious inefficiency.

None of that requires technical knowledge to ask. It requires being willing to sit through the pause after the question, which is where most of the information actually is.