The handover guide we leave on every project.

A handover guide isn’t documentation in the heavy, comprehensive sense. It’s a working document a competent engineer can pick up and use to run, change, and extend the system without us. We write it as we go, not at the end, because end-of-project documentation is always thinner than it should be.

What goes in

Architecture overview, environment setup, deployment runbook, the three or four things that will surprise the next engineer, the decisions we made and the trade-offs behind them, and a list of known fragilities. We avoid auto-generated API references unless they’re genuinely useful; the goal is comprehension, not completeness.

What stays out

No code walkthroughs, no commentary on style, no architectural philosophy. Those age badly and rarely help. The guide is meant to outlive us; opinionated commentary doesn’t.

Why it matters

Most agencies treat handover as a closing ritual. We treat it as a deliverable. If you continue with us on Campaign, the guide is what your stakeholders read. If you hand it to your own team, the guide is the thing that lets them take ownership without three weeks of archaeology.

How we keep it honest

The guide is reviewed at every milestone, not just at the end. When a decision changes, we update the entry that records it on the same day. When a fragility is discovered, it goes on the list before the bug fix. The result is a document that reflects the system as it actually exists, not the system we wished we had built.

A living document

After release the guide does not stop. We treat it as the source of truth that any future engineer — Gnomic or otherwise — can update. New runbooks for new failure modes. New entries for the trade-offs the next year of operation reveals. A short changelog at the top so a returning reader can see what is new since their last pass.