Why we hand over the keys.

Software you cannot leave is software you do not own. Most of the industry is built on the opposite premise: the vendor keeps the servers, the keys, and the exit, and the customer keeps a subscription. The arrangement is usually described as convenience. It is more honestly described as custody — theirs, not yours.

This practice is organized around a different idea. Every system we deliver runs on infrastructure the client controls, is sealed to a master key only the client holds, and ships with the evidence — the complete, attributed history of every change — in the client's own hands. When the engagement ends, we delete our access. The platform does not notice, because nothing in it ever depended on us.

Ownership is a technical property

Ownership is often treated as a contractual matter — a clause about data export, an escrow arrangement, a termination schedule. Contracts describe intentions. Architecture enforces them. A platform is owned when it runs on your machines, when its secrets open only with your key, when its software comes from your own registry rather than the public internet, and when the one optional outside service it calls can disappear without taking anything down with it. Ours meets that definition on the day it is installed: the installer mints the master key on your hardware, refuses to finish until your keyholder confirms custody, and leaves no second copy anywhere — including with us.

The same discipline extends to the work itself. Every change, whether a person or the build crew wrote it, lands as a permanent, attributed entry. AI-written changes carry their author, model, and session forever. An independent inspector signs into a working preview and attacks it — cross-user data probes, hostile inputs, broken flows — before anything ships, and the builder cannot approve its own work. The record this produces is not a report we prepare for you; it is the system's native state. When someone asks who changed what and who approved it, the answer is a document.

Why there is no subscription

We sell two things: implementations, scoped per project, and senior development at $250 an hour — rolling or batched. There is no maintenance contract, no scheduled updates, no renewal. This is not an omission. A recurring fee for keeping a system alive is a confession about how the system was built. Ours keeps running — deploying, testing, backing up, repairing its own guardrails — because those functions are part of the platform, not part of a services agreement.

The commercial consequence is deliberate: every engagement is structured so the client can walk away with everything — the code, the keys, the knowledge. A firm confident in its work builds the exit into the contract, and then wins the next engagement on the work rather than on the switching costs. Clients return to us the way they return to a good structural engineer: not because leaving is painful, but because the last thing we built is still standing.

The AI question, answered structurally

An AI crew that builds production software is only as trustworthy as the structure around it. Ours works on temporary credentials scoped to a single project, expiring in hours; master keys never reach a run. Its spending is metered in dollars against ceilings the client sets, with a tripwire for runaway activity and a pause that loses nothing. Its output faces the same gate as everyone else's — and a second, adversarial inspection besides. The governing rules were written down before the crew was granted a single permission, and changing those rules is itself a recorded, approved change. Capability arrived after governance, in that order, on purpose.

What this model is not for

There are engagements this practice does not fit. An organization that wants a vendor to hold the pager — to own the infrastructure, carry the risk, and answer at three in the morning under an SLA — is asking for a managed service, and should buy one. We will say so in the first conversation. What we build is for organizations that intend to hold their own keys, and want the machinery, the evidence, and the discipline that make holding them safe.

The long view

ESPO has engineered for organizations whose systems cannot fail since 1965. Sixty-one years teaches a particular lesson: relationships that survive are built on work that survives, and work survives when it belongs to the people who depend on it. This practice is that lesson, applied to software. We build it on your servers, hand you the keys, and delete our own — and we expect to hear from you again.