~10 min read · You "own the code". You have the repo. So why can't anyone else work on it? Here's the difference between having the code and being able to actually use it — and what to insist on before signing the next contract.
There's a moment, often a year or two into the life of an app, where the question of ownership stops being abstract.
Maybe the developer is leaving. Maybe you're considering a new partner. Maybe a strategic conversation has come up — an acquisition, an investment, a due-diligence pass — and someone needs to look at the code seriously, not just demo it.
You go to the repository. You're listed as the owner. The folder structure exists. The README exists. You hand it to someone, say here, this is ours, and wait for them to start working with it.
A week later, they come back with questions you can't answer. Where are the build instructions? Where's the staging environment configured? What does this credential file do, and where do I get one? Where's the contract between the mobile app and the backend documented? Is there a runbook for deploying?
You don't have the answers, because the answers were never written down. Whoever built the app knew them. You "owned the code", in some technical sense, from day one. But the act of handing it to a stranger has revealed something uncomfortable: owning the code and being able to use the code are not the same thing.
This article is about the gap between those two — and what real ownership looks like when you insist on it.
Ownership Is a Spectrum, Not a Binary
The phrase "you own the code" tends to imply a clean, binary state. Either you do or you don't. The reality is messier.
Code ownership exists on a spectrum with at least five clear points. Most buyers stop around point two and assume they're at point five. The gap between what they have and what they think they have is where most ownership disputes — and most painful handoffs — actually live.
Level 1: Access. You can log in to the repository. You can see the files. You can download a copy.
Level 2: Readable. Someone other than the original developer can open the code and identify what each part is for. The folder structure makes sense. Files have descriptive names. The high-level shape is legible.
Level 3: Buildable. A new developer, given the code and the documentation, can get the app running on their own machine within a day. They can build it, deploy it, run the tests if there are any. The "from a fresh laptop to a running app" path is documented and works.
Level 4: Understandable. A new developer can read the code, understand why it's structured the way it is, and find their way around without a guided tour. The decisions made by the original developer are either visible in the code or written down somewhere. The implicit knowledge has been made explicit.
Level 5: Extensible. A new developer can add a feature, fix a bug, or refactor a part of the app — confidently, without breaking the rest. The structure was designed to be added to, and the documentation supports it.
Most buyers, when they say "we own the code", mean level 1 or 2. Most contracts, when they grant "ownership of the code", grant level 1 or 2. The contract is technically honored. The expectation — the level-5 version of ownership that the buyer was actually hoping for — was never written into the deal.
The difference between level 1 and level 5 is dramatic. Level 1 is a folder you can download. Level 5 is a working partnership with the next developer, before they've even been hired.
What Level 1 (Access) Actually Buys You
If all you have is access, here's what you can do.
You can prove the code exists. You can give a copy to a lawyer. You can use it as evidence in a dispute. You can hand it to a forensic developer who'll spend a few weeks reverse-engineering what's there.
You can't easily continue building it. You can't quickly hand it to a new developer. You can't audit it. You can't migrate it. You can't sell it as a meaningful asset, because anyone evaluating it for purchase will discount it heavily once they discover they can't read it.
Level 1 ownership is a starting point. It's better than nothing. But it's also the lowest possible useful state, and most buyers who think they have "real ownership" have only this.
What Level 5 (Extensible) Actually Requires
If you want extensible ownership, here's what has to exist.
Buildable from scratch. A new developer, with a fresh laptop, the code, and the documentation, can get the app running locally within a day. This sounds simple. It almost never is, unless someone explicitly invested in making it so. There's usually a hidden file the developer had on their machine, an undocumented environment variable, a step they did manually two years ago and forgot. Being buildable from scratch means those gaps have been hunted down and closed.
Documented decisions. Not a novel. But somewhere, in a README or an architecture document, the major decisions are written down. We chose Postgres because we needed transactional integrity for orders. We chose Flutter because we needed iOS and Android from one codebase. We separated the rules into their own layer because the screens needed to be redesigned twice without changing the logic underneath. A few paragraphs in the right places save weeks of archaeology later.
At least some tests. Automated tests, however minimal, function as documentation. They tell the next developer what the code is supposed to do, in a way that can be verified. An app with no tests is an app whose intended behavior is in someone's head — and if that someone has left, the intended behavior is gone too.
Clean structure. Not a clean codebase in some perfectionist sense — a structure where things are where you'd expect them to be, named in ways that explain their purpose. We touch on what this looks like in the three apps inside your app — the same separation that makes an app cheap to maintain also makes it possible to inherit.
A working contract between the mobile app and the backend. Even informally — a written description of what the endpoints return, what errors mean, what auth looks like. This is one of the joints we describe in the technical-debt piece — and one of the joints most often invisible to a new team taking over.
A runbook. Even a short one. Here's how to deploy. Here's how to roll back. Here's what to do if X breaks. The presence of a runbook is the single clearest signal that someone thought about what happens after the original developer is gone.
Level 5 ownership doesn't require a perfect codebase. It requires deliberate handoff work, done as the project goes — not retrofitted at the end.
The Bus Factor Test
There's a useful test for what level of ownership you actually have. It has a slightly grim name: the bus factor.
The bus factor is the number of people who could be hit by a bus before the project becomes unworkable. If only one person understands the code, the bus factor is one. If three people could each pick it up and continue, the bus factor is three.
A bus factor of one is the most common situation in small-team apps, and it's the most fragile. You don't need a bus to lose the developer — they can quit, get a better offer, burn out, or simply stop responding (we've written about that scenario specifically in your developer left — what happens next).
The bus factor test, applied to ownership, is this: if my current developer disappeared tomorrow, how long would it take a competent new developer to pick up where they left off?
If the answer is "a week or two", you have level-5 ownership.
If the answer is "a month or two", you have level 3 or 4.
If the answer is "we'd basically have to start over", you have level 1 or 2 — regardless of what the contract says.
This is a more honest measure of ownership than any clause in a contract. The contract grants you rights. The bus factor tells you what those rights are actually worth.
What to Insist on in the Contract
If you're about to sign a new development contract, or about to negotiate the renewal of an existing one, here are the specific clauses that move you toward level 5.
Repository ownership from day one. The repository is under your account, not the developer's. The developer is added as a collaborator. When the engagement ends, you revoke their access; the code stays where it is.
App store accounts under your email. Apple Developer, Google Play Console — registered to an email you control. The developer is added as a team member. The accounts can outlive the engagement.
Signing keys and certificates in your possession. Android keystores, Apple certificates, the passwords for both. Stored somewhere you can access, with documented backups. If Google Play App Signing is available for your platform, enrolled in.
All credentials in a place you control. The hosting account, the database, the third-party services (Firebase, Stripe, SendGrid, anything paid). Either registered in your name or transferred to you on engagement end.
A maintained README. Updated as the project evolves, not written at the very end. The README is the document a new developer will read first. If it's out of date or never existed, the project is harder to inherit than it should be.
Documented architectural decisions. Even minimal. Even a short "we chose X because Y" document. The decisions are the part of the code that's most expensive to reverse-engineer; documenting them is the cheapest insurance there is.
A handoff clause. Specifically: when the engagement ends, the developer commits to a defined handoff — typically a few days of guided onboarding to a successor, plus a clean state of the documentation. The terms can be modest. What matters is that the handoff is named, not assumed.
These aren't unusual to ask for. A developer who has worked seriously on production projects will recognize all of them and have ready answers. A developer who pushes back on any of them is telling you something about how the engagement will end, and that signal is worth listening to.
We cover the broader skill of reading contracts and quotes in how to read a developer's estimate — the ownership clauses are one specific dimension of the wider literacy.
The AI Complication
There's one more layer worth naming, because it's increasingly common and increasingly confusing: ownership of code that was largely generated by AI tools.
The legal answer is mostly straightforward. The code in your repository is yours, regardless of whether a human or a tool produced it. The terms of the major AI coding tools generally grant you full rights to the output. (Always read the specific terms of the tool your developer used, but this is the usual case.)
The practical answer is more complicated.
AI-generated code, especially when produced without a human architect holding the opinions of the project, tends to be harder to inherit. We've written about why in detail in your AI coding tool doesn't have opinions. The short version is that AI tools produce locally competent code without an overall design. A new developer inheriting that kind of codebase has to reverse-engineer the implicit assumptions of every feature, because the assumptions were never made explicit by anyone.
The result is that you can legally "own" an AI-generated codebase while practically being unable to use it. You're at level 1 even if the contract says level 5.
The fix isn't to avoid AI tools. The fix is to insist that someone — a human — was responsible for the opinions of the codebase, and that those opinions are written down. An AI-built codebase with explicit architecture documentation is much more inheritable than a human-built codebase without it. The medium isn't the problem. The documentation is.
If your project was AI-heavy and you're worried about ownership, the next step is usually a short audit: someone independent reads the codebase and tells you, honestly, what level you're at and what it would take to move up. This kind of review costs much less than most buyers expect and prevents much more expensive problems later.
What Ownership Means When You Have It
When ownership is at level 5, almost every difficult moment in an app's life gets easier.
The day your developer needs to leave, the handoff is calm. A new developer reads the documentation, runs the build, and is making meaningful changes within two weeks. Nothing is lost.
The day an investor asks to see the code, you can show it to them — confidently, knowing that what they see will reflect well on the business. They can do due diligence without you having to translate every file.
The day you want to bring development in-house, the transition is feasible. You're not buying back access; you're continuing what was already accessible.
The day you want to sell the business, the code is an asset. Buyers can evaluate it. They can extend it. It has real value beyond "this thing works".
Level 5 ownership isn't a luxury. It's the version of ownership that does what most buyers thought they were buying when they signed the original contract. The work to reach it is small, but it has to be deliberate.
You don't need to be technical to insist on it. You just need to know that the contract clause "you own the code" doesn't get you there by itself — and that the difference between owning a folder and owning a working asset is the difference between an app you can do anything with and an app you only think you can.