Every engagement ends. The build finishes, the budget runs out or the relationship changes. We plan for that on day one, in writing, because the way an engagement ends tells you most of what you need to know about how it was run.
Lock-in starts as convenience
Lock-in rarely begins as a strategy. It begins as convenience. The repository lives in the vendor’s account because that was quicker to set up. The cloud bill is under the vendor’s name. The domain was registered by whoever happened to be on the call. Each choice is harmless on its own. Together they mean that, at the end, you cannot leave without asking permission.
We design against it from the start, so there is nothing to untangle later.
Yours from the first commit
From the beginning of the build:
- The repository sits in an account you own, and your code lives in it from the first commit. We work in it as collaborators.
- The cloud accounts and the domains are registered to you, not to us.
- The intellectual property in what we build is assigned to you on full payment.
The test is simple. If we stopped replying tomorrow, you would still have the code, the infrastructure and the keys. Nothing you depend on runs through us.
What the handoff contains
A handoff is three things: keys, documentation and training.
Keys means every credential, access and account the system needs, transferred to you and checked.
Documentation is written for the next engineer who has to read it. That might be a new hire, another agency or you, in two years, trying to remember why something works the way it does. It covers how the system fits together, how to run and deploy it, and the decisions that are not obvious from the code.
Training is how your people learn to run the system, so the knowledge does not stay with us. The checklist for all of this is published on the ownership page, so you can read it before you sign anything.
Even before the build
The first piece of work, the written spec, follows the same rule. It is yours to keep. If you read it and decide to build elsewhere, you leave with a document another team can quote against. You paid for it, so you own it. You can read more about that step in why we write the spec before the code.
Why we do this
There is an honest commercial reason and a practical one.
The commercial reason is that if the only thing keeping you with us is the cost of leaving, we have not earned the work. We would rather be chosen again every Friday than be hard to remove. That is a better test of whether the work is any good.
The practical reason is that software built to be handed over is better software. It has documentation because someone else must read it. It has automated tests because someone else must change it with confidence. It has no hidden dependencies because there is nowhere for them to hide. Planning for the exit forces discipline on everything that comes before it.
Staying is a choice
After launch, you can keep working with us on support or a retainer. You do it with the keys already in your hands. That is the only arrangement we are comfortable with.
If you want to understand the terms in full, start with ownership. If you would like to see how the work runs before you decide, read how we work, or start a project and tell us what you are building.