You own it. Here is exactlyhow you would leave.
Not on final payment — from the first commit. This page is the arrangement, the worst case, and a checklist you can use against any supplier including us.
What you already hold.
Not on final payment, and not on completion. This is the arrangement from the first commit onwards, which is what makes the rest of this page possible.
What exists, where it lives, whose account it is in, and what we hold
| What | Where it lives | Whose account | What we hold |
|---|---|---|---|
| The source code | Your GitHub organisation | Yours | Write access, which you can remove. |
| The database | Your Supabase or cloud account | Yours | An administrator login, which you can remove. |
| Hosting and deployment | Your Vercel or cloud account | Yours | A team member seat, which you can remove. |
| The domain | Your registrar | Yours | Nothing. We do not register domains on a client's behalf. |
| Your data | The database above | Yours | Nothing beyond what operating it requires. |
| Third-party accounts | Your accounts, in your name | Yours | API keys we set up, which you can rotate. |
| The documentation | The repository, beside the code | Yours | Nothing. It is committed, not hosted by us. |
What happens if SoftWrites disappears tomorrow.
Not a managed handover — the version where we stop answering the phone.
- Nobody has to do anything
The system keeps running.
It is deployed in your accounts, on infrastructure you pay for directly. Nothing routes through us, and no licence of ours is required for it to serve a request. Our disappearance is not an outage.
- You do this
Remove our access.
Three or four accounts: the repository, the database, the hosting, and whatever third-party services the system uses. Each is a member you delete, not a migration you run.
- You do this
Read the handover document.
It is in the repository, updated as part of the work rather than written at the end. What the system does, how it is deployed, what runs on a schedule, what to watch, and what we would have done next.
- You do this
Give it to another developer.
Standard languages, standard database, standard hosting, no framework of ours. The handover pack names specific firms we would suggest, so the conversation starts with somebody rather than with a search.
- Nobody has to do anything
There is no data to extract.
Your data was never in a system of ours. There is nothing to export because there is nothing held anywhere you cannot already reach.
- Nobody has to do anything
There is no contract to exit.
The build is paid a phase at a time and the retainer is monthly. If we vanish mid-phase you have lost the remainder of one phase, and you keep everything that shipped in it.
The offboarding checklist.
Written to be used against any software supplier, including us. If you are leaving somebody else, take it — several of these are things a supplier will not raise on your behalf.
Before you tell them
- Confirm the repository is in your organisation, not theirs.Check the URL. If it is under their account, this is the first thing to fix and it is easier before the conversation than after.
- Confirm you are the billing owner of every hosting account.Billing owner, not administrator. The person who pays cannot be locked out.
- Confirm the domain is registered to you.
- Take a database backup you have restored yourself.Not one they took and handed you. One you produced and proved works.
The handover
- A written description of what the system does, by area.
- How it is deployed, and how to deploy it.Including which branch, what runs on merge, and what has to be set for a fresh environment to work.
- Every scheduled job, what it does and when it runs.The most commonly missed item, and the one that fails silently three weeks later.
- Every third-party service, what it is for, and whose account it is in.
- Every environment variable, and what breaks without it.
- The backup and restore procedure, with the date it was last tested.
- Known problems and what they would have done next.Ask for this in writing. A supplier who will not write down the weaknesses is telling you something.
Access
- List every account they can reach, and remove each one.
- Rotate every credential they have held.Removing a person does not rotate a key they copied. These are separate jobs and only one of them is obvious.
- Check for automation running under an individual's login.If a scheduled job authenticates as a person who has left, it stops when their account does.
- Confirm nothing sends email from a domain they control.
After
- Deploy once, yourselves, before you need to.The handover is not verified until somebody who is staying has done a deployment.
- Restore a backup into a scratch environment.
- Confirm the monitoring alerts reach somebody who still works there.
Plain text, no tracking, no address required. It is also laid out to print from this page.
What would actually be hard.
- Knowledge that is genuinely in our heads and not in the repository. We write things down as we go and the handover document is real, but somebody who has worked on a system for a year knows things that are not written anywhere, and pretending otherwise would be the easiest lie on this page.
- The first few weeks with a new developer will be slower than the last few weeks with us. That is true of any handover and it is a real cost of leaving. It is not a reason to stay, but it should be in your estimate.
- We have never actually done this. No client has left us, because we have not had a client system under management long enough for one to. Everything above describes how we operate rather than a process we have rehearsed, and the first real handover will find something this list has missed.