Owned, not leased: a case for handing the keys back
Most AI consulting ends with a dependency. We think that's the wrong model. Here's why we structure every engagement around handing the client full ownership of what we build.
The consulting model has a well-known failure mode: the consultant leaves and the client can’t maintain what was built. The code lives in a private repo the client doesn’t fully understand. The infrastructure is in an account they have nominal access to. The institutional knowledge is in someone’s head, and that someone is now at their next engagement.
AI consulting has a particularly acute version of this problem, because the work tends to be novel and because the tooling moves fast. A system built on a specific framework today may be unmaintainable — or simply abandoned by its creator — in eighteen months.
We think the right response is not to mitigate this dependency, but to eliminate it.
What “handing the keys back” actually means
At the end of every engagement, the client should be able to:
- Read and understand the code we wrote
- Deploy it themselves, from scratch, with no help from us
- Maintain it with a competent engineer who wasn’t involved in building it
- Replace us — or fire us — without losing access to anything
This sounds obvious. In practice, it requires deliberate choices at every step of the build.
The choices that make it possible
Languages and frameworks the client’s team already knows. We write TypeScript and Python because the client’s engineers already know them. We don’t introduce frameworks we like that require a week of onboarding.
Infrastructure the client controls. Everything runs in the client’s own cloud account, not ours. We set it up, we hand them the credentials, we teach them what it does.
Documentation written for the next engineer, not us. Runbooks, architecture decisions, the reason we made the weird choice in the queue configuration — all of it, written down, in the repo, before we leave.
No proprietary lock-in. If a vendor disappears, the system should degrade gracefully or be replaceable with a week of work.
Why this is good business
Clients who own their systems don’t resent you. They refer you. They come back for the next project. The dependency model creates recurring revenue but destroys trust. The ownership model creates trust and, it turns out, more durable recurring relationships.
The best outcome of an engagement is a client who can run without us, and who chooses to call us again anyway.