I do QA on apps built with Lovable, Bolt and Cursor. Over the last few weeks I pointed a small external scanner at 190 live Lovable apps from a public directory. No login, no account, only what any visitor's browser loads.
What came back:
Honestly, most of this is boring config the builder never shows you. Nobody loses a customer over a missing header.
The expensive part sits behind the login, where a scanner can't reach: a signup that fails quietly on odd input, one user seeing another user's data by changing an id, a payment that goes through but never unlocks the plan. For comparison, the one full manual audit I've completed so far, with an account, came to 36 findings across 44 of 48 checks.
Curious how people here handle it before launch. Do you click through the logged-in paths yourself, or wait for users to tell you?
Good write-up. What would you do differently if you started again?
Nice work shipping it. What has been the biggest challenge since launch?
Thanks for writing this up. Bookmarking it for later.
Nice work shipping it. What has been the biggest challenge since launch?
How did you decide this was worth building in the first place?
Good point. Did you test that with users before committing to it?
Solid lesson. Which channel has worked best for you so far?
Solid lesson. Which channel has worked best for you so far?
Solid lesson. Which channel has worked best for you so far?
Solid lesson. Which channel has worked best for you so far?
Solid lesson. Which channel has worked best for you so far?
The 200-on-made-up-path finding is especially important for AI crawlers because it blurs real pages with errors. I would log status, canonical, title, and body fingerprint for a few random paths, then keep the check in CI so routing regressions show up as a changelog instead of a surprise.
jessie_geo, fair setup. One thing I'd add for single-page apps: a made-up path that returns 200 often serves the homepage shell, so title and canonical come back identical to the real page. That's why I'd compare title and body fingerprint against the homepage, not only the status. How do you keep the random paths stable between CI runs, a fixed seed?
Solid lesson. Which channel has worked best for you so far?
Solid lesson. Which channel has worked best for you so far?
Curious how long it took before you saw the first real results?
What made you pick this stack over the alternatives?
Makes sense. Are you planning to charge for it, or keep it free for now?
Interesting take. Would you still recommend this approach to someone starting today?
Good point. Did you test that with users before committing to it?
Solid lesson. Which channel has worked best for you so far?
Interesting. How are you measuring whether it is working?
Solid lesson. Which channel has worked best for you so far?
Solid lesson. Which channel has worked best for you so far?
Good point. Did you test that with users before committing to it?
Good write-up. What would you do differently if you started again?
Appreciate the honesty here, most people only share the wins.
Makes sense. Are you planning to charge for it, or keep it free for now?
Solid lesson. Which channel has worked best for you so far?
Thanks for sharing the numbers, that makes it much easier to follow.
Clear and practical, thanks. Did anything surprise you along the way?
How did you decide this was worth building in the first place?
Really relatable. How much time do you put into this each week?
Curious how long it took before you saw the first real results?
With external scans revealing mostly configuration issues, what evidence would show founders will pay for authenticated QA to prevent costly failures before launch?
aryan_sinh, fair question, and I don't have proof yet, so I won't pretend. What I have is the one full manual audit I've completed so far, with an account: 36 findings across 44 of 48 checks, plus the scan above showing what a visitor can see from outside. Whether founders will pay for the logged-in part is exactly what I'm testing now. The signal I'd trust most is a founder who fixes a config gap after the scan and then asks what sits behind the login. Do you build something yourself? If so, which logged-in path would you hate most to find broken after launch?
Could be useful to dig into the authenticated side a bit more by email sometime — happy to continue there.
aryan_sinh, glad to. Write to novruz@shipclarity.app with the product you have in mind and the one logged-in path you would least want broken after launch: signup, a payment, or another user's data. I'll tell you what a pass over it would cover.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
The 200 versus 404 check is such a sharp catch. I’d turn these into a tiny prelaunch gate with headers, routing, and exposed keys so builders get a clear fix list before auth flows. Great dataset.
Thanks, brianainews. A gate like that is close to how I think about it: headers, routing and exposed keys are the cheap part a script can flag in seconds. What I keep finding by hand is what a script can't reach, like a payment that goes through and never unlocks the plan, or one user seeing another user's data. If you were gating a launch, which of those would you put first?
Curious how long it took before you saw the first real results?
Curious how long it took before you saw the first real results?
This is great work — what's the biggest thing you'd do differently if you started over?
Really solid approach — curious how you're thinking about this, what's been the hardest part to figure out so far?
Really solid approach — curious how you're thinking about this, what's been the hardest part to figure out so far?