Building with AI: Phase 01 — Planning & Architecture

Why planning comes before code

Before a single line of code, before any framework decision, you need to be clear about what you are building, for whom, and why it matters.

Planning is the unglamorous phase that separates products that ship from side projects that stall. In this tutorial, you define your project with precision: one problem statement, one persona, and three features. Nothing more.

You will also make your first foundational technical choices, the kind that are expensive to change later. Each decision is framed with concrete trade-offs, and AI is used where it genuinely speeds up the work.

1. Project definition

Every project needs a one-sentence problem statement. Not a feature list, and not a vision statement. One sentence that describes the pain, the person experiencing it, and what your solution does about it. This becomes your north star for every future decision.

The best problem statements are embarrassingly specific. "Helps people save time" is useless. "Helps solo freelance designers who lose 3+ hours a week chasing invoice payments, by automating follow-up emails after 7 and 14 days" is a product you can build and sell.

2. Target audience and user persona

A persona is not a demographic box. It is a concrete human being with a specific situation, a specific frustration, and a specific desired outcome. You are designing for this person, not for "users" in the abstract.

Your persona document needs four things:

1. who they are
2. what they are trying to accomplish
3. what currently blocks them
4. what success feels like

Step 1: Name and context

Give them a real name and a one-line description of their situation.

Example: Jamie, 34, runs a Shopify store selling handmade ceramics on the side of a full-time job.

Step 2: Their goal

Describe what they are trying to achieve in life or work.

Example: Jamie wants the store to replace her salary within 18 months so she can make ceramics full time.

Step 3: Their blocker

Define what currently stops them from reaching that goal. This is where your product lives.

Example: She spends 6 hours a week manually managing inventory, writing product descriptions, and chasing abandoned carts.

Step 4: Their success definition

Make success emotional, not just functional.

Example: Jamie logs in on Monday morning, sees the week's admin work already handled, and spends those 6 hours glazing a new batch instead.

3. Defining your MVP scope

An MVP is not a half-built version of your full product. It is a complete, working solution to one specific problem for one specific person. The word "minimum" refers to features, not quality.

The most effective way to define scope is the 3-feature rule: list every feature you could build, then cut everything except the three without which the product cannot solve the core problem at all.

A useful filter is this question: Can the user get the core value of the product without this feature? If the answer is yes, move it out of scope.

4. Technical choices

There is no universally correct tech stack. There is only the right stack for your situation: your team's current skills, your product's real performance requirements, your timeline, and your budget.

Before choosing a stack, answer three questions honestly:

• What do I already know well enough to ship fast?
• What does my product genuinely need?
• What can I deploy and maintain without hiring?

AI prompt: Stack comparison

I'm building [describe your product in 2-3 sentences].

My constraints:
- Team size: [solo / 2 devs / etc.]
- Timeline to MVP: [X weeks]
- Budget for infra: [free tier / $X/month]
- My current skills: [languages/frameworks you know]

Compare these two stack options for my situation:
Option A: [stack A]
Option B: [stack B]

For each, cover: time to ship MVP, scaling risk, monthly cost at 1k users,
and one thing I'll regret if I choose it. End with a direct recommendation.

5. Using AI to generate user stories

A user story is a short sentence written from the perspective of the user:

As a [type of user], I want to [do something] so that [I achieve some goal].

They are not technical specs. They are expressions of what value a feature delivers.

AI is especially useful here when you feed it the persona first. That keeps the stories grounded in real behaviour rather than generic product language.

AI prompt: User story generation

My user persona:
Name: [Name]
Situation: [one line about who they are]
Goal: [what they're trying to achieve]
Blocker: [what currently stops them]

My 3 core MVP features:
1. [Feature A]
2. [Feature B]
3. [Feature C]

For each feature, generate 3 user stories using this format:
"As a [persona name], I want to [action] so that [benefit]."

Then for each story, add one acceptance criterion:
"Given [context], when [action], then [expected result]."

Keep each story specific to my persona and avoid generic language like "the user".

Once you have the stories, review them as a set. Can you trace a path from first visit to core value? If not, you have either found a missing feature or discovered that one of your "core" features is not actually core.

6. Sketching your sitemap and route structure

A sitemap is the list of every page or screen in your product, organised hierarchically. It is not a design. It is a map of what exists. Before writing a single component, you should be able to list every route your app will have in V1.

Route planning forces a useful discipline: if you cannot name the page, you probably have not defined the feature properly.

Example V1 route map

/* PUBLIC routes - no auth required */
/                        -> Landing page
/pricing                 -> Pricing page
/login                   -> Login / signup
/blog                    -> Blog index
/blog/[slug]             -> Individual post

/* AUTH routes - require login */
/dashboard               -> Home after login
/dashboard/projects      -> Project list
/dashboard/projects/[id] -> Single project view
/dashboard/settings      -> User preferences

/* API routes */
/api/auth/[...nextauth]  -> Auth endpoints
/api/projects            -> CRUD projects
/api/ai/generate         -> AI generation endpoint

Most V1 apps need between 8 and 16 routes. If you are planning more than 20, you have probably let V2 scope leak into the initial build.

AI prompt: Sitemap generation

I'm building [product description] using [framework].

My 3 core MVP features are:
1. [Feature A]
2. [Feature B]
3. [Feature C]

Generate a complete V1 sitemap with:
- All public routes (no auth)
- All authenticated routes
- All API routes needed to support the features

Format as a flat list with path -> description.
Flag any route that sounds like a V2 feature so I can cut it.
Suggest a logical URL naming convention to use consistently.

7. Phase checklist

Before moving to the next phase, make sure every item below is complete:

8. What you should have at the end of Phase 01