What happens after we ship: handover, docs, ownership

The riskiest moment in a software project is not the build. It is the week after launch, when the team that knows how everything works stops being paid to think about it.

We have inherited enough products where that transition went badly to have strong views. Here is what a proper handover contains, and what to demand from anyone who builds for you — us included.

The six documents

1. Credentials inventory

Every account, who owns it, and where the credentials live. Domain registrar, DNS, hosting, database, payment gateway, messaging provider, analytics, error tracking, email, app store accounts, and the certificate for signing builds.

The failure mode here is boring and catastrophic: an app that cannot be updated because the signing certificate lived on a former contractor’s laptop, or a domain that expires because the renewal email went to an address nobody reads.

Rule: every account is registered to a company email you control, not to an individual. The studio gets added as a collaborator, never as owner.

2. Architecture note

Two pages. What the pieces are, how requests flow, where data lives, what talks to what, and the three decisions that would surprise a new reader.

Not a diagram generated from code. A human explanation of why it is shaped this way — that context is what disappears when the team leaves. The rules file we keep in every repo carries most of this already, which is one of the reasons we write it.

3. Runbook

The operations manual for the things you will actually need to do. Add an admin user. Refund an order. Re-send a failed webhook. Export data for the accountant. Rotate a key. Restore from backup.

Each one written as steps a careful non-author can follow. This document earns its keep in the first month.

4. Deploy and rollback procedure

How a change reaches production, who can do it, how long it takes, and — the part usually missing — how to undo it.

If your rollback plan is “call the developer”, you do not have one.

5. Environment reference

Every configuration value, what it does, which environment it applies to, and which ones are secret. Values themselves stay in a secret manager. The reference is the map.

6. Known issues

Honest, ranked, with severity. Every product ships with compromises. A studio that hands over a list of them is telling the truth; one that claims there are none is either not looking or not saying.

The technical handover

Documents are half of it. The rest is state.

Repository in your organisation. From day one, not moved at the end. Full history, branches, and the pipeline configuration.

A staging environment that matches production. If staging does not exist, the next developer tests in production. That is how outages happen.

Working migrations. Somebody must be able to rebuild the database from files in the repository. This is the item most often missing on rescues, particularly on AI-assisted builds — a pattern we cover in the production triage post.

Monitoring pointed at your inbox. Error tracking, uptime checks and spend alerts must reach you, not just the studio.

Backups you have restored once. An untested backup is a hypothesis. Restore it to staging as part of handover, and know how long that takes.

The handover meeting

An hour, recorded, with the actual engineers rather than a project manager. Walk through the runbook live. Deploy a small change together. Break something in staging and roll it back.

Anything the recipient cannot do unaided in that hour becomes a documentation fix before the engagement closes.

What comes next: three honest options

Retainer. The studio stays on a monthly basis for monitoring, patching and a small change budget. Right when the product carries revenue and you have no in-house engineer. From about ₹40,000 a month at our end — the reasoning is in what we charge.

Ad-hoc. You call when something breaks. Cheaper, slower, and you are in a queue. Fine for internal tools, risky for anything customer-facing.

In-house takeover. You hire and the studio hands over. This works well when the handover pack is real, and it works badly when it is not. Overlap for a month if you can — one engineer, one studio, same repository.

The maintenance nobody budgets for

Software decays even when nobody touches it. Dependencies age out of support. Payment providers change APIs. Browsers and mobile operating systems ship updates that break assumptions. Certificates expire.

Budget 10 to 20% of build cost per year. A ₹5L product needs ₹50,000 to ₹1L annually just to stay where it is. That number surprises founders, and it is far smaller than the rebuild that follows two years of neglect — we quote those regularly and they are never cheap.

The test

Here is how to know your handover is real. Give the pack to a developer who has never seen the project. Ask them to deploy a text change to production.

If they can do it in a morning using only your documents, you own your product. If they cannot, you are renting it from whoever built it — and that dependency will cost you at exactly the wrong moment.

Ask about the handover pack before you sign, not at the end. It is question eleven for the hiring checklist, and the answer tells you a great deal about how the last week of the project will go.