When to use it
You have a product idea and need to decide "what to build it on and how" before writing the first line — at the product level, not the level of a single feature. The AI's role is tech lead/architect who thinks reuse-first and weighs trade-offs. Output: a clear MVP architecture you can estimate against and start from (or hand to a coding agent as a spec-driven brief).
The prompt (copy and paste)
You are a tech lead/architect. Design the MVP architecture for this idea. Reason step by step, weigh trade-offs.
PRODUCT: "<PASTE: what the service is and who it's for>"
KEY MVP FEATURES: <2-4 main functions>
CONSTRAINTS: <team/timeline/budget; stack I know; load, if known>
Give me:
1. The stack: frontend/backend/database/hosting — with a SHORT justification for each choice and where "boring and reliable" beats trendy. Reuse-first: take what exists, don't reinvent.
2. Data schema: main entities, fields, relations (as a list of tables/models). Mark keys and important indexes.
3. System components and flows: what talks to what (client ↔ API ↔ DB ↔ external services), without over-complicating.
4. The main risks and bottlenecks of the MVP + how to defuse them cheaply at the start.
5. What NOT to build in the MVP (an explicit list of tempting over-engineering).
6. Launch phases: 3-4 milestones from "skeleton" to "first users", with what's done at each.
Where data is missing, make a reasonable assumption and mark it [assumption]. One recommended path, not "it depends".
The technique: step-by-step reasoning over trade-offs plus a "what NOT to build in the MVP" section keeps the model from producing a beautiful architecture nobody can carry. Architecture and the data schema are the primary artifact the code is derived from.
Filled-in example
Product: "a booking service for independent professionals (barbers, nail techs): online slots + reminders". MVP features: a directory of pros, slot booking, SMS/email reminder. Constraints: solo developer, I know TS/React/Node, minimal budget.
Expected AI response: stack Next.js + Node + PostgreSQL + managed hosting (justification: one language, fast deploys, "boring and reliable"); entities master, service, slot, booking, client with keys and an index on slot time; flow client → API → DB, reminders via a queue + an external SMS provider; risk — double-booking the same slot → solved with a unique constraint in the DB; "don't build" — microservices, your own auth, a mobile app; phases: skeleton+DB → booking works → reminders → first pros onboarded.
Variations
- Several options. "Give me 2 stack options (monolith vs serverless) with pros/cons and recommend one for my constraints."
- ADR. "Write up the 3 key decisions as short Architecture Decision Records: context → decision → consequences."
- Bridge to code. "Based on this data schema, give me the PostgreSQL DDL" or "generate a spec-driven brief for the booking feature."
Pro tips
- The most valuable section is "what NOT to build in the MVP". If the AI waters it down, demand an explicit list of over-engineering temptations.
- Push "reuse-first": for standard problems (auth, payments, queues) an off-the-shelf solution almost always beats your own — ask it to name specific ones.
- Read an AI's architecture like a strong colleague's draft: check the trade-offs against YOUR constraints instead of taking a trendy stack on faith.