What to Look For in a Software Development Partner
Judging a supplier on evidence rather than on a pitch
Choosing who builds your software matters more than most of the technical decisions that follow. A capable supplier will correct a weak brief. A weak one will build exactly what you asked for, including the parts that were wrong.
The difficulty is that everyone presents well. What follows is how to get past that, based on the things that actually predict how a project goes.
Judge the questions, not the pitch
The strongest signal available is free, and it arrives in the first conversation.
A supplier who asks about your process, your exceptions, your existing systems and who makes decisions is working out whether they can help. One who spends the time describing their methodology is selling.
Pay particular attention to whether they ask anything difficult. “What happens to an order that is cancelled after dispatch” is a question from someone thinking about your business. “What is your budget” as the first question is a question about theirs.
Be wary of a supplier who agrees with everything. A brief always contains at least one thing worth challenging, and a partner who never challenges anything is either not reading closely or not willing to say so.
The questions worth asking them
About the work
What would you build first, and what would you leave out? A good answer is specific and slightly smaller than you expected. A supplier who wants to build everything at once is either inexperienced or selling scope.
What is most likely to go wrong here? Every project has a main risk, usually an integration or a piece of unknown data. A supplier who cannot name one has not thought about it.
What would make this cheaper? There is nearly always an answer. Unwillingness to find one is informative.
About what happens afterwards
Who owns the code? The answer should be you, in writing, without needing to ask twice.
What happens if we stop working together? Can you take the system elsewhere? Is it built on anything proprietary to them? A supplier confident in the relationship will answer this comfortably.
Where does it run, and whose account is it in? Infrastructure in your own cloud account, or clearly transferable to it, is worth insisting on.
What does a change cost after launch, and how quickly can it be made? The answer tells you what year two looks like.
About how they work
Who will actually do the work? The people in the meeting are not always the people on the project. Ask directly.
How often will we see something running? Regular working software beats regular status reports. Weekly or fortnightly is reasonable; monthly is slow; “at the end” is a warning.
What do you need from us, and how much of it? A supplier who says they need nothing is either not going to ask the questions that matter, or will ask them all at once at the worst moment.
About security
Worth asking even for internal tools, and the answers should be immediate rather than researched:
- How is access controlled, and can it be revoked straight away?
- Is two-factor authentication available?
- Where is the data held, and who can reach it?
- What happens if there is a breach?
Our own view on what good looks like here is set out in why secure authentication matters. The point for you is less the specific answers than whether they arrive without hesitation.
Signals worth taking seriously
A quote with no questions attached. Nobody can price work they have not understood. A number arriving without a conversation is a guess, and it will be revised.
A fixed price for an unclear scope. This sounds like safety and is usually the opposite. Either the scope gets defended narrowly when you need a change, or the price carries a large contingency you are paying for regardless.
Everything is easy. Experienced people know which parts are hard, and say so.
No interest in your existing systems. The integration is where projects slip, and a supplier not asking about it has not priced it.
Reluctance about the code or the accounts. Anything that makes leaving difficult is a commercial decision on their part, not a technical necessity.
A single point of contact who is also the only developer. Fine for a small piece of work, a real risk for anything you will depend on.
Things that matter less than people think
Company size. A larger supplier gives you continuity and process. A smaller one gives you the people who actually build it. Neither is inherently better, and the relevant question is who is doing your work rather than how many people they sit near.
Sector experience. Useful, and frequently overrated. Understanding your process matters more than having built something superficially similar elsewhere, and deep sector familiarity sometimes arrives with assumptions about how you ought to work.
The technology. For most business applications, several reasonable choices exist and the difference between them is far smaller than the difference between a supplier who understands your process and one who does not. Be more interested in whether the choice is mainstream and maintainable than in which one it is.
Set the first piece of work up to be small
The most reliable way to judge a supplier is to work with them on something contained. A first project with a clear boundary tells you more than any reference call: whether estimates hold, whether questions are good, whether problems get raised early or discovered late.
It also limits what a wrong choice costs. If it goes well, you have a working system and a supplier you understand. If it does not, you have lost weeks rather than a year.
This is the same argument as starting narrow for delivery reasons, covered in how long custom software takes, and it works for the same reason: small pieces of work produce information early, while decisions are still cheap.
Before you approach anyone
Write the brief first. It improves the quotes, it makes them comparable, and it lets you judge suppliers on how they respond to the same information rather than on how well each of them interviewed you. There is a structure you can copy in how to write a brief for a software project.