Planning and Prompting Your Build

Why the Plan Comes Before the Build

Every app that turns out badly was usually built in the wrong order. Someone opened a builder, typed a wish, liked what appeared, and kept adding to it — and only later discovered that nobody had agreed on what the app was for. The plan is not paperwork that slows a build down. It is the thing that stops the build from drifting.

Today is the turning point of this phase. So far you have learned what a website and an app are made of, how the interface is designed, and how an app is arranged screen by screen. From today the question changes from what is this? to what am I going to build, and why?

An app is never the goal. The goal is always a problem that costs a business money, time or customers — and the app is only one possible answer to it. A fashion seller who loses sales because buyers keep asking the same sizing questions does not have an app problem. She has a question problem that a simple size guide page, or an automated reply, might solve just as well.

So the first sentence of any build plan is a problem statement, not a feature list. Something like: customers order on WhatsApp, then disappear when it is time to pay, and we lose roughly half of them at that step. That sentence is worth more than a page of feature ideas, because it tells you what the build has to fix and how you will know it worked.

Ask three questions before you write a single feature. Who exactly has this problem? What do they do today instead? What would change if the problem went away? If you cannot answer all three plainly, the build is not ready to start, and no amount of prompting will rescue it.

Building without a plan produces the same three failures every time. The first is drift: the app quietly becomes a collection of whatever seemed like a good idea that day, with no single purpose holding it together. The second is waste: effort goes into screens nobody asked for while the one journey the business actually needs stays half finished.

The third failure is the worst, because it is invisible until launch. With no written definition of done, the build never ends. There is always one more button, one more colour, one more small change — and the app sits unfinished for weeks while the business keeps losing the money it was supposed to save. A one-page plan is what converts an endless build into a finished one.

Turning the Problem Into a Feature List

A feature list is simply the problem statement broken into the specific things the app must do. It is written in plain business language, not technical language, because it has to be agreed by the person who owns the problem — not just by whoever is building.

Take the problem and work backwards. If customers disappear at the payment step, then the app must show a price clearly, take payment without leaving the app, and confirm that payment immediately. Each of those is a feature. You are not inventing anything; you are unpacking what the problem already implies.

Write each feature as a sentence that starts with a person and a verb: a customer can see the price of every item. A buyer can pay with a card or a bank transfer. A buyer receives confirmation of their order. This format keeps the list honest, because a feature nobody can describe as an action is usually not a feature at all — it is a decoration.

Once the list exists, sort it into two columns. Must-haves are the features without which the app does not solve the problem at all. Nice-to-haves are everything else, however attractive. For a food delivery app like Chowdeck, ordering a meal and tracking the rider are must-haves; a loyalty points system is a nice-to-have, no matter how much the business wants it eventually.

The discipline is in being ruthless with the must-have column. If a feature can be removed and the app still fixes the original problem, it is not a must-have. Most first builds fail because this column was allowed to grow until the build became too large to finish.

Every feature should be understandable to someone who has never opened a builder. Avoid words like dashboard, integration, module or API unless you can immediately explain what they mean in the sentence. If a shop owner cannot read the list and nod, the list is not finished.

Plain language also pays off later. When you hand the plan to an AI to build, the clarity of your sentences is the clarity of what gets built. Vague features produce vague apps, and the blame sits with the plan, not the tool.

Mapping the User Journey

A feature list says what the app can do. A user journey says the order in which a real person does it. They are different documents, and the second one is where most design mistakes are caught before any building starts.

A user journey is the path one person takes from the moment they arrive to the moment their goal is met. It has a beginning, a middle and an end, and every step in between is a place where they can get lost or give up. Writing it down as a numbered list is enough: they open the link, they see the offer, they tap Buy, they enter their details, they pay, they see confirmation.

Walk it as the customer, not as the owner. The owner already knows where everything is, which is exactly why the owner is the worst person to spot a confusing step. A journey that makes sense to you on the tenth reading may still lose a first-time visitor on the second screen.

Every journey starts somewhere, and that somewhere is usually not your home page. It might be a link in a WhatsApp status, an Instagram bio, a Google search result or a QR code on a flyer. Deciding the entry point first tells you what the very first screen has to do: explain the offer and give one obvious next action, without assuming the visitor has seen anything else.

This is where most Nigerian businesses lose people. A link that lands on a busy home page with ten options asks a stranger to make decisions before they understand what is being sold. A link that lands on a single clear offer with one button converts far better, and it costs nothing to build that way from the start.

The critical path is the shortest journey that delivers the value: the one route the app absolutely must get right. Everything else — the about page, the blog, the settings screen — is secondary. If the critical path works, the app works, even if the rest is plain.

Mark the critical path clearly in your plan and test it first, on a phone, as a stranger. Paystack's checkout is a useful study here: from the moment a customer decides to pay to the moment they see success, every screen removes everything that is not that decision. That is what a well-planned critical path looks like.

Choosing the First Version (v1)

The first version of an app is not a smaller version of the final app. It is the smallest build that proves the idea works. Getting v1 right is the single biggest decision in a build, because it decides whether you launch in weeks or talk about launching for months.

v1 is the version that does one job properly for one kind of user. It takes the must-have column, the critical path, and nothing else. An OPay-style wallet v1 sends and receives money with a clear record of it; splitting bills, airtime and savings come later, after the core has proved itself with real users.

The purpose of v1 is not to impress. It is to put something real in front of real customers so that their behaviour — not your assumptions — tells you what to build next. Every feature you leave out of v1 is a feature you get to design later, with actual evidence.

List the nice-to-haves deliberately, and write beside each one why it is being deferred. Something like: saved cards — deferred, because v1 uses a hosted checkout and the gateway already remembers cards. Writing the reason matters, because it turns a decision into a record, and stops the same argument from returning next week.

There is a second list worth keeping: the never list. Some ideas are not deferred, they are simply out of scope for this app — usually because they belong to a different product, or to a stage the business has not reached. Naming them once saves a great deal of energy later.

Scope creep is the slow addition of small, reasonable requests until the build has quietly doubled in size. Each request is defensible on its own, which is exactly why it is dangerous. A shop that planned a simple order form ends up with a wishlist, a review system and a referral programme, and still has not taken a single payment.

The defence is not stubbornness, it is a written plan. When a new idea arrives, the question is never is this good? It is always is this in the plan, and if not, does it replace something that is? The plan is what lets you say yes to a genuinely important change and no to a merely interesting one.

Sketching the Screens Before You Build

Before a single screen is built, every screen should exist on paper. A sketch costs nothing, takes minutes, and catches the problems that would otherwise cost hours to fix inside a builder.

On paper there is nothing to polish. You cannot adjust a shadow or pick a nicer colour, so your attention stays on the only question that matters now: does this screen do its job in the right order? Sketching also keeps the cost of being wrong low, which means you will actually be willing to throw a bad idea away.

A rough rectangle, a few lines and the word Buy is a complete sketch. Nobody needs to draw well. The value is in deciding what sits at the top, what the main action is, and what a person sees before they scroll.

You need one sketch for each screen on the critical path, and no more than that for v1. Typically that is: the landing screen, the list or catalogue, the detail view, the form, and the confirmation. Five sketches will cover most first builds in this program.

Sketch them in the order a user meets them, left to right, so the whole journey sits on one page of paper. Seeing them side by side is how you notice that two screens say the same thing, or that a step is missing between them.

Under each sketch, write three short lines: what the user sees, what they can do, and what happens next. This tiny piece of writing is what turns a drawing into a specification, and it is also the raw material for your prompts later.

It forces the empty and error cases into the open. What does the list show when there is nothing in it yet? What does the form say when a required field is left blank? What does the confirmation look like when the payment fails? Screens that nobody planned for are the screens that break in front of a customer.

How to Prompt Base44 Well

Prompting is not a talent and it is not a trick. It is a form of briefing, and like any brief it succeeds or fails on how completely it describes the thing you want. Everything you wrote in the plan is now the material you prompt with.

A wish is short and hopeful: build me an online store. A brief is specific and complete: build an online store for a shoe seller, where a visitor sees a grid of products with prices in naira, taps one to see details, adds it to a cart, and pays with a card or bank transfer. The second one produces something usable on the first attempt far more often, because nothing important has been left for the tool to guess.

The rule is simple: anything you would be annoyed to see missing, put it in the prompt. Anything you would be annoyed to see added, say so explicitly. Prompts are cheap; rebuilding is not.

A strong prompt usually carries five things: who the app is for, what the user should be able to do, what the screens are, what data is involved, and any rule that must not be broken. You do not need headings — a few clear sentences in that order will do.

For example: This app is for a Lagos-based catering business. Customers should browse menu packages, choose a date, and request a quote. Screens: a landing page, a packages list, a package detail page, and a quote form. Each package has a name, a description, a price per head and a photo. Do not add user accounts — customers should be able to request a quote without signing in. That prompt is short, but nothing in it is guesswork.

Do not ask for the whole app in one message. Ask for the structure first, then one screen at a time, checking after each. Building in steps keeps the AI's attention on one job, makes it obvious where a mistake came from, and means a wrong turn costs you one screen instead of the entire app.

A workable rhythm is: describe the whole app so the tool understands the shape of it, then say build the landing page first, and stop. Review it. Then move to the next screen. This is slower on the first afternoon and much faster by the end of the week.

The data is the information the app has to remember: products, orders, customers, dates. Say what each one holds, in ordinary words. An order holds the customer's name, phone number, the items, the total, and whether it has been paid. That sentence alone tells the builder what to store and what the forms must collect.

The rules are the constraints: only an admin can see all orders; a customer must never see another customer's details; a booking date cannot be in the past. Stating the rules early is what stops you having to explain them later, and it is the difference between an app that is safe to show a customer and one that is not.

Planning With ChatGPT and Finding the Right Words

Most people do not arrive at a builder holding a plan. They arrive holding a feeling: I want an app for my business, but I do not know where to start, and I do not know the words for half of what I want. A general AI assistant such as ChatGPT is very good at exactly that gap. Used properly it is a planning partner and a translator, never a second builder.

One rule governs everything in this section. ChatGPT helps you decide and helps you word things; Base44 builds. Keep those two roles separate and each one does its job well.

A chat is a cheap place to think. You can describe your business in messy sentences, be asked questions you had not considered, and change your mind ten times without anything being built or broken. A builder is the opposite: there, every change costs something.

It is also a place to be honest about what you do not know. You can say plainly: I run a small catering business in Ibadan, most of my orders come through WhatsApp, and I lose people when it is time to pay. I want an app but I do not know what it should contain. That is a perfectly good opening for a conversation, and a terrible opening for a build.

The output you want from this stage is not an app. It is the one-page plan from earlier in this class — problem, features, journey, v1 scope — written down and agreed with yourself.

Describe the business and the problem first, then ask for help shaping them. For example: Ask me questions about my business, one at a time, until you understand what I do, who my customers are and where I lose money. Then help me write a one-sentence problem statement.

Once the problem is settled, work through the plan in pieces. Ask it to turn the problem into a feature list, then to sort those features into must-have and nice-to-have, then to map the user journey as a numbered list of steps, then to suggest what to leave out of v1. Working in pieces keeps you in charge of each decision, so you can reject one suggestion without losing the whole plan.

Push back when it drifts. An assistant that does not know your business will happily invent features that sound sensible — a loyalty programme, a review system, a live chat widget. Your job is to keep asking one question: does this solve the problem we wrote down? If it does not, it comes out.

Before you send anything to the builder, use the chat to produce one master message: the base prompt. This is the single prompt that describes the whole app — who it is for, what it does, the screens, the data and the rules. Everything you send afterwards is an addition to it, so it quietly sets the shape of the entire build.

Ask for it directly, and ask for it as one block you can copy: Based on the plan we just wrote, write me a single prompt I can paste into my app builder to start the project. It should describe the app in plain language — who it is for, what a user can do, the screens, the data each record holds, and the rules that must not be broken. Keep it to a few paragraphs and do not invent anything that is not in the plan.

Then read it as the plan, not as a message. If the base prompt contains a feature that is not on your list, take it out. If a rule you care about is missing — only admins see all orders, no sign-up required — put it in. This one message is the cheapest place to correct a mistake, because every screen built afterwards follows its lead.

Send it, look at what comes back, and resist adding more until you have. The base prompt builds the frame; the screens come next, one at a time.

This is the habit worth building. When you know what you want but not how to say it, do not guess and hope. Describe the outcome in ordinary words and ask for the prompt itself.

For example: I want customers to be able to filter my products by size and colour, but I do not know how to ask for that. Write the exact prompt I should send to my app builder, including what to say about the data and what the filters should look like. Or: my app has a booking form but I want to stop people choosing a date in the past. I do not know how to ask for that. Write the prompt.

You can go further and ask for the whole set at once: based on the plan we just wrote, write the prompts I should send, in the order I should send them, starting with the app structure and then one screen at a time. That gives you a script to work through instead of improvising as you go.

Always read the prompt before you send it. Read it the way a builder would: is anything missing, has it assumed something about your business that is not true, has it quietly added a feature you never asked for? Fix those first. A prompt you understand is a prompt you can correct later.

An assistant does not know your customers, your prices, your margins or the way your business actually runs, and it cannot see the app sitting in front of you. So it will sometimes describe a plan that is neat and wrong, or a feature that cannot be built in the tool you are using.

The checks are the same ones you would apply to any advice. Does this match what I know about my customers? Can this actually be built in Base44, and if I am unsure, does the tool tell me so? Have I tested the result on a phone, as a stranger, before believing it works? Let the assistant do the thinking and the wording, and keep the deciding and the checking for yourself.

Then come back to it when the build starts. Paste in what went wrong, describe what you expected instead, and ask how to word the fix. That loop — plan in the chat, build in Base44, review the result, return to the chat for the next prompt — is how most people actually ship a first app.

Reviewing What the AI Built

A build is never finished when the AI stops working. It is finished when you have checked it against the plan and corrected what does not match. Reviewing is a skill, and it is the one that separates people who ship from people who keep rebuilding.

Open your one-page plan and walk the critical path on a phone, as a first-time user, from the entry point to the confirmation. Tick off each must-have as you meet it. What you are checking is not whether it looks nice, but whether the app does what the problem required.

Then check the awkward cases deliberately: submit the form empty, enter a phone number that is too short, open a page that has no content yet, look at what happens when a payment fails. These are the moments a customer meets on a bad day, and they are exactly the moments a first build gets wrong.

Feedback should describe behaviour, not disappointment. Saying it doesn't work gives the tool nothing to fix. Saying when I tap Place Order with the phone field empty, the page reloads and loses my name — instead show a message under the phone field and keep everything else — tells it exactly what to change.

Change one thing per message. Stacked complaints produce stacked fixes and make it impossible to tell which change caused a new problem. Describe what happened, describe what should have happened, and keep the rest of the app out of the sentence.

Iterating Without Losing Control

The final skill of planning is keeping control of the build after it starts. Ideas will keep arriving — yours and your customers'. The plan is what lets you welcome the good ones and refuse the rest without losing the thread.

Every change is a small risk: it might fix the thing you meant and quietly disturb something you were happy with. So change one thing, look at it, and only then move on. This is slower in appearance and much faster in practice, because you always know what caused a problem.

Keep a simple running list of what you have changed and what you still intend to change. It costs a minute a day and it saves you from re-deciding the same question three times.

When the app and the plan disagree, one of them is wrong, and it is worth pausing to find out which. Sometimes the plan was unrealistic and should be updated deliberately. Sometimes the build drifted and should be corrected. The mistake is letting them drift apart silently, because then nobody can say what the app is supposed to be.

Updating the plan is allowed — encouraged, even — but it should be a decision, written down, not an accident nobody noticed.

v1 is finished when every must-have on the list works on a phone, the critical path runs end to end without breaking, and the awkward cases give clear messages instead of silent failures. That is the bar. It is deliberately lower than perfect, because perfect is not a launch condition and waiting for it is how apps never ship.

Then you publish, and you let real customers teach you what v2 should be. Planning, prompting, reviewing and iterating are not four stages that end — they are the loop you will run for as long as the app exists.