The Fable Kickoff — PRD template

Why a PRD beats a good prompt

The difference between a build that lands in one shot and a build that spirals into twenty correction messages is almost never the model. It is how much the model knew before it started. A frontier model handed a clear spec builds the right thing once. The same model handed a one-line idea guesses, and you spend the next hour steering it back.

So the move is to separate thinking from building. Do the thinking with a cheap model that interviews you. Do the building with a frontier model that gets the finished spec as a single message. Review with a cheap model again. You end up paying frontier prices only for the part that needs frontier intelligence.

The three-step workflow

1. 1

   Fill the template with a cheap model

   Paste the interview prompt below plus the blank template into a cheap model (Haiku, GPT-5 mini, whatever is nearly free). Let it interview you one question at a time. This is the part people skip, and it is the part that matters most.

2. 2

   Hand the finished PRD to a frontier model as ONE message

   Open a fresh session on your best model (in Claude Code, Cursor, or Zed), paste the completed PRD, and let it build. One message. Do not dribble in details, the whole point is that everything it needs is already there.

3. 3

   Review and iterate on a cheaper model

   Once the first build exists, most fixes are small. Drop back down to a cheaper model for the review-and-tweak loop so you are not paying frontier rates to rename a button.

The interview prompt

Paste this at the top, then the blank template underneath it, into any cheap model. It turns filling in a spec from a chore into a five-minute conversation.

Interview me one question at a time to fill in the product spec template below. Rules:

- Ask about ONE section at a time, in order. Do not move on until the current section is specific enough that a stranger could build from it.
- Push back on vague answers. If I say "users can manage their stuff," ask what "manage" and "stuff" mean concretely.
- Suggest a concrete default when I am unsure, and let me accept or change it.
- Keep your own questions short. I am the one who should be typing paragraphs, not you.
- When every section is filled, output the COMPLETE spec as one clean markdown document I can copy in a single block, with nothing else around it.

Here is the template:

[PASTE THE TEMPLATE BELOW]

The template, section by section

Nine sections. Each one exists because leaving it out is a specific way builds go wrong. The download at the bottom is the blank version to copy.

1. What we are building (one sentence)

The shape: A [thing] that lets [who] do [what]. If you cannot say it in one sentence, the model cannot build one product, it will build three half-products.

2. Who it is for and the problem

Who exactly, what they do today instead, and why that is painful. The builder model performs measurably better when it knows the why, because it makes a hundred small design calls that all point the same direction.

3. What done looks like

Checkable criteria, not vibes. "A visitor can sign up, create a project, and see the dashboard update live" beats "it works well." Three to six bullets. This section doubles as the model's definition of done in step 9.

4. Core user flow (3 to 7 steps)

The single most important path through the product, start to finish. If there are two critical paths, list both. Everything else is a detour the model can figure out.

5. Screens (aim for 5 or fewer)

Name each screen and its one job. Fewer screens is a feature. A first build with five tight screens ships. A first build with fifteen screens never gets reviewed.

6. What data gets stored (plain language)

The nouns and how they relate, in English. "Users have an email and name. Projects have a title, an owner, and a created date. Each user has many projects." No schema required, the model writes the schema. You just supply the nouns.

7. Stack and integrations

What you know you want: hosting, database, auth, payments, email, any APIs. "Whatever is simplest" is a valid answer, but say it out loud so the model picks for you instead of guessing silently. The SaaS Starter Stack in the Vault is a ready answer for this line.

8. Out of scope, what NOT to build

The feature-creep vaccine. List everything a clever model might add that you do not want yet. Frontier models respect boundaries when you state them, and invent scope when you do not.

9. How it should verify its own work

Tell the model what to check before it claims done: run the app, click through the core flow from section 4, confirm each criterion from section 3 passes. Ask it to establish its own checking method and actually use it. This one line prevents most "it said it was done but nothing worked" moments.

Take the template

Built something with this? Reply to any Robots on Payroll issue and show me. I feature reader builds.