Plan Before You Build

The Zero-Shot Trap

A common mistake when first learning to use AI for software is opening a blank chat and typing: "Build me an app that does X. Here are my 3 features. Write the code."

The AI will eagerly try. It will spit out 500 lines of code. And it will get it wrong. Why? Because you forced it to guess your business rules, guess your database structure, and guess your architecture — all at once.

Want just the prompts? They're in the Quick Reference.

In construction, you measure twice, cut once. In software, you document first so you're not debugging blind later. Or if you're my dad — measure once and swear twice. Totally up to you.

The planning workflow is linear — each step unlocks the next:

Step 1: Discovery

Instead of giving the AI a massive brain dump, flip the script. Have the AI interview you — the same way a business analyst would run a discovery meeting:

I have an idea for a software application. Before we write 
any code, act as a Senior IT Business Analyst and Systems 
Architect.

Interview me to extract the business requirements, user 
journeys, technical constraints, and data needs.

Rules:
1. DO NOT write any code
2. Ask 1-3 questions at a time
3. Wait for my answers before continuing
4. Research what I don't know and recommend solutions
5. Keep going until you have 100% understanding

Say "I am ready. Let's begin." if you understand.

A thorough discovery should cover:

Step 2: Write the Requirements Docs

Once discovery is complete, have the AI produce your documentation suite. These docs — your BRD, tech spec, and data schema — become the requirements docs you'll hand to the AI before every coding session.

Document 1: Business Requirements Document (BRD)

What it defines: What you are building and Why.

Key sections: Executive Summary, Target Users, Core Features (with acceptance criteria), Out of Scope, Open Questions.

Why the Acceptance Criteria matter: They become your testing checklist. When the AI writes code, you go through them one by one: did it do this? Yes or No. No ambiguity.

Document 2: Technical Specification

What it defines: How the app will be built.

Key sections: Tech Stack, Architecture Overview, Project Structure, External Dependencies, Environment Variables.

Document 3: Data Dictionary & Schema

What it defines: Every piece of data, its exact shape, and how things connect.

This is the AI's source of truth. When the AI knows the exact column names, types, and relationships, it can't hallucinate them. If your schema says the field is displayName and the AI writes user_name, you catch it instantly — because the spec is right there.

Not sure what a good one looks like? Here's a simplified example:

Table: users

Table: posts

If the table above looks unfamiliar, don't worry — you don't need to know database terminology. Describe your data however you can: "Users have a name, email, and a role that's either 'user' or 'admin.'" The AI will help you structure it. The point is: tell the AI exactly what your data looks like so it never has to guess.

Step 3: The Handoff — Time to Code

You now have your requirements docs saved as files in your project. Feed them to the coding AI:

Act as a Senior Full-Stack Developer. Here are the project 
documents — BRD, Tech Spec, and Data Schema:

[attach files]

Rules:
1. Do NOT write the whole app at once
2. Use EXACTLY the field names in the Data Schema
3. Follow the architecture in the Tech Spec
4. Build one feature at a time, wait for my approval
5. If anything in the docs is ambiguous, ask — don't guess

Review the docs and say "Read and Understood."

Feed Features One at a Time

Chat 1: "Set up the project structure and database"
         → Uses: TECH_SPEC + DATA_SCHEMA

Chat 2: "Build user registration and login"
         → Uses: BRD (Feature: Auth) + DATA_SCHEMA

Chat 3: "Build the main feature"
         → Uses: BRD (Feature section) + DATA_SCHEMA

Chat 4: "Polish and fix bugs"
         → Uses: Acceptance Criteria as testing checklist

Each chat is focused. Each chat has documented context. Each chat produces a verifiable result.

Why This Works So Well

Quick-Start: 40-Minute Version

Don't have time for the full suite? Here's the minimum:

1. Project Brief (10 min) — What, why, and for whom
2. Data Schema (15 min) — Every table, field, type, and relationship
3. Acceptance Criteria (15 min) — Testable checklist for each feature

That's 40 minutes of documentation that will save you hours of wasted coding iterations.

When to Start Over

Sometimes the AI takes your project so far down the wrong path that no amount of fixing will save it. Every patch creates two new bugs. The codebase becomes a Jenga tower where you're afraid to touch anything.

The five warning signs:

The 50% Rule

If fixing the current codebase will take more than 50% of the time it would take to rebuild with updated docs — start over. The rebuild is cleaner and faster.

Starting Over ≠ Starting From Zero

This is why the planning workflow above exists:

Before you abandon the old code, extract what you learned:

We're going to do a post-mortem on this project. Document:
1. What worked well that we should keep
2. What architectural decisions caused the most problems
3. What requirements we discovered during development
4. What to avoid next time

Don't write new code — just create a "Lessons Learned" document.

Update your docs with those lessons, open a fresh chat, feed it the updated requirements, and go. You're not exploring this time — you're executing a proven plan.

When NOT to Start Over