How to choose a software partner
What to look for, which questions separate the serious from the salesy, and the warning signs worth walking away from.
Published
Commissioning software is one of the few purchases where you cannot see what you are buying. You buy a promise, and only months later does it become clear whether it held. So the choice is less about who gives the best presentation and more about what to recognise a partner by and more about who answers the awkward questions well.
Watch what they ask, not what they tell
The best signal in a first conversation is the direction of the questions. A firm that opens with technology is selling what it happens to know. A firm that digs into your process, your exceptions, and what currently goes wrong is trying to find where the money leaks first. That difference predicts more about the working relationship than any portfolio.
Five questions to always ask
- Who owns the code, and what happens if we want to leave? The answer should come without hesitation. And ask who you will actually be sitting across from.
- What is not in the quote? A quote without boundaries commits to nothing.
- Who actually does the work? Ask for names. The firm that sells and the team that builds are not always the same.
- What happens after delivery, who is reachable during an outage, and what does that cost?
- What technology do you build on, and why that? If the answer is an in-house framework, you are harder to hand over later.
Warning signs
- A fixed price for a question nobody has examined yet. That is not decisiveness, it is a risk that returns as additional work.
- Everything is possible. A firm that never pushes back is not thinking with you.
- References you are not allowed to call.
- Vagueness about code ownership, or licences on something built for you.
- No questions at all about what happens when things go wrong.
Large agency or small team
A large agency brings process, cover when someone is ill, and a solid contracts department. A small team brings short lines and the people who build it at the table. Neither is better; it depends on how costly a stall would be. In both cases you want to know who will still be on your project in a year, and whether that is written down or assumed.
Start small with the choice too
You do not have to award the whole engagement at once. A bounded first piece, fixed price, concrete deliverable, tells you in weeks what a procurement process cannot in months: how they communicate when something goes wrong, whether they hit dates, and whether the work holds up. It is the cheapest due diligence available.
Frequently asked
Should I request several quotes?
Two or three is sensible; more mostly creates work. Compare what is bounded rather than the totals: one prices the build only, another includes discovery, testing, and handover. Without that comparison the cheapest quote looks best while often promising least.
Is a nearby firm better?
Not automatically, but it helps in practice. Dropping by when something is unclear does more than a video call. It matters more the more complex your process is and the more people are involved.
How do I judge whether they are technically good?
If you are not technical yourself, you cannot, and you do not need to. Ask instead for a system they built and speak to that client. Ask what went wrong and how it was resolved. Every project hits trouble; the response says more than the trouble.
What if we want to stop halfway?
Agree that up front. With bounded phases, stopping is simple: you pay for the completed phase and keep what exists, code included. With one large engagement and no checkpoints, stopping is expensive, which is exactly why phases are worth insisting on.
Read next
- InsightsWhat does custom software cost?Where the money in a custom build actually goes, which choices move the price most, and how to judge a quote.
- ServicesCustom SoftwareA web application, portal or internal system that carries the work your package does not allow for, built around your process.
- InsightsBuild or buy: when custom software pays offA practical way to weigh off-the-shelf tools against a custom build, including the cases where buying clearly wins.