Boring architecture, written down
Choose the dullest tech that works, and record why in one page.
Use this when
A queue for ten users
Microservices before product-market fit
An abstraction with exactly one caller
The quality gate
- Every non-obvious choice has a 5-line ADR: context, decision, alternatives, trade-off, exit path
- No new infra a single senior couldn't operate alone
- Data flows one direction; components own their state or clearly don't
- The 10× question is answered: what breaks at 10× data/users, and is that OK for now
- No abstraction until the second concrete use exists
Prove it: For each piece of infra ask: could one senior operate this alone at 3am? If no, the ADR must say why it's worth it.
Install or copy
Save the download as boring-architecture/SKILL.md in your agent's supported skills directory, or copy the complete package below. Load it only when its description matches the work.
--- name: boring-architecture description: "Applies “Boring architecture, written down” as a repeatable product-quality gate. Use during architecture work when choose the dullest tech that works, and record why in one page." --- # Boring architecture, written down Apply this skill during **Architecture** work. It supports Any stack. Choose the dullest tech that works, and record why in one page. ## Instructions Default to boring, proven technology; every deviation needs a written 5-line ADR (context, decision, alternatives considered, trade-offs, how we'd back out). Design data to flow one direction. Answer the 10× question explicitly: what breaks at 10× scale, and why that's acceptable today. Refuse speculative abstraction — duplicate once, abstract on the second real use. If asked for microservices, queues, or a new database, first prove the monolith + Postgres can't do it. ## Detect the problem - A queue for ten users - Microservices before product-market fit - An abstraction with exactly one caller ## Hold the gate Do not declare this phase complete until every item passes: - [ ] Every non-obvious choice has a 5-line ADR: context, decision, alternatives, trade-off, exit path - [ ] No new infra a single senior couldn't operate alone - [ ] Data flows one direction; components own their state or clearly don't - [ ] The 10× question is answered: what breaks at 10× data/users, and is that OK for now - [ ] No abstraction until the second concrete use exists ## Verify the result For each piece of infra ask: could one senior operate this alone at 3am? If no, the ADR must say why it's worth it.
More architecture skills
The data model comes first
Schema before endpoints — constraints in the database, not in hope.
Business logic is a pure core
Rules live in pure functions; I/O stays at the edges; state machines are explicit.
Every dependency is a hire
Each package is code you now maintain but didn't write — interview it first.
Want this quality gate applied to a real product decision?
Start a First Loop