On-call and incident response
Alerts route to a person, not a shared inbox. We hold a rotation with an agreed first-response time, work the incident, then write the note that stops the repeat.
On-call rotaPost-launch
Kept running, patched, and safe to change
A monthly retainer for software already in production: a named engineer who has read your codebase, an on-call rotation that answers, and a patch cadence that keeps dependencies current.
- Named engineer
- Response and resolution SLAs
- Rolling monthly term
- 30-day notice period
What a retainer actually buys
Your code does not change on its own; everything it stands on does. A dependency ships a security advisory, a payment provider deprecates the endpoint you use, certificate lifetimes shorten, a cloud service is retired, traffic doubles. The few things that do decay in place — expiring secrets, disks filling, tables outgrowing their indexes — do it on a clock nobody is watching. Maintenance absorbs that pressure at a steady, boring pace rather than in a panic on a Friday afternoon.
Deferred maintenance does not stay the same size. A runtime reaches end of life and stops receiving security patches; a framework that supports one major-version hop at a time stops offering a route from the version you are on. Skip two years and a two-day upgrade has become a migration with a rewrite hiding inside it. That is the arithmetic a retainer buys against: dull continuous work, priced monthly, instead of an unbudgeted quarter of emergency engineering.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| System was built by someone else | Cannot promise SLAs on day one | Takeover audit precedes any SLA |
| Backups are untested until restored | Recovery targets are assumptions, not facts | Quarterly restore into isolated environment |
| Advisories arrive on vendors’ schedule | Patch queue must stay short | Weekly train, security jumps queue |
| Feature work outbids reliability work | Shared budget starves patching | Ring-fenced floor, separate change budget |
| AI behaviour drifts without code changes | Regression cannot be judged by eye | Stored evaluation set gates swaps |
In scope
- Running production systems and their infrastructure
- Incident response, patching and restore drills
- Small changes within a monthly budget
- Upkeep of live AI features
Not in scope
- Ground-up rebuilds of failing systems
- Major version rewrites and platform moves
- Desktop, network and helpdesk IT support
Handled by
- Legacy Application ModernizationFor systems past the point of patching
- Software MigrationRuntime, platform and major-version moves
What we build
Dependency and patch cadence
A weekly train of small upgrades that pass CI, with security advisories jumped to the front. Small and frequent beats one annual upgrade: a two-hour patch becomes a two-day emergency once exploited.
Weekly upgrade logBackup and restore drills
A backup nobody has restored is a hypothesis. Each quarter we restore your database into an isolated environment, time it, and record the real recovery point against what you assumed.
Restore drill resultsSmall change delivery
The change budget covers work too small to be a project and too real to ignore: a report, a form field, a partner integration tweak. Same tests and review as a build.
Monthly changelogAI feature upkeep
Evaluation sets live in the repository and run on every prompt, retrieval or model change, with cost and latency tracked per request. When a provider retires a version, the swap is measured.
Evaluation setVulnerability handling
A queryable dependency inventory, advisories triaged against what you run, and a disclosure path with a named owner. Under the EU Cyber Resilience Act, exploited vulnerabilities need early warning within 24 hours.
Dependency inventoryHow the work runs
- 01Weeks 1–2
Takeover audit
We take custody before responsibility: repository, cloud, domains, certificates, payment and app store logins. Then we deploy it ourselves, restore a backup into a scratch environment, run whatever tests exist. What fails becomes the risk register.
You getAccess matrix and risk register
- 02Week 3
Set the floor
We agree what counts as working: the user journeys that must not fail, and the thresholds that mean broken. Alerts are rebuilt around those symptoms, and anything that pages without a matching action is deleted.
You getAgreed SLOs and alert routing
- 03Weeks 4–8
Stabilisation month
The first cycle is not feature work. We clear what causes most of the noise: expiring certificates, dependencies with live advisories, jobs dying into a dead-letter queue, the backup nobody has restored, the nightly false alert.
You getStabilisation report with fixes shipped
- 04Week 9 onward
Steady cadence
Then it is rhythm rather than reaction: a weekly patch train, a fortnightly change slot, a monthly report on incidents, spend and what we left alone. Each quarter, a restore drill and an exit check.
You getMonthly report and current exit pack
What you are handed
- Risk register with severity and cost
- SLO definitions and alert routing rules
- On-call rota with named engineers
- Dependency inventory and weekly upgrade log
- Quarterly restore drill results
- Post-incident notes with follow-up actions
- Evaluation set for live AI features
- Monthly report, changelog and spend review
- Exit pack kept current each quarter
Typical stack
Monitoring
OpenTelemetry instrumentationGrafana and PrometheusSentry for error trackingSynthetic and uptime checksLoki or CloudWatch log retention
On-call
PagerDuty or Opsgenieincident.io or RootlyEscalation policies in codeAutomated status page updatesPost-incident note templates
Change safety
GitHub Actions and GitLab CIPlaywright regression suitesTerraform with reviewed plansFeature flags for staged rolloutBlue-green and canary deploys
Upkeep
Renovate and DependabotTrivy and osv-scannerCycloneDX SBOM generationPostgres backups with point-in-time recoveryEvaluation suites for AI featuresCloud cost budgets and anomaly alerts
The calls we make, and why
Should the retainer buy a block of hours or a named engineer?
A named engineer with reserved capacity, not a block of hours
Hours make the wrong thing scarce: in a quiet month you have bought nothing, and in a bad one you are negotiating scope during an incident. We price a fixed reliability floor plus a separate change budget, so neither starves the other.
We’d choose otherwise whenthe system is genuinely dormant and you want a cheap, best-effort safety net
Do we need 24/7 on-call, or is business-hours cover enough?
Business hours plus automated recovery, for most products
Genuine round-the-clock cover needs three or more engineers in a rotation, and you pay for that whether or not anyone is paged. For most products the same money buys more reliability spent on self-healing, tighter alerts and a tested restore.
We’d choose otherwise whenrevenue moves while you sleep, a contract names overnight response, or stalled queues cause irreversible harm
Continuous dependency upgrades, or one planned upgrade project a year?
Continuous, in small batches CI can judge
An annual project bundles hundreds of changes into one release, so when something breaks you cannot tell which change did it — and you sit exposed on known advisories for months meanwhile. Small batches keep the blast radius readable.
We’d choose otherwise whena frozen system sits under regulatory validation, where every change carries a revalidation cost
Should we negotiate an uptime guarantee with service credits?
Negotiate response and resolution commitments instead
An uptime credit refunds a slice of the monthly fee; it does not restore your data or your customers. No studio controls your cloud provider, payment gateway and DNS registrar well enough to underwrite total availability.
We’d choose otherwise whenwe run the whole stack and the number reflects a measured baseline, not a guess
This fits if
- Your build partner has moved on and nobody owns deployment
- Production issues reach you by customer email, not by alert
- Dependencies are years behind and nobody wants to go first
- One internal developer who cannot be on call alone
- An AI feature is live and drifting in cost or quality
Look elsewhere if
- You want unlimited fixes and features for one small fee
- The system needs rebuilding — a retainer would fund the decline
- You need helpdesk and network IT, not application engineering
EngagementMonthly retainer
Typical lengthRolling, 30-day notice
How it startsGive us read access to the repository and one hour with whoever last deployed it.
Questions we get asked
Will you support code your team did not write?
Yes — most of what we support was written elsewhere. We do not commit to a response time until the takeover audit is done, because promising four hours on a system we cannot deploy is a lie. If the audit finds something we cannot hold, like a runtime past end of life, we say so and price the fix separately.
What happens if we want to leave?
You give thirty days’ notice and take the exit pack, which we keep current every quarter rather than assembling on the way out. Everything already lives in your accounts: repository, cloud, monitoring, registrar, secrets. We run a handover session with whoever takes over, and we never hold code, infrastructure or domains hostage. Ownership was never ours.
Who pays when something you shipped breaks production?
We do. Defects in work we shipped are fixed at no charge and outside your change budget, and each fix ships with the regression test that would have caught it. Incidents that originate elsewhere — a provider outage, a change your own team made — we still work immediately, but that time comes out of the change budget.
How much of the work is automated, and who checks it?
Monitoring, dependency upgrades, vulnerability scanning and routine remediation are heavily automated, and AI assistance drafts triage summaries and first-pass fixes. Anything that touches production data or mints a credential passes through a human approval gate — a deliberate limit, not a missing feature. The engineer who approves a change is accountable for it.
Can you keep our cloud bill from drifting upward?
We review spend monthly against a budget you set and alert on the trend rather than the invoice. Most drift is structural: a log retention default, an oversized database left from a load test, a storage class nobody chose, retries multiplying calls to a metered API. We report the causes and the fix cost; the decision stays yours.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.