How we hand off code at the end of an engagement

The single biggest fear in enterprise procurement is vendor lock-in. Buyers have been burned by agencies that ship a black box, keep the keys, and then quietly raise the retainer every quarter. We don’t work that way. This post walks through exactly what a client owns when a Courtix engagement ends, and how we get them there.

Handover is part of the build, not an afterthought

We design every engagement with the handover in mind from week one. That means readable code, conventional tooling, no exotic dependencies that exist only to make us indispensable. If a competent engineer outside Courtix can’t pick up the repository and ship a small change inside a day, we haven’t done our job.

What the client owns from day one

The client owns everything from the first commit. Specifically:

• The source code, in a repository on the client’s GitHub or GitLab organisation, not ours.
• The cloud accounts (Cloudflare, AWS, GCP), in the client’s name with the client’s billing.
• The domain names, DNS zones and TLS certificates.
• Every secret, API key and service account, rotated to client-owned credentials before launch.
• All written artefacts: SOWs, architecture documents, threat models, runbooks.

We work inside the client’s accounts as collaborators. We do not host code, infrastructure or credentials on Courtix-owned accounts and then "migrate" them at the end. That migration is the lock-in.

The handover artefacts

Before we close an engagement, the client has the following in writing:

• Architecture decision records for every non-obvious choice (why this database, why this queue, why this deployment topology), so the reasoning survives the people.
• Runbooks for every recurring operational task: deploys, rollbacks, common incidents, credential rotation, scaling events.
• A threat model kept current with the final shipped system, aligned with our Secure SDLC Policy.
• An onboarding guide that walks a new engineer from "I have a laptop" to "I just merged a pull request" in under a day.
• A dependency inventory with licences and update cadence, so the next team isn’t surprised by a paid component six months later.

If any of these are missing, the engagement isn’t done.

The walkthrough

Documents alone aren’t a handover. We run live walkthrough sessions with the client’s receiving team, recorded for the people who join later. We cover the architecture, the deployment pipeline, the on-call runbooks and the known sharp edges. We answer questions in front of the code, not over email a week later.

For larger systems we split this across two or three sessions, organised by subsystem rather than by document.

The 30-day tail

For the 30 days after handover we stay on standby for bug fixes related to the work we shipped, at no additional cost. This is a warranty, not an open-ended support contract. It exists so the receiving team can find the things we missed without negotiating a new SOW to get them fixed.

If the client wants ongoing support past that window, we offer it as a separate retainer with a clearly scoped SLA. They can also walk away, and a fair number do, because the handover left them in a position to run the system themselves. That’s the point.

Why it matters

Enterprise buyers are not buying code. They’re buying the ability to operate, evolve and eventually replace that code without us. A handover done well is the proof that we built for their interests, not ours. It’s also the reason clients come back: when the next project starts, they remember that the last one ended cleanly.