How do you get an AI to build your app without it falling apart?

An AI can write a working screen in a minute. What goes wrong is the tenth prompt: it rewrites something that worked, you don’t notice for three more prompts, and now nobody knows which change broke it. Everything in this chapter is there to stop that. It applies whether you picked an AI builder or a coding agent in chapter 2.

1. Write a one-page plan before the first prompt

The AI fills every gap you leave with a guess. A short plan leaves fewer gaps. Write it in plain words, in a note or a file, and keep it to one page:

• What the app does, in one sentence, and for whom. “Dog walkers book and pay for walks” is enough.
• The screens, one line each: landing page, sign up, the main screen where the real work happens, settings. Mark the one screen without which the app is pointless.
• The data it keeps: the things it stores and what each one holds. For example, a walker (name, email), a booking (date, time, walker, price).
• What is not in the first version. Write this list too. It is what you point to when the AI offers to add a chat feature you never asked for.

Paste the plan into your first message, or save it in the project (the coding-agent section below shows where). Build the one screen that matters first, then the rest in the order a visitor meets them.

2. One small change per prompt

Ask for one thing you can see and check: “Add a sign-up form with email and password on the landing page. Don’t change anything else.” Not “build the booking system”. A small request gives the AI less to get wrong, and when it does get something wrong, you know exactly which request did it.

Useful phrases to add to a prompt:

• “Don’t change anything outside this screen.”
• “Tell me which files you changed and why.”
• “Ask me before you add a new package or service.”
• “If something in my request is unclear, ask instead of guessing.”

3. Test after every change

Open the preview and use the thing you just asked for, the way a visitor would. Click the button, submit the form with a wrong email, reload the page and check your data is still there. Then click through the screens that already worked, because those are the ones an AI breaks without saying so. It takes a minute, and it is the minute that saves the evening.

When something is broken, describe what you did and what you saw: “I clicked Book, the page went blank, the browser console says X.” Paste the exact error text rather than a summary of it.

4. Save a working state before the next prompt

Every time a change works, save it, so you always have a version to go back to.

On an AI builder, the builder keeps versions for you. Each one documents it differently:

• Lovable saves every change as a version. Open History in the top bar, pick a version and choose Revert. Bookmark a version that works before a big change. Its docs warn that reverting restores code only, not the data in your database.
• Bolt: Version history (the clock icon) in the top menu, pick a version, then Restore this version and confirm with Restore version.
• Replit: the Agent makes checkpoints as it works. In the Agent tab, find one and choose Rollback to here.

On the coding-agent path, use git. It is a free program that keeps a history of your project, and the Cloudflare starter below can set it up for you. If yours isn’t set up yet, run this once in the project folder:

git init

Then, every time something works:

git add -A
git commit -m "Sign-up form works"

To see your saved states:

git log --oneline

If the AI has made a mess since your last save, this puts every file git already tracks back the way it was at that save (as long as you haven’t run git add since). Files the AI created since then stay; git status lists them so you can delete them:

git restore .

Claude Code also keeps checkpoints within a session: press Esc twice or run /rewind to go back. Its own docs say these are not a replacement for version control, and changes made through terminal commands are not tracked, so commit anyway.

5. Keep secrets out of the code

A secret is anything that lets someone act as you: a Stripe secret key, a database password, an email service key. If it sits in your code, it ends up wherever your code goes, and code that runs in the visitor’s browser can be read by anyone who opens the page.

• On an AI builder, use its secrets feature. Lovable, for example, keeps secrets encrypted, hands them only to its server-side functions and says they never reach the browser; when a feature needs one, it asks you for it through a secure field in the chat. Don’t paste keys into a normal prompt.
• On the coding-agent path, put local secrets in a .dev.vars or .env file, which Cloudflare’s docs say should not be committed to git. Add both to a file called .gitignore in the project folder, which tells git to leave them out:

.dev.vars*
.env*

Do this before your first commit: .gitignore does not affect files git already tracks. Putting secrets on the live site is in chapter 6.

6. When the AI goes in circles

You will see it: the same bug fixed and broken again, or three different “fixes” for one problem. More prompts in the same conversation rarely help, because the conversation is now full of failed attempts. Instead:

1. Go back to your last working save (step 4).
2. Start a new conversation. In Claude Code that is /clear; its best-practice guide suggests exactly this after correcting it twice on the same issue.
3. Write one better prompt that includes what you learned: what you want, what didn’t work and why.
4. If it still fails, make the step smaller.

Get the project ready

Before the first real prompt, set the project up so that everything later in this guide has somewhere to go: a place to save work, a way to measure, and notes your AI reads every time.

On the coding-agent path

1. Start the project. Cloudflare’s starter tool (C3) creates a project ready to host on Cloudflare, which is the stack this guide uses. For a React app, its docs give:

npm create cloudflare@latest -- my-react-app --framework=react

It asks a few questions. When it asks whether to use git for version control, say yes, and step 4 above is half done.

2. Run it on your own computer.

cd my-react-app
npm run dev

The terminal prints a local address to open in your browser. That is your preview: test there before anything goes live. A plain Worker without a framework runs with npx wrangler dev at http://localhost:8787.

3. Connect Nordva Launch. In the same folder, run:

npx nordva@latest init

It signs you in through the browser (the free plan has no time limit and needs no card), writes your keys to the project’s env file and adds that file to .gitignore, and installs the Nordva Launch MCP server for Claude Code, Cursor, VS Code and Windsurf, so your agent can set up the waitlist, analytics and changelog itself. It also hands your agent a planning prompt that asks for a plan you approve before any code is written: the same habit as step 1, for that job. Doing it now means the app measures where visitors come from from its first deploy, instead of from the day you remember. The one-prompt page shows what the agent does with it, and the docs’ quickstart covers the rest. (Every step in this guide also works without it: skip this one if you’d rather use other tools.)

4. Give the agent its notes. Coding agents start each session without memory of the last one, so they read a file of instructions from your project instead:

• Claude Code reads a CLAUDE.md in the project folder (or .claude/CLAUDE.md) at the start of every session. Run /init and it writes a first version from your code. It can also read an AGENTS.md when there is no CLAUDE.md. Its docs suggest keeping the file under 200 lines.
• Cursor reads project rules from .cursor/rules (as .mdc files) and also supports an AGENTS.md in the project root.

Put the essentials there: a link to your one-page plan, the commands to run and test the app, and your rules (“never put keys in code”, “one change at a time, then stop”). Claude Code also has a plan mode (press Shift+Tab until it shows), where it reads and proposes without editing; its docs suggest it when a change touches several files or you aren’t sure of the approach, and skipping it for small fixes.

On the AI-builder path

Your builder already made the project and saves versions for you (step 4). The one thing to add now is measurement: paste the Nordva Launch script into your builder with the prompt from its page (Lovable, Bolt, v0, Replit or Base44), so you can see where visitors come from from the first day it’s live.

Before you move on

You have a first version when a visitor can do the one thing the app is for, from the landing page to the result, and you have a saved state of it. Next: data and login.