Hand over

Client work ends. At some point the site is live, the invoice is paid, and somebody has to answer who is responsible for the hosting from now on. Most hosting arrangements answer that badly, which is why so many finished projects sit on an agency account years later, quietly billed to the wrong party.

# Ownership and infrastructure are separate

The usual reason a handover hurts is that ownership was tied to infrastructure, so changing one meant moving the other. An app here has an owner, and that owner can change without the app moving. Code, database, domains, certificates, and environment variables stay exactly where they are.

That turns a handover into a short administrative act rather than a project. There's no migration window, no DNS propagation to wait out, and nothing to re-test afterwards, because nothing about the running application was touched.

# Billing follows ownership

Once a client's account takes over an app, the charges appear there. Payment methods are held per account, so the agency card is not involved after the transfer, and nobody is passing hosting invoices through with a markup.

Billing is pro-rated and post-paid by the day, so a transfer that lands mid-month doesn't mean either side pays twice for the same period.

# Access outlives ownership

Handing over the account doesn't have to mean handing over the work. Most clients who take ownership still want the person who built the site to keep maintaining it, and most developers want a maintenance retainer to survive the handover.

Access is granted per person and per app, separately from ownership. A client can own an app, pay for it, and still have granted the original developer the deploy and SSH access needed to keep working on it. That access can also be revoked without touching the app, which is what makes a clean break clean when the relationship genuinely ends.

# It works in every direction

Handover is not only agency to client. A freelancer growing into an agency, a contractor swapping out mid-project, a client bringing development in-house, an agency inheriting a site somebody else built — they're all the same operation.

Teams map the same way. People join and leave, roles change, and an app can be shared across teams when more than one party needs it. None of that requires touching the application.

# Build for it from the start

Handovers go badly when they're discovered at the end. A few decisions made early decide whether it's a five-minute operation or a week of archaeology.

Configuration belongs in environment variables rather than in code, so credentials can be rotated by the new owner without a deployment. Anything scheduled belongs in the jobs component rather than in somebody's personal crontab. Uploaded files belong in the storage component rather than on a local disk. Each of these keeps an application self-describing, which is the property that makes it transferable — and, incidentally, the property that makes it maintainable by whoever comes next.