Highlights
- The happy-path trap: testing only the inputs you'd type yourself is how bugs reach customers.
- Test as every kind of user (customer, staff, owner), and confirm each one sees only what they should.
- Bolt.new's security audit sits in the Publish menu, and a database security check is available on every plan.
- Five testers find most usability problems; an app with distinct user groups needs three or four testers from each.
- Before you publish, label the version you're launching and export a copy.
Bolt.new builds your app from a description. This is how to check it before your customers do.
Your booking form works every time you try it. That's because you always type a real phone number.
Customers won't. They'll leave fields blank, pick last Tuesday, hit Submit twice, and open pages you never linked to. A pre-launch test is you doing those things first, on purpose, before anyone you'd like to keep as a customer does them by accident.
How do you test an AI-built app before you launch?
Test an AI-built app before launch in six passes, using what's already in your app builder. You don't need a developer or a testing tool:
- Test past the happy path: wrong inputs, double clicks, the back button.
- Test as each kind of user, and confirm each one sees only what they should.
- Fill the app with realistic data, not five tidy examples.
- Run the security checks.
- Put it in front of a few real people and watch.
- Label the version you're launching and back it up.
Run them in order. The early passes catch the problems you'd rather fix before a real tester ever sees them.
Why isn't testing as you build enough?
Testing as you build catches bugs inside each new feature. A launch test catches what happens when the features meet, and what real people do that you never would. If you've been building one feature at a time, every layer already passed its own checks. The booking form worked, and so did the crew schedule. The launch test asks whether a booking made on a phone, by a customer you've never met, shows up on the right crew member's schedule.
What does testing past the happy path mean?
The happy path is the one route through your app where everything goes right: real name, real phone number, a date next week, one click on Submit. Testing past it means trying everything else a customer might do. Bugs hide off that path, because the person who built the app tends to walk the same route every time.
This table lists wrong inputs to try on a booking form, and what a working form should do with each:
| Try this | A working form should |
|---|---|
| Leave the phone number blank | Stop and ask for it |
| Pick a date in the past | Refuse it and ask for a future date |
| Type a 300-character street address | Save it without breaking the page layout |
| Click Submit twice, fast | Create one booking, not two |
| Hit the back button halfway through | Keep what the customer typed, or start clean |
| Book a service you've since removed | Hide that service from the list |
When something fails, describe what you saw to Bolt.new in your own words ("clicking Submit twice creates two bookings") and fix that one thing before you move on.
How do you check what each user can see?
Log in as every kind of user your app has, one at a time, and confirm each one sees only what they should. This is where apps leak private information: a crew member who can open the owner's revenue page, or a customer who can see someone else's address.
This table shows what to check for an example booking app with three kinds of users:
| User | Should see | Must not see |
|---|---|---|
| Customer | Services, prices, the booking form, their own confirmation | Other customers' bookings, any staff page |
| Crew member | Their own jobs for the day | Other crew members' jobs, prices and revenue, owner settings |
| Owner | Everything | Nothing off-limits |
Don't stop at the menu. Copy the web address of an owner page, log out, log in as a crew member, and paste it in. If the page opens, the app is hiding the link but not protecting the page. Our client portal walkthrough covers how to describe logins and privacy rules so they hold.
Why test with realistic data?
Five example bookings make every app look fast and tidy. Two hundred bookings show you what a busy month looks like: a schedule that takes too long to load, a list that sorts the wrong way, a name that runs off the edge of a card. Ask Bolt.new to fill the app with realistic test data before you launch:
Add 200 example bookings spread over the next two months, with realistic
names, a mix of short and long addresses, every service type, and a few
cancellations. Mark them as test data so I can delete them before launch.
Then use the app the way you would on your busiest Monday. Delete the test data before you publish, and check that the delete didn't take anything real with it.
How do you check your app's security before launch?
Run Bolt.new's security audit: click Publish, then Run security audit. The audit reviews who can see and change your data, what your app makes public, how people sign in, and what input your app accepts, along with your keys and security settings, and Bolt.new fixes most problems on its own (Bolt.new docs, 2026). As of October 2026, the full audit is on paid plans, and a database security check is available on every plan.
If the audit flags something it can't fix, it tells you what to change, often a setting in a service you've connected. Make that change before launch, not after. And if your app uses API keys, confirm they're in Secrets rather than in your code, one of the habits in our tips for non-developers.
Who should test your app before it goes live?
Five people, watched with care, find most of the problems real users hit. Jakob Nielsen's research found that testing with 5 users uncovers about 85% of usability problems, and that an app with several distinct groups of users needs three or four testers from each group (Nielsen Norman Group, 2000). A booking app with customers and crew needs a few of each.
Give testers the app, not the project. Every Bolt.new plan can publish for free to a bolt.host address, so testers can use the real app before your own domain is connected. A public site is open to anyone with the link, and search engines can index it, so keep test data off a public test site. On paid plans, you can publish the site as private, visible only to your team and the people you invite, and they don't need a Bolt account (Bolt.new docs, 2026). Save the Share button for teammates who need to see the project itself.
Then watch, and keep quiet. Give each tester one task ("book a deep clean for next Friday") and note where they hesitate, what they tap that does nothing, and where they give up. Don't explain the app while they use it. Your customers won't have you there to explain it either.
What should you do right before you publish?
Label the version you're launching, export a copy, then publish. In Version history, give the launch version a name like "Launch, Oct 2026" so you can find it fast if a later change goes wrong. Then export a copy from the project title (Export, then Download) and keep it somewhere outside Bolt.new.
After launch, keep this checklist as your test list. Published sites don't update on their own: changes you make in the project reach your customers when you click Update in the Publish menu (Bolt.new docs, 2026). That gives you a natural checkpoint. Before every Update, rerun the passes that touch what you changed, because a new feature can break one that worked last week.
Type a blank phone number one more time. If the form stops you, you're ready to publish.
Start building free: bolt.new
