What "you own the code" actually means
“You own the code” is easy to say in a proposal and hard to cash in when you want to leave. Ownership is a package. Here is what should be in it, and what to watch for in the fine print.
Vinerals TechnologiesWorkshop notes
“You own the code” shows up in almost every custom software proposal. It sounds reassuring. It is also vague enough to mean almost nothing until you try to use it.
We have watched companies discover, two years in, that they own a zip file they cannot deploy, or a GitHub repo they cannot log into, or a system that only runs on a server whose credentials live with the agency. The words were there. The package was not.
Ownership is not a single checkbox. It is a bundle: the source, the accounts, the documentation, and a contract that lets you walk away without paying a ransom to keep your own business running. This piece unpacks that bundle so you know what to ask for before you sign, and what to insist on before you pay the final invoice.
Three different things people call “ownership”
When a vendor says you own the software, they might mean any of three quite different arrangements. They are not interchangeable.
Source code ownership.
You hold the intellectual property in the custom code written for you. You can hire someone else to maintain it, fork it, or stop paying the original shop without losing the right to the work product. This is what most SMEs think they are buying when they choose custom.
A hosted product you rent.
You pay monthly for access. The vendor runs it, updates it, and holds the code. You get an account, not an asset. Fine for commodity tools. A poor fit if the software is supposed to be your competitive edge.
A license to use.
You can run the software, sometimes on your own servers, but you cannot see the source, cannot modify it freely, and cannot take it elsewhere. Common with white-label platforms and some “custom” builds that are really configured instances of the vendor’s core product.
The confusion usually lives in the third bucket. A system can feel bespoke while the underlying platform stays the vendor’s property. Ask plainly: if we stop paying you, what still works, and what stops? The answer tells you which bucket you are in.
The accounts matter as much as the repository
Source code in a repo you cannot access is a souvenir. For ownership to be real, you need control of the infrastructure around it.
Source control.
GitHub, GitLab, Bitbucket, or equivalent. The repository should live in an organization you own, with your admins, not buried inside the vendor’s account with you as a guest.
Hosting and cloud.
AWS, Azure, Google Cloud, or your own servers. Root or admin access to the environments where production runs. Billing in your name, not theirs.
Domains and DNS.
Registered to you. Pointing where you decide. We have seen companies lose a domain because it was registered under an agency email that nobody monitors anymore.
Third-party services.
Payment processors, email providers, maps APIs, auth services. Each should have an account you control, or a clear sub-account structure with export rights. API keys should not be secrets only the vendor can rotate.
Databases and backups.
You should be able to pull a backup without filing a ticket. If the only copy of your data lives on a server you cannot SSH into, you do not own the system. You rent it.
A practical test: could a competent developer you hire next month deploy the application from scratch using only what you hold? If the honest answer is no, close the gap before the project ends, not after a dispute starts.
Documentation that makes ownership usable
Code without context is a puzzle box. The documentation is what turns a repository into something your next team can actually run.
How to build and deploy.
Step-by-step setup for local development and production deployment. Which commands, which environment variables, which branches map to which environments. Not a novel. Enough that someone new is not guessing.
Architecture in plain language.
What the main pieces are, how data flows, where the fragile parts live. A diagram helps. A one-page narrative helps more than a diagram nobody updates.
Integration map.
Every external system, what it is for, which credentials it uses, who owns the account, and what breaks if it goes down.
Operational runbook.
How backups run, how to restore, where logs live, who gets paged when something fails at 2am. Boring until you need it.
Known debt and shortcuts.
Every project has them. The part that was rushed for launch, the integration that needs replacing. Honest notes here save the next team months of archaeology.
You do not need encyclopedic docs on day one. You need enough that leaving the vendor is a project, not a crisis. If handover documentation is not in the statement of work, add it.
Red flags in contracts and statements of work
The friendly sales conversation and the contract are sometimes written by different people. Read the contract. A few patterns we treat as warnings.
“License to use” instead of assignment.
If the IP clause grants you a license rather than ownership of the custom work, you are renting your own build. For genuinely custom code, you want assignment of copyright in the work product you paid to create, with a carve-out for the vendor’s pre-existing tools and open-source components.
Hosting bundled with no export clause.
“We host it for you” is convenient until it is the only way the system runs. Insist on deployment docs and a tested handover before final payment.
Escrow that never triggers.
Source code escrow sounds safe. In practice it often requires a dispute, costs money to access, and holds a snapshot that may not match production. Prefer living access in your repo throughout the project.
Transfer fees on exit.
Some contracts charge to “migrate” you off their platform, or withhold credentials until a fee is paid. That is lock-in with paperwork. Walk away from those terms.
Vague definitions of “custom.”
If the SOW does not separate custom code from the vendor’s reusable framework, you may own the paint job while they keep the engine. Ask which files are yours outright and which are licensed.
No milestone tied to handover.
Final payment should not be due until you have repo access, credentials, and a walkthrough you understand. Tie money to the package, not just to a demo.
None of this means the vendor is acting in bad faith. Often it is just their default template, written for their convenience. Your job is to make the template match what you are actually buying.
How we structure handover
We are a solidarity cooperative that builds software by hand for SMEs. Ownership is not a footnote in our proposals. It is how we think the work should end.
Your repo from the start.
We work in a repository inside your organization. You see progress as it happens. There is no big reveal at the end.
Your cloud accounts.
Production runs on infrastructure billed to you. We get access to build. You keep access when we step back.
IP assignment in writing.
Custom code we write for you is yours, with standard exclusions for our internal tooling and open-source libraries everyone uses.
Handover as a deliverable.
Deployment guide, architecture notes, credential inventory, and a recorded walkthrough. Final invoice ties to that package, not just to a feature list.
No hostage maintenance.
We want ongoing work because the system is worth improving, not because you cannot log in without us. If you hire another shop, they should be able to pick it up.
That structure is not generosity. It is what custom software is supposed to mean. You paid for the craft. You should leave with the thing.
A short checklist before you sign or pay
Run through this with your lawyer if the deal is large. For most SME builds, it is enough to get the questions on the table.
1. Who holds the copyright in the custom work?
You want assignment, not a license, for code written specifically for you.
2. Where does the repo live, and who is admin?
Your organization, your admins.
3. Who pays the cloud bill and holds root access?
You, with documented credentials in your vault.
4. What happens on day one after the vendor leaves?
Can you deploy, restore a backup, and rotate an API key without them?
5. Is handover documentation a named deliverable?
With acceptance criteria you can check.
6. Is final payment tied to that handover?
Not just to a demo on the vendor’s laptop.
If you get clear answers to all six, “you own the code” is probably true in the way you mean it. If several answers are fuzzy, fix the contract before you fix the software.
Custom software is worth the premium when it becomes an asset your company holds, not a subscription you cannot escape. The phrase “you own the code” is only as good as the repo, the credentials, the docs, and the contract behind it.
We build software by hand for SMEs, and we treat handover as part of the craft, not an afterthought. If you are comparing proposals and want a second pair of eyes on what “ownership” actually means in each one, we are glad to read them with you. Bring the SOW. We will start there.
