How to Plan an App Before You Prompt: A Pre-Build Checklist

TL;DR: Most AI-built apps that fail were poorly planned, not poorly built. The pre-build checklist for indie founders: target user (one specific person), problem statement (what they currently do that's painful), data model (what entities and relationships), integrations (what external services), success criteria (what 'good' looks like), MVP scope (what must ship vs defer), constraints (timeline, budget, technical). 1--3 hours of planning before prompting saves days of building the wrong thing. This guide covers the full checklist, the deliverables (PRD, data model, wireframes), and the pre-build discipline that separates shipped apps from abandoned prototypes.

Introduction

AI app builders made the build phase fast. A weekend produces what used to take months. The bottleneck shifted upstream --- most failed AI-built apps fail because they were the wrong app, not because they were built badly. Build velocity without planning discipline produces fast failure, not fast success.

The planning discipline that mature product teams developed over decades still applies. Talk to users; understand the problem; design the solution; spec the MVP; build deliberately. AI app builders compressed the build phase; they didn't eliminate the planning phase. Founders who skip planning and dive into prompting often produce technically working apps that don't solve real problems for real users.

This guide covers the realistic pre-build checklist for indie founders using AI app builders. The questions to answer before writing a single prompt. The deliverables (PRD, data model, wireframes). The 1--3 hours of work that saves days of building the wrong thing.

Why planning still matters in the AI era

• Build velocity without planning = fast failure, not fast success
• AI generates what you ask for; if the ask is wrong, the build is wrong
• Most AI-built apps that fail were poorly planned, not poorly built
• Planning takes hours; rebuilding takes days
• Planning surfaces assumptions before they're baked into code
• Planning forces clarity about user, problem, and success

The pre-build checklist

1. Target user (one specific person, not 'everyone')

• Name one specific person this app is for
• What's their job?
• What's their context (industry, company size, role)?
• What tools do they currently use for this?
• What's their level of technical comfort?
• Are they paying for tools in this space currently? How much?
• Specific over generic --- 'solo lawyers running 1--3 person firms' beats 'professionals'

2. Problem statement

• What is the user currently doing that's painful?
• How much time does it take?
• What goes wrong with current approach?
• What's the cost of the current pain (money, time, missed opportunity)?
• How urgent is solving this for the user?
• Why now? What changed that makes solving this matter?
• Avoid vague problem statements --- 'too much friction' is meaningless; 'spends 4 hours/week manually entering invoice data into accounting software' is concrete

3. Data model

• What entities exist in this app? (User, Project, Task, Invoice, etc.)
• What attributes does each entity have?
• What are the relationships between entities? (User has many Projects; Project has many Tasks)
• What needs to persist vs ephemeral?
• What needs to be private vs shared?
• Draft this on paper before prompting --- saves significant refactoring
• Example for habit tracker: User → has many → Habit → has many → HabitLog (one per day per habit)

4. Integrations

• What external services does this app connect to?
• Auth provider (Supabase, Clerk, Auth0, etc.)
• Payment processor (Stripe, Paddle, Lemon Squeezy)
• Email service (Resend, Postmark, SendGrid)
• AI APIs (OpenAI, Claude, etc.) if any
• Other SaaS APIs (Google Calendar, Slack, etc.)
• Data import sources (CSV, existing tools)
• Identify integration costs (some are pay-per-use)

5. Success criteria

• How will you know if this app is working?
• Quantitative metrics: signups, activations, retention, revenue
• Qualitative signals: users say 'I'd pay for this'; users use it repeatedly
• Define specific numbers --- '10 users using daily within 30 days of launch'
• What would make you continue investing? What would make you stop?
• Failure criteria --- if X metric is below Y by date Z, you'd reconsider

6. MVP scope

• What MUST ship in v1 to be useful at all?
• What features can be cut from v1?
• Most founders include too much in v1; aggressive cutting wins
• Test: if you removed feature X, would users still find this useful for the core problem?
• Define explicit 'in scope' and 'out of scope' lists
• Defer everything that's not solving the core problem

7. Constraints

• Timeline --- When does this need to ship?
• Budget --- Hosting, tooling, paid services
• Technical skills --- What can you do? What requires help?
• Time commitment --- How many hours per week?
• Legal/regulatory --- Industry-specific constraints (healthcare, financial, etc.)
• Constraints inform tradeoffs throughout build

The deliverables (what you produce before prompting)

1. One-page PRD (Product Requirements Document)

• Title and brief summary (2--3 sentences)
• Target user (specific)
• Problem statement
• Proposed solution (the app itself)
• Key features (5--10 max)
• What's NOT included (explicit non-goals)
• Success criteria
• Constraints
• 1--2 pages maximum

2. Data model sketch

• Hand-drawn or text-based entity-relationship diagram
• Each entity with key attributes listed
• Relationships between entities marked
• What's RLS-protected (user data isolation)
• What's public vs private
• 30--60 minutes of work

3. Wireframes (optional but recommended)

• Rough sketches of 3--5 key screens
• Hand-drawn is fine; tools like Excalidraw or Figma optional
• Focus on screen flow, not pixel-perfect design
• Helps you visualize the user experience before prompting
• 30--60 minutes of work

4. The actual prompt

• Built from the PRD, data model, and wireframes
• Detailed enough to generate the right thing
• Specifies stack (Next.js, Supabase, Stripe, etc.)
• References the data model explicitly
• Includes success criteria for the build itself
• Saves significant iteration vs vague prompts

Example pre-build for a habit tracker

Target user

Adults in addiction recovery using AA, NA, or similar 12-step programs. Specifically those 1--3 years sober, who want to track daily recovery habits (meeting attendance, sponsor calls, meditation, journaling, gratitude practice). Currently use a mix of paper journals, generic habit apps, and AA workbooks.

Problem statement

Generic habit trackers don't fit recovery workflows. They don't understand the language ('working a step,' 'sponsor check-in,' 'meeting attendance'). They use shame-based streak mechanics that trigger users in recovery. They don't connect habits to recovery goals or step work. Users currently switch between paper, Streaks, and the BigBook with no integration.

Data model

User (id, email, recovery_date, program) → has many → RecoveryHabit (id, user_id, name, target_frequency, category --- Meeting/Step/Service/Daily) → has many → HabitLog (id, habit_id, date, completed, notes). SponsorContact (id, user_id, name, phone). MeetingLog (id, user_id, date, meeting_name, type). All entities RLS-protected --- users only see their own data.

Integrations

Supabase Auth, Stripe ($4.99/month after 14-day free trial), Resend for emails, optional Google Calendar for meeting reminders.

Success criteria

20 users completing daily check-ins for at least 30 days within 60 days of launch. Average $5/month willingness to pay confirmed by 20+ user interviews. If MRR isn't $500+ within 90 days of launch, reconsider direction.

MVP scope

• In: habit definitions, daily check-ins, streak tracking (without shame mechanics), meeting log, sponsor contact, basic analytics
• Out: AI features, sharing/social, group accountability, integration with AA service work, native mobile app

Pre-build customer development (often skipped, always valuable)

• Talk to 10--15 potential users in your target audience BEFORE building
• Show them your PRD or wireframes; ask if they'd use this
• Ask what they currently do for the problem you're solving
• Ask what they'd pay
• Ask what's most important to them
• Customer interviews surface mistaken assumptions
• Saves building the wrong product entirely

Common Mistakes in Pre-Build Planning

• Targeting 'everyone' --- Generic target audience → generic product → no audience finds you
• Vague problem statements --- 'Productivity is hard' is meaningless. 'Spends 4 hours/week on X' is concrete.
• Scope creep before launch --- Every feature that 'might be useful' delays launch. MVP discipline wins.
• Skipping customer interviews --- Building based on assumptions = building wrong thing. 10--15 interviews surface gaps.
• Over-specifying --- Don't write 50-page PRDs for indie SaaS. 1--2 pages is enough.
• Ignoring constraints --- Timeline and budget shape everything. Plan within constraints rather than ignoring them.
• Diving into prompting without planning --- Build velocity multiplies wrong direction.
• No data model planning --- Refactoring data model later is expensive; plan upfront.
• No success criteria --- Without targets, you don't know if you succeeded.
• Pretending planning is wasted time --- Pre-build pays back many times over.
• Not committing to the planning --- Half-done planning produces half-clear prompts.
• Treating planning as one-time --- Plans evolve; revisit as you learn from users.

The realistic time allocation

Pre-build is ~10% of total project time but determines whether the other 90% produces something useful.

Frequently Asked Questions

Q1: How long should planning take? 1--3 hours for the documents; 10--20 hours including customer interviews. Less than 1 hour suggests you skipped important parts. More than 10 hours on documents alone suggests overplanning --- get to building.

Q2: Can I plan in my head or do I need to write it down? Write it down. The act of writing forces clarity. Vague intent becomes specific text. Plans you can't articulate aren't plans; they're hopes.

Q3: What if I don't know my users yet? Then your first step isn't building; it's customer discovery. Talk to 10--15 potential users before designing anything. Building without knowing users produces building wrong thing.

Q4: Should I use AI to help with planning? Yes --- AI can help interview prep, brainstorm features, draft PRD sections. But validate with real customers; don't rely on AI for understanding your users. AI generates plausible-sounding planning; only real customers tell you if it's right.

Q5: What about iterating the plan as I learn? Yes --- plans evolve. Pre-build plan is your starting point; revise as customer interviews and early usage surface new information. Don't be rigidly attached to v1 plans.

Q6: How detailed should the data model be? Detailed enough to be useful; not so detailed it becomes useless. Key entities, key relationships, key constraints (RLS for user data). 5--10 entities for typical SaaS. Don't try to spec every column upfront.

Q7: What if the AI generates something different from my plan? Iterate. AI generates based on prompt; refine the prompt or refine the generated code. Treat AI output as draft, not final. Your plan is the spec; AI helps execute it.

Conclusion

• Most AI-built apps that fail were poorly planned, not poorly built. AI compressed the build phase; planning discipline matters more, not less.
• Pre-build checklist: target user (specific), problem statement (concrete), data model (entities and relationships), integrations (external services), success criteria (quantitative + qualitative), MVP scope (in/out lists), constraints (time/budget/skill).
• Deliverables: 1-page PRD, data model sketch, optional wireframes, detailed prompt. Total time: 1--3 hours for documents; 10--20 hours including customer interviews. ~10% of total project time.
• Skip customer interviews and you're building from assumptions. Talk to 10--15 potential users before building.

Before your next AI-built app, work through this checklist. The investment pays back many times in avoided rebuild. Build velocity without planning produces fast failure; planning + build velocity produces fast success. The AI builders who ship working products in 2026 are the ones who plan deliberately before prompting. Treat planning as the most leveraged time of the project. Then build with confidence.