The handover test

Here is a test worth applying to any external team you hire, including this studio: if they disappeared tomorrow, mid-project, how bad would it actually be? Call it the handover test. Every engagement passes or fails it, and the outcome is decided not at the end, in a handover meeting, but continuously, in a hundred small defaults from day one.

The failing version is common enough to have a familiar shape. The code lives in the vendor's GitHub organization. The app deploys from the vendor's cloud account, under credentials only they hold. The domain, mysteriously, is registered to them. Documentation is a promise scheduled for the final sprint, which is exactly when the relationship is most likely to be strained. None of this is usually malice. It is the accumulation of convenience: their org was already open, their account was already configured. But the result is identical to lock-in by design, and the client discovers it at the worst possible moment, holding a product they paid for and cannot operate.

The passing version is a set of defaults, each unremarkable alone. The repository lives in the client's organization from the first commit, with the vendor as a collaborator who can be removed in one click. Infrastructure runs in the client's cloud account, billed to their card, with the vendor holding revocable access rather than ownership. Secrets live in the client's manager. The domain, the app store listings, the third-party services: registered to the client, always, no exceptions for convenience. Documentation is written as the system grows, because the architecture decision is best recorded in the week it was made, not reconstructed from memory in the final sprint.

Notice what these defaults have in common: they cost the vendor almost nothing during the project. Setting up a repo in the client's org takes the same ten minutes as setting it up in ours. The only thing ownership-by-default costs the vendor is leverage, and that is precisely the point. An external team that holds your infrastructure hostage, deliberately or by drift, has converted your project into their annuity. The relationship should be held together by the quality of the work, not by the cost of leaving.

There is a less obvious beneficiary of the handover test: the next engineer. Every project eventually gets a next engineer, whether an in-house hire, another agency, or the founder's technical co-founder arriving at last. That person's first week is the audit no vendor can talk their way out of. Does the README's setup actually run? Do the tests pass? Do the architecture notes explain why, or only what? We find it clarifying to work as if that audit were scheduled, because it is. The date is just unknown.

Clients can enforce all of this with one habit: ask the handover question at the start, in the contract, when it is cheap, rather than at the end, when it is leverage. Whose org, whose accounts, whose names on which services, what documentation exists at each milestone. Any vendor who bristles at those questions has answered them.

And vendors get the better end of the deal anyway. Working as if you could be replaced tomorrow produces the kind of work that ensures you will not be.