How to choose a software development partner: 12 questions that matter

Before you contact anyone

Two pieces of preparation change the quality of every conversation that follows.

Write down the problem, not the solution. "We need a mobile app" is a solution. "Our engineers waste two hours a day on paperwork and we cannot see job status in real time" is a problem — and a good supplier may solve it more cheaply than you expected.

Decide your budget range and say it. Withholding budget is standard practice and it is counterproductive. A supplier who knows you have £60,000 will design the best possible £60,000 solution. One who is guessing will either over-scope and lose the work, or under-scope and disappoint you six months in.

The twelve questions

1. Who will actually write the code, and can I meet them? The classic bait-and-switch is a principal engineer in the pitch and juniors on delivery. Ask for names, seniority and location, and ask for it in the contract.
2. What does your discovery process produce? You want a written scope, architecture outline, risk list and estimate that you own outright. If discovery is free, it is a sales activity and will not be thorough.
3. What happens if the estimate turns out to be wrong? Every estimate is wrong to some degree. What matters is the mechanism: a change control process, a monthly review, a shared contingency. "That won't happen" is not an answer.
4. Who owns the IP and the source code? The answer must be you, in writing, with repository handover on completion. Ask specifically whether they use proprietary frameworks or licensed components you would be dependent on.
5. What documentation is a deliverable? Architecture notes, runbooks, deployment instructions, environment setup, decision records. If documentation is "available on request", it does not exist.
6. How do you test? Who does it — a dedicated QA function or the developer who wrote the feature? What is automated? Is there a regression suite? Ask what their release process looks like on a normal Tuesday.
7. How do I get released from this relationship? The single most revealing question. A confident supplier explains the handover process. An anxious one changes the subject.
8. What happens after launch? Get the support proposal alongside the build proposal, with response times and monthly cost. Discovering a £2,000/month retainer after launch is a nasty surprise.
9. Can I speak to a client whose project went badly? Every supplier with a real history has one. Willingness to introduce you is enormously informative — and the reference call will tell you how they behave under pressure, which is what you actually need to know.
10. What will you need from us, and when? Projects fail on client-side capacity as often as supplier performance. A good partner tells you upfront how much of your people's time they need.
11. What are the three biggest risks in this project? A supplier who cannot name three has not thought about it. Listen for whether they name real technical risks or generic platitudes about "scope creep".
12. What would you advise us not to build? The best answer any supplier can give. Anyone who agrees your entire wish list is essential is selling, not advising.

How to compare incomparable quotes

Quotes for the same brief routinely vary by 4x. That is almost never because one supplier is four times better. Normalise them before comparing:

Warning signs

• A fixed price with no discovery. Either they will cut corners or they have padded heavily. Sometimes both.
• No questions asked. If a supplier quotes without interrogating your brief, they are not planning to understand it.
• Everything is possible and nothing is a risk. Competence includes knowing what is hard.
• Case studies without named clients or verifiable outcomes. Anonymous claims cost nothing to invent.
• Pressure to sign before you have a written scope. Discount deadlines are a sales technique, not a commercial reality.
• Unwillingness to discuss handover or exit. The relationship should be retained on quality, not on lock-in.
• Testimonials you cannot trace. If the named person and company cannot be found anywhere, assume they do not exist.

A cheap way to de-risk it

Rather than committing to a full build on the strength of a pitch, buy a small piece of work first. A paid technical audit of your existing system, or a two-to-three-week discovery, costs a fraction of a build and tells you almost everything: how they communicate, whether they hit dates, how they write, whether they tell you inconvenient things, and whether their analysis is any good.

If the small engagement goes badly, you have learned it for a few thousand pounds instead of mid-build. If it goes well, you start the real project with a supplier who already understands your systems.

That is how we prefer to start too — see how we work, or tell us about your project.