Bolt.new builds your app from a description of what it should do. This is the order to describe it in.
You add a booking form, a payment step, and staff logins in one prompt. Payments and logins work. The booking form doesn't, and you can't tell whether the form itself is wrong or one of the other changes broke it, because three things changed at once.
Why should you build your app one feature at a time?
Build your app one feature at a time so each change is small enough to test, cheap to undo, and easy to trace when something breaks. When one thing changes, you know what caused whatever happens next. Bolt.new's own guidance is direct: "Do one thing at a time. Don't try to add multiple features in one go." (Bolt.new docs, 2026).
Developers have a name for this habit: working in small batches. Google Cloud's DORA research program found that working this way makes it easier to triage and remediate problems, and calls it a safety net for AI adoption (DORA, 2025). That safety-net line matters to anyone building with an AI app builder. The AI can write a lot of software in one go. Your job is to keep each go small enough to check.
This table compares one big prompt with one feature at a time:
| Several features in one prompt | One feature at a time | |
|---|---|---|
| Testing | Several new things to click through at once | One new thing to check before you build on it |
| Undoing a mistake | Rolling back loses every feature in the prompt | Rolling back loses one feature |
| Finding what broke | Any of the new features could be the cause | The last change is the only suspect |
Doesn't building one feature at a time mean more prompts?
Building one feature at a time means more prompts, but not smaller ones. Each prompt covers one feature, and you describe that whole feature inside it. A booking form with its fields, its rules, and its confirmation email is one feature, so it belongs in one complete prompt.
That's the same rule our guide to better prompting is built on: one workflow per prompt, all of that workflow in the prompt. That guide covers how to write each prompt. This post covers which prompt comes next.
What order should you build your app in?
Build your app in layers, from the parts every feature depends on to the parts nothing depends on. Plan first, then pages, data, and logins, then features one at a time, then polish, then publish. Each layer settles a question the next layer needs answered.
Building in layers means building an app in the order its parts depend on each other: groundwork first, then one feature at a time. As of 2026, Bolt.new, an AI app builder, recommends the core of it in its own docs: start with pages and navigation, then add features one at a time.
- Plan. Talk the app through in Plan mode, which doesn't make any changes to your project once it exists and uses fewer tokens than building (Bolt.new docs, 2026). Started from the homepage, Plan mode sets up your app's base structure first, then shares the plan. Settle what the app is for, who uses it, and which feature comes first.
- Pages and navigation. Bolt.new's docs recommend you start with core pages and navigation before adding features (Bolt.new docs, 2026). Pages give every later feature a place to live.
- Your data. Decide what the app stores: customers, orders, bookings, whatever your business runs on. Every feature reads or writes this data, so editing it later means revisiting every feature that touches it.
- Logins. Decide who signs in and what each person can see. Adding privacy rules after features exist means checking every feature again.
- The one core feature. Build the thing the app exists to do, and nothing beside it.
- The next features, one at a time. Each one gets its own prompt, its own test, and its own saved version.
- Polish. Colors, wording, and spacing come last, because restyling a finished page is cheap and restyling a moving target isn't.
- Publish. Put it on your own domain once the layers underneath it hold.
Steps 3 and 4 are our advice, not a rule from the docs. A booking form built before you've decided what a booking contains is a form you'll rebuild.
What does building in layers look like?
Building in layers looks like a series of short, complete prompts, each one followed by a check and a saved version. Here's the order in practice, with one prompt per layer. The business is an example, not a customer: a three-person house-cleaning company that wants customers to book online and the crew to see their day's jobs.
Layer 1, the plan (in Plan mode):
I run a three-person house-cleaning company. I want an app where customers book a cleaning, my crew sees their jobs for the day, and I see every booking. Help me plan it: the pages, the data it needs, who logs in, and what to build first. Don't build anything yet.
Layer 2, the pages:
Build four pages: Home, Services and prices, Book a cleaning, and Crew. Add navigation between them. Placeholder text is fine. No forms or logins yet.
Check: every page opens, on a laptop and a phone. Save the version.
Layer 3, the data:
Set up a database with three tables. Customers: name, phone, address. Services: name, price, hours. Bookings: customer, service, date, morning or afternoon window, assigned crew member, and status (requested, confirmed, done). Add my four services with prices and five example bookings so I can see them on the pages.
Check: the example bookings show up, and the services page lists real prices. Save the version.
Layer 4, the logins:
Add logins with two roles. The owner sees every booking. Crew members see only the bookings assigned to them. Customers book without an account.
Check: log in as a crew member and confirm you can't see anyone else's jobs. Save the version.
Layer 5, the core feature:
Build the booking form on the Book a cleaning page. The customer picks a service, a date, and a morning or afternoon window, then enters their name, phone, and address. Save it as a new booking with status "requested," email me the details, and show the customer a confirmation message.
Check: book a cleaning as a customer, then find it as the owner. Save the version.
Layer 6 and on, one feature each: a Today page where the crew sees their jobs in order and marks each one done, then an email the owner sends in one click to confirm a booking, then reminders the day before. Each one follows the same pattern as the layers above. Use prompt queueing to line up the next layer while the current one builds.
Polish and publishing come after the layers hold. By then, every page you're restyling is a page that works.
How do you know a layer is done?
A layer is done when it passes three checks, and then you save the version before starting the next one:
- Use it the way a customer would, start to finish.
- Do it again on a phone.
- Try the wrong input on purpose: a blank phone number, a date in the past, a booking for a service you removed.
The wrong-input check finds the problems a normal run-through won't. If the booking form accepts a cleaning for last Tuesday, you want to find that before three more features depend on the form.
What do you do when a new feature breaks something?
When a new feature breaks something in Bolt.new, roll back to the last version that worked, then try again with a better description. Bolt.new's Version history restores your project to a previous state without consuming tokens (Bolt.new docs, 2026), so a bad change costs you nothing to undo. One limit: restoring a version doesn't roll back your database, so if the broken feature changed your data, check the data too.
Restoring is free; prompting the AI to undo its own change spends tokens on work you already had. Don't keep clicking Attempt fix either; the docs warn that each attempt uses tokens (Bolt.new docs, 2026). Restore, then describe what went wrong in your own words ("the confirmation email goes out before the booking saves") and rebuild that one feature. Because only one thing changed, you know which thing to fix.
Every layer you tested is a version you can return to. The app you publish is a stack of small things that each worked.
