Who Owns the Code? What to Check Before You Commission Bespoke Software

Insurance brokers are starting to write policies specifically for AI and software companies, because the questions clients ask before they sign a contract have got sharper. Who owns this? What happens if you disappear? Where does the code actually live? These aren't new questions, but I'm hearing them more often, and they're fair ones. Here's what I'd want to know if I were the one commissioning the work.

Who owns the code, in writing

This should be simple and usually isn't. Unless your contract says otherwise, in UK law the person who wrote the code owns the copyright, not the person who paid for it. If your agreement doesn't include a clause assigning intellectual property to you on payment, you might have paid for software you don't legally own.

Ask for this in plain terms before work starts, not after. It should say that IP transfers to you once invoices are paid, not "on completion of the project" (which is vague and can be argued over) and not "on final sign-off" if there's no fixed date for that. I put this in writing on every project I take on, because it protects both sides. You know exactly what you're getting, and I know exactly when my obligation ends.

Where the code actually lives

Ask where the repository is hosted and whose account it sits under. If your entire codebase lives in a developer's personal GitHub account, you're one dispute or one missed renewal away from losing access to your own product. I set repositories up under the client's own organisation account from day one. It's a small thing to arrange and it removes an entire category of risk.

The same goes for hosting, domain registration, and any third-party accounts the software depends on (payment processors, email services, cloud storage). If you don't hold the keys, you don't control the business.

What happens if the developer isn't available

This is the honest question for anyone working with a single, independent developer, and it deserves a straight answer rather than a dodge. I work alone. There's no second developer sitting behind me who can pick up a support ticket if I'm off sick for a week. What there is, is a deliberate way of working that reduces how much that matters:

• I build on mainstream, well-documented stacks (Laravel, PHP, MySQL, standard React) rather than anything unusual, so another competent developer could read the code and understand it without me explaining it to them.
• I write documentation as I go, not as an afterthought: what each part of the system does, why decisions were made, how deployments work.
• Credentials and environment details live in a shared password manager the client has access to, not only in my head.

None of that replaces a team. But it means the business isn't dependent on one person's memory, and if you ever needed to hand the project to someone else, they could actually do it. That's a fairer trade than paying agency overhead for a "team" that, in practice, hands your project to whichever junior developer is free that week.

Insurance and liability

Ask any developer or agency whether they carry professional indemnity insurance, and what it covers. It's a reasonable question, not an insult. I carry professional indemnity insurance, because if a mistake in something I've built causes a client financial loss, that's a real risk worth covering properly rather than hoping it never comes up. If someone can't answer this question clearly, that tells you something too.

Data protection, plainly

If the software touches customer data, ask where it's stored, who can access it, and what happens to it if the relationship ends. This matters more for UK businesses under GDPR than most people realise when they're focused on features and timelines. A short, clear answer here (which country the data sits in, who the processor is, what the data retention policy is) tells you more about how carefully someone works than a long list of technologies on their website.

A shorter list than it looks

Strip away the legal language and it comes down to four things: you own what you paid for, you hold the keys, someone else could pick up the code if they had to, and there's a proper safety net if something goes wrong. Any developer, solo or otherwise, should be able to answer these plainly. If the answers are vague, that's the real warning sign, not the size of the team.

If you're weighing up whether to commission bespoke software and want to talk through how this works in practice, here's how I run a project from first conversation to handover, or you can get in touch directly to talk about what you're planning.