We wrote a tips post on this a while back. Reading it again, it was mostly about us. So here's the version I'd actually want a friend to read before they hire anyone, us included.

Who actually writes the code?

Ask it plainly: "Who will be writing my software, and can I speak to them?"

Plenty of agencies sell with a senior person and build with someone you never meet. Sometimes that's a junior, sometimes a subcontractor, sometimes a team overseas. None of that is automatically wrong, but you should know which it is before you sign, not six months in.

The answer you're hoping for is a name, and ideally a conversation with that person. If the developer can explain your project back to you in plain English, that's a very good sign.

Who owns the code and the IP?

This one catches people out. Some developers build on their own platform and licence it to you. That can be fine, but it means you never really own your system, and you keep paying to use it.

Ask for it in writing: when I've paid, is the code mine? Can I take it to another developer if I want to? Are there any licence fees, now or later? A good answer is short. "Yes, yes and no."

Where will it live, and who has the keys?

Your software has to run somewhere: a cloud account, a server, a hosting company. Ask whose name that account is in, and who holds the logins for the server, the domain, the code repository and any paid services it relies on.

The safe setup is simple. The accounts belong to your business, and the developer has access you can take away. If everything sits in the developer's personal accounts, you're one fallen-out relationship away from being locked out of your own system.

How do they use AI, and who checks it?

In 2026 almost every developer uses AI tools. That's not the question. The question is who reviews what the AI writes before it goes live, and whether anyone on the team properly understands the finished code.

Ask how they test, how code gets reviewed and what happens when something breaks. If the answer sounds like "the AI handles that", be careful. And if your contract or your data means you'd rather they didn't use AI at all, ask whether they can work that way and what it does to the price.

How do they price it?

There are three common ways, and each has a catch.

  • Hourly. Flexible, but you carry all the risk. If it takes longer, you pay more, and you end up reading timesheets.
  • Fixed price for the whole project. Feels safe. In practice the developer pads the estimate to cover the unknowns, and every change becomes a negotiation about scope.
  • Fixed price per sprint. You agree what goes into the next week or fortnight, at a fixed price, then agree the next one. You can change direction between sprints without tearing up a contract.

We moved to the third one, and I've written about why we stopped quoting by the hour. Whatever model you pick, make sure you understand what happens when something takes longer than expected. That's where the arguments start.

What happens when the project ends?

Software isn't finished when it goes live. It needs updates, security patches, fixes and the odd new feature. Ask what support looks like afterwards, what it costs and how quickly they respond when something's broken.

Then ask the awkward one: if we part ways, what do we get? You want the code, the documentation, the logins and a proper handover. A developer who's comfortable answering that is usually one you won't need to leave.

References you can actually ring

Logos on a website are easy. A phone number for a client who'll talk to you for ten minutes is much better. Ask for one or two clients with projects similar to yours, and ask them what went wrong and how it was handled. Every project has something. How it got sorted tells you more than the bits that went well.

Red flags

  • They can't tell you who'll write the code.
  • You won't own it, or the answer about ownership is long and vague.
  • Your system will run in their accounts, with no plan to hand them over.
  • A price before they've understood the problem.
  • No mention of testing, review or support.
  • Pressure to sign quickly, or a big upfront payment for the whole project.
  • They say yes to everything. Good developers push back sometimes.

What a good first conversation looks like

A good first call is mostly the developer asking you questions. How do things work today? Where does it hurt? What have you tried? What happens if you do nothing?

You should come away feeling they understood your business, not that you sat through a pitch. They might even suggest you don't need bespoke software at all, and point you to something off the shelf. That's a good sign, not a lost sale.

If you'd like a longer list of names to compare, we've put together a guide to custom software development companies in the UK, with an honest note on who each one suits.

Where we fit

For what it's worth, here's how we'd answer those questions. We're a UK team, and you deal with me and Jason, who are on every project. The code we write for you is yours outright, with no licence fees. We price by the sprint. And we're happy to talk you out of a build if it isn't the right answer.

If you're weighing up a project, have a look at how we approach custom software development, or just get in touch for a chat. No pitch, just questions.

Cheers, Rob