Testing a Bolt.new App: The Bugs It Ships With and How to Catch Them

A Bolt.new app usually ships with bugs the builder never saw: layouts tested only in the Chrome preview, data rules that are open or wrong, failure paths nobody triggered, and no tested way to recover the database. Catch them by running Bolt's security audit, then testing the published app on Safari and phones, with two accounts, failed payments and a rehearsed data restore.

If you would rather have your Bolt app tested for you, see how RAITHub would test this below.

None of this is a case against Bolt. It turns a prompt into a running full-stack app in minutes, and it now audits its own security. But building and testing are different jobs. Everyone can build with AI now; almost no one has a tester. This post is the testing half, written for the way Bolt actually works.

How does Bolt.new build and run your app?

In two places. While you build, Bolt runs your whole project in your browser tab. Its open-source repository describes "an in-browser development environment powered by StackBlitz's WebContainers", where the AI has control over "the filesystem, node server, package manager, terminal, and browser console" (bolt.new on GitHub). When you publish, the app moves to Bolt Cloud, which bundles hosting, databases, authentication, file storage, server functions and domains, and is "powered by trusted platforms like Netlify and Supabase" (Bolt Cloud docs).

Three facts from Bolt's own documentation shape the test plan:

• JavaScript only on the server. "Bolt only supports JavaScript-based backends" (supported technologies). Your server code is Node or edge functions, so that is what you call directly in tests.
• Mobile apps go through Expo. The same page says Bolt projects "can be turned into mobile applications using Expo". A mobile build needs testing on real iOS and Android devices, not a desktop preview.
• Version history does not restore data. Bolt's database docs say "Bolt's Version History feature currently does not support database restores", and that databases in unpublished projects can pause after six days of low use.

Which bugs does a Bolt.new app usually ship with?

The pattern is predictable once you know where the app was and was not exercised. This is engineering guidance from how the tool works, not a count from audits: RAITHub has no published case study of testing a Bolt app.

Bug class	Why a Bolt app is prone to it	Test that catches it
Layout and input bugs on Safari and phones	The builder saw it in a desktop browser preview; WebContainers are fully supported in Chromium browsers and only partly elsewhere (WebContainers browser support)	Run the published app in WebKit and on real iPhones and Android phones
Users reading or changing each other's data	Generated data rules match the prompt, not your roles	Two-account tests on every table and server function
Failure paths that were never run	The prompt described success; declines, timeouts and empty states were guessed	Force each failure: declined card, offline, empty list, expired session
Preview data or settings that differ in production	The preview and the published app run in different places	Sign off on the published URL with production settings
No tested recovery after a bad change	Reverting code does not revert the database	Rehearse an export and restore before launch
Regressions after the next prompt	Each prompt can rewrite files beyond the one you asked about	A short automated smoke suite run before each publish

What does Bolt's security audit check, and what is left for you?

Bolt has two checks (Bolt security docs). The project security audit, on paid plans, reviews code and database: data access controls ("your app's users should be able to touch only their own information"), public exposure, authentication and sessions, misuse, input validation, and secrets. It fixes what it can, lists the rest in the chat, and you can run up to 30 audits a day. The database security check, on all plans, flags issues such as a "missing row-level security (RLS) policy or a permission that's too open" (database security docs).

Run the audit before every publish; it costs no tokens. Then test the things an audit cannot judge, because it does not know your business: which role should see which records, what happens to an order when payment fails, whether the app is usable on a small phone with the keyboard open. An audit reads the app. A tester uses it.

What is the test plan for a Bolt.new app?

1. Run the project security audit and act on the action items

Some findings need a change outside Bolt, such as a setting in a connected service. Do those first; they are the ones most often left open.

2. Test the published app across browser engines

A small Playwright suite that runs the same journey in Chromium, WebKit (Safari's engine) and Firefox, plus a phone viewport, finds most of the layout bugs a desktop preview hides:

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  use: { baseURL: process.env.APP_URL },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'iphone', use: { ...devices['iPhone 13'] } },
  ],
})

// tests/signup.spec.ts
import { test, expect } from '@playwright/test'

test('a new user can sign up and reach the dashboard', async ({ page }) => {
  await page.goto('/signup')
  await page.getByLabel('Email').fill('qa+' + Date.now() + '@example.com')
  await page.getByLabel('Password').fill('a-long-test-password-1')
  await page.getByRole('button', { name: 'Sign up' }).click()
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible()
})

Point APP_URL at the published site, not the preview. If getByLabel cannot find a field, that is a finding in itself: the input has no accessible label. Then repeat the main journey by hand on a real iPhone and a mid-range Android phone; emulation does not show the on-screen keyboard covering a submit button.

3. Test data access with two accounts

Create users A and B. As A, create a record; as B, try to read, edit and delete it by changing the ID in the URL and by calling the server function directly. Bolt Database is managed through Supabase in at least some setups (Bolt's database security page refers to a database "managed in Supabase"), so the same RLS reasoning applies; the vibe-coded app security checklist has the checks and the RLS fix has the SQL.

4. Force every failure path

Declined and authentication-required cards from Stripe's test cards, a webhook that arrives late or twice, a session that expires mid-form, an upload that is too large, a list with zero items and one with a thousand. Bolt Cloud includes Stripe payments, so test them in test mode with the cases in testing payments and webhooks.

5. Rehearse a data restore before you need one

Because version history restores code, not data, decide how you would undo a bad prompt that damages records. Export the data, or use the backup tools of the underlying database if you have access, and actually restore it once into a test project. SaaS backup and disaster recovery explains restore drills.

6. Check that production is what you tested

Sign up on the live domain, check confirmation and reset emails arrive and their links work there, and confirm that test data from building did not ship. The causes of "works in preview, breaks live" are collected in AI app works locally, breaks in production.

7. If you built a mobile app with Expo, test it on devices

Install the build on real phones, test permissions, offline behaviour, backgrounding and small screens. The mobile app testing checklist covers iOS and Android releases.

8. Keep a smoke suite for every later prompt

The Playwright file above becomes your regression check. Run it before each publish, and add a test each time a bug is fixed so the next prompt cannot quietly bring it back.

How long does testing a Bolt.new app take yourself?

For a small web app with sign-up, one core workflow and payments, plan on two to three days if you can read TypeScript: a few hours for the audit and its action items, a day writing and running the cross-browser suite and two-account tests, half a day for payment failures and the restore rehearsal, and the rest for phones and fixes. Add two to three days for an Expo mobile build. These are estimates, not a quote.

The main risk of doing it yourself is coverage, not skill. People test the paths they built, in the browser they built in. The bugs users find first are on the other paths.

Buy, build or hire?

Route	Choose this when
A tool or SaaS testing platform (Bolt's audit, scanners, a cloud browser grid)	You want fast checks on known patterns and many browsers. Keep running Bolt's audit regardless.
Freelancers or crowdtesting	You need many real devices quickly and can write the test cases and triage the results.
An in-house QA hire	You publish several times a week and have a full-time tester's worth of work.
A managed QAaaS team	You want the plan above done before launch, with a ranked report and a smoke suite left behind, without hiring.

Why RAITHub for this

• Testers who also build. RAITHub's own builds carry large suites: 1,024 tests on PropDesk, which takes rent through Stripe, and 400+ on this website. That is testing discipline, not a claim about Bolt apps.
• Real devices included. RAITHub tests web apps and mobile apps on iOS and Android, on real devices and device clouds. It does not develop mobile apps.
• A report you can act on in Bolt. Each issue comes with steps to reproduce and a suggested fix you can paste into a prompt.

When you don't need RAITHub

• The app is an internal prototype with no real users or payments. Run Bolt's audit and the Playwright suite above.
• You need a certified penetration test or a compliance attestation. RAITHub's security checks are application-level, against OWASP guidance.
• You want a tester working inside your team under your management. RAITHub does not offer staff augmentation.

How RAITHub would test this

• Scope from your app: the roles, the core journeys and the payment flows, agreed before testing starts.
• Cross-browser and device pass: the published app in Chromium, WebKit and Firefox, and on real iPhones and Android phones, including any Expo build.
• Data access and failure paths: two-account tests on every table and server function, declined and duplicated payments, expired sessions and empty states.
• Recovery and regression: a check of how data would be restored, and a smoke suite you can run before every publish.

What you buy: a fixed-price launch audit, then an optional monthly QA plan while you keep prompting changes. You receive: a ranked bug report with reproduction steps, evidence and a suggested fix for each issue, any automated tests in your repository, and full IP under NDA. See AI-built app testing, mobile app testing and QA as a service. Next step: a free 15-minute call, then a written fixed quote.

Publishing a Bolt app soon? Ask for a launch audit quote.

Frequently asked questions

Why does my Bolt.new app work in the preview but not for users?

The preview runs in your own browser tab, usually a desktop Chromium browser, with your data and session. Users arrive on Safari, phones, slow networks and fresh accounts. Test the published URL on those before launch.

Does Bolt's security audit replace testing?

No. It reviews code and database settings and fixes common issues, which is worth doing before every publish. It cannot know your roles, business rules or how the app behaves on real devices, so those need tests.

Can I undo a bad change to my Bolt database?

Not through version history: Bolt's documentation says it does not support database restores. Plan and rehearse your own export and restore before launch.

Do I need to test a Bolt Expo app on real phones?

Yes. Permissions, the keyboard, gestures, backgrounding and performance behave differently on devices than in a browser preview. Test at least one current iPhone and one mid-range Android phone.

What should I test first if my budget is small?

Data access between two accounts, then payments including declines, then the main journey on an iPhone. Those are the failures that cost users money or privacy. Cosmetic issues can follow.

Can RAITHub fix what it finds in a Bolt app?

Yes, under a separate fixed quote. Or fix the issues yourself in Bolt: each one in the report includes reproduction steps and a suggested fix you can use as a prompt.