Skip to content
How we work · Phase 04 of 04

A system that keeps earning after we leave

Shipping is the middle of the job, not the end. Every system goes live with monitoring, documentation and a 90-day warranty — and then you choose: we run it on a retainer, or we hand it cleanly to your team.

What actually happens

The phase most firms treat as an afterthought is the one your business lives with longest.

1

Go-live, instrumented

The system enters production with monitoring and alerts wired to your channels — not to a dashboard nobody opens. If something breaks at 2 a.m., it wakes the right people.

2

The 90-day warranty window

Defects in anything we shipped are fixed free for 90 days after acceptance. No arguing about definitions — if it doesn't do what the accepted milestone said, it's a defect.

3

You choose the path

Retainer or handover — decided by what serves the system, not what serves our invoicing. Plenty of clients start on a retainer and hand over once their own team is ready.

4

The system keeps earning

Either way, the goal of this phase is the same: software that keeps producing the metric it was built for — whether we're operating it or your team is.

Two paths, one standard

The engineering is identical either way — the only question is who operates the system day to day.

Path A · Retainer

We run it and keep improving it

For teams that want the system's leverage without building an engineering function around it.

We run the system: monitoring, incident response, fixesAlerts and reports arrive in your channels, not oursContinued improvement against the original metricA roadmap you steer — new milestones, same process
Path B · Handover

Your team takes over, cleanly

For companies building in-house capability — the handover is planned like a milestone, not improvised.

Architecture & decision records — why the system is shaped this wayRunbooks and admin documentation for daily operatorsTest suite & CI/CD a new engineer can deploy with on day oneHiring help if you're building the team that takes over

What ships with every system

These aren't retainer extras — they're part of the build's definition of done, whichever path you choose.

Monitoring & alerting, live in your channelsThe system reports its own health — before your users do
Architecture & decision recordsWhy the system is shaped the way it is — in writing
Runbooks & operations documentationFor the people who operate the system daily, not just engineers
Test suite & CI/CD pipelinesA new engineer can deploy safely on day one
90-day warrantyDefects fixed free after acceptance — no definitions argument

What we need from you

The operate phase is light on your time — but three things make it work.

A decision on the path

Retainer or handover — we'll recommend one based on your team, but the call is yours. It isn't final either: retainers hand over, and handovers can come back.

An operating owner

One person who receives the alerts, reads the reports and owns the system internally — even on a retainer, the system should have a name next to it inside your company.

Your channels, open

Monitoring and alerts go where your team already lives — Slack, Teams, email, pager. We wire into your stack, not the other way around.

The exit door

The handover is the exit door — and it's always open

This phase is built so you can leave it. Everything a future team needs — code, records, runbooks, pipelines — exists in writing from day one, so ending the retainer is a planned handover, not a hostage negotiation. No lock-in by obscurity, ever. You keep the system, the documentation and every capability it earned you.

90 days
warranty on everything we ship
zero
lock-in by obscurity — it's all documented

Common questions about operating

What exactly does the 90-day warranty cover?

Defects in anything we shipped — behaviour that doesn't match the accepted milestone scope — fixed free for 90 days after acceptance. No arguing about definitions.

What does a retainer typically include?

We run and improve the system: monitoring and incident response, fixes, and continued development against the metric it was built for — with reporting in your channels.

How does a handover work in practice?

Your team gets the architecture and decision records, runbooks, the test suite and CI/CD — and time with the engineers who built the system. Handover is a process we plan, not a zip file we send.

Can you help us hire the team that takes over?

Yes. If you're building an in-house team, we help you hire it — writing the roles, screening candidates, and onboarding them into the codebase we documented for exactly this moment.

Can we come back after a handover?

Any time. The documentation that made the handover clean makes the return cheap — we pick the system back up without an archaeology phase.

Is there any lock-in?

No — and by design, not by promise. Everything is documented for a team that isn't us, the IP is yours, and nothing about the system depends on our continued involvement.

Already running a system nobody wants to touch?

We take over existing codebases after a short technical audit — and document them so nobody fears them again.