Architecture Decision Records

Preserve technical decision context so teams can reason about past tradeoffs.

Use lightweight ADRs for stack, architecture, and process decisions with lasting impact.

ADR template

  1. Context: what forced this decision.
  2. Decision: what was chosen.
  3. Alternatives: what was rejected and why.
  4. Consequences: expected outcomes and risks.
  5. Review date: when to revisit.

Implementation checklist

  • Store ADRs in version control.
  • Link ADRs from relevant docs pages and PRs.
  • Update ADR status when decisions change.

Common pitfalls

  • Writing ADRs only for “big” decisions and missing recurring patterns.
  • Never revisiting decisions after product scale changes.

On this page