Exit-ready by design: why making it cheap to fire us keeps us hired

Every agency will tell you the relationship is built on trust. Look at the contract and the architecture instead, because a lot of them are built on switching costs: your code in their repos, your infrastructure in their cloud account, the operational knowledge in their heads, and an exit priced — carefully, implicitly — to be unthinkable. We build the opposite in from day one, on purpose. It must always be cheap to fire us. That sentence is not a slogan; it is the design constraint everything else here follows from.

Lock-in is a business model

None of it requires malice — only billable incentives followed downhill. The repos live in the vendor’s organisation “for convenience”. The cloud runs through the vendor’s account, resold. Documentation never happens, because hours spent writing it are hours not billed, and the undocumented system conveniently requires its authors. Teams are blended and anonymous, so the knowledge maps to the company rather than to people you could name, keep or hire. Then, at renewal, the negotiation is conducted against your own cost of leaving. Every step was locally reasonable; the sum is a client who stays out of fear. Renewals built on fear feel like victories to the vendor and like hostage payments to everyone else.

Your repos, your cloud, from day one

The structural fix is boring and absolute: from the first commit, the code lives in your version control organisation and the infrastructure runs in your cloud accounts. Our engineers are collaborators whose access you can revoke this afternoon. There is nothing to migrate at exit because nothing was ever ours to give back. This pays off long before any exit, too — due diligence in a funding round or acquisition starts with “show us the repos”, security reviews want to inspect the actual infrastructure, and your own hires onboard into systems you demonstrably control.

Exit-readiness lives in the definition of done

An exit package assembled in the last month of a contract is fiction with a table of contents. So exit-readiness is not a hand-back ceremony; it is part of our definition of done, continuously. Documentation stays current because stale documentation fails review. Architecture Decision Records capture why things are the way they are, at the moment the decision is made. And we run handover drills — periodically answering, with evidence, the question “could a competent stranger take this system on with what is written down?” A useful side effect: a team that can hand over to a stranger also survives its own personnel changes gracefully. The discipline pays for itself even if you never leave.

What an exit-ready handover actually contains

  • Repos and CI already in your organisation — nothing to transfer; only access to revoke.
  • The ADR log — every consequential decision with its reasoning and the alternatives that were rejected, so the next team inherits judgement, not just code.
  • Runbooks — deploy, rollback, incident response and the on-call knowledge that usually lives in one person’s head, in text.
  • Test and eval suites wired into CI — the definition of “working” is executable, not tribal. A new team can change code on day one and know what they broke.
  • An access inventory — every credential, secret and third-party account: where it lives, who holds it, how to rotate it.
  • A handover drill record — evidence that someone outside the team has actually walked the documentation, and what got fixed because of it.

This list doubles as a vendor test. Ask any prospective partner — us included — to describe their exit package before you sign. A vendor who cannot answer quickly has already told you what leaving will cost.

Why cheap exit produces renewals

Here is the inversion that makes this a business strategy rather than charity. When leaving is cheap, staying becomes a decision our clients re-make on merit, effectively every month — which means we have to earn the engagement on the work itself, continuously. Conveniently, the practices that make us easy to replace are the same ones that make a team good: current documentation, recorded decisions, named engineers who stay, review gates an outsider can audit. It is the same incentive alignment as our named-squad, no-blended-rates model — remove the tricks, and what remains has to be quality. Being replaceable but not replaced is, as far as we can tell, the only kind of client relationship worth having.

If you are evaluating partners, put the exit question first — it predicts everything downstream of it. And if you want to hear how we would answer it for your system, that conversation is a technical call, not a sales call.