How to hire a software developer for your business
Hiring a developer is hard when you cannot evaluate the work itself. These are the questions and contract terms that separate a safe hire from an expensive lesson.
Hiring a developer is uncomfortable because you are buying something you cannot inspect. With a builder you can look at previous work and tell good from bad. With software, two systems that look identical from the outside can be entirely different underneath, and the difference only shows up two years later when one is easy to change and the other is not.
So the useful skill is not judging code. It is knowing which questions surface how someone works, and which contract terms protect you if it goes wrong.
The three ways to buy development
| Freelancer | Small agency | In-house hire | |
|---|---|---|---|
| Typical cost | Lowest | Middle | Highest, ongoing |
| Speed to start | Fast | Moderate | Slow, months to recruit |
| Continuity risk | High, one person | Lower, a team | Low while they stay |
| Best suited to | A defined first project | Larger programmes | Continuous internal need |
For most small businesses commissioning their first system, a freelancer or very small agency is the sensible starting point. An in-house hire only makes sense once you have enough continuous work to keep someone busy, and by then you will know what you need.
The continuity risk with a single freelancer is real and worth planning for rather than avoiding. The contract section below is how you manage it.
What good actually looks like
They ask about your business before your software
The first conversation should be mostly about how your business runs, where work gets stuck, and what happens when something goes wrong. A developer who opens with a technology recommendation before understanding the process is selling, not diagnosing.
They are willing to talk you out of it
Someone who tells you that an off the shelf product would serve you better, or that only part of your idea is worth building, is showing you their judgement. It is also the strongest possible signal that they are not simply maximising the invoice.
They talk about what happens after launch
Software is not finished when it launches. Ask what maintenance looks like, how updates are handled, and what happens when something breaks at 4pm on a Friday. Vague answers here usually mean nobody has thought about it.
They can explain things without jargon
Anyone who genuinely understands a system can explain it in plain language. Jargon used at a non technical client is often a way of avoiding scrutiny rather than a sign of expertise.
Questions worth asking
These are the ones that produce genuinely revealing answers.
- Who will own the code and the accounts? The only acceptable answer is that you will. See the contract section below.
- What happens to my system if you are unavailable for a month? Listen for whether anything exists beyond the person in front of you: documentation, a repository you can access, a second pair of hands.
- How will you handle my existing data? If migration has not been mentioned by this point, the estimate is not complete.
- What would you deliver in the first six weeks? A good answer names one specific workflow. A vague answer suggests the project has not been thought through.
- Can I speak to a client whose project did not go smoothly? The reaction to this question tells you more than the answer does.
- What ongoing costs should I expect after launch? Hosting, maintenance, and support should all have numbers attached.
Warning signs
- A fixed quote given before anyone has looked at your data or processes. It is a guess, and guesses get corrected later at your expense.
- Reluctance to hand over code or hosting access. This is sometimes framed as protecting you. It is not.
- No mention of maintenance, hosting or ongoing cost. Either it has not been considered, or it is being hidden until after you sign.
- Everything is possible and nothing is a trade-off. Real engineering involves compromises, and someone who never mentions any is not being straight with you.
- Pressure to decide quickly. Legitimate work does not require urgency to close.
What belongs in the contract
This section matters more than the interview. Get these five things in writing regardless of how well the conversations went.
- Intellectual property transfers to you on payment. Without this clause, you may be licensing your own system.
- The code lives in a repository you own, with your account as owner from day one, not handed over at the end.
- Hosting and domain accounts are in your name, with the developer given access rather than ownership.
- A defined handover, covering documentation, credentials, and a written description of how the system is deployed.
- Data ownership and export, stating that you can extract all of your data in a usable format at any time. This also matters for UK GDPR compliance.
How to test cheaply before committing
The most reliable way to evaluate someone is to work with them on something small and paid. Commission the first phase, the one narrow workflow described in our post on timelines, and treat it as a trial for both sides.
You learn how they communicate, whether estimates hold, and whether the result actually fits how your team works. If it goes well, phase two is an easy decision. If it does not, you have spent a limited amount and you still own everything produced.
That is a far better position than discovering the same information nine months into a large fixed price programme.
Frequently asked questions
For a first project with defined scope, a freelancer or very small agency is usually the better value and moves faster. Larger agencies make more sense for multi-team programmes or where continuity guarantees matter enough to pay for. In both cases the contract terms around code and data ownership matter more than the label.
Judge the process rather than the code. Do they ask about your business before proposing technology, do they explain trade-offs in plain language, do they raise maintenance and data migration unprompted, and will they start with a small paid phase. Those signals correlate well with quality of work.
You should, and it should be written into the contract with intellectual property transferring on payment. The repository and hosting accounts should be in your name from the start, with the developer given access. Anything else leaves you dependent on one supplier.
The hourly rate is usually lower, but total cost depends heavily on communication overhead, timezone overlap and how much rework results from misunderstood requirements. It can work well for clearly specified work, and tends to work less well for projects that need frequent back and forth about how your business operates.