You Should Be Able to Run It Without Us
Updated: October 5, 2026 (7531-10-15 in the Bulgarian calendar)
Back to Strategic Approach · Infrastructure as Code · Server Setup · Service Offerings
We treat handover as part of the work rather than as a closing formality. The test of a finished engagement is simple: can you run, change, and recover the system without calling us? An engagement that ends with a dependency on us has failed on its own terms — however well the thing we built happens to work.
1. Why This Is a Principle, Not a Courtesy
Dependency is the default outcome of consulting, and it does not require bad intent to happen — it accumulates. A fix applied by hand, a setting only one person remembers, a credential that lives in a contractor's password manager, and within a few months the client cannot make a change without a phone call.
- Lock-in is a risk you carry, not a feature we sell. A system only its builder can operate is one outage, one holiday, or one ended contract away from being unmaintainable.
- It is also a bad deal for everyone honest. Work billed because the client cannot do it themselves — rather than because it is genuinely specialised — is a slow tax on a relationship that should be built on being useful, not being necessary.
- Independence is checkable. “You could run this without us” is not a sentiment; it is something you can test by having your own team do it while we are still around to answer questions.
2. Credentials and Access in Your Control From Day One
The most common and most avoidable form of lock-in is access. It costs nothing to get right at the start and is painful to unwind later.
- Accounts, domains, and infrastructure are registered to you, not to us with a promise to transfer them later. We get access we need; we do not become the owner of record.
- Secrets live in your vault, issued to us for the work and revocable the day it ends — not in a personal store that walks out the door with the consultant.
- Revoking our access is a non-event. When the engagement ends, removing us should change nothing about whether the system runs. If it would, the access was a hidden dependency.
3. Infrastructure as Code, Over Undocumented Manual Steps
The difference between a system you own and one you are renting the knowledge of is whether its current state is written down in a form that reproduces it.
- The setup is code, not a memory. The server, the services, the proxy, the backups — defined in files you hold, so the system can be rebuilt from them rather than from whoever happened to configure it.
- The code is the documentation that cannot drift. A wiki page describing manual steps goes stale the first time someone changes something at the console; a definition that is actually applied cannot lie about the current state for long.
- Reproducibility is the real test of handover. If a clean environment can be stood up from what you hold, you own the system. If it depends on steps only one person remembers, you own a description of it.
4. No Component Only One Person Understands
The quietest dependency is knowledge. A system can be fully in your accounts and still be unrunnable because the one person who understands a critical piece is unavailable — whether that person is ours or yours.
- No bus factor of one. Anything load-bearing should be understood, and ideally operable, by more than a single individual.
- Runbooks for the things that matter — the deploy, the restore, the failover — written to be followed by someone who did not build the system, and proven by having them follow it.
- Prefer boring, legible choices precisely because they are easier to hand over — see boring infrastructure. A clever design only its author understands is a dependency wearing a nicer name.
- Handover is woven through the work, not bolted on at the end. Knowledge transferred continuously, while decisions are fresh, beats a documentation sprint in the final week that nobody reads.
5. What This Means for Working With Us
This principle shapes the engagement, and it is fair to hold us to it:
- The consultant who built it explains it — the same person, not a handoff to someone who also has to learn it.
- A handover is a deliverable with a definition of done: access in your name, the system as code you hold, runbooks for the critical paths, and a drill your team has run.
- Ongoing support, if you want it, is a choice — not a sentence. We are glad to keep helping where it is genuinely useful; we are not glad to be the only reason the lights stay on. See the revenue model for how continuing work is structured.
- You can leave. The clearest sign the work was done right is that ending the relationship is easy — and knowing it is easy is usually why it does not have to happen.
How We Approach It
- Put access in your name from day one — accounts, domains, infrastructure, secrets in your vault.
- Build it as code you hold, so the system can be reproduced from what you own, not from memory.
- Write runbooks for the critical paths and prove them by having your team run them.
- Avoid single-person knowledge, and prefer legible choices that are easy to hand over.
- Transfer knowledge continuously, not in a final-week scramble.
- Make revoking our access a non-event — the proof that nothing quietly depended on us.
What You Get
- Ownership of your accounts, domains, and infrastructure, in your name.
- The system as code you hold, reproducible without us.
- Runbooks your own team has followed, for deploy, restore, and failover.
- No single point of knowledge — and the freedom to end the engagement whenever you choose.
The question worth asking of any system a consultant leaves you with: if they stopped answering the phone tomorrow, could you run it, change it, and recover it — and who, on your side, has actually done each of those?