How to choose a software development company: a practical checklist

Before speaking to any vendor, write one page describing the problem, the people who will use the software and what success looks like in six months. It does not need to be technical. A clear brief lets you compare proposals like for like, and it quickly reveals which companies are listening and which are pitching a template.

Be honest about what you do not know. A good partner will help you fill the gaps; a poor one will quote confidently for a scope nobody has examined.

Many agencies are sold by senior people and delivered by whoever is available. Ask to meet the designers and engineers who would work on your project, and ask whether any part of the work will be subcontracted.

Continuity matters more than headcount. A small, stable team that stays with your product usually outperforms a large rotating one, because context is not lost every time someone changes.

Portfolios are easy to decorate. Ask for a live product you can click through, and ask what the team specifically did on it — strategy, design, engineering, or only one of those.

If most past work is confidential, that is normal, but a credible company can still walk you through its reasoning on a call: what was built, which trade-offs were made and what they would do differently.

The single best predictor of a smooth project is how often you see working software. Status reports and percentage-complete charts can look healthy right up until the deadline. Weekly or fortnightly demos on a real preview environment do not lie.

Ask how decisions are recorded, who you will speak to day to day and what happens when something slips.

You should own the source code, the design files and the accounts your product runs on — domain, hosting, app store listings and third-party services. Confirm this in the contract, including when ownership transfers.

Ask for repository access from the start of the project, not at the end. It costs the vendor nothing and protects you if the relationship ends.

The cheapest quote is often the one with the least thinking behind it. Compare what each proposal includes: discovery, design, testing, deployment, documentation, handover and support after launch. A lower price that leaves out testing and handover is not cheaper — it simply moves the cost to later.

Milestone-based payments tied to working deliverables align everyone's incentives far better than large upfront payments.

Software is never finished. Ask what support looks like after release: who fixes bugs, how quickly, and at what cost. Ask for documentation and a handover session so that your own team, or another vendor, could take over if needed.

A partner who is comfortable planning for their own replaceability is usually one you will want to keep.