App Blueprint: Idea to Spec, Mocks, Architecture & Schema

Coding agents build what they're told, so vague input gets you improvised architecture, invented screens and a schema that can't store what the product needs. App Blueprint gives your agent a fixed, five-phase method for turning an idea into a build-ready blueprint, with your approval between every phase.

What it does

• Spec (phases 1–2): pressure-tests the idea (one-sentence test, non-goals), then writes FR-numbered requirements with observable acceptance criteria.
• Designer (phase 3): a design language (palette, type, spacing), component and screen inventories that cite FR IDs, user flows, and standalone clickable HTML mocks that open in any browser with no build step.
• Architect (phase 4): a stack table with rationale, rejected alternatives, precise module paths and contracts, data and dependency flow, a requirements trace (FR → entry point → modules → durable effect), security posture and deployment.
• DB (phase 5): schema docs where every table cites the FRs it serves, enum values with their meanings, query patterns with matching indexes, and real forward-only migration files in your stack's idiom (SQL, Prisma, Drizzle and others).

How it works

1. One continuous agent session plays four roles in a fixed order: Spec → Designer → Architect → DB.
2. Design comes before architecture, because the mocks constrain the stack (a real-time screen needs a real-time transport).
3. After each phase the agent summarises what it produced, names the one decision most worth a second look, and waits for your approval.
4. It's resume-safe: run it again and it starts at the first missing file, without regenerating approved work. You can also run a single phase ("just do the schema").

Frameworks & tools

Stack-agnostic. Architect picks the simplest stack your requirements justify, or honours one you specify. Mocks are plain HTML; migrations follow whatever data layer Architect chose.

Why this beats prompting it yourself

One big "write a PRD and architecture" prompt produces documents that don't agree with each other. Here every screen, module and table traces back to an FR ID, so gaps surface before code. Module paths are written precisely enough to hand to separate agents without merge collisions, and nothing downstream is built on a draft you didn't approve.

Use cases

• Plan a new app or major feature before any coding agent touches it.
• Get clickable mocks plus a defensible stack decision in one sitting.
• Produce a schema and initial migrations that match the product.
• Hand a contractor or AI agent a blueprint they can't misread.

Known limitations

Doesn't write application code (DB writes migrations only). It runs in one session, so very large products are best blueprinted one feature at a time. Mocks use the Tailwind Play CDN by default; ask for inline CSS if you need them to work offline.