Who Owns the Code When Someone Builds Software for You?

The short version

When I build software for you, you get all of it at handover. That means the working software, the specs, a README and documentation, and the source code. I keep the right to reuse what I write in later work. The details are spelled out in the proposal before the build starts, so nobody finds out at the end.

"Who owns the code?" is the question most people forget to ask before paying for custom software, and the one they most want answered afterward. It matters for a plain reason. If the answer is vague, you can end up depending on one person for software your business runs on.

Here is how it works when I build something, and what I'd ask any developer you're considering.

What you get at handover

You get the whole package, not a locked box:

  • The working software, ready to run.
  • The source code. A script is source code, so it's handed over too, along with everything else I write for you.
  • The specs, a technical README, and a plain-language guide to using the basics. Documentation is included in the price and never billed as a line item.

What I keep

I keep the right to reuse what I write in later work. If you need something different, such as exclusivity or a different handover, tell me before we start and it goes into the proposal.

What you want How I handle it
The software and the source code Standard. It's all included
Code in your own repository I can work in a repo you own and invite me to
Something different Tell me at the start and we'll write it into the proposal

I usually work in my own private repository until handover, but that's a habit, not a rule. If you'd rather I join yours, that's fine.

Domains, accounts, and paid tools

The accounts around the software matter as much as the code, because they decide who can switch things off.

  • Domain. It doesn't matter much who owns or registers it. Whoever operates the app is responsible for the domain's routing and DNS records, and I'm happy to help with that. If you don't have a domain yet, I can help you register one.
  • Running it. Your software is built to run on your own computers, your own servers, or services you already use. I don't sell hosting on its own. If we're working together long-term and there's a good reason for me to host something, we'll agree that separately.
  • Paid libraries and services. I favor open-source and free tools wherever they do the job. If something proprietary is the right choice, you buy it, and the keys are shared with me for the build. It's your license, not mine.

"What if my developer disappears?"

This is the real worry behind the ownership question, and it's a fair one when you're hiring one person instead of a firm.

Three things answer it. You hold the source code and the documentation, so someone else can take over at any point. The software is built to be read and built by another developer, and the README exists for exactly that reason. And if it runs on your own machines, it keeps running without me.

Questions to ask any developer

  1. Who owns the code, and is that in writing?
  2. Do I get the source code, and in what form?
  3. Whose name are the domain and any other accounts in?
  4. What happens to the software if we stop working together?
  5. What does handover include?

A good answer is specific. If the reply is "don't worry about it", keep asking.

Talking it through

Ownership is easier to settle in the first consultation than at the end of a build. If you're planning custom software, get in touch and we'll sort out the handover before anything is built. For a real example of the finished result, see the Flemington salon scheduler.

Updated

← Back to Insights