For engineering teams

Standards that outlive any one person.

Your team's conventions live in one senior engineer's head, a wiki page nobody has opened since the re-org, and three Slack threads. Rulebound turns them into a handbook with the reasoning attached — numbered, versioned, and short enough that people actually read it.

Start your team's book Read a finished handbook

Free to startPrivate books stay privateImport what you've already written

Why handbooks rot

Every team writes one. Almost nobody reads the one they have.

The reasoning goes missing

A rule with no why gets routed around the first time it's inconvenient. Six months later nobody can tell a hard-won lesson from one person's old preference — so it gets relitigated in review, every time.

Nobody can see what changed

Wiki revision history is a wall of diffs no one opens. “What's different since I joined?” and “what did we agree last quarter?” are reasonable questions your docs can't answer.

It reads like a chore

One four-thousand-word page with no shape to it. Skimmed once during onboarding, never opened again, quietly false within a year.

What's different here

A handbook shaped like something you'd actually read.

Rulebound gives your standards a structure borrowed from good reference books: numbered rules, each carrying the reasoning, the practice, and the honest exceptions — published as editions rather than edited in place.

Every rule carries its why

A statement, the reasoning behind it, how it works in practice, and the cases where it doesn't apply. People learn the judgment, not just the instruction.

Editions, not silent edits

Revisions publish as numbered editions in an append-only history, so you can point at exactly what the standard said in March — and show what changed since.

❦

Fork instead of starting blank

Remix any public handbook with its provenance intact, then diverge where your team genuinely differs. The lineage stays visible on the book.

✳

A route through it for new hires

Context Packs let you lay out an ordered path — these rules, this recipe, that access request — for someone's first week, with progress they can tick off.

☞

What a rule looks like

This is one rule — not a bullet on a page.

Pulled live from a published handbook in the catalogue. Every rule in a Rulebound book has this shape, which is what makes the difference between a document people argue with and one they learn from.

Team Handbook

How Our Team Actually Works

by Rulebound

33 rules · Living edition

From , chapter 2 of How Our Team Actually Works

Getting started

From the docs you already have to a first edition.

Bring what exists

Paste rough notes, upload a Markdown file, or point at a public GitHub repo — CONTRIBUTING, style guides, ADRs, and conventions get parsed into chapters and rules automatically.

Fill in the reasoning

The studio shows a completeness meter per rule: why, in practice, exceptions, a worked example, a source. It's the part that turns a policy into a teachable rule.

Publish an edition

Ship the first edition. Every later revision becomes another edition, so the handbook can change without losing the record of what it used to say.

Hand it to the team

Share the book, or build a Context Pack that walks a new hire through the rules that matter for their first week in the order they'll need them.

From the catalogue

Handbooks and standards you can read — or fork — right now.

Team Handbook

How Our Team Actually Works

by Rulebound

33 rules · Living edition

How Our Team Actually Works

Rulebound

Write down how your team actually works.

Start private, import what you've already written, and publish a first edition when it's ready. Free while Rulebound is in early access.

Start your team's book Read a finished handbook

Rule 7

Write the decision down, or it didn't happen

Why: A decision that lives only in someone's memory isn't a decision, it's a rumor with a half-life. Three months later nobody can remember whether we chose Postgres because of a real constraint or because someone had a bad week with the alternative, and the reasoning that would let us revisit it sensibly is simply gone. Writing it down, the decision, the date, who made it, and crucially why, turns a moment of judgment into a durable artifact the team can build on and argue with. It protects us from relitigating the same question every quarter, and it protects the decider from being second-guessed by people who never saw the constraints they were working under. It's also how new people absorb why the system is the way it is, instead of assuming everything that looks odd is a mistake. The written record is the difference between a team that accumulates wisdom and one that just accumulates code. If it's not written down, it didn't happen, and we'll pay for it later in a meeting we could have skipped.
In practice: For any decision that's expensive to reverse or affects more than one person, write a short decision record before you consider it settled. Capture the context, the options you weighed, the choice, and the reasoning, in a few paragraphs, not a dissertation. Note who owns the decision and the date, so future readers can weigh how stale it is. Put it somewhere durable and findable, linked from the relevant project, not buried in a chat scroll. Record the decision even when it's unanimous and obvious, because obvious-in-the-moment is exactly what gets forgotten. When you later change your mind, don't delete the old record, write a new one that supersedes it and says why, so the trail of reasoning stays intact.
Exceptions: Small, easily reversed decisions don't need a formal record; deciding what to name a variable or which morning to ship is not a constitutional matter. The bar is roughly: would someone reasonably ask 'why did we do it this way?' six months from now. If yes, write it down.

Read this rule in the book →