Introduction
Owners usually ask us this one late, after the interesting part of the conversation is over. If we stopped working with you, what would we still have?
It is the right question and it belongs at the start. A connected system holds your customers, your pricing rules, your job history and the way your business actually runs. If all of that only works while one provider keeps answering the phone, you do not own a system. You are renting access to your own business.
So this is what we hand over, and what you should ask of anyone who builds this kind of work for you, including us.
What owning the system actually means
Owning a build is not a feeling of goodwill between you and your provider. It is a set of specific things sitting in accounts with your business name on them.
You own it when you can open every account without asking anyone, take a copy of your data today, read the rules the system runs on, understand what happens when it breaks, and switch it off. Everything below is a way of proving one of those.
There is a real difference between a provider who will give you access if you ask and a provider who put the accounts in your name on the first day. Only the second one survives a bad ending.
What belongs on the handover register
We keep a register for every build. It is written at the start rather than assembled in a hurry at the end, and it is the document we walk through when the work finishes.
- Accounts. Domain, hosting, database, analytics, advertising and profile accounts, plus every outside service the build depends on, each one in the business name with billing under the business card.
- Code and configuration. The repository, the deployment settings, the environment names and enough written context for another competent developer to pick it up without an introduction.
- Data. A current export of customers, jobs, quotes, conversations and files in a format other software can read, plus the way to produce that export again without us.
- Prompts and rules. The exact instructions the system runs on. Your pricing rules, your tone, your escalation triggers and your boundaries, in the words the system reads, not a summary written for a slide.
- Credentials process. Where keys live, who holds them, how they get changed and how our access is removed when we are done.
- Runbooks. What each workflow does, what it touches, what it must never do, and the manual path your team follows the day it stops.
- Tests. The cases the build was accepted against, including the messy ones, so the next person can prove that a change did not break something quietly.
- Alerts. What is watched, who gets told, and what the message means when it arrives out of hours.
- Running costs. Every recurring charge the system carries, named, with the person who is billed for it.
- Off switch. How to pause one workflow or the whole layer, who is allowed to do it, and what happens to work in progress while it is off.
Read that list again as a buyer. Most of it is not technical. It is the difference between a system your business holds and a system your business is a guest in.
No lock in anywhere
That is our standing position and it is worth saying plainly, because the industry mostly does not.
Accounts go in your name from the first day. You can export your data whenever you ask, without a notice period and without it being treated as a favour. The rules the system follows are written in plain language you can read and change. Production work is never trapped inside a monthly service. Where there is a monthly service, it covers running the layer, and stopping it does not take the system with it.
We would rather be kept because the work is good than because leaving is expensive.
What to ask before the build starts
You do not need to know how any of it is built to ask these. Ask them of us and of everyone else you are talking to, and notice who has an answer ready.
- Whose name goes on each account this project creates?
- Can I take a full export of my data today, and what is the process?
- Where are the rules written, and can I read them without you?
- What happens to the system if we stop working together?
- What does it cost to run each month, and who is billed?
- Which of these answers will you put in writing before we start?
A provider who has done this properly will find the questions ordinary. Our implementation standards cover the same ground before launch, alongside access boundaries, owner decisions, the manual path and the measures we agree to.
Do the handover before you need it
The worst time to test whether you can leave is the week you want to leave. Do it while everyone is getting along.
Ask for the export. Sign in to one account you have never opened. Read one runbook. If any of that turns into a project, you have found something worth fixing now, at no cost to the relationship. Providers who work this way expect the check and are not offended by it.
If you would rather see the shape of it than read about it, book an Operations Review. We follow one real example through your business, show you what we would build and what you would hold at the end of it.
FAQs
Does handing everything over mean you stop supporting the system?
No. Most clients stay because the work keeps paying, not because they are stuck. Handover is about where things live and who can reach them. Support is a separate decision you get to make each month.
What if we have nobody technical to receive it?
That is the normal case, and it is why the register is written for an owner rather than a developer. You are not expected to maintain the code. You are expected to be able to hand the whole package to someone else and have them start work without ringing us for permission.
Can we take the system to another provider?
Yes. Accounts, code, data, rules, tests and runbooks all travel together, which is the point of keeping the register current. We will do the transfer conversation properly rather than make the next provider guess.
SOURCES
CONTENTS