Write the Spec Before You Build the SaaS

Starting a SaaS build by having Claude help you write a short product spec — the core user, the problem, the must-have features for v1, what's explicitly out of scope — and approving it before any code. The spec becomes the reference every later build decision is checked against.

The failure mode of AI-assisted building is speed without direction: Claude will happily generate features, but if the destination is vague, you get a pile of plausible code that doesn't cohere into a product. A spec fixes the target first. Written before building, it's cheap to change — cutting a feature is a line edit, not a refactor — and it forces the scope decisions that otherwise leak in mid-build as 'oh, and it should also…'. It also gives every subsequent prompt a frame: 'per the spec, build X' keeps generation aligned instead of drifting. An hour on the spec saves days of building the wrong thing well.

At the very start of any non-trivial SaaS or app build with Claude, before scaffolding or the first feature. Especially valuable when the idea is still fuzzy — the act of specifying is what forces the fuzziness to resolve.

Genuine throwaway prototypes or spikes meant to explore feasibility, where the point is to learn fast and discard — a formal spec there is overhead. Write the spec once you've decided the thing is worth actually building.

Before we write any code, help me write a tight v1 spec for this SaaS: <the idea>. Cover: the primary user and the one problem it solves for them; the 3–5 must-have features for a usable v1; what is explicitly OUT of scope for v1; and the key data entities. Push back on scope creep — for anything nice-to-have, argue for cutting it from v1. Keep it to a page.

For a client-invoicing tool, the spec work cuts 'multi-currency', 'team accounts', and 'a dashboard' from v1, leaving 'create invoice, send it, mark paid'. That ruthless scoping means the first build slices are all core, ship in days, and cohere — instead of a half-built dashboard sitting next to invoices that can't actually be sent yet.

Keep the spec as a living document Claude builds against — reference it in build prompts ('does this fit the v1 spec?') and update it deliberately when scope genuinely changes, so scope creep becomes an explicit edit rather than a silent drift. Combined with vertical-slice building, the spec tells you which slice is next and when v1 is actually done.

• Jumping straight to 'build me a SaaS that…' and letting scope emerge feature by feature, with no agreed destination.
• Writing a spec so exhaustive it becomes its own project — a page of must-haves and non-goals beats a design doc nobody rereads.
• Treating the spec as fixed forever, or as decorative — it only helps if you both build against it and update it on purpose.