What to put in a PRD for Lovable

A traditional product requirements document was written to align a team. Most of its sections exist to settle arguments between people: scope negotiation, phasing, acceptance criteria, non-goals for the next quarter. Hand that to Lovable and the majority of it is inert.

What a prompt-driven builder acts on is narrower and stranger than engineers expect. It acts on nouns, on sequences and on refusals.

The 6 sections that change the output

1. 01One line stating the trade. What the visitor gives and what they get. This becomes the headline, and it constrains everything below it.
2. 02The numbered path to first value. Screen by screen, from landing to the moment the product has worked once. A feature list produces a dashboard; a numbered path produces a product.
3. 03Every screen with 3 states. Full, empty, broken. Skip this and you ship demo-quality screens that only look right with fake content in them.
4. 04The exact copy for the 5 hardest strings. The headline, the one button, the empty state, the payment failure, the 404. Write these yourself. Everything else can be generated.
5. 05Data: the tables and the fields. Name them. Otherwise a form that collects an email stores it nowhere and you find out after the first sale.
6. 06Bans. The things it must never do — no signup before checkout, no second call to action, no words from this list. Bans survive re-prompting better than any other kind of instruction.

What to cut

Personas written as biographies. Competitive matrices. Phased roadmaps. Success criteria expressed as percentages of a number you do not yet measure. Anything hedged with “consider” or “ideally”, because a builder reads a hedge as permission to choose.

Also cut the technology section, unless a choice is load-bearing. Prescribing a state library to a tool that has its own conventions buys friction and no product.

State one decision per line

The failure mode of a written spec is the paragraph that contains three possibilities and no choice. Compare these two.

Weak:  Onboarding could use email or social login, and we may
       want to defer signup until the value is clear.

Strong: No account before payment. Email is collected once, on
        the checkout page, and never asked for again.

The second one is shorter and it removes work. That is the shape every line should have.

Keep it where the tool can re-read it

A document pasted into the first chat message decays. Put the same text in the project as files, and start each session by pointing at them. Then when the product drifts, you have something to compare it against besides your memory of what you meant.

The honest length

Roughly 2 pages. Long enough to hold 6 sections with real content, short enough that every line was decided rather than filled in. If it runs longer, check whether the extra pages contain decisions or descriptions. Descriptions are the part that changes nothing.