What happens if your
builder disappears.
"You own the code" is a promise. Whether it holds depends entirely on what was handed over and how it was built. Here is how to check both — before you sign anything.
One of the genuine advantages of a business automation over a subscription service is that you own what was built. If you stop working with the person who built it, the software keeps running. That matters.
But there is a version of this that is only true on paper. You have the code. You cannot read it. The person who can is no longer responding to emails. And a new builder, looking at what was left behind, says it will be faster to start again than to fix it. This article is about how to make sure that does not happen to you.
The two things "you own the code" actually requires.
Ownership means two things in practice. First, you have a copy of the files somewhere you control — not on the builder's laptop or in their private cloud account. Second, a different competent builder can read those files and understand what they do without needing to speak to the original builder.
Most builds satisfy the first condition. Fewer satisfy the second. The difference between them is the difference between owning a car and owning a car with no manual, no spare parts list, and no record of what previous mechanics did to it.
Paul · Building maintenance contractor — his previous build was delivered as a zip file with no documentation. When his builder moved abroad and became unreachable, two developers quoted more to understand the existing code than to rewrite it. He rebuilt from scratch. The original owner-ship was real. The original handover was not.
What a proper handover actually contains.
A handover that actually protects you contains four things:
- The code in a repository you own. Not a zip file emailed to you. A code repository — GitHub or similar — where you are the owner of the account and the builder is a collaborator. If the builder's access is revoked, the code is still yours and accessible.
- A plain-English description of what each part does. One page per automation, not a technical specification. "This file reads incoming emails and extracts the client name and the job type. If it cannot find a job type, it flags the email for you to review." A new builder should be able to read this and know where to start.
- A list of every external service the build depends on. The AI service. The email integration. The calendar connection. Every account, with a note on what it is used for and who currently holds the login. If any of those accounts are in the builder's name, that needs to be transferred.
- Instructions for the one thing most likely to need changing. Usually: how to update the information the automation draws on. Pricing, service lists, staff names. An owner should be able to do this without calling anyone.
How to check a build is actually transferable before you hire.
You can test for this before you spend a dollar. Ask the builder one question: if you became unavailable tomorrow, what would a new developer need to take over this project?
A builder who has thought about this will give you a specific answer. They will describe the repository, the documentation, the external service accounts, and roughly how long it would take a competent developer to get up to speed. They may even have done this before and can describe a real example.
A builder who hasn't thought about this will say something vague about the code being clean and well-commented. Clean and well-commented is not the same as transferable. Ask for specifics.
What to ask before you sign.
Three questions. Ask them on the first call and listen carefully:
A good response sounds like:
“Yes. The code lives in a repository in your name from day one. I document as I build. At handover you get a plain-English description of each part and a list of every account. I have done this before — it is part of what you are paying for.”
A response worth worrying about sounds like:
“The code is clean so it should be easy enough for someone to pick up. We can worry about documentation at the end.”
Documentation written at the end is rarely written at all. It gets deprioritised, condensed, or delivered as a rushed afternoon of work that answers none of the questions a new developer would actually ask. Documentation written as the build happens is the only kind that works.
Red flags.
-
Any external service account is in the builder's name.
If the AI service, the email integration, or any other tool in your build is on an account the builder controls, your automation depends on your relationship with that person continuing. Ask for every account to be in your name before the build ends.
-
The code is delivered as a zip file rather than a repository.
A zip file is a point-in-time snapshot. A repository is a living record of everything that was built and changed. Any future developer will want the repository. Insist on it.
-
Documentation is described as a future deliverable with no specific date.
It will not arrive. If documentation is not part of the scope with a delivery date alongside the working software, treat it as absent.
-
The builder cannot name a past client whose build was successfully handed to a new developer.
This is the real test. Transferability is easy to claim and specific to prove. Ask for an example, even with names removed.
The short version.
Owning the code means a different competent developer can pick it up without speaking to the original builder. That requires a repository in your name, plain-English documentation, a list of external service accounts, and instructions for the things you will need to update yourself. Ask for all four before you sign anything. A builder worth hiring will not find the question surprising.
If you want to know what a proper handover package looks like in practice, email below.