Taking Over a Lovable App for Production: What Breaks First, What We Keep, What It Costs (2026)

A Lovable app with paying users usually breaks in one of five places before it breaks anywhere else: row-level security that was never turned on, secrets sitting in the browser, authentication that the UI enforces but the database does not, a schema that the AI generated for the demo rather than for the data, and no tests, so every new prompt risks the last working feature. A production takeover fixes those five, keeps the parts that already work (your Supabase schema and most of the UI), and rebuilds only the parts that cannot be trusted. At KUMO that is a fixed-scope engagement of $20,000 to $50,000 over 8 to 12 weeks for one product; $50,000 to $100,000 when the app has several integrations, payments and a customer or partner portal. Most founders who ask for a takeover do not need a rebuild; they need the 12 checks below, in order.

Key facts (updated 20 October 2026; Lovable product details read 2 October 2026 from lovable.dev and docs.lovable.dev)

• Lovable can host production apps and states SOC 2 Type 2 and ISO 27001 for its infrastructure; production readiness is a property of your app, not of the tool
• The five failures that reach users first: missing row-level security, secrets in the browser, auth enforced only in the UI, demo-shaped schema, no tests
• A takeover keeps the Supabase schema and most of the UI; it rebuilds the data rules, the auth boundary, the integrations and the deploy pipeline
• Cost: $20,000 to $50,000 for one product (the smallest takeovers from $15,000); $50,000 to $100,000 with several integrations, payments or a portal; 8 to 12 weeks; ongoing engineering $5,000 to $10,000 per month if you have no engineers
• First step: send three lines (what the app does, what is breaking, how many users) and get a scoped estimate in two working days

Who this is for

A founder or owner who built the first version in Lovable (or Bolt, Replit or v0 with the same pattern: generated React front end, Supabase or a similar backend, deployed from the builder) and now has users, revenue or a signed customer, and one of these sentences is true: a customer saw data that was not theirs; a feature that worked last week stopped after a new prompt; the bill from the backend jumped; a bigger customer asked for SSO, an audit log or a security questionnaire; or an investor or acquirer asked who owns and maintains the code. You do not need an engineer on staff to read this; you need to know which of three jobs you are buying.

What breaks first in a Lovable app, in the order we see it

1. Row-level security is off or wrong. Supabase tables are readable by any logged-in user unless RLS policies say otherwise. AI builders get the app working before they get the policies right, so the most common first incident is one customer seeing another customer's rows. The fix is a policy per table, tested with a second account, before anything else.

2. Secrets in the browser. API keys for payments, email or AI models pasted into front-end code ship to every visitor. Anyone can read them. The fix is moving every call that needs a secret behind a server function and rotating the keys.

3. Authentication enforced by the screen, not the data. The UI hides the admin page; the API still answers. Fix: enforce roles at the database and the server, and treat the UI as decoration.

4. A demo-shaped schema. Tables built to make the first screen work: text fields where there should be relations, no constraints, no indexes, money stored as floats. Works at 20 users, slows at 2,000, corrupts at the first concurrent edit. Fix: a migration plan, not a rewrite; most schemas survive with constraints, indexes and two or three new tables.

5. No tests, so every prompt is a gamble. The reason "it worked yesterday" happens. Fix: a small test suite on the flows that make money (sign up, pay, the core job), run on every change, and a deploy pipeline outside the builder so a bad change can be rolled back.

After those five: integrations that were mocked (the CRM sync that only pretends), background jobs that run on a page load, file uploads with no size or type limits, and costs (the AI model called on every keystroke).

The three jobs hidden behind "take over my app"

The honest order for most founders: hardening first, because it is cheaper and it tells you whether the other two are needed. We say so in the estimate when it is true.

What we keep and what we rebuild

Kept: the product itself (you validated it; that is the valuable part), the Supabase project and most of its schema, the UI components and copy, the hosting if it fits. Rebuilt: the data rules and policies, the authentication and authorisation boundary, every integration that was mocked or client-side, the deploy pipeline and environments, the tests, and any screen whose generated code is slower to fix than to replace. Written down in the first week as a keep-and-rebuild list you can show anyone.

What it costs, and what sits on top

Included in the band: the readiness review on your real app, the keep-and-rebuild list, the work, tests on real flows, monitoring, a runbook, and the handover of code, infrastructure access and documentation to you. On top: your hosting and backend bills (Lovable's 100-credit Pro tier covers about 200 small edits a month by Lovable's own examples, read 2 October 2026; Supabase and model usage are billed by those vendors), and ongoing engineering at $5,000 to $10,000 per month if nobody in-house owns the code after launch. Companies that keep shipping without engineers keep KUMO on that retainer; companies that hire get a clean handover and leave.

The 12 checks that decide whether you need any of this

Run these before you talk to anyone, including us. Each takes minutes with a second test account.

1. Log in as user B and try to open user A's record by changing the id in the URL.
2. View the page source in production and search for "key", "secret" and "sk_".
3. Call the API route for an admin action while logged in as a normal user.
4. Count the tables; find a money or quantity column stored as text or float.
5. Create two records with the same unique value (email, order number) and see if it lets you.
6. Change something in Lovable and check whether the last feature still works without you testing it by hand.
7. Find where the CRM, email or payment sync happens; confirm it is a server function, not a browser call.
8. Upload a 200 MB file and a .exe to any upload field.
9. Open the backend billing page and look at the last 30 days of model and database cost against user growth.
10. Ask for the audit log of who changed a customer's record; see if one exists.
11. Check whether you can deploy a previous version in under ten minutes.
12. Confirm the repository, the Supabase project and the domain are in an account you control.

Three or more failures: hardening. Six or more, or a failure on 1, 2 or 3 with real customer data: a takeover. A rebuild is only on the table when the answer to "can this data model carry the next customer" is no.

Proof, labelled

KUMO has not published a Lovable takeover case study yet, so the proof here is adjacent and specific to production builds: FLIN is a mobile credit app built for regulated workflows (KYC, credit-bureau integration) from scoped brief to launch; Equipp is a production rental platform with auditable ledgers; CampaignHQ is KUMO's own product, in production since 2022, which is where our deploy, test and monitoring patterns run first. KUMO's founders built Volopay's first production version as its founding engineers, a finance product where every approval and every payment had to be traceable. KUMO is a software engineering studio that builds custom AI agents, workflow apps and portals for 10 to 100 person companies, and a Registered Partner in the OpenAI Partner Network.

Questions founders ask

Can a Lovable app be used in production? Yes, if the app passes the checks above; the platform states SOC 2 Type 2 and ISO 27001 for its infrastructure. The risk is in the generated app, not the host: RLS, secrets, auth at the data layer, schema and tests.

How much does it cost to take over a Lovable app and make it production ready? $15,000 to $30,000 for hardening, $20,000 to $50,000 for a full takeover with handover, $50,000 to $100,000 if the core has to be rebuilt for multi-tenant, payments at volume or a portal. The estimate says which one you need and why.

Do we have to leave Lovable? No for hardening; you can keep editing in Lovable with tests and a deploy pipeline around it. A takeover moves the code to a repository you own and Lovable becomes optional. A rebuild replaces the generated core.

How long does a takeover take? 8 to 12 weeks for one product; the first two weeks produce the readiness report and the keep-and-rebuild list, which you own whether or not you continue.

Who owns the code after? You do: repository, infrastructure accounts, documentation and runbook are transferred at handover; there is no licence or lock-in.

What should I send to get a scoped estimate? Three lines: what the app does, what is breaking or what a customer is asking for, and how many users and transactions a month. Read-only access to the repository and the backend lets us give a tighter number, but the first estimate does not need it.

Send those three lines to get a scoped estimate in two working days, see how KUMO handles vibe-coded apps to production and Lovable projects, compare agencies in best agencies to take over a Lovable project, or book a 30-minute call.