Post-launch support. Optional, and it never recreates a dependency.
Every engagement ends properly: documentation, a trained person on your side, credentials transferred. For those who want a quiet first year on top of that, a light monthly arrangement keeps watch on what we built.
It came from a measurement, not from a sales meeting
Measured in July 2026, across roughly thirty engagements delivered since 2019: no client has ever had to call us back on an emergency after handover. The only follow-on contracts signed were to extend a warranty or widen the knowledge transfer. Never to repair something we had left behind.
That record is why this arrangement exists in the form it does. We are not selling insurance against our own defects, which would be an odd thing to charge for. We are extending a watch over a system that is already sound, for people who would rather sleep easily through the first year.
Three boundaries, stated before you ask
- Not managed IT services. We do not run your device fleet, your workstations or your mail. The scope is exactly what we built or assessed, and nothing beyond it.
- Not a recreated dependency. Your trained person keeps the documentation and the controls. It stops when you want, at short notice, and nothing degrades if you leave because everything is already documented on your side.
- Not compulsory. Every handover is complete with or without it. This exists for directors who prefer a quiet first year, not to keep a relationship alive that has served its purpose.
What it does cover: the critical indicators set at handover, such as backups, queues, certificates and scheduled jobs, intervention when an incident hits the delivered scope, security updates on the technical foundation, and a short quarterly review of what ran and what was fixed. You decide what happens next, nothing is imposed.
Four answers without the sales pitch.
-
Is this managed IT services?
No, and the distinction matters. We do not run your device fleet, your workstations or your mail. The scope is exactly what we built or assessed during an engagement, and nothing else. If you need someone to own your whole IT estate, a managed services provider is the right answer and we will say so rather than stretch to fit.
-
Can we subscribe without a prior engagement?
No, and that is deliberate. This watches indicators that were set during a handover, on a system we know because we built or audited it. For a system we have never seen, the honest first step is a short assessment that maps what exists. After that, this becomes possible.
-
How is this different from a maintenance contract?
A conventional maintenance contract bills tickets and lives off your dependency. This watches a defined set of indicators on a closed scope, with the documentation already sitting on your side and one of your people trained to act. If you never use it, that is good news for everyone, and it is cancellable at short notice precisely because it is not meant to be a lock-in.
-
What happens if something breaks outside the scope?
We say so plainly and, where we can, point you at who should handle it. Stretching the scope silently would be the start of exactly the dependency this arrangement is designed to avoid. If the incident reveals that the boundary was drawn in the wrong place, that is a conversation worth having openly rather than a line quietly added to an invoice.
This comes after an engagement, not before.
If we have not worked together yet, the honest starting point is a short assessment of what you actually run. This becomes available once there is something we know well enough to watch.