Built Your App with Lovable, Bolt or Cursor? What to Test Before Real Users Arrive

Before real users arrive, test your vibe-coded app twice: once to check it works, once to check it is secure. The first pass walks through sign-up, forms, devices and error messages the way a normal user does. The second pass tries to break in, looking for exposed keys, leaked data and gaps in your business rules.

A vibe-coded app that works in the preview is not ready for real users yet. The AI built the path you described, and real users take every other path.

The risk is documented. In May 2025, a researcher scanned 1,645 apps from Lovable’s public showcase. In 170 of those apps, anyone holding the public key was able to read or write the database tables.

The flaw was logged as CVE-2025-48757, and the cause was Row Level Security (RLS) left switched off. Lovable disputes the record, stating that each customer is responsible for protecting their own app’s data. That position puts the testing on you.

Veracode’s 2025 GenAI Code Security Report tested more than 100 AI models on 80 curated coding tasks. The models introduced OWASP Top 10 vulnerabilities in 45% of those tasks. The study measured generated code samples, not deployed apps.

This guide walks through the exact process we use to test vibe-coded apps before launch. We wrote it for founders, CTOs and product leads who built with Lovable, Bolt or Cursor.

Why Does a Working Vibe-Coded App Still Need Testing?

A working vibe-coded app still needs testing because a clean interface says nothing about the backend. Anyone can skip the interface and send requests straight to your database. Testing checks what happens on those paths.

Vibe coding means building software by describing features to an AI tool in plain language. Vibe coding tools turn those descriptions into working code within minutes.

Lovable and Bolt generate full web apps from chat prompts, usually on a Supabase backend. Cursor is an AI code editor that developers use to write and change code faster.

The generated app reflects the prompt. Prompts describe what users do when everything goes right. They rarely mention empty fields, a second browser tab or a user editing a request by hand. Those gaps are where vibe-coded apps break.

Across our testing of vibe-coded apps, almost every serious issue came from the security pass, not the functional pass. Both passes belong to standard web application testing, applied here with AI-specific failure patterns in mind.

Is Vibe Testing the Same as Testing a Vibe-Coded App?

No, vibe testing and testing a vibe-coded app are different practices. Vibe testing uses AI agents to write and run tests from plain-language prompts. Testing a vibe-coded app means verifying software that AI built, with any method that works.

This guide covers the second practice. AI testing tools support it, but they do not replace the manual checks below.

Each AI builder already runs some checks on your behalf. Knowing what those built-in checks cover tells you where your own testing starts.

What Do Lovable, Bolt and Cursor Already Test for You?

Lovable, Bolt and Cursor already test for you through browser checks, security scans and generated tests. These checks look for known problems. They do not know your app’s specific rules, like who is allowed to change a price.

Lovable’s testing documentation lists 3 verification tools: browser testing, frontend tests and edge function checks. Frontend tests and edge tests run only when you ask for them.

Bolt’s security audit reviews the project’s code and database, fixes what it can and flags the rest. Bolt’s database check flags weak rules, including a warning called “RLS Policy Always True”.

Cursor writes unit tests that match your existing test patterns and reviews pull requests through Bugbot. Cursor tests the code a developer is writing, not the deployed app a user sees.

💡 Practitioner Note: In our testing work, business logic abuse is the category that scanners miss most often. A scan confirms that known patterns are absent. A scan cannot confirm that a normal user is unable to change their own plan.

Does Lovable’s Built-In Testing Make Your App Ready for Users?

No, Lovable’s built-in testing does not make an app ready for real users on its own. Lovable’s browser testing runs as the same app user you are logged in as in the preview.

One logged-in user cannot prove that a second user’s data stays private. That proof needs 2 separate accounts, covered in the security pass below.

Lovable’s security documentation lists security scans, API key protection, database access checks and dependency audits. We treat those results as a first filter, not a final answer.

Built-in checks set the floor. The 2 passes below are what we run on top of that floor.

How Do You Test That a Vibe-Coded App Works?

To test that a vibe-coded app works, walk every core flow as a real user, then push the edges. The functional pass covers 7 areas. Each area targets a gap that prompts leave open.

The functional pass is black box testing: we test from the outside, without reading the generated code. The 7 areas run in this order:

1. Main user flows.
2. Forms and inputs.
3. Double-clicks, back buttons and 2 open tabs.
4. Devices and browsers.
5. Lost connections and error messages.
6. Basic speed.
7. Retesting after every fix.

The Main User Flows

Main user flow testing confirms that each core journey works end to end, the way a real user completes it. We start with the 4 account flows every app shares:

• Sign-up.
• Login.
• Logout.
• Password reset.

Next, we complete each core action the app exists for, from the first click to the final confirmation screen.

Partial checks hide failures between steps. A flow passes only when a real user finishes it without help.

Forms and Inputs

Input testing checks that every form rejects bad data with a clear error message. We enter 5 types of bad input into every field:

• Empty fields.
• Very long text.
• Special characters and emojis.
• Wrong email formats.
• Negative numbers.

A clear error message is a pass. A crash, a frozen screen or a silent failure is a fail. Silent failures cause the most damage of the 3, because the user believes the data saved.

Double-Clicks, Back Buttons and Two Tabs

Edge case testing repeats ordinary user habits that generated code does not expect. We run 4 checks on every important flow:

• Double-click each submit button.
• Press back in the middle of a flow.
• Refresh the page during a submit.
• Open the app in 2 tabs and act in both.

These habits create duplicate records and broken states. A double-clicked order button that creates 2 orders is the kind of defect this check exposes.

Devices and Browsers

Device and browser testing confirms that layouts hold and buttons stay clickable on the platforms real users use. We test on Chrome, Safari and Firefox, on both mobile and desktop screens.

The builder preview shows one browser engine at a time. Cross-browser defects stay hidden there until launch day.

Lost Connections and Error Messages

Error handling testing checks what the app shows when the network fails mid-action. We switch off the internet halfway through an action. Then we slow the connection down to match a weak mobile signal.

A helpful message with a retry option is a pass. A spinner that never ends is a fail.

Basic Speed

A basic speed check measures how long pages and key actions take to load for a single user. We time each page and each core action, then flag anything that feels slow to a first-time visitor.

A basic speed check is not load testing. Heavy traffic needs a separate load test before any large launch.

Retesting After Every Fix

Retesting after fixes confirms that a change did not break a feature that worked before. Testers call this check regression testing. We rerun the main flows after every fix, without exception.

AI tools sometimes change more code than the prompt asked for. A request to fix a button label can rewrite the form logic behind that button. In our testing of vibe-coded apps, this retest step mattered more than in hand-written projects for exactly that reason.

A clean functional pass proves the app works for an honest user. The security pass assumes the user is not honest.

How Do You Test That a Vibe-Coded App Is Secure?

To test that a vibe-coded app is secure, test it like an attacker: skip the interface and hit the backend. The security pass covers 8 checks. A clean interface proves nothing about any of them.

The security pass follows the same logic as security testing for web applications, focused on the places AI builders slip. The 8 checks are:

1. Exposed secret keys.
2. One user reaching another user’s data.
3. API calls while logged out.
4. Row Level Security and storage buckets.
5. Checks that run only in the browser.
6. Business logic abuse.
7. Rate limits on expensive actions.
8. Automated scans and AI review.

Exposed Secret Keys

Secret key testing searches everything the browser downloads for keys that belong only on the server. We open the browser’s developer tools and read the network requests and the JavaScript bundle. We look for 3 kinds of secrets:

• Payment provider secret keys.
• AI service keys.
• The Supabase service role key.

The Supabase anon key showing up is normal. Supabase designs the anon key for public use, with RLS doing the protecting.

The service role key bypasses RLS completely. Finding the service role key in the bundle is a critical failure.

One User Reaching Another User’s Data

Cross-user access testing checks whether one logged-in user can read or change another user’s data. Cross-user access testing is the most useful test we run. Security testers call this flaw an insecure direct object reference (IDOR).

We create 2 accounts and log in as the first. Then we target the second account’s data by changing IDs in API requests and page URLs.

Here is the test with User A (ID 1042) logged in and User B (ID 1043) as the target:

Any result in the fail column blocks the release. One leaked row proves the access rule is broken, so we test every table using the same rule.

API Calls While Logged Out

Logged-out testing calls every application programming interface (API) endpoint with no session to see what data comes back. We send requests to each endpoint and each backend function without a login token.

Public content coming back is fine. Anything tied to a user, an order or a payment is a fail.

CVE-2025-48757 was this exact failure: tables readable and writable with no login at all.

Row Level Security and Storage Buckets

Row Level Security is the Supabase database feature that decides which rows each user can read or change. We confirm that every table reachable through the Supabase API has RLS switched on. Supabase’s RLS documentation explains how policies limit rows to the logged-in user.

We then read each policy line by line and test whether it enforces the intended access rule. A policy that allows everything gives the same protection as no policy at all. An “RLS enabled” checkbox stays green either way.

Storage buckets get checked in the same pass. A bucket set to public by accident exposes every file stored in it. We confirm each public bucket holds only files meant for everyone, like product images.

Checks That Run Only in the Browser

Server-side validation testing confirms that important checks run on the server, not only in the browser. We review 3 areas of logic:

• Admin permission checks.
• Login and session checks.
• Input validation rules.

A check written only in front-end code stops honest users and nobody else. Anyone can edit browser code or send requests that skip it entirely.

Breaking the Business Logic

Business logic testing tries to make the app do things its own rules forbid. Scanners usually miss this category, because the rules are unique to each app. As a normal user, we try to change 4 values we do not control:

• Our own role.
• Our subscription plan.
• Our credit balance.
• The price at checkout.

We replay and modify requests to see whether a user can skip steps. One example is reaching a paid feature before payment completes.

A webhook is the message a payment provider sends your app when a payment succeeds. We confirm the payment webhook verifies its signature, so a forged “payment succeeded” message cannot unlock paid features.

Rate Limits on Expensive Actions

Expensive action testing checks that every action costing money verifies the caller and has a rate limit. Actions in this group include sending emails, calling an AI model and charging a card.

A rate limit caps how many requests one caller makes within a set time window. An unprotected email endpoint lets one script send emails on your account without limit.

Can Scanners and AI Review Prove an App Is Safe?

No, scanners and AI code review cannot prove an app is safe. A clean scan means no known pattern matched, not that your business rules hold.

After the manual checks, we run an OWASP-recommended security scanner and Semgrep for static code analysis. An AI model then reviews the code as a second pair of eyes. We treat all 3 results as backup.

What Comes After the First Round of Security Testing?

After the first round of security testing comes deeper work on dependencies, injection, sessions and logging. Our current process does not go deep on these 4 areas yet. They form the next layer for any app holding sensitive data.

• Dependency vulnerabilities: Third-party packages inside the app carry their own known security flaws.
• Injection testing: Attackers insert code into form fields to make the database or server run it.
• Session handling: Session testing confirms that logins expire, rotate and end cleanly on logout.
• Security logging: A logging setup records security events, so an attack leaves a trail to follow.

Apps handling payments or health data need this layer before launch, usually through a full penetration test.

When Does a Vibe-Coded App Need Professional QA?

A vibe-coded app needs professional quality assurance (QA) once real people trust it with data or money. 4 triggers mark that point. Each trigger raises the cost of a missed defect.

• Real user data: The app stores personal details, messages or uploaded files.
• Payments: Money moves through subscriptions, credits or a checkout flow.
• Paid acquisition: Ad spend sends strangers to the app before friends and early users find the bugs.
• Investor or client demos: A failure in front of a buyer costs more than the testing.

How Does Testscenario Test AI-Built Apps?

Testscenario tests AI-built apps with the same 2-pass process this guide describes, run by dedicated QA engineers. Teams receive results from both passes with every defect documented. Testing starts within 48 hours.

Testscenario holds a 4.9 rating on Clutch from 17 reviews, across 81 client engagements. To get an AI-built app tested before launch, start with our web application testing services. The service covers functional, security, compatibility and regression testing for apps built with any tool.

FAQ

How Do You Test a Vibe-Coded App?

You test a vibe-coded app in 2 passes: a functional pass and a security pass. The functional pass checks flows, inputs, edge cases, devices, errors and speed. The security pass checks secret keys, cross-user access, database rules and business logic.

How Reliable Are Apps Built with Lovable?

Apps built with Lovable are as reliable as the testing behind them. Lovable produces working apps quickly.

Reliability depends on whether someone tested the paths the prompt left out. CVE-2025-48757 showed 170 showcase apps with open database tables.

Is Vibe Coding a Trap for Production Apps?

No, vibe coding is not a trap for production apps when testing happens before launch. The trap is shipping on the strength of a working preview. A preview proves the happy path, and production traffic finds everything else.

Should You Test on a Copy or the Live App?

Test on a copy of the app first, then run a final check on the live app. Lovable supports separate test and live environments, and its browser testing runs against the test preview.

Security tests that change data belong on the copy. Use fake accounts only, never real customer records.