DEV Community: CodesSavvy

Is Your Lovable App Production-Ready? (And How to Fix It)

CodesSavvy — Thu, 06 Aug 2026 10:47:36 +0000

Originally published on CodesSavvy.

Short answer: most Lovable apps are not production-ready the day real users arrive — and that's normal, not a failure. Lovable builds a working product in an afternoon, but it consistently ships the same gaps: authentication and database rules that look enforced but aren't, no handling for the ways real users break things, and code that buckles under load. The good news is that "production-ready" is a concrete, checkable standard. Below is the exact checklist we use, the security data you should know, and how to close the gaps.

What "Production-Ready" Actually Means

"It works when I click through it" is not production-ready. Production-ready means the app holds up when people you've never met use it in ways you never planned — on bad networks, with weird input, at the same time as each other, and occasionally while trying to break it.

Lovable is genuinely excellent at the first 80%: the screens, the flows, the happy path. Production-readiness lives in the last 20% — the invisible engineering that AI tools skip because it doesn't show up in a demo. We broke down that 80/20 split here.

The 8-Point Lovable Production-Readiness Checklist

Run your app against these. Each one is a place we routinely find gaps in "finished" Lovable builds.

#	Check	Production-ready means
1	Database access rules (RLS)	Row-Level Security is ON for every table; users can only read their own rows
2	Real authorization	Permission checks run on the server, not just hidden in the UI
3	Secrets & API keys	No keys in the client bundle or committed to the repo
4	Input validation	Every input is validated server-side before it touches the database
5	Error handling	Failed requests, timeouts, and edge cases show a human message, not a white screen
6	Data integrity	Constraints, migrations, and no duplicate or orphaned records under concurrent use
7	Performance & limits	No N+1 queries, basic caching, and rate limiting so a spike doesn't take you down
8	Payments reconcile	Webhook idempotency so no one is charged twice; failed payments recover cleanly

If you can't confidently tick all eight, your app isn't ready yet. The most common failure — by a wide margin — is the first one.

The Biggest Risk: Your Database May Be Wide Open

The single most dangerous Lovable gap is missing Row-Level Security (RLS) on your Supabase database. This isn't hypothetical. In May 2025 it was assigned its own vulnerability, CVE-2025-48757 — rated 9.3, critical — described by NIST as "an insufficient database Row-Level Security policy in Lovable ... [that] allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites."

In plain English: for a large number of Lovable apps, anyone on the internet could read or edit your users' data directly — no login required — because the app trusted checks that only existed in the browser.

This isn't unique to one platform. Security firm Escape scanned over 5,600 publicly available vibe-coded applications and found more than 2,000 critical vulnerabilities, 400+ exposed secrets, and 175 instances of exposed personal data (PII) — with Lovable the single largest platform in the sample (Escape, 2026). And the problem isn't shrinking as models improve: Veracode's Spring 2026 analysis found only 55% of AI-generated code is secure — the other 45% ships a known vulnerability — a rate that has stayed flat for two years straight even as the models got dramatically better at everything else (Veracode, 2026).

Better AI coding tools are producing more insecure apps, not fewer — because they generate more code, faster, at the same 55% security rate.

One fair caveat: Lovable has since updated its code generation to enable RLS on new projects, and disputes the CVE on the grounds that securing application data is the customer's responsibility. Both can be true — but if your app was generated before that fix, or you added tables yourself, the responsibility (and the risk) is yours to check.

A 60-Second Self-Test

You don't need us to start. Ask yourself:

If a stranger opened your app's network tab, could they find your Supabase URL and key? (They can — it's in the frontend. The real question is what they can do with it.)
Is Row-Level Security enabled on every table, with policies you've actually tested?
Have you tried logging in as User A and loading User B's data by changing an ID in the URL?
What happens when a payment fails halfway, or two people submit the same form at once?

If any of those made you uneasy, that's the gap between a demo and a product.

How to Fix a Lovable App That Isn't Ready

The work is unglamorous and follows a clear priority order — security first:

Lock down the database. Enable RLS on every table and write tested policies so users can only reach their own data.
Move authorization server-side. Every permission check runs where the user can't tamper with it.
Pull secrets out of the client and rotate anything that was exposed.
Add validation and error handling at every input and failure point.
Harden data and performance — constraints, migrations, caching, rate limiting.
Verify under real conditions — concurrent users, bad input, failed payments.

Most of this is a focused hardening pass, not a rewrite — typically two to four weeks for a real app.

Fix It or Rebuild It?

Almost always: fix it. The idea, the UI, and usually the data model your Lovable app captured are worth keeping — they just need production hardening. A full rebuild is only warranted when the data model is fundamentally broken, the platform blocks your roadmap, or the generated code is too tangled to safely change. That's the same honest call we make on our AI App Rescue projects — and because fixing is cheaper for us to quote, we have no reason to push an unnecessary rebuild.

Frequently Asked Questions

Is Lovable safe to use for a production app?

Lovable is safe for building and validating — it's the fastest way to get a working product in front of users. It is not automatically safe to launch as-is. The generated code has known security gaps, most notably database Row-Level Security that historically shipped disabled (CVE-2025-48757). Treat Lovable as a great starting point: a production launch needs a security and hardening pass on top of it.

How do I know if my Lovable app is secure?

Start with the database: confirm Row-Level Security is enabled on every table and test that one user cannot load another user's data by changing an ID. Then check that permission logic runs on the server, not just in the UI, and that no API keys sit in the frontend bundle. If you can't verify all three, assume it's exposed until a senior engineer reviews it.

Can I make my Lovable app production-ready myself?

If you're technical, yes — enabling RLS, adding server-side validation, and handling errors are all doable. The risk is not knowing what you don't know: the dangerous gaps like authorization bypass, race conditions, and leaked secrets are invisible in a working demo. Many founders do the first pass themselves and bring in an engineer to audit for the failure modes they can't see.

How long does it take to make a Lovable app production-ready?

For a typical Lovable app, a focused hardening pass — security, error handling, data integrity, and performance — usually takes two to four weeks. Apps with payments, complex permissions, or a broken data model take longer. A quick audit tells you which bucket you're in before you commit to any timeline or budget.

Should I fix my Lovable app or rebuild it from scratch?

Fix it, in the large majority of cases. The core idea and data model are usually sound and worth keeping; they just need production hardening, which is faster and cheaper than starting over. Rebuild only when the data model is fundamentally wrong, the platform blocks where you're headed, or the code is too tangled to change safely.

The Honest Takeaway

Lovable didn't fail you — it did exactly what it's built to do: get you to 80% astonishingly fast. Production-readiness is the last 20%, and it's a concrete, checkable standard, not a mystery. Run the eight-point checklist, start with the database, and fix in priority order.

If you'd rather have a senior engineer check it for you, get a free AI App Health Check — we'll send back an honest report on exactly what your Lovable app needs — or see how our AI App Rescue works.

This article was originally published on codessavvy.com. CodesSavvy is a senior engineering studio that rescues broken AI and vibe-coded apps.

Web App Development Cost in 2026: Real Numbers, No Fluff

CodesSavvy — Thu, 23 Apr 2026 06:40:21 +0000

How much does it cost to build a web app?

It's the most Googled question in software development. And it gets the worst answers. "Anywhere from $5K to $500K." "It depends on complexity." "Contact us for a quote."

Here's the honest answer — broken down by build type, feature, and stage. Based on real projects we've scoped and delivered for startups in the US, UK, Canada, and Australia.

The Short Answer: Web App Development Cost in 2026

Simple internal tool / CRUD app — $5K – $12K · 3–5 weeks
Marketing site with custom backend — $8K – $15K · 4–6 weeks
Web app MVP (3–5 features) — $8K – $20K · 5–8 weeks
SaaS MVP (auth + billing + tenancy) — $15K – $30K · 6–10 weeks
V1 product (full feature set) — $40K – $80K · 10–16 weeks
Cross-platform (web + mobile) — $35K – $70K · 10–16 weeks
Enterprise platform — $80K – $250K+ · 4–12 months

These are senior-agency rates for production-ready software — not offshore template shops, not $15/hr freelancers, not WordPress with a premium theme.

What Actually Drives Web App Development Cost

Feature Count — The Biggest Cost Driver

This is the number one lever. Not the technology. Not the design. The features. A web app with 4 focused features costs a fraction of one with 14. Not because 14 features takes 3x as long — it takes 8x as long. Every feature interacts with every other feature. What sounds like "one feature" is often four.The most expensive word in software development is "can we also add.

Authentication and User Management

Basic email and password login: 2–3 days. Now add social logins, multi-factor authentication, team accounts with invites, role-based permissions, and SSO for enterprise clients — you're looking at 3–4 weeks. Auth is one of the most underestimated cost items in any web app estimate. Shortcuts here are the shortcuts that end up in breach notification

Third-Party Integrations

Each integration — Stripe, Twilio, HubSpot, Salesforce, SendGrid, Zapier, Slack — adds 1–3 weeks of development time. APIs are never as clean as their documentation suggests.
Can we just add a Salesforce sync?" is never just one sprint.

Compliance Requirements

HIPAA (healthcare): 4–8 weeks minimum
SOC 2: 2–4 months of process documentation and infrastructure
GDPR (EU users): 2–3 weeks for data deletion, consent management, data portability
PCI DSS (card data): Almost always better to use Stripe and avoid touching card data directly

Real-Time Features

Real-time notifications, live dashboards, collaborative editing, chat — anything that updates without a page refresh requires WebSocket infrastructure and careful state handling. Add 1–3 weeks per real-time feature.

Infrastructure and DevOps

A Vercel deployment is one day. A production AWS setup with CI/CD pipelines, blue-green deployments, monitoring, and alerting is 2–4 weeks. It's not optional for production systems with real users.

AI and LLM Features

Budget 2–5 weeks for any meaningful AI feature. Prompt engineering, streaming responses, token cost management, fallback handling, output validation — these take time to do properly.

Web App Cost Breakdown by Stage

Stage 1: Simple Internal Tool ($5K – $12K)

Admin dashboards, internal reporting tools, client portals, booking systems. Single-purpose apps with a clear user flow.Included: authentication, 4–6 CRUD screens, basic integrations, production deployment, error monitoring.

Stage 2: Web App MVP ($8K – $20K)

The most common project type for early-stage startups. An MVP is not a prototype — it is the smallest version of your product that a real user can sign up for and get value from on day one.
Included: production-ready architecture, 3–5 core features, auth, one payment integration, CI/CD, basic analytics.

Stage 3: SaaS MVP ($15K – $30K)

SaaS costs more because of what's under the hood — multi-tenancy, billing lifecycle, subscription logic, dunning for failed payments, usage metering.

Stage 4: V1 Product ($40K – $80K)

Full feature set, admin dashboard, third-party integrations, email automation, onboarding flows, team accounts, architected to scale to tens of thousands of users. A V1 is typically 3–4x the cost of the MVP it follows.

Stage 5: Enterprise Platform ($80K – $250K+)

Compliance, SSO/SAML, custom permissions, documented APIs, SLA-grade infrastructure. If you're targeting enterprise customers, build like one from day one — retrofitting enterprise requirements onto a startup codebase costs as much as a fresh build.

Hidden Costs Most Estimates Miss

Hosting: $200–$2,000/month on AWS or GCP depending on scale
Ongoing maintenance: 10–20% of original build cost per year
Performance optimization: What works at 100 users often needs engineering work at 10,000
Security audits: $5K–$20K for a proper pentest before your first enterprise client

Fixed Price vs. Hourly

Hourly means the agency's incentive is hours, not outcomes. Every additional hour is revenue for them.
Fixed price forces the agency to scope clearly and build efficiently — overruns come out of their margin, not yours. It only works with a proper written spec covering every feature, exclusion, and acceptance criterion.

The Real Cost of Choosing the Cheapest Option

There are agencies that will build your web app for $3K–$8K. Here's what that timeline looks like:

Month 1: It looks like it works. The demo goes well.

Month 3: Bugs appear with real users. Fixes introduce new bugs.

Month 5–6: A senior developer reviews the code and finds: no tests, hardcoded API keys, SQL injection vulnerabilities, no architecture.

Month 7: You're paying a proper team to rebuild from scratch. Cost: $25K–$50K. Plus six months of lost momentum and burned runway.

A $5K build that requires a $35K rebuild did not save you $15K. It cost you an extra $20K and half a year.

How to Get an Accurate Quote

Write a one-page brief — who the users are, what problem they have, what the 4–5 most important features are
Book a discovery call — 30–60 minutes with the actual engineers, not a salesperson
Ask for a written spec — not a slide deck, a document covering every feature and a fixed price
Ask who will actually build it — names and LinkedIn profiles, not "our team"