From Lovable Prototype to Production: What It Really Costs

You built it in a weekend. Lovable, Bolt, Replit, v0, maybe Cursor for the last mile. It works. People signed up. Some of them are asking when they can pay.

And now something is off. A user sees another user's data. The login flow breaks on Safari. You asked the tool to add a feature and it quietly rewrote 3 others. You are not sure where the API keys live, and you have a bad feeling they live in the browser.

This is the wall, and in 2026 it is the most common reason a founder books a call with us. The good news is the prototype did its job. It proved someone wants the thing. The question now is what it costs to make the thing real, and the answer is $5,000 to $35,000 depending on which of 3 paths fits.

Where the prototype stops being enough

AI builders are very good at the part of a product you can see. They are much weaker at the part you cannot. The same 5 things break in these apps, in roughly this order.

Permissions. The database has no row-level rules, so any logged-in user can read any row. This is the one that gets you in the news.

Auth. Password reset is missing or broken, email verification was never turned on, there is no rate limit on login, and roles do not exist. Everyone is an admin.

Data model. Tables were created feature by feature. There are 3 tables that mean the same thing, nothing has a foreign key, and a report that should take 1 query takes 40.

Secrets. The OpenAI key, the Stripe key and the Supabase service key are in the frontend bundle, readable by anyone who opens developer tools.

Nothing is tested. Zero tests, so every change is a coin flip. This is why the tool broke 3 features when you asked for 1.

The security problem is documented, not hypothetical

In 2025, a researcher disclosed CVE-2025-48757. Across 170+ apps generated with Lovable, 303 database endpoints were readable by anyone holding the app's public anon key, because Row Level Security had never been enabled on the underlying Supabase tables. Exposed data included emails, API keys and payment details. One writeup put the effort at 15 lines of Python and under an hour.

Nothing was hacked. Nobody bypassed anything. The database was simply set up in a way that answered every question anyone asked it, and the tool that generated the app never wrote the 1 line per table that would have stopped it.

Whatever any single builder does about its defaults, the same pattern shows up in apps from every AI builder, because the builder optimises for the screen working, and RLS does not change what the screen looks like. Supabase ships the anon key in the frontend by design. That is fine, as long as every table has a policy behind it. In a vibe-coded app, most do not.

If you take one thing from this post, take this: before you spend a dollar on a rebuild, open your Supabase dashboard and check whether RLS is on for every table that holds user data. If it is not, fix that today, before anything on the roadmap.

What you keep, and what gets rewritten

Founders arrive assuming the code is worthless and everything starts over. It is usually the opposite. The most expensive parts of a product are the decisions, and the prototype already made them.

You keep the product decisions: which features matter, which ones nobody used, the words that made people sign up. You keep the UI flows, or at least the ones users did not complain about. You usually keep the Supabase project and a good part of the schema, once it is cleaned. You keep the design if it is decent. And you keep the single most valuable thing, which is proof that demand exists. That proof is what makes a $25,000 rebuild a sane decision instead of a gamble.

What gets rewritten is the plumbing. Authentication and roles. The permission layer. The API layer between the screen and the database. Integrations, because the prototype called third-party APIs from the browser. Tests, from zero. Deployment, monitoring and backups. And whatever AI feature you added in a chat box, because it was bolted on with no evaluation, no cost guard and no fallback.

The 3 ways out, and what each costs

Path 1: harden in place, from $5,000, 2 to 3 weeks. Enable RLS on every table with real policies. Fix auth: verification, reset, rate limiting, roles. Move secrets to server functions. Add security headers and basic monitoring. Keep the Lovable frontend as it is. This is the right call when you have under a few hundred users, the schema is sane, and the product itself is still changing weekly. You buy safety and time, not scale.

Path 2: rebuild the backend, keep the front, $15,000 to $25,000, 6 to 8 weeks. New API layer, cleaned data model, proper permissions, integrations moved server-side, tests, CI and monitoring. The frontend is kept and cleaned up rather than rebuilt. This fits when the product works and users like it, but the plumbing cannot be trusted with money or personal data.

Path 3: full production rebuild, $25,000 to $35,000, 8 to 10 weeks. Same product decisions, new stack, UX fixes from what real users showed you, AI features designed into the architecture instead of added in a chat box. This is for the founder who is charging money, growing, and has learned enough from the prototype to know exactly what version 2 should be. It is also the path where the 6-week MVP process applies almost unchanged.

Those are our fixed prices for this work, not estimates, and they come with full IP transfer. The pricing page has the detail on what is included at each level.

How a 6-week rebuild actually runs

Weeks 1 and 2 are the audit and the architecture. We read the prototype, export the data, list every table and every place a secret lives, and interview 5 to 10 of your users about what confused them. The data model and the permission rules get designed here, with the person who will build them in the room. Skipping these 2 weeks is where rework comes from.

Weeks 2 to 3 fix the UX problems your users already reported, then lock down auth, RLS and permissions.

Weeks 3 to 5 rebuild the core workflows on the new API layer, with tests written alongside, and wire in the AI features and integrations properly, server-side, with cost guards and a fallback when the model is unsure.

Week 6 is migration, launch and the start of 30 days of fixes. Your users log in to the new version with the same account and the same data. Most never notice anything changed except that things stopped breaking.

The architecture decisions that decide whether an MVP scales are all made in the first 2 weeks. That is the part the AI builder skipped, and it is the part you are really paying for.

When you should not rebuild yet

If you have no paying users and no waitlist, stay on the prototype. Harden the security in a weekend, keep shipping, and come back when someone is asking to pay. A production rebuild of a product nobody wants is the most expensive way to find out nobody wants it.

If people are leaving because the product does not solve their problem, code will not fix that. Talk to the ones who left first.

And if the tool still lets you ship what your users ask for, and your data is locked down, you are fine. The wall is real, but you have not hit it until you have hit it.

When you do, the full product build page describes exactly what we do, and the MVP development cost post covers how we price a build from scratch, which is the comparison you should have in front of you before choosing a path.