← All guides

Lovable app audit before launch: what a person checks behind the login

By Novruz Veliev, Senior QA Engineer · ShipClarity · Published 28 September 2026

You built the app in Lovable. It works when you click through it yourself, and launch is close. Before real customers arrive, someone should use it the way they will: sign up with a fresh inbox, forget the password, pay, and try to open another person's data from a second account. That is the audit I do.

I'm Novruz, a senior QA engineer with 10+ years of testing real products. I test apps built with Lovable, Bolt, Cursor and Claude by hand, on the live product.

What the audit covers behind the login

Most of what goes wrong in a Lovable app happens after sign-up, where nobody looks without an account. These are the areas I test there, in roughly the order a new customer hits them.

Sign-up and password reset emails

I sign up with a real inbox and wait. Then I ask for a password reset and follow it to the end. Does the email arrive, or land in spam? Does the link open your domain or an old preview address, and can I log in afterwards? In the sample report below this was the top finding: the app said "check your inbox" and nothing ever came. The do-it-yourself version is in why Lovable reset emails don't arrive.

One user against another (Supabase RLS)

A Lovable app reads from Supabase straight from the browser, so Row Level Security decides who sees which rows. I use two accounts. The first creates data. The second tries to reach it through the interface, by changing the id in the URL, and by calling the API directly. Logged-out visitors and admin pages get the same treatment. The ten-minute version you can run alone: Supabase RLS and the anon key.

Payments in test mode

If the app takes money, I pay with test cards and follow what happens next. I check that the amount at checkout matches your pricing page and that the plan unlocks, then cancel and see whether that works too. The bad case is a quiet one: a customer pays and still sees the free plan.

Forms

Empty required fields, a date typed as 202633, very long text, HTML in a comment box, a double click on Submit, the Back button right after sending. AI-built forms often accept all of it, or fail without a word.

Mobile

Safari on a real iPhone, with Android and tablet sizes in emulation. I look for hidden buttons, a keyboard covering the field, pages that scroll sideways.

Quick Check covers the first three areas, with payments limited to the happy path. The Pre-Launch Audit covers all five and the rest of the 48-point checklist: security basics, data integrity, speed, and launch details such as robots.txt, link previews and the 404 page.

What the free scanners already cover, and what they can't see

As of September 2026, Lovable runs a quick security scan every time you publish, and a deeper one when you ask for it. Both are free. They read your code and database rules and catch things like a table with RLS switched off, a secret key in the frontend or a vulnerable package. Run them first and fix what they flag before you pay anyone.

The free ShipClarity scan looks from the other side: 17 automatic checks against your live URL, no login, about 20 seconds. I ran it on 190 live Lovable apps, and 189 had at least one flagged issue. The full numbers and the method are here.

No tool of either kind signs up with a real inbox and waits for the email, or logs in as two different people to compare what each can see. Paying with a test card is out of their reach too. My scan covers 9 of the 48 audit checks. The other 39 need someone with accounts, and that part is what you'd be paying for.

Price and turnaround

• Quick Check, $290. Report in 48 hours. Sign-up email, password reset, one user against another user's data, the payment happy path in test mode.
• Pre-Launch Audit, $790. Report in 3-4 days. All 48 checks.

The price is fixed before you pay anything. Each report comes with a written verdict and a screen recording of every critical and high issue. Re-testing your fixes later is a separate $290 order, limited to the findings in your report.

How it starts: you send the URL in the form above and get my reply within 24 hours. If you say yes, I send a short access list: a test account, a second one, and test-mode payments if the app takes money. I start when I get access. You get page 1 (the verdict) before paying. The invoice is a Payoneer link - card or bank transfer, no account needed. Full report the same day the payment lands.

The sample report

This is a real pre-launch pass on a study app built with Lovable, with the product anonymized: 22 of 48 checks, 9 findings. Page 1 gives the verdict in plain words: hold the launch until the emails work, about a day of fixing, then go. Each finding has steps to reproduce, the impact and the fix.

Download the sample report (PDF)

The sample covers part of the checklist. Latest full audit: 36 findings across 44 of 48 checks, 4 critical.

Questions people ask first

Do you need my code, or a call?

Neither. I test the live app as a user would, with test accounts, and we talk by email. Repo access helps with a couple of checks, outdated packages for example, and it's optional.

Will you touch real customers or live data?

Only where you allow it. You tell me which environment to test and what's off limits. A staging URL works too, as long as sign-up is switched on there.

Do you fix what you find?

No, I don't change your code. Each finding says what to change, in words you can pass to Lovable or to a developer. When the fixes are in, a re-test confirms them.

Lovable's scan came back clean. Am I ready?

You've passed the part a scanner can check. Whether the reset email arrives, or whether a second account can see the first one's data, is a separate question. Answering it takes a person with two logins.