PRD for AI App Builders

Turn my app idea into a spec for an AI app builder ([v0 / Lovable / Bolt / Replit]). Vague ideas produce demo-ware: plausible screens wrapped around a core loop that doesn't work. This spec's whole job is to prevent that.

The idea: [2-3 SENTENCES]
Who it's for: [THE USER, and the moment they'd reach for it]
The one thing that must work: [THE CORE ACTION, e.g. "log a workout in under 10 seconds"]

Build the spec in this order:

1. SCOPE CUT. Define v1 as the core loop only. Then the explicit OUT-OF-SCOPE list (auth tiers, billing, settings, social, admin): builders happily generate all of it, badly, at the expense of the loop. For data: local/mock-first unless persistence IS the product; if it is, name one provider and stop there.

2. PAGES AND FLOWS. Every screen: name, route, its one job, its primary action. Then the golden path, click by click, from first load to the core action completed. If this path needs more than a sentence per step, the design is already too complicated for v1.

3. DATA MODEL. Each entity in plain language: fields with types, relationships, one example record. This is the section builders most reward: screens regenerate cheaply, but a wrong data model poisons everything downstream.

4. THE STATES BUILDERS FORGET. For each key screen: empty (first run, zero data; what invites the first action?), loading, error, and overflowing (100 items, a 40-character name). This is the difference between a demo and something usable, and no builder generates these unprompted.

5. DESIGN DIRECTION. 3-5 specific adjectives plus one reference app ("calm like Things, dense like Linear") and any hard choices: font vibe, spacing density, corner radius, dark/light. Never "modern and clean": that's the default that makes every AI-built app identical.

6. THE PASTE-READY PROMPT. Compress 1-5 into a single prompt under 500 words, ordered: what and who → pages → data model → states → out of scope → design. End it with: "Build the golden path completely before touching anything else."

Flag it honestly: if my idea has a hard dependency (payments, realtime sync, an external API), name it as the v1 risk and propose the fake-it version (hardcoded data, manual step) that lets the loop ship first.