Bolt.new Testing: How to QA an App Bolt Built for You

Bolt.new testing means verifying that the app Bolt generated actually works outside of Bolt's own preview window — in a real browser, with real data, on a real deployed URL. Because Bolt writes a complete full-stack project in one pass from a prompt, the code compiles and the preview renders long before anyone has checked whether sign-up, payments, permissions, or mobile layout behave correctly. Bolt.new testing is the step that closes that gap: a short, repeatable pass over the flows that matter, run on the deployed build rather than the editor.

What is Bolt.new testing, exactly?

Bolt.new is StackBlitz's prompt-to-app builder. It runs your project inside a WebContainer — a Node environment running in your browser tab — and can wire up a database (commonly Supabase) and deploy out to a host such as Netlify. That architecture is what makes Bolt feel instant, and it is also what makes testing a separate job.

So Bolt.new testing is not one tool. It is three distinct checks that people usually collapse into one:

• Does it render? The Bolt preview answers this, and it is the only question the preview reliably answers.
• Does it work? Can a stranger complete the flow the app exists for — sign up, create the thing, pay, log back in and still see their data?
• Does it keep working? After the next prompt rewrites three files you never read, is the flow from last week still intact?

Most bug reports from users of prompt-built apps land in the second and third buckets. The first one passed.

Why doesn't the Bolt preview count as testing?

The preview is an honest answer to a narrow question. It shows the app as rendered for you, signed in as you, on your screen size, with whatever rows you happened to create while building. Four things it structurally cannot show you:

• The first-run state. You have seed data. A new user has an empty table, and empty-state handling is one of the most common gaps in generated UI code.
• Someone else's permissions. If the generated schema has no row-level security policies, every signed-in user can often read every row. The preview, where you are the only user, looks perfect.
• The real environment. Server-side environment variables, API keys, redirect URLs and OAuth callbacks that work in the in-browser container frequently differ from the deployed host. Auth redirects are a classic one: localhost is allow-listed, the production domain is not.
• Other browsers and real devices. The preview is one engine, one viewport, one set of fonts.

This is the same failure pattern we documented for other prompt-to-app tools in testing a Lovable app: the builder's preview is a compile check wearing the costume of a QA pass.

What breaks most often in Bolt-generated apps?

Three categories account for the bulk of it, and each needs a different check.

1. Data access and permissions

AI-generated schemas tend to be permissive by default. If you asked for "a dashboard where users see their projects" and never mentioned security policies, the generated query may fetch by user id in the client while the database itself allows anything. Test it by creating two accounts and trying to read account A's data from account B — via the UI, and by editing the id in the URL.

2. Auth and session edges

Sign-up works. The paths around it often don't: email confirmation links pointing at the wrong domain, password reset, logging out then back in, an expired session mid-form, a second browser tab. Each of these is a distinct path through the code, and a single prompt rarely produces all of them correctly.

3. Silent regressions from the next prompt

This is the one specific to AI builders. Asking Bolt to "make the pricing page nicer" can touch shared components, a layout file, or a utility that checkout depends on. Nothing announces it. You review the diff for the page you asked about, and the break lands two screens away. That dynamic is the subject of our vibe coding QA checklist, and it is the reason a checklist beats ad-hoc clicking: you need the same flows re-checked, not whichever ones you remember.

Bolt preview vs. testing on the deployed build

The practical rule: never accept a Bolt change on the strength of the preview alone. Deploy it, then test the deployed URL.

What does a minimum Bolt.new testing checklist look like?

Ten minutes, in this order, on the deployed build. Run it after any prompt that touched more than copy.

1. Fresh account, incognito window. Sign up with an address you have never used. Does the confirmation email arrive, and does its link land on your real domain?
2. The empty state. Before creating anything, look at every main screen. Blank panels, infinite spinners and undefined in a heading all show up here.
3. The core flow, end to end. The one thing the app is for. Complete it fully, including whatever confirmation or receipt it promises.
4. Log out, log back in. Is the thing you just created still there, and still yours?
5. Second account. From account B, try to reach account A's data — through the UI and by swapping the id in a URL.
6. Refresh mid-flow and hit Back. Generated apps often hold state only in memory; a refresh exposes it.
7. Open the browser console. Red errors on a page that looks fine are the clearest early warning you get for free.
8. One real phone. Not a resized desktop window — an actual device, where fixed headers, modals and keyboards behave differently.

That list is deliberately short. A checklist you run every time beats a thorough one you run once.

How do you test a Bolt app without writing test code?

Most people building in Bolt are not going to hand-write Playwright specs, and they shouldn't have to in week one. The sequence that works is to add layers in the order of what fails first:

1. Make reports reproducible. The first thing to fix is not the bugs, it's the bug reports. When a client or a friend says "the button didn't work", you need the URL, the console errors, the network calls and the browser — not a screenshot in a text message. Klavity Snap captures that from a right-click, so a non-technical tester can file something a developer (or Bolt itself) can act on.
2. Get a stranger's pass. You cannot un-know how your own app works, which is why your clicking will always miss the obvious. Sims runs AI personas through your deployed app the way different real users would — the impatient one, the one who refreshes mid-checkout, the one who tries the URL directly — and reports what broke.
3. Lock the flows that matter. Once a flow works, it should stay working through the next twenty prompts. AutoSim turns those passes into end-to-end tests that repair their own selectors when the AI rewrites your markup, which is what usually breaks conventional generated tests on a Bolt project.

The underlying principle is covered in depth in our complete guide to AI QA: when code generation gets faster, verification — not writing — becomes the bottleneck.

When should a Bolt app get automated tests?

Two triggers, not a date. First, when anyone other than you depends on the app: a paying user, a client, a demo you cannot reschedule. Second, when you break something you had already fixed. The second time a regression reaches a user is the signal that manual re-checking has stopped scaling, and that is the moment to record your core flows rather than re-click them.

Before either trigger, the checklist above is genuinely enough. After them, skipping automation just moves the testing onto your users, which is the most expensive place to do it.

Try it on your Bolt app

Deploy your Bolt project, then run the checklist on the live URL — fresh account first. If you want the reproducible reports, the persona pass and the self-healing tests without building a QA process from scratch, Klavity does all three on a deployed URL.

Try Klavity free — scan your Bolt app in minutes