What you should own when a software studio hands over
A handover that's only a repository isn't a handover. Here's the checklist we work against, and what to ask any studio before you sign.
The most expensive thing that can happen after a build isn't a bug. It's discovering that the software runs on an account you don't control, deploys through a pipeline only one person understands, and depends on a service nobody documented. The code was delivered. The system wasn't.
This is our own handover checklist. We're publishing it partly because it's the standard we hold ourselves to, and partly because it's a fair list to hold any studio to — including when you're deciding between us and someone else.
1. The code, in your organisation
Not a zip file, and not a repository inside the studio's account that you've been added to as a collaborator. The repository should live in an organisation you own, with full history. Squashing months of work into a single 'initial commit' destroys the record of why decisions were made — that history is a large part of what you paid for.
2. Infrastructure in accounts you control
Cloud provider, database, domain registrar, DNS, error tracking, email sending, anything with a bill attached. These should be your accounts, with the studio holding delegated access that can be revoked without anything breaking.
The test is simple: if the relationship ended tomorrow with no goodwill on either side, does the system keep running? If any single revoked account takes production down, that's not handed over.
Ask directly: which accounts is this deployed to, and whose name is on them? A studio that has to think about the answer has told you the answer.
3. Secrets, in a place you can rotate them
API keys, database credentials, signing secrets, third-party tokens. You need the inventory — what exists, what it's for, where it's stored — and the ability to rotate any of it without the original developer. Credentials that only live in one person's environment file are a single point of failure with a person attached.
4. A runbook, not just a README
A README explains how to run the project locally. A runbook explains how to operate it when something is wrong at an inconvenient hour. The difference matters most on the worst day you'll have.
- How to deploy, and how to roll back
- Where logs and errors surface, and how to read them
- The scheduled jobs: what runs, when, and what breaks if one doesn't
- Restoring from backup — with a note of when that was last actually tested
- The three or four failures most likely to occur, and the first thing to check for each
5. The decision record
Why this database, why this queue, why this integration works the way it does, what was considered and rejected. This is the knowledge that normally walks out of the door, and its absence is why the next team's first instinct is to rewrite rather than extend — not because the code is bad, but because they can't tell which parts are load-bearing.
6. A working local environment, verified by someone else
Setup instructions that were only ever run on the machine of the person who wrote them are usually wrong in small ways. The check is that a developer who didn't build the system can go from a clean machine to a running application using nothing but the written instructions. If that's never been tried, it's a guess.
7. Tests that describe the business rules
Coverage percentage is a weak signal. The useful question is whether the rules specific to your business — the ones that would cost money to get wrong — are written down as tests. Those are the ones that let the next person change the system without quietly breaking an invariant nobody remembered.
Why we publish this
Handover is where the incentives of a studio and a client diverge most sharply. A system only its builder can maintain produces repeat revenue; that's a real commercial pull, and it's worth naming rather than pretending it doesn't exist.
We'd rather be hired again because the work was good. So: ask for this list. Ask us, and ask whoever else you're considering.