THE VAULT / START HERE / PROMPT + MARKDOWN

The Architecture Interview

You should not need to know what a database is to plan an app. This kit flips the job: you paste one prompt, the AI interviews YOU (one plain-English question at a time, about 12 total), and out comes a complete architecture.md that Lovable, Bolt, or Claude can build from without guessing. You get the interview prompt, a finished worked example for a dog groomer's booking page, and the maintenance prompt that keeps the plan honest as your app grows.

LAST VERIFIED 2026-07-09

Apps built without a plan collapse on feature 5

Here is the pattern. Features 1 through 4 feel like magic: you describe, the AI builds, it works. Then feature 5 ("let customers log in and see their own stuff") breaks features 2 and 3, and every fix breaks something else. Two days later you're pasting error messages into chat like a slot machine.

NOTE

Use this page as a prompt reference. Every file below is built to be handed straight to an AI. Download it, drop it into Claude, ChatGPT, Cursor, or Lovable, and say "use this as my playbook." The prompts on this page are copy-paste ready.

The cause isn't your prompting. When you build feature by feature, the AI makes dozens of silent structural decisions on your behalf: where information gets saved, what's public, what connects to what. Each decision is locked in by the time you find out it was wrong. Feature 5 is usually just the first feature that exposes one.

The traditional fix is an architecture document: a plan of the app's parts and how they fit, written before building. The catch: writing one normally requires exactly the technical vocabulary you don't have yet. So here's the move this kit is built on: you don't write the plan, you get interviewed for it. The AI asks about your app in plain English, explains every concept in one sentence as it goes, makes the technical choices itself, and hands you the finished document.

Building feature by feature	Building from architecture.md
The AI decides where data lives, silently, per feature	Data plan written once, every feature reads and writes the same way
"Who can see this?" answered by accident (often: everyone)	A who-sees-what table the AI turns into privacy rules
Feature 5 fights features 2 and 3	Build order is planned so each step leaves the app working
Surprise costs when you connect payments or email	Monthly cost estimate in dollars, before you build

How the interview works: 12 questions, zero jargon required

1
Open a fresh chat
Claude or ChatGPT, either works. Fresh chat matters: no leftover context steering the questions.
2
Paste the interview prompt
The full prompt is below (and downloadable). Send it as-is, nothing to fill in.
3
Answer roughly 12 questions
One at a time, in plain English. The AI explains every concept inside the question itself ("a database is just a spreadsheet your app reads and writes automatically..."). If it ever asks you to pick between two technical options, it's breaking its own rules: tell it "you choose, explain why in the document."
4
Save the output as architecture.md
The interview ends with one complete document. Save it as a file named architecture.md. That file is now the plan every build session starts from.

The interview covers eight things, and the output document has a fixed section for each: what we're building, pages and screens, the data it stores, who can see what, outside services (things like payments and email that come from other companies, each with its own account and price), hosting (the computer on the internet your app lives on), a monthly cost estimate in dollars, and a build order that starts with a walking skeleton (the smallest version that's real and online).

PAYOFF

The interview also protects you from yourself. When you describe a v1 feature that doubles the difficulty (real-time chat, a mobile app, teams), the prompt makes the AI say so, propose the simpler version, and park the ambitious one in a "Not in v1" list instead of deleting it. That list is where good v2s come from.

The interview prompt (paste it whole)

This prompt is long on purpose. The one-question-at-a-time rule stops the AI from dumping a questionnaire on you. The "never ask me to make a technical choice" rule is the whole product. The fixed output format is what makes the result buildable. Don't trim it.

PROMPT: THE ARCHITECTURE INTERVIEW PROMPT (paste into a fresh chat, nothing to fill in)

You are a friendly, extremely experienced software architect interviewing me, a non-technical founder, about an app I want to build. Your goal: understand my app well enough to write a complete architecture document that any AI coding tool (Lovable, Bolt, Claude, Cursor) can build from without asking me a single technical question.

RULES OF THE INTERVIEW

1. Ask me EXACTLY ONE question at a time. Wait for my answer before asking the next one. Never send a list of questions.
2. Plain English only. Assume I have never heard the words database, auth, API, backend, or deploy. Every time you need a technical concept to ask a question, explain it in one sentence first, inside the question itself. Example: "A database is just a spreadsheet your app reads and writes automatically. What information does your app need to remember between visits?"
3. Never ask me to make a technical choice. Do not ask "Postgres or MySQL?" or "which auth provider?" Ask me about my app and my users, then YOU make the technical choices and note the reason in the final document.
4. If my answer is vague, ask one short follow-up to pin it down. "People can post stuff" becomes "What exactly is a post here: text, a photo, a price, a date?"
5. Push back when I overcomplicate. If I describe a feature that doubles the difficulty for version 1 (real-time chat, a mobile app, AI features, teams), say so in one sentence, propose the simpler version, and ask if v1 can ship without it. Put anything we cut into a "Later" list, do not delete it.
6. Keep a running count. Start each question with "Question N of roughly 12" so I know where we are. If my app is very simple, finish early.
7. Money questions are mandatory. Before finishing, you must know: do users pay (and how much), and roughly how many users I expect in the first 3 months. You need both to estimate running costs honestly.

THE GROUND YOU MUST COVER (adapt the wording, keep the substance)

- What the app does, in one sentence, and for whom.
- The 3 to 5 things a user actually does in it, step by step.
- The screens/pages that requires (you propose the list, I confirm).
- What information the app must remember between visits (this becomes the database plan). For each kind of information: what it contains and who it belongs to.
- Who logs in, if anyone. Explain: "logging in is only needed if the app must remember who someone is or hide their stuff from others." Visitors vs. account holders vs. an admin (me).
- Who is allowed to see and change what. Get concrete: "can customer A see customer B's bookings?"
- What the app must talk to in the outside world: taking payments, sending emails or texts, showing maps, using AI. Explain that each of these is an outside service with its own account and price tag.
- Anything already existing: a domain name, a brand, a spreadsheet of current customers, an Instagram, a current manual process.
- Expected scale: users in month 1 and month 3, so hosting and cost estimates are honest, not hand-wavy.
- The one thing that would make me consider v1 a success.

WHEN THE INTERVIEW IS DONE

Say "That's everything I need. Here is your architecture document." Then output ONE complete markdown document called `architecture.md`, and nothing after it. It must contain EXACTLY these sections, in this order:

## 1. What we're building
One paragraph, plain English. The app, the user, the job it does. Plus the single success criterion I gave you.

## 2. Pages and screens
A numbered list of every page. For each: its name, its one job, and who can see it (everyone / logged-in users / admin only).

## 3. Data it stores
Plain-English tables. For each kind of thing the app remembers (e.g. Customers, Bookings, Services): a bullet list of the fields it holds, in everyday words ("the customer's phone number", not `varchar(20)`), and one line on how things connect ("each Booking belongs to one Customer and one Service").

## 4. Who can see what
A short table: each kind of user (visitor, customer, admin) against each kind of data, with see / edit / nothing. This section exists so the coding AI builds the privacy rules instead of leaving everything public.

## 5. Outside services
Every third-party service the app needs: what it's for in plain English, the specific provider you recommend, and its price. If a free tier covers my expected scale, say so and say where the free tier ends.

## 6. Hosting
Where the app will live on the internet, in one short paragraph: the provider you recommend, why, and what I'll need to sign up for. Assume I will deploy through the AI tool's own publish button when possible.

## 7. Monthly cost estimate
A small table: each service, its monthly cost at my expected month-3 scale, and the total. Include a one-line "when this grows" note: the first thing that starts costing money as usage climbs, and roughly at what point.

## 8. Build order
The features as a numbered build sequence, smallest working version first. Each step must leave the app in a usable state. Mark step 1 clearly: it is the walking skeleton (one page, real data, deployed). Put every "Later" item we cut during the interview at the bottom under "Not in v1".

DOCUMENT RULES

- Everything in the document is in plain English with any unavoidable technical term explained in one clause.
- Make real technology choices (which database service, which payment provider) and give a one-line reason for each. Choose boring, popular, cheap-or-free options suited to a beginner using AI tools, not whatever is trendiest.
- No placeholders like [TBD]. If we didn't cover something, make the sensible default choice and mark it "(default, change if wrong)".
- The test of this document: a coding AI that has never spoken to me should be able to build v1 from it without asking me anything.

Begin now with Question 1. Remember: one question, plain English, explain any concept as you go.

What the finished document looks like (a dog groomer, in full)

Below is a complete architecture.md the interview produces for a realistic beginner app: a booking page for a one-person dog grooming business, with deposits paid by card. Read it before you run your own interview so you know what "done" looks like.

Things to notice as you skim it:

[ ]Every technical choice is made and explained, and none required the founder to know anything. Stripe for payments, Supabase for the database, each with a one-line why.
[ ]Section 4 is a who-sees-what table. Visitors see that a slot is taken, never who took it. Without that table, most AI builders leave everything public.
[ ]Costs are numbers: $25/month fixed, plus $0.74 of Stripe fees per $15 deposit, and the exact point where the free tiers end.
[ ]Build step 1 is a walking skeleton: one page, real services, live at the real domain, usable before payments even exist.
[ ]"Not in v1" holds five cut features, including the SMS reminders that got cut during the interview. Cut, not forgotten.

Handing architecture.md to Lovable, Bolt, or Claude

The document only pays off if your builder actually follows it, and follows it in order. The biggest mistake is pasting the whole plan and saying "build this": the AI attempts all 7 build steps at once and you're back to feature-5 chaos, just faster. Hand it over with the kickoff prompt below instead: it pins the AI to step 1 and makes the document the law.

Tool	How to attach the document
Lovable	Open your project, click the gear icon, then Knowledge, and paste architecture.md there so every future chat sees it. Then send the kickoff prompt in the chat.
Bolt	No knowledge store, so paste the kickoff prompt and the full architecture.md together as your first message, prompt on top.
Claude (web or Cursor)	Attach architecture.md as a file (paperclip icon in the chat box), then send the kickoff prompt. In Cursor, drop the file in your project folder so it's always in reach.

PROMPT: THE KICKOFF PROMPT (send with architecture.md attached or pasted below it)

The attached architecture.md is the complete plan for my app. Treat it as the law for this entire project.

Rules:
1. Build ONLY step 1 of section 8 (the walking skeleton). Do not build ahead, even partially. I will ask for each next step explicitly.
2. Follow sections 2 through 6 exactly: those pages, that data plan, those access rules, those services. Do not add pages, fields, or services the document doesn't mention.
3. Section 4 (who can see what) is a hard requirement, not a suggestion. Nothing may be visible to a user type the table doesn't grant it to.
4. If anything in the document is ambiguous or seems wrong while you build, STOP and ask me in plain English. Do not improvise a fix.
5. When step 1 is done, tell me in one paragraph: what exists now, what a visitor can do, and what step 2 will add. No jargon.

Confirm you've read the document by listing my app's pages and the build steps in one line each. Then build step 1.

WATCH OUT

The most common failure: the builder quietly adds a login system, an extra settings page, or a "nice to have" field that isn't in the document. Catch it with one line: "Is everything you just built in architecture.md? List anything that isn't, and remove it or justify it." Run that after every step until you trust the tool.

After step 1 ships, the loop is boring on purpose: "Build step 2 from architecture.md, nothing else." Then step 3. Each step leaves the app working, which means each step is also a natural stopping point for the day.

Keeping the document alive (it's a plan, not a plaque)

Your app will change: a customer asks for something, a feature from "Not in v1" earns its slot, a price changes. When the app and the document disagree, the document loses its power, because the AI starts trusting neither. The fix costs 5 minutes: run the maintenance interview whenever you're about to build something the document doesn't cover.

PROMPT: THE MAINTENANCE PROMPT (paste with your current architecture.md attached)

You are the software architect who maintains my architecture.md (attached). I want to make this change to my app:

[DESCRIBE THE CHANGE IN PLAIN ENGLISH, e.g. "customers keep asking to pay the full amount upfront instead of just the deposit"]

Do this, in order:
1. Interview me ONE question at a time, plain English only, explaining any technical concept in one sentence as you ask, until you understand the change well enough to update the plan. Usually 2 to 5 questions. Never ask me to make a technical choice; make it yourself and note the reason.
2. Tell me the blast radius before changing anything: which sections of architecture.md this touches, whether it changes the monthly cost estimate, and whether anything already built has to change. If the change is bigger than I seem to think, say so plainly and offer a smaller version.
3. Then output the FULL updated architecture.md (not a diff, the whole document) with every changed line marked with [CHANGED] at the start of it, so I can skim what moved. Update section 7 (costs) and section 8 (build order) if they're affected, and add the new work as a numbered step, not a vague note.

Rule: the updated document must still pass the original test: a coding AI that never spoke to me could build the app from it alone.

[ ]Before any new feature: run the maintenance prompt. 5 minutes now beats 2 days of feature-5 archaeology later.
[ ]After the update: save the new file over the old one, and re-paste it into Lovable's Knowledge (it does not update itself).
[ ]Monthly: ask your builder "compare the app as built against architecture.md and list every mismatch." Fix the document or the app, whichever is wrong.
[ ]Never keep two versions. One file, one truth.

When you outgrow this

architecture.md answers "how is this app put together?" Its sister document, the PRD (product requirements document: what the app must do and for whom), answers "what are we building and why?" The Fable Kickoff PRD kit is the same interview trick pointed at that question, and the two documents together are the strongest handoff you can give any builder: PRD for the what, architecture.md for the how.

When browser tools start feeling tight and you want your files, prompts, and projects living on your own machine, the Workspace Setup kit walks you from browser-only to a real working setup, one copy-paste at a time. And at the far end of this road sits the SaaS Starter Stack: the full production setup for when your dog groomer's booking page turns into a business with paying subscribers. You don't need it yet. It's good to know the road has an end.

PAYOFF

The whole kit in one line: 12 plain-English questions now, so feature 5 lands like features 1 through 4 did. Run the interview before you build anything this week.

Get the next drop

Every new Vault system ships to the list first. Twice a week, free.