A business calls me because they want to change something. Add a feature, move to a new developer, get a second opinion on an app that’s been running for years. Simple enough. Then I ask for the source code. And that, more often than you’d think, is where it falls apart.
Sometimes the previous developer has it and won’t hand it over. Sometimes nobody knows where it lives. And every so often they paid tens of thousands of euros and have, in their possession, exactly nothing they can give the next maintainer.
They assumed that paying for the software meant owning it. It’s a completely reasonable assumption, but it’s also, more often than not, wrong.
Paying for custom software and owning it are two different things.
This post is about the difference. What you’re actually buying, what the law assumes if nobody wrote it down, and the handful of boring sentences that decide whether you own your software or rent it back from whoever built it.
The three things people call “the software”
When someone says “we own the software,” they usually mean one big fuzzy thing. It’s actually three, and you can hold any one of them without the others.
Think of a restaurant meal. There’s the plate of food in front of you, there’s the recipe that made it, and there’s the kitchen it came out of. Pay for dinner and the food is yours. That doesn’t mean you walked out with the recipe, and it certainly doesn’t mean you own the kitchen.
Software is the same three things.
- The recipe: the source code. This is the actual written instructions a developer types, the human readable version of your app before a computer turns it into something it can run. Whoever holds a complete, current copy of the recipe can cook the dish again, change it, or hand it to a different cook.
- The deed: the rights. This is the legal ownership, who is allowed to copy, change, sell, or license the software to someone else. It’s called intellectual property, or IP, and it’s a separate thing from the recipe itself. You can hold a full copy of the recipe and still have no right to sell it, license it to others, or open your own restaurant with it.
- The restaurant: the running system. The live app, the hosting accounts it sits on, the domain, the database. I wrote a whole post specifically about who pays for this, so I’ll keep it short here. Just know that you can own the recipe and the deed and still discover the app runs on a computer only your developer has the password to.
Most “we don’t really own our software” horror stories are just one or two of these three going missing, and nobody notices until it matters.
The default nobody reads to you
In many European countries, the law’s starting point is not the intuitive “whoever paid for it owns it.” Copyright is born with the person who writes the code. For an outside contractor it doesn’t necessarily jump to you just because you commissioned and paid for the work, and in plenty of places who ends up holding the rights is genuinely contested. What you can safely assume you bought is permission to use the result. Full ownership, the right to change it, resell it, or take it elsewhere freely, is a separate thing you have to actually secure.
I’m your go to technical guy and not your lawyer, and the exact rules vary by country and by whether the person was an employee or not. But I can tell you this:
Rights don’t transfer just because money did. They transfer only with a contract.
That one gap is behind a surprising number of disputes. A company grows, wants to sell, and due diligence turns up that they don’t actually own the core software their valuation rests on. Or they want to switch developers, and the old one points out, correctly, that they hold the rights and aren’t obliged to help.
The fix is cheap and unglamorous. A clause, agreed up front, that assigns the IP to you on payment.
What a real handover actually looks like
Say the rights are sorted. You still need the recipe, and “they emailed us a zip file once” is not the same as having it.
A full handover means all of this:
- The full source lives somewhere you control. Ideally you’re not receiving the code at the end of an engagement, you already hold it the whole way through in a repository (the shared, history tracked home where code lives).
- Someone else can actually build it. Code on its own is a pile of ingredients. A second developer needs to be able to turn it into a running app without spending weeks just figuring out how the pieces fit together. The setup steps should be written down already.
- There are no secret ingredients. Plenty of apps silently depend on a tool, a script, or an account that only the original developer has. At a minimum, that should be known up front.
- The licenses on the borrowed parts are clear. No real software is written entirely from scratch. Developers assemble it partly from free, openly available building blocks made by other people, each with its own licensing terms. You want to make sure you’re actually allowed to use them commercially.
Vendor lock in, and its polite disguises
Lock in is when leaving your current developer is expensive, slow, or frightening enough that you don’t do it even when you should. It’s usually a series of small frictions that add up.
It comes in a few flavors:
Contractual lock in. The rights and the handover were never nailed down, so leaving means negotiating, calling your lawyer, or both.
Knowledge lock in. The code is technically yours, but it’s a maze only its author can walk. Any new developer has to reverse engineer it before they can safely touch it, which is slow and expensive. This isn’t always deliberate, sometimes it’s the result of a rushed build.
Technology lock in. The software was built on some developer’s private toolkit, or an unusual technology that few other people can work with, and that scarcity has a price.
I want to be fair, because not all of this is villainy. A developer who hosts everything on their own accounts and keeps the code close often isn’t scheming, they’re doing the thing that’s fastest for them and genuinely convenient for you on day one. The trouble is that convenience and lock in look identical from the outside. That’s exactly why you should settle it at the start.
When you genuinely don’t need to own it
If you just want to eat pizza, do you really need to own the restaurant?
When the thing you’re using is a product, a subscription tool, a platform somebody else uses too, you’re not commissioning custom software at all. You’re renting a finished thing alongside everyone else who pays for it, and that’s usually the smart move, not a compromise.
Think of the small studios that sell, say, inventory management software to a whole industry. Dozens of businesses run their day on it and not one of them owns it, and they’re right not to. It’s cheaper to buy than paying someone to build your own. It’s also cheaper to keep alive, because the cost of maintaining it, fixing it, and hosting it is split across every customer instead of landing on you alone.
As long as the relationship is good and the tool does its job, why take on the weight of owning it?
Leaving is harder, no argument there. But you weigh that one downside against everything you save by not carrying the thing yourself, and very often it’s a trade worth making.
Ownership earns its keep when the software is genuinely yours, something built specifically for your business that you’re meant to keep, grow, and lean on for years. The more a custom system sits at the center of how you operate, the more it matters.
The short version to say out loud before you sign
You don’t need to become an expert. You need to ask a few plain questions early, and listen for whether the answers are specific or vague:
- When the project ends, who owns the rights to the software?
- Where will the source code live, and when do I get access?
- Could another developer take this over without you?
- Are there any parts I’d stop being able to use if we parted ways?
If the answers are clear and specific, you’re probably in good hands. A developer who has thought about this is telling you something reassuring about how they work.
If the answers are foggy or a little defensive, that’s not proof of anything sinister. It’s just a sign to slow down and get the boring sentences written before the money moves.
The takeaway
Paying for custom software buys you the work. Owning it is a separate thing you have to actually arrange.
The good news is that none of it is hard or expensive to get right at the start. It’s a couple of clauses and a couple of questions, agreed while everyone’s still on good terms.
If you’re not sure what you actually own right now, or you’re about to commission something and want the ownership side written properly before you sign, that’s a short conversation well worth having first.