The first step of Pre-Production is nailing down exactly what I'm building. Not vaguely. Not "I'll figure it out as I go." Exactly.
This is the part that feels slow. It isn't. I've built enough projects to know that the 2 hours spent on requirements will save 20 hours of "wait, what was this feature supposed to do again?"
From Concept to Requirements
The concept document from Phase 0 gave me the what and why. Now I need the how much. Requirements specification is scoping: what's in, what's out, and what gets punted to a future version I may or may not ever build.
The MoSCoW Method
I use MoSCoW prioritization to force hard choices. The key word is "force." Without a framework, everything is Must Have and your MVP ships sometime around the heat death of the universe.
- 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 (the most liberating category)
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 |
Notice that Polish is entirely "Should Have." If I'm running behind, every animation and filter can be cut without touching the core value. That's the point of prioritization: you decide what to sacrifice before you're panicking at 2am.
Sprint Planning
With 20 stories mapped, I planned 4 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): Filtering, animations, portfolio detail
The walking skeleton approach means I have a deployed, themed site with working MDX before building any content pages. Hardest technical unknowns first, content later. If the MDX pipeline is going to blow up, I'd rather find out in Sprint 1 than Sprint 3.
The Uncomfortable Truth
Writing requirements before code feels like procrastinating. Every instinct says "just start building, you know what you want." I do know what I want. I just don't know all the things I don't want yet, and that's what requirements are actually for.
// 20 stories. 4 sprints. 0 ambiguity about what "done" means.
const scope = {
mustHave: 12,
shouldHave: 8,
couldHave: "later",
wontHave: "the liberating part",
};