Describing your app (mini-PRD)

Why describe before generating

The temptation is strong to open the tool and type "make me a habit-tracking app". Try it, and you'll see the problem: the AI will fill every gap with its own choices. It will decide the colors, the features, the structure — and the odds that its choices match what you had in mind are slim. You'll then spend ten messages unraveling what two minutes of thinking could have prevented.

That's the whole point of the mini-PRD. PRD stands for "Product Requirements Document", the spec that professional product teams write. The "mini" version fits in about ten lines and answers five questions: what the app is for, who uses it, what exactly it does, what it looks like, and on what technical foundation. With that, the AI produces something close to your vision on the first try.

There's a hidden benefit: writing the mini-PRD forces you to clarify your own thinking. Many app ideas seem crystal clear in your head and turn out fuzzy on paper. "An app to help students" — fine, but to do what, concretely? The mini-PRD is your first project-manager tool, before even the first prompt.

The mini-PRD in five blocks

• Purpose: one sentence. "A web app to track daily work habits."
• Users: who uses it and in what context. "Middle-school students, on their phones, in the evening."
• Features: 3 to 5 concrete actions, numbered. No more for a v1.
• Style: 3-4 adjectives and one constraint. "Clean, mobile-first, green accent, big buttons."
• Tech: keep it simple. "Plain HTML/CSS/JS, local storage, no user accounts."

The order matters: you start from the intention (the purpose) and end with the implementation (the tech). If you don't know what to put in the tech block, simply write "as simple as possible, no database and no user accounts" — the AI will understand and pick a sound foundation for you.

Tom's complete mini-PRD

I want to build a web app: a habit tracker.
Users: middle-school students who want to keep work routines, mostly on phones.
Features:
1. add / delete a habit
2. check off each day whether the habit was done
3. see a streak of consecutive successful days
4. see a mini-calendar of the month with checked days
Style: clean, mobile-first, green accent, big easy-to-tap buttons.
Tech: plain HTML/CSS/JS, local storage (localStorage), no user accounts.
Build ONLY features 1 and 2 first. We'll add the rest after my tests.

Look at the last line: Tom gives the complete vision, but explicitly asks to build only features 1 and 2. That's the winning combination — the AI knows the destination (it will make choices consistent with what's coming), but the first deliverable stays small and testable. You validate the foundation, then you ask "now add feature 3" in a following message.

The words that change everything

Some terms in your mini-PRD have an outsized effect on the result. "Mobile-first" tells the AI to design for a small screen first — crucial if your users are on phones. "Local storage" avoids all the complexity of accounts and servers. "Clean" steers toward a sober design rather than a cluttered one. These keywords are shortcuts to entire technical decisions.

Conversely, some words trigger complexity you don't suspect. "User account" implies sign-up, login, passwords, recovery — hours of work. "Notifications" implies permissions and external services. "Real-time" (seeing others' changes instantly) implies a permanent server. If one of these words sneaks into your v1, seriously ask yourself whether it can wait for v2.

Describing the style without being a designer

You don't need designer vocabulary to get a beautiful app. Three simple techniques: give adjectives (clean, warm, professional, playful), cite a well-known reference ("in the spirit of Apple's Notes app", "sober like a news site"), and specify an accent color ("green accent", "midnight blue tones"). The AI will translate these hints into consistent typographic and visual choices.

If the first render doesn't please you, refine by comparison rather than jargon: "more breathing room", "the buttons are too small for a thumb", "too many colors, keep only the green and the gray". These are remarks anyone can make, and the AI understands them perfectly.

Prioritizing: v1 or later?

Distinguish the "essential for v1" from the "nice to have later". The test is simple: without this feature, is the app still useful? If yes, it's a "later". Tom applies the test: without adding habits, the app is empty — v1. Without daily check-offs, it's useless — v1. Without notifications, it works just fine — later. Without sharing between students, same — later.

flowchart TD
  I["Feature idea"] --> Q["Without it, is the app useful?"]
  Q -->|"No, it's unusable"| V1["Essential for v1"]
  Q -->|"Yes, it still works"| V2["“Later” list"]
  V1 --> P["Into the mini-PRD"]
  V2 --> L["Noted for v2"]

Keep your "later" list safe in a file or a note: it's not a trash can, it's your roadmap. In chapter 5, once the app is deployed, this list is where you'll pick your next improvements — guided by the feedback of your first users.

Chapter mini-glossary

• PRD: Product Requirements Document, the spec of a product.
• localStorage: a small storage space in the browser, where an app can save data without a server.
• Mobile-first: designing for the phone first, then adapting to large screens.
• v1 / v2: first usable version / next improved version.
• Streak: a run of consecutive successful days (a common term in habit apps).