Choosing a supplier
How to choose a software development company
Most of the signals people use to judge a software company - the website, the price, the portfolio - don't predict much. Here's what does, and how to check it without being technical.
Choosing a software company is genuinely hard, and not because you’re missing something obvious. You can’t inspect the work before you buy it. By the time you know whether you chose well, you’re already committed, and usually several months and several thousand pounds in.
What makes it harder is that most of the signals people reach for don’t predict much. A good-looking website tells you someone hired a designer. A low price usually means the scope is narrower than you think. A high price doesn’t guarantee anything either. A portfolio tells you what got built, not how well it was built, how the project actually went, or whether the client would do it again.
This is a guide to the signals that do predict a good outcome, and how to check them without being an engineer.
A note on bias. I build software for a living, so I have an obvious interest in you hiring someone like me. I’ve tried to write this so it’s useful either way, including being honest about what makes a difficult client as well as a bad developer.
Who’s actually out there
Before you can choose well, it helps to know what you’re choosing between.
Freelance developers work alone. The range is enormous - from very experienced engineers to people learning on your project. Usually cheaper than an agency, and best for small, well-defined work or adding capacity to a team you already have. The main risk is continuity: if they’re ill, busy or take another job, the work stops.
One-person and boutique firms run from a single senior engineer through to perhaps fifteen people. The good ones give you senior experience and direct attention at the same time, which bigger agencies struggle to do - the founder is usually involved in delivery, and in the smallest firms delivers everything personally. The trade-off is the same continuity risk as a freelancer: if one person is unavailable, work pauses.
Whoever you choose, ask how they handle that - what’s written down, who owns the code and the accounts, and whether someone else could pick the work up. This is where I sit, so apply that test to me too.
Mid-size agencies are roughly fifteen to a hundred people, with project managers, account managers and specialist teams. More consistent than a small firm, but the person who sells the work is rarely the person who builds it. Suited to larger projects with a defined scope.
Large consultancies have hundreds or thousands of engineers. They’re the right answer for genuinely large programmes that need that scale. For most small and medium businesses, the overhead isn’t justified by the size of the job.
Offshore and nearshore teams cost less per day and add coordination overhead in exchange. They work best on well-specified projects where someone on your side has the time and the experience to manage the communication gap.
What actually predicts a good outcome
Technical competence at the right level
Obvious, but worth saying plainly: the single biggest factor is whether the people doing the work can do it well. Senior engineers make better structural decisions, write code that can be changed later, and see problems coming that junior engineers find afterwards. That shows up as fewer surprises, lower total cost and a system that’s still workable in three years.
The difficulty is that competence is hard to judge without technical knowledge. There are ways around that, and they’re further down.
Clear communication and honest expectations
Most failed software projects don’t fail technically. They fail because requirements weren’t understood, problems weren’t raised until they were crises, scope grew without anyone agreeing to it, or the timeline was never realistic.
A developer who asks good questions, is honest about what they don’t know yet and tells you about problems early will usually deliver a better result than a more technically gifted one who communicates badly.
Understanding of your business
Software that’s well built but doesn’t fit the business doesn’t help anyone. The people worth hiring spend time understanding what you do and who your customers are before proposing anything - and they’ll push back when what you’ve asked for isn’t what you need.
Ownership of the outcome
There’s a difference between someone who executes a list of requirements and someone who takes responsibility for whether the result works. The first is a contractor in the narrow sense. The second is what you’re actually trying to hire.
How to evaluate
1. Decide what you’re asking for
Before you contact anybody, get clear on the type of work, the rough scale, your timeline, your budget range, how involved you want to be, and whether this is a one-off build or the start of a long relationship. You don’t need a specification. You do need enough clarity that three different people would give you comparable answers.
2. Find candidates
The most reliable source is a referral from someone whose judgement you trust who has actually worked with them. After that, directories with verified client reviews - Clutch is the established one for software.
Searches and social media produce plenty of names at lower average quality. Aim for three to five to take seriously. Fewer than three and you’ve nothing to compare; more than five and you’re doing a lot of work for no extra insight.
3. Screen quickly
Before you spend real time on anyone, check: do they have relevant experience, are they the right size for your project, does their early communication give you confidence, and can they point you at real clients you could speak to? Anyone failing those doesn’t need a detailed evaluation.
4. Pay attention to the first conversation
This tells you more than anything else, if you’re watching the right things.
Do they ask good questions? Someone who asks in detail about your requirements, your users and your existing systems before proposing anything is trying to understand the problem. Someone who moves quickly to solutions and prices is prioritising the sale.
Are they honest about what they don’t know? Good engineers are clear about what will only become obvious after proper investigation. Be sceptical of confident quotes given without enough information - that’s either a guess or what you wanted to hear.
Do they push back on anything? Someone who agrees with everything is either too keen to win the work or not engaged enough to notice the problems. You want to be told things you’d rather not hear.
Can they explain clearly? Jargon used to impress rather than clarify is a warning. Explaining a technical decision in plain English is a sign of both communication skill and genuine understanding.
5. Assess technical capability without being technical
Interrogate the portfolio. Look for work similar to yours in type and complexity, still live, where the developer can talk specifically about the technical challenges and what they decided. Be wary of entries that are vague about what they personally did.
Speak to references, properly. Ask: did it deliver what was promised? Was it on time and on budget? How were problems handled? Would you work with them again, and why? What would you do differently? Be persistent - reluctance to give you references, or only carefully managed ones, tells you something.
Borrow a technical friend. If you know someone capable, asking them to look over a code sample reveals things you can’t see. Not everyone will share code, but good engineers often will.
Ask specific questions about your project. How would you handle the data? What about logins? How would this talk to our accounts system? You don’t need to judge the answer technically - you can judge how specific, thoughtful and honest it is.
6. Read the proposal properly
Is it specific to you, or could it have been sent to anyone? Is the scope defined clearly enough that you both know what’s not in it? Is the effort broken down by area, so you can see where assumptions differ from yours? Is the timeline credible given the scope?
Most importantly: check what’s excluded. Testing, deployment, documentation and post-launch support are the usual omissions, and they’re what keeps the headline number low.
Flags, both colours
Red flags
- A quote without enough questions. They’re guessing, or applying a standard answer to a non-standard problem.
- A price that seems too low. It almost always means narrower scope, less experience, or costs that arrive later.
- Can’t explain their own past work in detail. Either they didn’t do it or they didn’t understand it.
- Reluctance to provide references. People with happy clients are usually glad to introduce you.
- Talking more than listening. The best first conversations are mostly questions about your business.
- Vague scope. Either poorly thought through or deliberately slippery. Both end the same way.
- No plan for after launch. Software needs maintaining. A proposal that ignores that is ignoring a third of the job.
Green flags
- More questions than statements in the first conversation.
- Honest about uncertainty - what they don’t know yet, and what the risks are.
- Willing to say bespoke isn’t the answer. Someone who tells you to buy something off the shelf instead is worth keeping - that decision has its own guide.
- Specific answers to specific questions, rather than generic ones.
- References who give detail, not just warm words.
- A clear plan for after launch, because they’re thinking about the whole life of the thing.
Structuring the engagement
Choosing well is most of it. How you set the work up is the rest.
Invest in scoping. A proper specification, written together before development starts, is the most valuable money you’ll spend on the project. It costs time and it saves considerably more.
Agree what success looks like. Not the feature list - the outcome. What business problem is solved, what gets faster, what people will do differently. It makes every decision during the build easier.
Tie payments to milestones. Payments against working software rather than elapsed time keeps everyone’s incentives pointing the same way. Avoid large payments up front that aren’t attached to anything.
Agree how you’ll communicate - how often, through what, and what you’ll get at each update. Problems accumulate quietly when nobody’s reporting.
Be an active client. The best outcomes come from clients who answer questions quickly, review progress and make decisions when the plan needs to change. A developer left to interpret ambiguous requirements alone will interpret them, and you may not like the result.
Questions I get asked
How many quotes should I get? Three to five. The point is to understand the range, not to find the cheapest.
Should I pick the cheapest? Almost never. The cheapest quote is cheap for a reason, and the reason usually appears later as a change request. The most expensive isn’t automatically best either.
Does it matter if they’re local? Less than it used to. What matters is communication, overlapping hours, and being able to meet occasionally when it’s genuinely useful. Someone three hundred miles away who communicates well beats someone down the road who doesn’t.
Should we sign an NDA first? A mutual NDA before sharing anything confidential is normal and most firms will sign one without fuss. Refusal is unusual enough to ask about.
How do I know the portfolio work is really theirs? Ask for specifics - what they built, what went wrong, what they decided. People who did the work can answer. People who didn’t give you generalities.
If you’re working through this and want a second opinion, I’m happy to be measured against every criterion above, references included.
Weighing up proposals?
Send them over for a second opinion - what's missing, what the numbers imply, and which questions I'd go back with. No charge, and I'll say if one of them looks right.