Run
We operate what we built, on your infrastructure.
SLOs, on-call, patching, upgrades, capacity and cost review. Priced per system, cancellable, and designed to hand back to your team the moment you want it. You own the code and the cloud account throughout.
The premise
Somebody has to be on call. Run is the arrangement where that somebody is us, on your infrastructure, under your account, with your name on the repository the whole time. It exists because the honest objection to owned software is operational, and the honest answer is not to pretend the work disappears.
What you get
- Service level objectives agreed with you and reported against monthly, including the months we miss them.
- A 24/7 or business-hours on-call rotation with a named escalation path and a response time in the contract.
- Patching, dependency upgrades and framework version currency on a schedule, so the system does not quietly become unupgradable.
- Capacity and cost review each quarter, with recommendations that sometimes reduce our own scope.
- Incident management with a written post-incident review for anything user-visible, published to you rather than summarised.
- A change process your team can use to ship into the system while we operate it — Run is not a freeze.
- A standing exit plan, kept current, so handing operations back to your team is a two-week exercise at any point.
How it runs
5 phases, each with a date attached.
Durations below are what this shape of work typically takes with a team of two to four. They move with scope, and the assessment is where they stop being typical and start being yours.
- 01
Operational readiness
2 to 3 weeksSLOs, alerting, runbooks, escalation and access. Where we built the system this is short; where somebody else built it, this phase is longer and occasionally ends with a remediation list before we will take the pager.
- 02
Shadow operation
2 to 4 weeksWe take alerts alongside your team without being authoritative. This is where the alerting gets tuned and where we find out what the runbooks left out.
- 03
Steady run
Ongoing, monthly service reviewOn-call, patching, upgrades and change support. A monthly review covering SLO performance, incidents, cost and the upgrade backlog, with your team in the room.
- 04
Quarterly engineering
Each quarterA block of engineering time inside the agreement for the work that keeps a system healthy — dependency major versions, cost reduction, the toil that never wins a prioritisation meeting.
- 05
Handback
2 to 4 weeks, whenever you want itThe exit plan is current at all times. Handback is your engineers taking the pager with us shadowing, then us leaving. No notice period games, no data extraction fee, because the data was never ours.
What it costs
No rate card on this page, on purpose.
Priced per system per month, driven by the response time you need and whether the rotation is business hours or genuinely round the clock. Out of hours costs more because it costs us more, and we will show you the difference rather than blending it.
The pricing is deliberately built so that it is never cheaper for us to keep you than to hand over. There is no minimum term beyond the first three months, no exit fee, and the exit plan is a contractual deliverable updated quarterly. If we are still running it in year three it should be because you decided that, not because leaving is expensive.
Cloud infrastructure remains billed directly to your account at cost. We do not resell compute, which means our incentive on cost engineering points the same way as yours.
A published day rate would be a number we could not stand behind for your specific situation, and every firm that publishes one quotes something different in the room. What we will commit to before you sign is the phase scope, the phase price and the team shape. Use the calculator for the replacement arithmetic against your own seat count.
Normally bought inside
Deliver
We take it end to end and hand over the keys.
Fixed price per phase. Run priced separately.
When not to buy this
3 reasons to walk away.
Every library entry has rows where the honest answer is no. Every service page has this section for the same reason: the cases below are ones we have seen go badly, and we would rather lose the work than deliver into them.
You have a capable platform team with spare capacity
Then run it yourselves. Buy the handover, buy a few days a quarter of upgrade help if you want it, and keep the operational knowledge inside the organisation where it is worth most.
You want us to run something we did not build and cannot change
We will not take the pager for a system we are not allowed to fix. If the code is frozen or owned by a third party who will not accept our changes, the on-call becomes theatre.
Run is being used to avoid hiring
If the plan is that you will never have engineers, you are choosing a managed service — which is a reasonable choice, and a licensed SaaS product is usually the cheaper version of it.
Pick one contract. We will show you the replacement.
A two-week assessment: we take your single most expensive SaaS line item, establish what you actually use, and come back with a parity matrix, an architecture for AWS and Azure, a cost model and a delivery plan. Fixed price. If the answer is keep buying it, we will tell you that.