How to Choose a Software Development Company

What actually goes wrong

Ask anyone whose software project failed and you rarely hear a technical story. You hear that the scope was never written down, that the person who understood the business left, that six months passed with nothing usable to look at, or that the supplier vanished when a bug appeared after launch.

So evaluate suppliers for those failure modes rather than for their technology list. Almost any competent team can build with React and Django; far fewer will write a scope you can hold them to and show you working software every fortnight.

Ask for a written scope before you pay for a build

The single strongest signal is whether a supplier will produce a functional scope document before quoting a fixed price — and whether they are comfortable with you taking that document to another firm for comparison.

A supplier who quotes a large project from a one-page brief is either guessing or planning to recover margin through change requests. Either way you will discover it in month four.

Look for a scope that names the user roles, lists the screens, states which integrations are included, says explicitly what is out of scope, and specifies what happens when you request a change.

The eleven questions worth asking

Ask every supplier the same list and compare answers rather than proposals.

• Who exactly will work on this, and will we speak to them or to an account manager?
• Can we see something working every two weeks, in a staging environment we can log into?
• What is explicitly not included in this price?
• Which integrations have you verified are technically possible, and how?
• Who owns the source code, and when is the repository transferred?
• Whose name are the hosting, domain and third-party accounts in?
• What happens in the first month after launch, and what does it cost?
• What is your defect warranty, and what counts as a defect versus a change?
• Can we speak to a client whose project is comparable in size to ours?
• What happens if we want to move to another supplier in two years?
• Which part of this project are you most worried about?

Why the last question is the most revealing

A supplier who says nothing worries them has either not thought about your project or is not being straight with you. Every real project has an uncomfortable part — an integration that may not be possible, a data migration that depends on your data being cleaner than it probably is, a performance requirement that needs testing before anyone can promise it.

The answer you want identifies a genuine risk and describes how it will be handled early. That is what technical judgement sounds like.

Checking the portfolio properly

A grid of logos proves nothing. Ask for two things instead.

First, a case study with the problem, the constraints, what was built and what it changed — with numbers where the client permitted them. Vague outcomes usually mean there were none, or that the project belonged to somebody else.

Second, a reference call with a client at your scale. A firm whose references are all far larger or far smaller than you is not evidence about your project. And a firm that cannot produce any reference for a substantial project is telling you something.

Where confidentiality prevents naming clients, that is legitimate — but they should still be able to describe the work concretely and connect you to someone.

Warning signs in a proposal

• A fixed price for a large project with no discovery phase
• No named individuals, only a company and a process diagram
• Hosting or domain registered in the supplier's name
• Nothing about the source code or IP transfer
• A payment schedule loaded heavily at the start with no milestone tied to working software
• Guaranteed outcomes on things nobody controls — search rankings, user numbers, revenue
• A quote dramatically below the others, which almost always means a smaller scope
• Reluctance to discuss what happens after launch

Cheap, offshore and small: judging honestly

Cheaper is not automatically worse, and a large firm is not automatically safer. What matters is whether the arrangement matches the risk.

A small team gives you direct access to the people building your system and no account layer, at the cost of resilience if someone leaves — so ask how knowledge is documented and who else can pick up the work.

An offshore supplier changes cost and time-zone overlap. Ask specifically which hours are shared, how demos are scheduled, and whether anyone will ever be on site. A supplier who is straightforward about having no local office is more trustworthy than one implying a presence they lack.

A very low quote deserves a specific question: what have you excluded that the others included? There is always an answer.

How we try to pass our own test

Discovery first, producing a written scope you could take elsewhere. Fixed price against that scope. A working demo every fortnight in an environment you can log into. Direct contact with the engineer building your system. Source code, repository and credentials transferred on final payment, with hosting in your own name. Defect warranty after launch and optional month-to-month support.

And in discovery, we will tell you if an existing product fits you better than a custom build. Our software development page describes the process, and the custom-versus-off-the-shelf comparison covers that decision honestly.