How we work.

A run-book is the single document an engineer who has never seen the system would read first. We write it during the first build, not after. It lives in the venture's own repository and is updated in the same pull request as the change it describes.

• Architecture in two paragraphs and one diagram
• Every external dependency, with the contract and the failure mode
• Deploy, rollback, and emergency-stop procedures
• Backup, restore, and secret-rotation steps with last-tested dates
• On-call rotation, escalation path, and named owner

Every consequential decision — a database choice, a scope cut, a vendor swap — lands in a numbered decision record. Short prose, written in the moment, dated and attributed. Future operators can read the log front-to-back and understand how the system arrived at its current shape.

• One Markdown file per decision, sequentially numbered
• Context, options considered, decision, consequences — in that order
• Linked from the run-book where the decision is load-bearing
• Never deleted; superseded entries point to the record that replaced them

When something breaks, the engineer who handled it writes the post-mortem within two working days. It is blameless, specific, and ends with concrete commitments. Recurring causes become run-book entries; recurring failures become architectural work.

• Timeline in UTC, with the human action that mattered at each step
• Root cause stated plainly, no hedging
• What we changed, what we are watching, when we are checking again
• Linked from the run-book under “known failure modes”

Because the run-book, decision log, and post-mortems live in the repository from day one, a handover is the act of granting access and recording a single walk-through video. Same-day handover is the default, not the exception.

• Repository, cloud account, domain, and third-party login transfer
• Run-book read-through and decision-log index
• Recorded walk-through of deploy, rollback, and incident response
• Thirty days of paid availability for follow-up questions, in writing

The operating week has three fixed moments. Everything else flexes around them. The cadence is the same whether a venture is one week old or four years old.

• Monday: review open incidents, risks, and decisions still in flight
• Wednesday: ship the smallest useful slice and update the run-book
• Friday: write down what changed, what is fragile, and what comes next