There is a category of engagement that looks like a delivery but functions as a subscription. The system works. The client owns it on paper. And yet every change requires the original supplier, because nobody else can safely touch it.
How dependency gets built
Rarely on purpose. It accumulates: undocumented deployment steps, infrastructure provisioned by hand, an architecture that made sense to whoever held the whole thing in their head. Nobody decides to make a client dependent. It is simply what happens when handover is a phase at the end rather than a constraint throughout.
What handover has to include
- Infrastructure as code, for every environment, with no manual steps
- Repositories in the client’s organisation from the first commit
- Runbooks for the failures that are actually likely, not a generic template
- A period where the client’s team deploys while we watch, not the reverse
- An architecture decision record explaining why, not just what
Simplicity is a handover feature
The strongest predictor of whether a client can operate a system is how much of it they have to understand at once. Every clever abstraction that saves us a week during the build costs somebody a month of comprehension later. We now treat architectural cleverness as a cost to be justified rather than a sign of quality.
We would rather earn the next project than hold the last one hostage.
The commercial argument
Clients notice. Roughly ninety per cent of our work comes from referral, and the referrals are almost always framed the same way: they built it and then they left, and it kept working. That is a better position to sell from than an unbreakable support contract.