How to Make Sure You Actually Own Your Code

Here’s a sentence that has ruined more founders’ months than almost any other: “Don’t worry, it’s all in the contract, you own everything.”

They’re not lying. You probably do own the intellectual property, legally, on paper. And it can still be true that you can’t run your product, can’t change it, can’t move it to another team, and can’t do a single thing with it without the exact people you’re trying to leave. Both of those can be true at once, and the gap between them is where founders get held hostage.

We’ve pulled four founders out of exactly this gap. Every one of them owned their code on paper. Not one could run, change, or move their product without the team they were trying to fire. The contract was never the problem.

Owning your code is not one thing. It’s two. There’s the legal ownership, which is easy and mostly handled by a clause. And there’s practical ownership, the ability to actually operate and move your product, which is a stack of boring, unglamorous access details that stay invisible until the day you desperately need them and don’t have them.

Legal Ownership vs. the Kind That Matters

Legal ownership is a copyright question. Does the contract assign the IP to you? If yes, good, that’s necessary. It is nowhere near sufficient.

Practical ownership is a different question entirely: if your dev team vanished tomorrow, could a new developer take over your product? Not eventually. Reasonably quickly. If the answer is no, you have a certificate of ownership for something you can’t actually control.

The reason this trap is so common is that practical ownership is invisible while things are going well. As long as the team is working, you don’t notice that the code lives in their account, the app runs on their server, and the only person who understands how it fits together is a developer you don’t employ. Everything’s fine. Right up until you want to leave, or they do, and then the invisible dependency becomes the only thing that matters.

The Five Things You Actually Need

Real ownership is concrete. It’s five things, and all five have to live in accounts that you control.

1. The code repository. Your code, in your GitHub (or GitLab) organisation, with you as admin. Not a zip file emailed at the end. Not their repo that they promise to transfer later. Yours, from the first commit, with the full history. A zip of the current code without its history is a photograph of a house, not the keys.

2. The deployment environment. The place your product actually runs (the hosting, the servers, the database) should be in your account, with the developers invited in. If the app lives on their infrastructure, they can switch it off, and “turn my product back on” is a terrible position to negotiate from.

3. The domain and DNS. Your domain, registered to you, with you controlling the DNS. This sounds trivial until your domain is registered under a developer’s personal account and pointing your product at your users runs through them.

4. The third-party services. Every external service (payments, email, analytics, storage, error monitoring) signed up under your company’s accounts, on your billing, with your credentials. When these live under a developer’s personal email, your Stripe account, your customer data, and your ability to email your own users all belong to someone else.

5. The documentation. Enough written down that a competent new developer could get the thing running and understand how it’s built. Without this, the knowledge lives in one person’s head, and you’re renting access to your own product.

What Lock-In Looks Like Before It Bites

Lock-in is rarely announced. It’s built quietly, usually without malice, through a hundred small defaults that all point the same way. In every build we’ve taken over, the lock-in was never written down anywhere. It lived in the accounts, not the contract. Here’s how to spot it while it’s still cheap to fix.

The worst case I have personally walked into: a live logistics system, used every day in distribution centres around the world, and the founder had no access to their own Stripe or GitHub. The code sat in a personal GitHub account, built on someone’s private internal framework, under an email address nobody controlled any more. The original developers were simply gone. No handover, no documentation, no tests, on a system real operations depended on daily. Our first job was not to improve anything. It was to understand what we had inherited fast enough to add tests, so we could work out what actually worked before we dared change a line.

The single most telling item is the last one. How a team reacts when you ask for access tells you almost everything. A confident, honest partner hands it over without a second thought, because your ownership was never in question. A team that stalls, over-explains, or treats the request as a sign of distrust is protecting leverage they’d rather you didn’t have.

Set It Up on Day One, Not at the Breakup

Almost everything in this guide is nearly free to do at the start and painful, expensive, or impossible to do during a bad exit. That asymmetry is the entire lesson.

Create the accounts yourself, then invite them in. This one habit prevents most lock-in. You make the GitHub org, the hosting account, the Stripe account. You add the developers as collaborators. Now leaving is just removing access, not extracting your product from someone else’s accounts. Reverse the direction and you’ve handed them the keys by default.

Get IP assignment in the contract. Necessary, not sufficient, but still necessary. Make sure the paperwork clearly assigns the code and everything around it to your company. This is the legal ownership half. Don’t skip it just because it’s not enough on its own.

Require documentation as you go. Not as a final gift. A running habit of writing down how things work and why decisions were made. Ask to see it periodically. If it doesn’t exist during the build, it won’t magically appear at handoff. Good teams do this anyway, and modern AI tools make keeping that context far cheaper than it used to be, so “no time to document” is a weaker excuse every year.

Do a handoff fire drill. Once in a while, ask: “If I needed to bring in a new developer next month, what would they need from you?” A healthy team can answer in specifics. A team that gets uncomfortable is showing you the ownership gap before it becomes a crisis.

Ownership Is Freedom, Not Distrust

Setting up clean ownership isn’t a lack of trust, it’s what a well-run company looks like. Get the five things into your accounts, get the clause in the contract, build the documentation habit, and do it on day one, when it’s free, so you never have to fight for it on the worst day, when it isn’t. Ownership you set up early is a formality. Ownership you have to reclaim is a war.

If you’re not sure which side of that line you’re on, the checklist below is the fastest way to find out. Tick honestly. If the gaps worry you, that’s exactly the conversation we’re happy to have.