How to write a PRD your AI can build from (template + example).

Say you want an AI to build you an app. Someone already told you the rule: don't just prompt it, write a spec first. You nod, open a blank page, and sit there watching the cursor blink, with no idea what the first line should even be.

The problem is not that you don't know what you want. You do, but it is in your head as a blob, not laid out in a way an AI can read. A PRD is just a form that pulls the blob out of your head into a list. It is not a formal document you have to make pretty. Once you know what boxes there are to fill, it is much easier than it sounds.

This post is hands-on. First the 8-section template and what each box asks. Then we write one real PRD line by line (for a little split-the-bill app). Finally, how to hand the spec to the AI to pressure-test before you tell it to build.

Part 1The 8-section PRD template, what each box asks

The good news: the PRD the AI needs is not a thick binder. Half a page that fills eight boxes is plenty. Think of it as a form, each box is a question the AI will answer for you (usually wrong) if you leave it blank. Copy these as an empty outline and go.

1. Problem and users what you are solving, for whom, where it hurts. One or two sentences. Don't skip it, it is the reason behind everything that follows.
2. Scope what it does, and more importantly what it does not do. The "does not" box is what keeps work from ballooning and stops the AI adding extras.
3. Capabilities what the user can do, as a list, not a floating paragraph. The more it is a list, the more the AI can build and you can check it one at a time.
4. Acceptance criteria "counts as working only if...", written so it can be checked true or false. This is the heart, more on it next.
5. Data and state what data exists, what fields each thing has, where it lives. If the AI does not know the shape of the data, it invents one, and usually the wrong one.
6. Constraints and hard limits like no paid services, must work on mobile, or do not store personal data. A rail so the AI does not wander.
7. Edge cases empty input, negative numbers, lost connection, a double tap, what should happen. This is the box vibe coding always skips.
8. Definition of done what a shippable version actually looks like, so "almost done" cannot drag on forever.

The box you can't leave blank: acceptance criteria

If you only write one box carefully, make it this one, because acceptance criteria is the only place that writes "correct" down concretely. The other boxes tell the AI what to build; this one tells you how to see that it is right.

The trick is to write them checkable, true or false, not "easy to use" or "fast" (each of which means a hundred things), but "press Save and the new row appears in the table right away," or "if the amount is typed as letters, show an inline warning instead of saving it." Concrete like that, the AI can check its own work and you can check it by eye. A quick test: read the criterion and ask "would two people agree on whether this passed?" If you can't answer, it is still too vague.

Part 2Writing one for real (a split-the-bill app)

Enough theory, let's write one. Say we want a little app to split the dinner bill after a meal out with friends. Watch how each box forces you to decide something you'd normally skip.

Notice the boxes that earned their keep are edge cases and acceptance criteria. In vibe coding you rarely tell the AI about uneven division or rounding, so it does the simplest thing and the total ends up a baht off with nobody noticing. Once you write "the amounts must always sum to the bill," the AI knows it has to handle the remainder properly.

Scale the detail to the size of the build

This example is a toy, half a page is plenty. For something bigger, real users, real money, you add detail inside the same boxes, you don't add new ones. The data box names field types precisely; the constraints box talks about security and personal data. Same eight boxes, each written deeper as the stakes rise.

Part 3Have the AI pressure-test the spec first

The AI is good at sharpening a spec before it builds from it. Don't tell it to build yet, have it read and check the spec first. This one step saves a lot of fixing later.

Tell the AI to push back, not to build

Paste the filled-in template and say something like "don't write code yet, read this spec and tell me where it's ambiguous, where you'd have to guess, and what edge cases it doesn't cover." What it points back at is the set of holes it would otherwise fill by guessing at build time. Fold those answers into the spec, then tell it to build.

With the split-the-bill example, the moment you ask it to check, it usually asks straight back: "if someone adjusts the per-person amounts so they no longer sum to the bill, what should happen?" That's a case you genuinely forgot. That's the value, you plug the hole while it is still text, before it becomes a bug in the code.

Test against the criteria, not against a feeling

When the AI is done, don't just look and go "seems fine." Open the acceptance criteria and walk them one by one. Does 900 split 3 ways give 300? Do the amounts sum back to the bill? Is the payer never told to pay themselves? Where one fails, fix the spec first and have the AI rebuild, don't just prompt the code directly, because fixing the spec keeps the next build correct too, while a loose fix breaks in the same spot again.

Start today

You don't need a polished PRD. Copy the eight boxes into an empty outline, write half a page for an idea that's been sitting in your head, and run the loop: write, let the AI push back, plug the holes, build, test against the criteria. One pass and you'll feel the difference from prompting cold. If you want a tool that checks whether an idea is ready and bounces it back as a PRD skeleton, we built a free one at productize.life/services/prd.