How to choose a software development company: 12 questions

Comparing software proposals by price rarely works. Two offers for "the same" project usually describe different things, built by different people, with different assumptions about what happens when something changes.

The better way to compare is to ask questions that show how a company actually works. Here are twelve, grouped by what they reveal, together with the answers worth listening for.

Before you talk to anyone

Four things on one page will make every conversation more useful:

• The outcome you want, in business terms: less manual work, more enquiries, a process that runs faster.
• A realistic budget range. Suppliers can only propose a sensible scope if they know the frame.
• What absolutely has to exist in the first version, and what can wait.
• Who decides on your side, and how quickly they can answer questions.

How they work

• 1. Who will actually work on our project? Meet them before signing. The people in the sales meeting should not disappear once the contract is signed.
• 2. How do you decide what to build first? A good answer starts from the riskiest assumption and the most valuable outcome, not from the easiest screens.
• 3. How will we see progress? Look for working software you can open at regular intervals, not status reports.
• 4. What happens when priorities change? They will. The answer should describe a process, not a change-request penalty.

Ownership and risk

• 5. Who owns the code and the accounts? The answer should be your company: the repository, hosting, domains, app stores and analytics, in your name.
• 6. What does handover include? Documentation, access and a walkthrough, so another team could continue without starting over.
• 7. How do you handle our data and confidential information? Expect an NDA before details, a data processing agreement where personal data is involved, and access limited to what the work needs.
• 8. What happens if we part ways midway? A mature supplier has a clear answer, and it does not involve holding your code hostage.

Quality

• 9. How do you test? Ask about automated tests, review of every change and how releases are checked before they reach users.
• 10. How will we know it works after launch? Performance, accessibility, error monitoring and analytics on the key journeys should be part of the delivery, not extras.

After launch

• 11. Who maintains it, and on what terms? Security updates, fixes and improvements need an owner and agreed response times.
• 12. What will it cost to run every month? Hosting, licences, third-party services and support. A low build price can hide a high running cost.

Check references the useful way

A list of logos says little. A short conversation with a past client says a lot, if you ask the right things:

• Ask to speak with a client whose problem looked like yours, not simply the most famous one.
• Ask what went wrong during the project, and how the company handled it. Every project has problems; the answer shows character.
• Ask whether the client still works with them, and if not, why the collaboration ended.
• Look at a product that is live today, and ask what changed after launch.

Start with a small paid piece of work

The most reliable way to choose is to work together before committing to the whole project. A short paid discovery, an audit of an existing system or a clearly bounded first feature shows how a company communicates, how it handles ambiguity and what the quality of its work looks like, at a cost that is small compared with choosing wrong.

A good supplier will welcome this, and will make sure the result is useful to you even if you do not continue together.

Red flags

• Guaranteed results. Nobody can promise outcomes that depend on your market and your users.
• A fixed price for an unclear scope, without any discovery work. Someone is going to absorb that risk, usually you.
• Code or accounts kept under the supplier's name.
• You only ever speak to an account manager.
• No written scope, no list of assumptions and no list of what is excluded.

How to compare proposals

Put the proposals on the same basis before comparing numbers. Check that each one describes the same scope, lists its assumptions and exclusions, names the people involved, and includes the cost of running the system for the first year. The cheapest offer on paper is often the one that left the most out.