How to write a spec (PRD) your AI builder actually follows (free template)

Updated

AI builders like Lovable, Bolt, Cursor and Claude Code are fast, but they build what you describe, and only that. When the description is vague, there is a real risk that the tool fills the gaps with guesses, which leads to exactly what so many people run into: a result that isn't what they expected. This guide gives you a free spec template and shows how to fill it in, so your AI tool builds what you meant with fewer rounds of fixes.

Why vague prompts break builds

A prompt like "build me a booking app for my salon" leaves hundreds of decisions open. Who books? Can customers cancel? What happens when two people book the same slot? The AI answers every one of those questions for you, silently, and each guess shapes the next one.

That works for a demo. It falls apart as the app grows: the tool forgets earlier decisions, contradicts itself and starts fixing one thing by breaking another. A spec gives it a fixed reference to come back to, so every new step starts from the same decisions.

What a build-ready spec contains

Product teams call this a PRD, a product requirements document. For AI builders it needs a few parts a classic PRD often skips, like the data model and the build order.

  1. Problem and first user. One specific group of people, what they do today and what they should be able to do instead.
  2. Scope. What is in version 1, what comes later and what is explicitly out. The "out" list saves more time than any other part.
  3. User flows. Step by step, what the user does and sees, including empty states and errors.
  4. Data model. The things the app stores, their fields and who may read or change them.
  5. Architecture. What runs where: frontend, backend, database, outside services and where the data lives.
  6. Build instructions. The order to build in, technical constraints and what the AI must not touch.

The template

Copy it into a file called SPEC.md, or download it, and replace everything in square brackets.

# [Product name] – Product spec
Version: 0.1 · Date: [YYYY-MM-DD] · Owner: [name]

## 1. Problem and first user
- Who has the problem? [one specific group, e.g. "small coffee roasters selling subscriptions"]
- What do they do today, and why is it not good enough?
- What should they be able to do with this product?

## 2. Scope
### Version 1 (must have)
- [Feature]: [what the user can do]. Done when: [a result you can test]
- [Feature]: [what the user can do]. Done when: [a result you can test]
### Later
- [Feature]
### Not in scope
- [Things the AI should not build, even if it seems helpful]

## 3. User flows
### Flow: [name, e.g. "Customer starts a subscription"]
1. [The user opens ...]
2. [The user chooses ...]
3. [The app shows ...]
Result: [what has changed when the flow is done]
Edge cases: [empty state, error, no access, slow network]

## 4. Data model
| Entity   | Fields                        | Belongs to |
|----------|-------------------------------|------------|
| User     | id, email, name, created_at   | –          |
| [Entity] | [fields]                      | [User]     |
Access rules: [who can read and change what]

## 5. Architecture
- Frontend: [web app / mobile app]
- Backend and database: [e.g. Supabase, or your own API + Postgres]
- Sign-in: [email and password / Google / magic link]
- Outside services: [payments, email, AI model]
- Where data is stored: [region, e.g. the EU]

## 6. Build instructions for the AI tool
- Build in this order: 1) data model and sign-in, 2) [first flow], 3) [next flow]
- Use: [framework, libraries]. Avoid: [libraries or patterns]
- Do not: [change the data model without asking / add features outside the scope]
- After each step: run the app, check it against "Done when", then continue

How to fill it in

How to use it in your AI tool

Update the spec when you change your mind, not just the code. Then the next step still starts from the right decisions.

Comparing tools that write the spec for you? See AI PRD generators compared.