JOURNAL
Published on
WHO OWNS THE CODEI BUILD FOR YOU
The question sounds legal. Day to day it is about access.
THE ANSWER
The custom code I write for you is yours. Ownership goes into the proposal before I start. Four things change hands at handover. The repository, the accounts, the declared dependencies, the documentation. Credentials are rotated and stay in your name. On contracts and licences, your own lawyer gives the opinion, not me.
AI-generated image
IN SHORT
Accounts are opened in your name from day one.
Keys are rotated at handover and stay with you.
Open source libraries stay with their authors.
THE REAL QUESTION
OWNERSHIP MEANS YOU CAN OPEN IT
Somebody asking who owns the code is asking something else. If I stopped answering tomorrow, would the system still work? The ownership that matters is measured in access. Who gets into the repository. Who rotates a key. Who ships a change to production. A contract naming you and a system running on my accounts contradict each other. (So I prepare the written half and the technical half together.)
THE HANDOVER
FOUR THINGS THAT CHANGE HANDS
The same four on every project. From the smallest automation to an internal app with roles.
The code and its history
Not just the finished files: the repository with its history, the commit messages, the branches. Whoever comes next can see why a decision went that way.
The accounts and the credentials
Hosting, domain, database, connected services: in your name wherever possible. I stay an invited user, not the owner. Keys live outside the code.
The dependencies, declared
Every library and every external service is written down, with its version. Nothing that only works on my machine.
The handover documentation
What was built, where it lives, how it starts. What to do when something stops. It’s the document that makes me replaceable.
HOW IT GOES
THE HANDOVER, STEP BY STEP
It isn’t a closing ceremony. It starts on day one, when we decide where things are created.
Accounts are opened in your name
Where that’s possible you open them at the start and invite me. Simpler than transferring an account of mine at the end.
The repository starts in your space
Or it starts in mine and moves across at handover, when there’s no organisation to put it in yet. Which of the two is written in the proposal.
Keys are rotated at the end
At handover the credentials are rotated and they stay with you. From then on my access isn’t needed.
We read the documentation together
I don’t send it as an attachment and leave it there. We walk through it once with the person who’ll need it. A document nobody has opened isn’t a handover.
AI-generated image
THE BOUNDARY
WHERE MY HALF ENDS
What I describe here is how I hand over, not what the law says. Assignment, clauses and licences belong in the contract. The contract is your lawyer’s to read: I bring the technical half. There’s a concrete reason I don’t generalise. This page is read under three different legal systems. What one country leaves implicit, another expects written out in full. The operational half I do identically for everyone. (Accounts in your name, readable code, declared dependencies, documentation.)
THE PERIMETER
WHAT DOES NOT BECOME YOURS
A system is also made of pieces I didn’t write. Those stay with whoever made them.
Open source libraries
They stay with their authors, under the licence each one carries. Your system uses them, it doesn’t buy them. Names, versions and licences are listed at handover.
Subscription services
Hosting, email providers and paid APIs stay with their suppliers. The account is yours, the configuration is yours, the data inside is yours.
The engine under a no-code platform
If an automation lives inside a tool, you own the scenario I built, not the product that runs it. If that’s a risk for you, we say so before choosing the tool.
The craft
The recurring patterns and what I’ve learnt from building stay mine. Your process and your data stay yours.
A system is yours the day somebody else can open it without asking me.
QUESTIONS
- If the project stops halfway, is the code still mine?
- Yes, for the part built and paid for, with documentation of the state it’s in. I hold nothing hostage: it’s a poor way to work.
- Can you reuse for others what you write for me?
- Whatever is specific to your process stays yours and doesn’t turn up elsewhere. Generic components and the method are my trade. Where the line falls is written in the proposal.
- What if I take the system to another developer?
- They find the repository with its history, declared dependencies and the handover documentation. There’s no step only I can perform. That’s the condition I aim to leave.
- Who answers on contracts and licences?
- Your lawyer. I tell you what the system contains and under which licences. Whoever drafts the contract starts from verifiable facts, not a general description.
If you’re about to have something built, ask for the ownership answer in writing. Before the first line of code. Tell me the case and I’ll tell you how I’d set it up.