Planning & specification

What this layer solves

Without a shared picture of what “done” means, you get endless tweaks, wrong features, and confused AI assistants. Planning turns a vague idea into something you can build and test.

Options (how teams capture intent)

Approach	Best for	Tradeoffs
One-pager — problem, user, success metric	Solo or tiny teams	Easy to skip edge cases
User stories — “As a … I want … so that …”	Agile product teams	Needs prioritization discipline
Lightweight spec / RFC — flows, data, non-goals	Anything you’ll hand to collaborators or AI	Takes a few focused hours
Design mockups (Figma, etc.)	UI-heavy apps	Can lag behind what’s feasible

Default for NK Wiki: a short spec — bullet goals, out of scope, acceptance checks, and rough data the app touches.

Outline: what to write before `create-next-app`

Who is the user and one primary job-to-be-done.
Screens or flows — list them; don’t design every pixel yet.
Entities — user, post, order… what gets stored.
Non-goals — what you will not build in v1.
Definition of done — e.g. “deployed URL, login works, CRUD on X.”

Official & further reading

Shape Up — product shaping without infinite backlogs (philosophy)
Writing good prompts for AI mirrors good specs: role, constraints, success criteria (see Start here)

When to pick an alternative

Heavier PRD when compliance or many stakeholders need audit trails.
No written spec only for throwaway spikes — still jot a paragraph so future-you remembers.