Phase 1 of the Playbook is Pre-Production — and the first step is nailing down exactly what you're building. Not vaguely. Not "we'll figure it out." Exactly.
From Concept to Requirements
The concept document from Phase 0 gave us the what and why. Now we need the how much. Requirements specification is about scoping: what's in, what's out, and what can wait.
The MoSCoW Method
We use MoSCoW prioritization to force hard choices:
- Must Have — the site doesn't work without these (12 stories)
- Should Have — important but the MVP ships without them (8 stories)
- Could Have — nice to have, punt to later
- Won't Have — explicitly out of scope (keeps scope creep at bay)
The 7 Epics
Here's how the feature set breaks down:
| Epic | Stories | Priority Mix |
|---|---|---|
| E1: Site Shell | 4 stories | All Must Have |
| E2: Content Pipeline | 3 stories | 2 Must, 1 Should |
| E3: Methodology Section | 2 stories | 1 Must, 1 Should |
| E4: Dev Journal | 3 stories | 2 Must, 1 Should |
| E5: Portfolio | 2 stories | 1 Must, 1 Should |
| E6: SEO & Performance | 3 stories | 2 Must, 1 Should |
| E7: Polish | 3 stories | All Should |
Sprint Planning
With 20 stories mapped, we can plan sprints:
- Sprint 1 (Walking Skeleton): Site shell, theming, MDX pipeline, deployment
- Sprint 2 (Content Model): Frontmatter schema, content index, journal listing, SSG
- Sprint 3 (Content Sections): Methodology, portfolio, OG tags, RSS
- Sprint 4 (Polish): Home page, filtering, animations, code highlighting
The walking skeleton approach means we have a deployed, themed site with working MDX before building any content pages. This de-risks the hardest technical unknowns first.
Lessons Learned
Writing requirements before code feels slow. It's not. It's faster — because you don't build the wrong thing. The 2 hours spent on this document will save 20 hours of rework.
The best code you'll ever write is the code you don't have to rewrite.