What a Lovable app has on day one — and what production asks for
| Area | What a prototype usually has | What production asks for |
|---|---|---|
| Who can read which data | Access rules that work for the person testing it | Each user sees only their own records — checked, not assumed |
| Secrets | Keys that make the demo work | Keys kept off the public side, so nobody else can run up your bills |
| Sign-in | A login screen | Password reset, session expiry, account recovery, staff versus customer roles |
| Payments | A checkout that succeeds | Refunds, failed payments, and records that agree with the money |
| Tests | Little or none | Enough coverage that a fix does not quietly break something else |
| Monitoring | You notice when it breaks | You hear about an outage before your customers do |
| Compliance | Not considered | Health or EU personal data handled the way an auditor will ask about |
None of this is a criticism of the tool. Lovable executed the prompts it was given; nobody prompted for account recovery or an outage alert.
What the public record shows
In 2025, two researchers scanned 1,645 Lovable-built apps featured on Lovable’s own site. 170 of them let anyone access information about the app’s users — names, email addresses, financial information and secret API keys for AI services (Semafor, 29 May 2025). The issue was registered as CVE-2025-48757, publicly disclosed on 29 May 2025.
It is not only Lovable. A 2025 study by Veracode tested code from over 100 large language models and found that 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities (Veracode, 2025 GenAI Code Security Report).
What Lovable says is your job
Lovable now offers built-in security scans. Its documentation is clear about their limits: “You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions” — and, for apps handling sensitive data, it suggests “an additional professional security review” (Lovable documentation, Security).
That is a fair position for a tool to take. It does mean the question “is it production-ready?” has to be answered by someone who will answer for it.
When a Lovable app is fine as it is
A tool for your own team, an internal dashboard, a landing page with a sign-up form, a demo for investors: if no outsider’s personal data or money passes through it, most of the table above matters less. Production readiness is not a fixed bar. It is the bar your users, your data and your regulator set.
Questions to ask before you launch
- Could one user see another user’s data? How do you know?
- Is anything secret visible from the browser?
- What happens when a user forgets their password — or leaves the company?
- Who finds out first when it goes down — you, or a customer?
- Does it handle health data, payments or EU residents’ personal data?
If any answer is “not sure”, that is the scope of the work — not a reason to rebuild.
How Pricient handles a Lovable app
Your prototype is the requirements document. Describe what you built and what is worrying you; today a person runs the intake with you by email. Before you pay anything you receive the specification, wireframes of every screen, the Not in this release list, the assumptions register and a three-tier itemized quote — QA and security in every tier, locked for 14 days.
The launch-ready MVP starts from $7,500, fixed once your spec is agreed: live 3 weeks after the spec is agreed, security-hardened, 80% test coverage and three months of support. Code you share is read-only, logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.