Why this decision is harder than it looks
Hiring a plumber is relatively straightforward. You can see the pipes. You can tell if the leak is fixed. If the work is bad, it's usually obvious.
Hiring a software developer is harder. The work is invisible until it isn't. A badly built system can look fine for six months and then fall apart. A developer can use the right words in all the right places — "scalable," "robust," "clean code" — and deliver something you'll be embarrassed by in a year.
This guide gives you a practical framework for evaluating developers, even if you have no technical background.
The first thing to get right: scope before anything else
Before you hire anyone, you need to know what you're asking for. Not at a technical level — at a business level. What problem does the software need to solve? What does success look like six months after launch? What does the user experience need to feel like?
Any developer worth hiring will help you clarify this in a discovery process before writing a single line of code. If someone quotes you a price without understanding your business properly first, that's your first red flag.
A developer who quotes a price before doing a discovery process is guessing. A good developer won't know what to charge until they understand what they're building — and they'll tell you that upfront.
Portfolio and relevant experience
Don't just look at whether the work looks nice. Look at whether they've built things similar to what you need. A developer with a strong portfolio of e-commerce sites might not be the right person for a complex internal booking and job management system.
Ask specifically: have you built something like this before? If yes, can I speak to that client? If they hesitate, probe further. If they offer references easily and those references check out, that's a good sign.
Communication and plain English
This one is underrated. If a developer can't explain what they're building in terms you understand, that's a problem — not because the technical language is wrong, but because it signals they either don't fully understand what they're building or they're not interested in making sure you do.
You should be able to understand the plan for your software. Not at a code level — at a "this is what it will do and why we're building it this way" level. If you can't, ask more questions. If the answers remain opaque, reconsider.
Excessive jargon without clarification is often a defence mechanism. Either the developer is covering for gaps in their understanding, or they're not invested in your understanding the project. Both are problems.
Who actually does the work?
This is a crucial question when dealing with agencies. You may be sold the project by a senior partner and delivered to a junior developer, or — in some cases — to an overseas team with limited communication. Ask directly: who will be writing the code? Will I have direct access to them?
This doesn't mean overseas development is automatically bad. But you should know who is building your system and be able to communicate with them clearly.
What happens after launch?
A surprisingly large number of developers and agencies effectively disappear after handover. You get a zip file of code, a vague promise of support, and silence. For a small business, this is a serious problem — because software always needs maintenance, updates, and occasional fixes.
Ask explicitly: what does post-launch support look like? Is it included? What's the response time if something breaks? What's the process for requesting changes? Get answers in writing.
Freelancer vs agency vs consultancy — what's the difference?
- Freelancer: Often lower cost and direct communication. Risk: availability gaps, limited breadth of skills, no continuity if they move on.
- Agency: Broader team, more process. Risk: premium pricing, potential for your work to be handled by junior staff, less personal attention.
- Small consultancy: The middle ground — experienced people with a focused offering, more personal than a large agency, more resilient than a solo freelancer.
There's no universally right answer. The right choice depends on your budget, the complexity of the project, and how much ongoing relationship you want.
The question that cuts through everything
If you want one question that reveals a lot about how a developer works, ask this: "Tell me about a project that didn't go to plan — and what you did about it."
Every developer has had a project that ran into problems. The ones worth working with can describe what went wrong, take appropriate responsibility, explain how they fixed it, and articulate what they learned. The ones who claim everything always goes perfectly are either lying or haven't done enough work to know what failure looks like.
If you're looking for a developer for your UK small business and want a direct conversation about what we do and how we work, get in touch. We'll be straight with you about whether we're the right fit.