When we take on an Enterprise Build, the first commit lands in the client's repositories and the first environment is provisioned in the client's cloud account. Not ours. Not a shared workspace that gets migrated at the end once the invoices are settled. Theirs, from the beginning.
That sounds like an operational detail. It is not. It decides who holds the leverage for the life of the software, and it changes what kind of firm we have to be in order to keep the work.
What lock-in actually looks like
Vendor lock-in is not a clause in a contract. Nobody writes down that the agency keeps the code. It arrives through defaults, and the defaults look like this.
The repository lives in the agency's organization, with an export promised later. The servers run in the agency's cloud account, on the agency's billing, under the agency's access management. The domain gets registered on someone's personal account because that was faster on the day. The CI pipeline holds a dozen secrets nobody outside the agency has ever read. Production deploys from one engineer's terminal because the script was never finished. Error tracking, the payment dashboard and the mail provider all sit behind the agency's logins.
None of that has to be malicious. It is what happens when nobody decides otherwise in the first week. The result is the same either way: the client cannot answer "what happens if we stop working with them" without commissioning a project to find out. The switching cost is not the source code. Source code is easy to hand over. The switching cost is the operational knowledge of how the thing runs, and that sits with whoever has been holding the keys.
What "you own it" means concretely
Ownership is a checkable state, not a sentiment. So here is the standard we hold ourselves to, written down so it can be held against us. Four things have to be true.
- Repositories. In the client's organization, under the client's administrators, with the full commit history rather than a squashed dump at the end. Infrastructure definitions and deployment pipelines belong there too, because those are the expensive parts to reconstruct.
- Infrastructure. The client's cloud account, the client's billing relationship, the client's identity provider — with us working inside it as invited users on scoped roles the client can revoke without asking us anything.
- Credentials. Secrets in the client's secret manager, not in a config file we email over. Registrar, DNS, payments, mail and monitoring accounts created under the client's domain and owned by the client's people from the moment they exist.
- Documentation. Architecture decisions written down as they are made, with the reasoning and the rejected alternatives. Runbooks for the operations that genuinely happen: deploy, roll back, rotate a key, restore a backup, add an engineer. Written for someone who was not in the room.
The test behind those four is uncomfortable on purpose. If we vanished this afternoon, could the client's team ship a change tomorrow morning? If the honest answer is no, that is not a relationship. It is a hostage.
Handover should be boring
Handover gets staged as an event. A knowledge transfer week. A document dump. A call where the outgoing engineers compress a year of context into ninety minutes. It is treated as normal, and it can even end up on an invoice.
The ceremony exists because the knowledge lived in the vendor rather than in the system. If the work has been in the client's cloud and the client's repositories throughout, there is nothing to transfer. Handover becomes an access change: remove us from the organization and the cloud account, and nothing else moves. No migration window, no DNS scramble, no rebuilt pipeline, no archaeology.
You cannot retrofit that in the final week. A boring handover is the compounding result of small decisions taken from the first one. An interesting handover is a symptom of how the project was set up on day one.
What changes when the client can leave at any time
Quite a lot, and all of it in the client's favor.
Architecture gets chosen on merit. When leaving is hard there is a quiet incentive to reach for the tool only you understand. When leaving is easy that incentive disappears, and boring, well-documented, widely known technology wins, because the client's next engineer has to be able to read it.
Documentation stops being a deliverable and becomes part of how the work is done, since it is the thing standing between us and a support call at midnight. Renewal has to be earned by the next piece of work being worth buying, not by the cost of escape. The commercial posture follows the same logic: fixed scope, published prices, no rate card, no billable hours, no proposal cycle. Every engagement we sell is on the store with its price on it — all four of them, priced in public before you speak to anyone here.
This is the default on Product Development — Enterprise Build, from $25,000: software carrying real users, real money and real data, with the architecture settled before anyone writes feature code. If you are not ready to commit an engineering budget, Product Feasibility, from $3,500, tests one idea before that budget exists — market reality, technical risk priced by a working spike, a three-band cost envelope, and a build or do-not-build recommendation with the reasoning shown.
If what you want is a supplier who holds the whole thing and stays the only party who understands it, we are not that firm. If the opposite sounds right, write to us.