Saket ShuklaIs your app ready for real users? The short answer
Not until someone has checked it outside the builder. Lovable and Bolt can take you from idea to a working app in days, but an app that works in a demo is not yet a product that holds up with strangers, real data and payments. Run the 12 checks below: most apps pass some of them, and the gaps can usually be fixed without starting again.
AI app builders such as Lovable and Bolt generate a complete application from a prompt – usually a React front end, a hosted database such as Supabase, sign-in and one-click hosting. The speed is real. What the builder cannot know is who your users are, which data each of them may see, and what happens when traffic, money and people looking for weaknesses arrive.
Key takeaways
- Most serious problems sit in three places: database access rules, secret keys and payments.
- The builder’s own security scan helps, but Lovable says it cannot guarantee complete security.
- Fix before you rebuild – an audit shows which parts need work and which can stay.
AI-built apps by the numbers
- In May 2025, 170 of 1,645 Lovable-built apps checked by a researcher let anyone read information about their users, including names, email addresses and API keys (Semafor, 2025). The flaw is recorded as CVE-2025-48757 with a critical score of 9.3; Lovable disputes it, saying each customer is responsible for protecting their app’s data.
- In Veracode’s October 2026 tests of 18 AI models, 38% of coding tasks still produced code with a security flaw – down from 44%, but still nearly four in ten (Veracode, 2026).
- 46% of developers actively distrust the accuracy of AI tools, more than the 33% who trust it (Stack Overflow Developer Survey, 2025).
- The global average cost of a data breach reached US$4.99 million (IBM Cost of a Data Breach Report, 2026).
The 12 checks
Work through them in order: the first six protect your users’ data and your revenue, the next four keep the app running as it grows, and the last two let you keep changing it safely.
Data and access
1. Row-level security is on for every table. In a Supabase-backed app the browser talks to the database directly, so the database itself has to decide who may see what. Supabase’s guidance is to enable row-level security (RLS) on every table in an exposed schema, because a table without it can be read and changed through the public API. Turn RLS on, write a policy for each table, then test it: sign in as two different users and try to read each other’s records.
2. No secret keys in the browser. Search the built front end for API keys. Supabase’s service-role key bypasses RLS and must stay on the server; so must your AI provider, payment and email keys. Move any call that needs them into a server function, and rotate every key that was ever exposed.
3. Every sensitive action is checked on the server. Hiding a button is not access control. Admin screens, refunds, role changes and data exports need a check in server code or a database policy, not only in the React interface.
4. Inputs are validated. Set limits on file uploads, text fields and URLs, and treat anything a user types into an AI feature as untrusted – especially when the model can call tools or read other users’ data, where prompt injection becomes a real risk.
Payments and money
5. Payments are confirmed by the server, not the browser. A “payment successful” page proves nothing. Grant access only when your server receives the payment provider’s webhook, verify the webhook’s signature, and make the handler safe to run twice.
6. Prices, plans and limits live on the server. If the front end sends the price or the plan, someone will change it. Read prices and entitlements from your database or the payment provider.
Reliability under real traffic
7. The database holds up. Add indexes for the queries your main screens run, paginate long lists and remove queries that run once per row. Load-test the key journeys with realistic data volumes, not the ten records you created while building.
8. Backups exist, and one has been restored. Check your database plan’s backup schedule and point-in-time recovery, then rehearse a restore into a separate project. A backup nobody has restored is a hope, not a plan.
9. Errors are visible. Add error tracking and logs for the front end and server functions, with alerts on failed payments, sign-in spikes and AI spend. You want to hear about a problem before your users do.
10. Abuse is limited. Rate-limit sign-up, login, password reset and AI endpoints, and protect public forms against bots. An open AI endpoint can run up a large bill overnight.
Running it as a product
11. Email and compliance basics are in place. Gmail requires SPF or DKIM authentication from every sender, and from bulk senders – more than 5,000 messages a day to Gmail accounts – SPF, DKIM and DMARC, plus one-click unsubscribe on marketing messages. Publish a privacy policy that matches the data you actually collect, let users delete their account and data, and check accessibility: the European Accessibility Act has applied since 28 June 2025 to services such as e-commerce and consumer banking in the EU.
12. You own the code and can change it safely. Sync the project to a GitHub repository your company owns, keep separate staging and production environments, put database changes in migrations and add automated tests for sign-in, payments and the core journey. Make sure the hosting, database, domain and payment accounts are in the company’s name, not a freelancer’s.
The 12 checks at a glance
| # | Check | What good looks like | Risk if skipped |
|---|---|---|---|
| 1 | Row-level security | A tested policy on every table | Users read or change each other’s data |
| 2 | Secret keys | Service-role, AI and payment keys only on the server | Full database access and bills run up by others |
| 3 | Server-side checks | Admin and money actions checked in server code or policies | Ordinary users act as admins |
| 4 | Input validation | Limits on uploads, text and AI prompts | Broken records, injection and prompt injection |
| 5 | Payment confirmation | A signed, repeat-safe webhook handler | Access without paying, or double charges |
| 6 | Server-side prices | Prices and limits read from the server | Customers set their own price |
| 7 | Database performance | Indexes, pagination and a load test | Slow pages and timeouts as users grow |
| 8 | Backups | Point-in-time recovery and a tested restore | Data lost for good |
| 9 | Monitoring | Error tracking, logs and alerts | Failures nobody notices |
| 10 | Rate limits | Limits on sign-in and AI endpoints | Spam accounts and runaway AI costs |
| 11 | Email and compliance | SPF, DKIM, DMARC, privacy, deletion and accessibility | Emails in spam and complaints to regulators |
| 12 | Ownership and change control | Your repository, staging, migrations and tests | Every change risks breaking production |
Use the builder’s security scan – then go further
The builders are adding checks of their own. Lovable runs a quick security scan when you publish, offers a deeper scan you start yourself, and lets workspace admins block publishing while critical issues remain. Its documentation is clear about the limits: the tools help find common issues but “cannot guarantee complete security”, and apps that handle sensitive data should get a professional review. Treat the scan as the minimum, not the sign-off.
Fix or rebuild?
Most apps that fail some of these checks do not need to be rewritten. If the data model fits the product and the code is reasonably structured, fixing access rules, moving secrets to the server and adding tests is faster and cheaper than starting again. Rebuilding a part makes sense when its data model is wrong for the product, its security flaws are structural – users can reach each other’s data by design – or the product has moved far beyond the first prototype.
That was the approach with Elabora’s stalled job board in Mexico: we assessed what already existed, then rebuilt and stabilised its core on Django rather than starting from a blank page. And when Routimize needed an MVP that a first enterprise customer could pilot, we built the dispatcher dashboard and driver app to production standards from the start; the pilot succeeded and won the startup its first customer.
Frequently asked questions
Is Lovable or Bolt safe for a production app?
Both can produce apps that run in production, but neither guarantees it. Safety depends on how the database rules, secret keys, payments and server code are set up – which is what the 12 checks cover.
What is row-level security?
Row-level security is a database feature that decides, row by row, which records each user can read or change. In Supabase-backed apps the browser talks to the database directly, so these policies are often the only thing that stops one user from reading another user’s data.
Do I need to rebuild my app from scratch?
Usually not. Most gaps can be fixed in place. Rebuild only the parts where the data model, the security design or the structure of the code blocks you.
Can I keep using Lovable or Bolt after a rescue?
Yes. Many teams keep using the builder for screens and quick changes, while server logic, database migrations and tests live in a repository that developers review before anything reaches production.
What should I fix first?
Anything that exposes data or money: row-level security, secret keys and payment confirmation – checks 1, 2 and 5. Then backups and monitoring, then performance.
How Assystant can help
We audit apps built with Lovable, Bolt, Replit, Cursor, Claude Code, Base44 and v0, tell you plainly whether to fix or rebuild each part, then stabilise what matters most to your users first. See Rescue a project, our pages for Lovable apps and Bolt apps, or talk to us about your app.
Sources
- Semafor – The hottest new vibe coding startup Lovable is a sitting duck for hackers (May 2025)
- NIST National Vulnerability Database – CVE-2025-48757
- Veracode – AI code security results, October 2026
- Stack Overflow – Developer Survey 2025: AI
- IBM – Cost of a Data Breach Report 2026
- Supabase – Row Level Security
- Lovable – Security documentation
- Google – Email sender guidelines
- National Disability Authority (Ireland) – European Accessibility Act