The hidden dependency
Many technology projects end with a working system and a supplier who is the only party able to change it. The code may technically belong to the client, but the knowledge does not. Every configuration change, every upgrade, every incident becomes a support ticket. That is lock-in, even when every component is open source.
We think this is the wrong way round. A platform built for an organisation should be designed from the first day to be run by that organisation. Handover is not the final phase of the project; it is the product. Our principle is plain: no lock-in, including to us.
Lock-in is rarely deliberate. It grows from small conveniences: an undocumented script on one engineer's laptop, a setting changed in production and never recorded, a password that only the supplier knows. Each is harmless on its own. Together they make the supplier indispensable, and an indispensable supplier has little reason to be efficient.
Design for the operator
Designing for handover changes technical decisions. It favours widely used open-source components over clever bespoke ones, because the client can hire for them. It favours plain configuration in version control over settings hidden in a database. It favours a small number of well-understood moving parts over an elaborate architecture that only its author can reason about.
It also means installation must be repeatable. A platform installed by hand once is a platform nobody can rebuild. Every environment should be installed by script, verified on the machine, and capable of being rebuilt from nothing by someone who was not there the first time.
What a real handover contains
A handover is more than a repository link and a slide deck. The client should own everything needed to run, change or replace the platform without the original builder:
A useful test is to imagine the original builder unreachable for six months. Could your team upgrade a component, recover from a failed disk, onboard a new administrator and explain every rule to an auditor? If any answer is no, the handover is not finished.
- Source code, configuration and installation scripts, in the client's own repositories.
- Documentation written for operators: architecture, runbooks, recovery procedures and known limits.
- Rules and decisions recorded with their reasons, so future changes can respect the original intent.
- Automated checks that prove the platform still behaves as designed after any change.
- Credentials, certificates and secrets transferred to the client's own vault, with every temporary access revoked.
- Training for the team that will run it, ideally hands-on in their own environment.
Checks that prove themselves
Automated checks deserve special attention, because they are the part of a handover that keeps working after everyone has moved on. A good check suite runs on every release and answers one question: does the platform still do what it is supposed to do? On our own releases we run 3,151 automated checks against the platform console pack, a verified figure for that pack.
Checks can also lie, by passing when they should fail. So we go one step further and keep proof scripts that deliberately put a defect back into the system and show that the relevant check catches it. A check that has never been seen to fail has not been proven to work.
Support without dependence
None of this means a client should be left alone. Production support and planned maintenance releases are valuable, and many organisations prefer to have an experienced partner on call. The difference is that the support is chosen, not required. The client could take it in-house, move it to another supplier or stop it altogether, and the platform would keep running.
That choice changes the relationship. A supplier that knows it can be replaced has every reason to stay useful. A client that knows it can leave can afford to stay.