There is no handover. There is no support tier.
The engineers who designed a system are the only ones who can keep it honest. So the people on month four are the people from month one, and nothing gets passed to a queue that has to learn it first.
Thirty minutes · no predetermined package
Four things, not one.
Support answers when something is wrong. Running is the work that means it goes wrong less.
Fixing what breaks, by someone who knows why it was built that way.
Making small changes, because a system that cannot change quietly becomes a system nobody trusts.
Keeping dependencies current, in small steps, because deferred upgrades compound.
Monitoring that is worth being woken by, and alerting that reaches a person rather than a dashboard.
Documentation updated as the system changes, written for someone who has never spoken to us.
Being replaceable on purpose — support that only works while we are here is not support.
What this means in practice.
What people ask about what happens afterwards.
What does running actually include?
Fixes, small changes, dependency upgrades, monitoring and documentation. The last three are what stop the first one happening at 2am.
Is it the same engineers?
Yes. That is the whole point. Someone who did not build it has to learn it first, and that learning happens during your outage.
What if we want to take it in-house?
Good. The handover is documentation, a runbook, walkthroughs and a defined period of questions. The code has been yours throughout.
How is it priced?
As a fixed monthly allocation of engineering time rather than per ticket, so nobody argues about whether something counts as a bug.
Do you provide on-call?
For systems where an overnight failure matters. It requires monitoring worth being woken by, which is usually the first thing we build.
What happens if we stop?
You keep everything. The repository has been in your organisation since the first commit, and the runbook is written for somebody who has never met us.