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
- Know exactly how it’s deployed and run, and who’s responsible for keeping it that way
- Bring in a competent engineer who wasn’t involved in building it, if and when they want to maintain it themselves
- 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.
No proprietary infrastructure. When a client already has their own cloud account and the people to run it, we build there directly: their account, their credentials, their access from day one. When they don’t, and a lot of small businesses genuinely don’t have a development and production environment sitting around waiting for us, we stand it up and run it on their behalf, on the same plain, portable infrastructure either way. The difference is who’s holding the keys today, not whether the system is built to be handed over.
Documentation written for the next engineer, not us. Runbooks, architecture decisions, the reasoning behind every non-obvious choice in the system, all of it written down, in the repo, before the engagement ends.
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.