Why we plan the handoff before we write code
There is a kind of engagement that never ends. The system gets built, it works, and then it turns out that only the people who built it can keep it working. The client keeps paying, not because they want to, but because the alternative is a system nobody understands. Everybody involved knows this is not a success. It is a dependency with an invoice.
We decided early that we would not build those. The way to avoid it turned out to be simple to state and demanding to do: plan the handoff before the first line of code.
The exit shapes the architecture
Once you know that a specific team, with specific skills, will own the system in six months, a lot of decisions make themselves.
If the team does not have engineers, the system's content and configuration have to live somewhere non-engineers can change them. That is why our mobile platform for a community organization put every piece of content in a CMS the client's staff could run.
If the team has engineers but not AI specialists, the AI parts need to be legible: prompts in version control with comments, evaluation harnesses that explain what they test, and no clever indirection that only its author can follow.
If the client might change vendors or platforms later, the architecture needs seams. Apps talk to an adapter, not to a backend directly, so the backend can be swapped without rewriting the front.
None of these are hard. All of them are easy to skip if the exit is somebody else's problem.
The owner is in the room from day one
Every system we build has a named owner on the client's side before we start it. Not a sponsor, an owner: the person who will be paged, who will make the next change, who will explain it to their successor.
That person pairs with us while it is being built. They review the pull requests. They run the evaluation harness themselves. By the time we leave, they have not been handed a system; they have been working on it for weeks and we have been getting out of the way.
This slows the first two weeks and speeds up everything after. It also changes what we build, because an owner in the room says "we would never operate it that way" at the moment it is cheapest to hear.
Documentation as a deliverable, not an afterthought
We write the documentation as we go, and we write it for the reader who will actually need it. Setup and deployment for whoever runs it. A functional reference for the people who use it. A technical reference for the engineer who inherits it. Decision records for the person who, a year from now, asks why on earth it works this way.
On the mobile platform that meant a large body of operator documents delivered into the client's own repository, with tagged milestones so they could see exactly what shipped when. It is not glamorous. It is the difference between a system a team owns and a system a team is afraid to touch.
Measure how much runs without you
The last piece is honesty about progress. On ongoing engagements we track, each quarter, how much of the work the client's team now does without us: which systems they change on their own, which incidents they resolve, which decisions they make without asking. The number should go up. If it does not, the engagement is not working, no matter how much we shipped.
This is uncomfortable to measure, because it is measuring the rate at which we make ourselves unnecessary. That is the job.
The commercial objection
People sometimes point out that this is a strange way to run a consultancy. Would it not be better business to be needed indefinitely?
In the short term, perhaps. In the long term, the clients who own their systems come back for the next one, recommend us to the next company, and talk about what they built rather than what they rented. A practice built on handoffs compounds. A practice built on dependencies plateaus, and everyone involved can feel it.
So we plan the exit first. Everything else follows from that.