Denshin / Blog / Process
What you should get when a software studio hands over your project
The app works, everyone is happy, and six months later the domain is in an ex-developer's name. A plain checklist of what you should own, and be able to do, when a studio hands over your project.
Denshin Team · Delivery · 23 October 2026 · 4 min read
The last week of a project is when people relax, and it is also when the most expensive mistakes get made. Not bugs. Ownership mistakes. The app works, everyone is happy, and six months later the client discovers that the domain is registered to a developer who has since left, the production database lives in the agency's AWS account, and the only copy of the payment gateway credentials is in a WhatsApp chat.
We have inherited enough projects in that state to have firm opinions about handover. When a studio finishes your project, us included, this is what you should be holding.
Things you should own outright
The principle is simple: anything that would stop your product working if the studio disappeared should be in your name, in your accounts, from the start. Not transferred at the end. From the start, because "we'll move it over at handover" is how things end up never moving.
- The source code, in a repository inside your own GitHub (or GitLab, or Bitbucket) organisation, with full history. A zip file is not a handover.
- The cloud account the product runs in. Your AWS, Azure or Google Cloud account, with billing on your card, where the studio has been given access rather than the other way round.
- The domain name and DNS, registered to your company, with the registrar login in your password manager.
- Every third-party service the product depends on: payment gateway, transactional email, SMS or WhatsApp provider, maps, analytics, error tracking, app store developer accounts. Each one registered to a company email address you control.
- Admin accounts in the product itself, for at least two people on your side.
- Any paid licences, fonts, themes or stock assets, bought in your name.
If any of these currently sit with the studio, ask for them to be moved before the final invoice is paid. A decent studio will not mind. A studio that resists is telling you something about the next conversation you will have with them.
Things you should be able to do without us
Owning the accounts is half of it. The other half is being able to actually operate the thing, which means documentation. Not a long document, a specific one.
A runbook should cover, in plain steps: how to deploy a change to production, how to roll back a bad deploy, how to rotate a secret, how to restore the database from a backup, and where the logs live when something breaks. Someone competent who has never seen the project should be able to follow it. The fair test is to hand it to a developer from another team and ask them to do a deploy using only the runbook. It is humbling the first time.
Deploys should be scripted, ideally with the infrastructure described in code. If deploying requires one specific person to remember an order of commands, you do not have a deploy process, you have a dependency on a person.
You should get a list of every environment variable the application reads, what each one is for, and where its value is stored. The list, not the values. Values belong in your password manager or your cloud provider's secret store, never pasted into an email or a chat. And after handover, rotate them. Every secret the studio's team has seen should be replaced with one they have not.
A short note on the data model helps more than people expect. Which tables or collections exist, what the important fields mean, and any rule that is not obvious from the code, such as "a project disappears from the public site when its end date passes". This is the knowledge that walks out the door with the original developers.
The less obvious items
A recorded walkthrough. An hour on a video call where the lead developer walks through the codebase, the admin panel and the deploy, recorded and saved somewhere you own. It costs very little and it will be the most useful onboarding material your next developer gets.
A list of known issues and loose ends. Every project ships with some. You want them written down honestly, with a rough sense of severity, rather than discovered later. A studio that hands you a clean list of open problems is more trustworthy than one that claims there are none.
A one-page guide to the admin panel for non-technical staff. We ship the admin panel with the product every time, and a short guide to it saves a surprising number of support emails.
Backup and monitoring details: what is backed up, how often, how long backups are kept, and who gets alerted when the site goes down. If the answer to the last question is the studio's on-call phone, that needs to change, or be covered by a support agreement in writing.
Ask for this before you sign
The best time to agree on handover is at the start, in the contract, not in the final week. If you are talking to studios now, add it to your list of questions to ask before you hire one. A studio that does this properly will have a checklist of its own and will be relieved you asked.
Tags: Handover, Ownership, Documentation, Process
All posts · Work with Denshin