Frontend Governance
Last updated:
Frontend governance protects quality across teams — standards should stay intentional and enforceable.
01 — Purpose
Governance protects quality at scale
Frontend governance protects quality across teams and projects — standards should stay intentional and enforceable.
Without shared rules, every squad invents its own patterns for CSS, accessibility, performance, and review. Onboarding slows, audits hurt, and refactors never finish because “we all do it differently.”
This site is an example of documented governance — standards, patterns, checklists, and architecture topics teams can point to in PRs.
02 — Scope
What governance covers
Frontend standards should remain intentional and enforceable.
- accessibility — standard, QA checklist
- performance — standard, budgets, performance review
- architecture — CSS layers, JS modules, state, folder structure
- code style — CSS architecture, code formatting
- QA and dependencies — frontend QA, dependency management
03 — Practice
Good frontend governance
Documented standards, review processes, shared tooling, and architectural guidance.
- documented standards — one place teams trust; date significant changes
- review processes — checklists in PR templates, not optional lore
- shared tooling — formatters, linters, CI budgets, accessibility scans as guardrails
- architectural escalation — new shared patterns go through architecture owners
Documentation expectations
Code explains what happens; documentation explains why and how to extend safely. If a PR changes shared behaviour, it updates docs in the same merge — not a follow-up ticket.
- decision logs or ADRs for non-obvious choices — build tool, CSS methodology, rendering model
- “when to use / when not to use” for shared UI — linked from design system governance
- migration notes for breaking component API changes
- docs reviewed in PR checklist — outdated Confluence is worse than none
04 — Avoid
Governance anti-patterns
Without governance, frontend systems drift into entropy.
- undocumented decisions — “ask Sarah” is not a standard
- inconsistent implementation — same feature built three ways in one org
- abandoned standards — wiki pages nobody updates after launch quarter
- docs divorced from the repo — auto-generated dumps with no guidance
05 — Close
Intentional and enforced
Governance only works when teams use it in review — not when it sits unread.
Link PRs to the relevant checklist or standard. When a rule no longer fits, change the doc and tell teams — silent drift is worse than no doc at all.
See design system governance and technical debt.