How to Test Your Bolt.new App Before Launch

Knowing how to approach testing bolt.new apps is the difference between a clean launch and a fire drill. According to a June 2026 Prufa audit of 49 Show HN launches, 78% had a critical bug on day one. Bolt.new generates working, full-stack JavaScript apps fast, typically Vite/React or Next.js paired with Supabase and deployed to Netlify or Vercel. What it does not generate is any verification that those apps survive real users, real payments, and real production data.

What Breaks in Bolt.new Apps?

Bolt.new apps fail in predictable places. Almost none of the failures are in the happy path. They live in the gap between Bolt's browser-based WebContainer preview environment and a real production deployment: missing secrets, open databases, and payment integrations that pass locally but drop events in production.

The four failure categories that break silently and consistently:

Environment variables and secrets. Bolt manages secrets in its own Secrets panel during development. Those values do not transfer to Netlify or Vercel automatically when you deploy. The build runs, the app tries to initialize with undefined variables, and crashes with a generic error that does not name the missing key. The AppStuck 2026 guide to Bolt.new errors documents this as the most frequently reported failure after deploy.

Auth and Supabase redirect URLs. Bolt generates Supabase auth flows configured for the Bolt preview URL. When you deploy to a custom domain, Supabase does not recognize the new domain as an allowed redirect target and sends users back to the login page on their first real session. The Nightlamp.app post-deploy guide (updated June 2026) lists this as one of eight documented failure patterns in Bolt.new deployments.

Supabase Row-Level Security disabled by default. Bolt.new generates Supabase SQL migration files that create tables without adding RLS policies. The dashboard surfaces a yellow "RLS disabled" warning, but that warning never reaches the AI. Any authenticated user can read and write every row until you manually enable RLS and write policies. This is the same class of flaw behind CVE-2025-48757: in a 2025 disclosure, 170+ apps built with AI scaffolding tools had Supabase tables readable by unauthenticated requests using the public anon key, exposing data for roughly 13,000 users. (byteiota.com, December 2025) The Afterbuild Labs Bolt.new RLS reference (April 2026) confirms this applies specifically to Bolt-generated schemas.

Stripe webhooks with no signature validation. Bolt generates Stripe integrations that handle payments on the client side but do not implement signature validation on the webhook endpoint. In test mode, Stripe's leniency hides this. In production, Stripe fires a real event with a cryptographic signature. If your endpoint does not validate it, the request is silently dropped. The payment succeeds in Stripe's records, the customer is charged, but the subscription never activates and no database record is created. The AppStuck Bolt.new error guide (2026) documents a real case: this failure was identified 4 hours 55 minutes before launch.

A fifth failure category is specific to Bolt's architecture: token burn producing incomplete output. Error loops, where the AI repeatedly attempts to fix a bug it introduced, can consume millions of tokens in an afternoon. A widely cited Hacker News thread from early 2025 documents a case where 10 million tokens were burned on cascading AI-introduced failures, leaving the app in a broken state. When Bolt runs low on context, it rewrites entire files rather than making targeted edits, which can silently break working integrations outside the section it was asked to touch.

How do I test my Bolt.new app without writing test code?

You can test your Bolt.new app end-to-end without writing a single line of test code. This 10-step playbook covers the failure categories above in the order that catches the most bugs first. Each step targets a different layer: environment, auth, payments, data isolation, and real-user behavior.

1. Deploy to your real production domain first, not the Bolt preview. The WebContainer preview auto-wires environment variables, Supabase connections, and auth callbacks. Production strips all of that. Deploy to Netlify or Vercel and set your VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, STRIPE_PUBLISHABLE_KEY, and any other secrets directly in the host's environment settings before running any other test.

2. Verify every environment variable is live in production. Open your browser's network tab on the deployed URL, navigate to a page that loads data, and look for failed requests to localhost or *.bolt.new or *.stackblitz.io. Any of those indicates a misconfigured or missing variable. Cross-check your host's environment panel against Bolt's Secrets panel one key at a time.

3. Run an automated surface scan on the production URL. Use Prufa or a similar tool on your live domain. This catches broken links, missing canonical tags, cookies without the Secure attribute, exposed API keys in client bundles, and analytics that never fire. This takes under 5 minutes and is the fastest way to find the class of bugs that hit 78% of Show HN launches.

4. Test signup with a fresh email address you have never used. Do not test with your own account, which carries session state from development. Create a net-new account on your production domain, go through email verification, and complete onboarding as a stranger would. Watch for: email that never arrives, redirect to a blank page after verification, or an error on the first real data load.

5. Update Supabase auth redirect URLs before testing login. Go to Supabase → Authentication → URL Configuration and add your production domain: both https://yourdomain.com and https://yourdomain.com/** as allowed redirect URLs. Without this, OAuth and magic-link logins fail silently at the redirect step, which is the most common auth failure in deployed Bolt apps.

6. Test your payment flow end-to-end, then check the webhook. Use Stripe's 4242 4242 4242 4242 test card and verify the webhook fires: check Stripe Dashboard → Developers → Webhooks for the payment_intent.succeeded event. Confirm the event reached your endpoint, the signature was validated using STRIPE_WEBHOOK_SECRET, and the subscription activated in your database. If the webhook event shows "failed" or does not appear, the subscription is not activating and your first paying customer will be charged without being upgraded.

7. Enable RLS and test data isolation with a second user. In Supabase → Authentication → Policies, toggle "Enable RLS on new tables," then verify policies exist for every table with user data. Log in as User A, create records. Log out. Log in as User B. If User B can see User A's records, RLS is not working. This is a production data breach, not a cosmetic issue. Fix before any public launch.

8. Test every empty state deliberately. Delete all test data. Load each page of the app with zero records. A Bolt-generated app that was never tested empty frequently shows a blank screen, a collapsed layout, or a JavaScript error. Fix each one before launch.

9. Test error states by breaking things on purpose. Temporarily set a wrong VITE_SUPABASE_URL in your environment and reload the app. What does the user see? An unformatted console error or white screen is not acceptable. Restore the correct URL and repeat for each integration (Stripe, any third-party API). Every integration should surface a readable error message to the user.

10. Walk through your three most important flows on a real phone. Bolt generates responsive layouts that break at specific viewport widths. Tap targets that look fine on desktop often overlap on mobile. Use Safari on iOS and Chrome on Android, not a browser dev-tools emulator. Then hand the URL to one person who did not build the app and watch silently while they complete a full journey: sign up, do the core thing, pay for something. Do not help. Every place they pause, click the wrong element, or give up is a bug.

When should I add human QA to my Bolt.new app?

AI-generated test suites cover the flows the tool was trained to write. They confirm the happy path works. They do not cover what a real user does when confused, what happens when production data looks different from test fixtures, or the business rule your app enforces that no prompt can fully describe.

Add human QA at these moments:

Before any public launch. Automated checks catch broken links and missing headers. They do not catch a confusing onboarding flow, an error message that makes users think the app is broken when it is not, or a mobile layout that collapses on the most common screen size. Green test results do not mean correct behavior; they mean the AI confirmed the assumptions it was trained on.

Before enabling real payments. Stripe live mode behaves differently from test mode in three specific ways: webhook signature verification is enforced, 3D Secure challenges are real, and card decline codes vary. A human tester running the full payment flow with a real card finds these differences before your first customer does. The cost of a failed webhook in production (a charged user who stays on the free plan) is higher than the cost of one test run.

After any major Bolt rebuild or regeneration. When you ask Bolt to rewrite a section, it regenerates code without full context of the rest of the app. Integrations that worked before the regeneration can silently break. The token-burn failure pattern documented in the Hacker News thread shows that Bolt sometimes removes security integrations (like signature verification) when rewriting adjacent files. A human pass through core flows after every significant rebuild catches regressions before users do.

When the automated suite is green but users are filing bugs. Green does not equal correct. AI writes the happy path and the tests that confirm the happy path. A human tester who has not seen your codebase will find the path you never imagined. They "aren't you, they don't share your assumptions." That is the bug your first real user finds: not a crash, but a flow so unclear or broken in a specific real-world condition that a genuine new user cannot complete it.

For Bolt.new founders shipping fast, the decision is not whether to test but how much of that testing can be automated and how much needs human judgment. See how Simz prices both layers at /pricing. For context on what QA services cost across the market, the QA pricing decoder normalizes every vendor to cost per human test run. If you are evaluating alternatives at the high end, the QA Wolf alternatives comparison covers the full field. If you built with Lovable instead of Bolt, the same failure categories apply: see the Lovable app testing playbook for a parallel walkthrough.

Simz runs your Bolt.new app through both AI test agents and human QA engineers on every plan, starting at $300/mo. Claim 5 free test runs and find out exactly what breaks before your first real user does.