No lock-in, on purpose: the setup that lets you fire us
The real test of an AI partner isn’t how good the demo is — it’s whether you can walk away and keep everything working. We design for that on day one.
A lot of AI consulting quietly sells dependency. The system runs on the vendor’s account, behind the vendor’s API key, with the prompts and the glue code living somewhere you can’t see. It works — right up until you want to leave, renegotiate, or just understand it. Then you discover you don’t own a system, you rent one.
We build the opposite on purpose. The goal is simple and a little uncomfortable to say out loud: you should be able to fire us and lose nothing. Here’s what that takes.
If you can’t switch us off and keep it running, you don’t own it — you’re renting it.
It runs on your accounts, not ours
The system lives in your cloud, your model provider account, your databases. We get access during the engagement; we don’t become the landlord. When we leave, there’s nothing to migrate off our infrastructure, because it was never on it. Your bill comes from your providers directly, at cost — no markup hidden in a “platform fee.”
Method note — the ownership checklist Before we call a pilot done, we confirm: code in your repo; secrets in your vault; it runs in your cloud and model accounts; your team has admin, not us; and a runbook exists that a new engineer could follow cold.
The code is plain, and it’s yours
It lives in your repository from the first commit. We avoid proprietary runtimes and exotic frameworks that only we understand; we prefer boring, well-documented tools your team can hire for. If a capable engineer who has never met us can read the code and the runbook and keep it alive, we’ve done our job.
No magic in the prompts or the glue
The prompts, the rules, the evaluation scripts — the parts people love to keep secret — are all checked in and documented. “How does it decide?” should have an answer you can read, not a black box only we can open. That transparency is also what lets your team improve it later without us.
The handoff is the deliverable, not an afterthought
Knowledge transfer isn’t a final-day slideshow. Through the build, your engineers have access and we work in the open. At the end you get a written runbook (how to run it, deploy it, and what to do when it misbehaves), a short architecture note, and a walkthrough with the people who’ll own it. The test we apply: could your team make a change next month without calling us? If not, we’re not finished.
0 Things you’d lose if you ended the relationship tomorrow. The code, the accounts, the data, and the know-how are already yours.
Why we’d build something that lets you leave
Because it’s the honest pitch, and because it makes us better. If clients stay only because leaving is painful, we never have to be worth keeping. Designing for a clean exit forces the work to stand on its own — measured value, readable code, a team that can run it. We’d rather earn the next engagement than trap you in this one.
It also lowers your risk to almost nothing. Trying a pilot with us isn’t a marriage to our stack or our availability. If we’re great, you keep working with us because you want to. If we’re not, you keep everything we built anyway. The lock-in was never doing any work that the quality of the system couldn’t do on its own.