How we work / Sample runbook excerpt
What the handover runbook looks like
Everything we build ships with a runbook: plain instructions for operating the system without us. It's the document that makes 'you own everything' true in practice — any competent developer can pick it up and take over.
Sample format — this is the document format you receive on a real engagement. Everything below is illustrative: the business, numbers, and findings are examples, not client data.
System: Store ↔ accounting sync (illustrative)
Audience: Your team + any future developer
Format: Versioned docs in your repository
What this system does
Two paragraphs in plain language: what flows where, which system owns which data, and what “healthy” looks like. Written for the person who joins two years from now.
How to check it's working
- Open the status dashboard [link in your account] — green means events are flowing
- The daily reconciliation report lands in your inbox at 07:00; 'no drift found' is the normal state
- Spot-check any order: search its number in the dashboard to see every step it took
Alerts and what they mean
- 'Backlog above threshold' — the accounting API is slow or down; nothing is lost, events are queuing. Action: usually none; the queue drains itself when the API recovers
- 'Event failed after retries' — one record needs a human decision. Action: open it in the dashboard, fix the named field, press retry
- 'Reconciliation found drift' — the nightly sweep caught and fixed a mismatch. Action: read the report; if it recurs, call the on-call contact
How to retry safely
Retries are idempotent: pressing retry twice cannot create a duplicate invoice. That property is guaranteed by the design, and the runbook explains why in one paragraph — so nobody is ever afraid of the retry button.
Access, keys, and rotation
- Every credential the system uses, where it lives (your accounts), and how to rotate it
- Who currently has access, and the checklist for removing anyone — including us
If we're unreachable
The section that makes this document matter: the code is in your repository, the accounts are in your name, and this runbook plus the architecture notes are written so any competent developer can operate, debug, and extend the system. Working with us stays a choice.
Want documents like this about your systems?
Describe the problem in plain language — broken, slow, manual, or missing. We'll tell you honestly whether and how we can help.
- 01We reply within one business day
- 02A short call to understand the problem
- 03A written scope and fixed quote — no obligation