# From Lovable prototype to production: a case study

Source: https://www.plutonapps.com/resources/lovable-prototype-to-production-case-study

Published 2026-10-02. By Plutonapps Engineering.

A founder shaped Looph in Lovable. Our engineers made it hold in production. Here is what we checked first, what we changed, in what order, and what it would take to repeat.

As of 2 October 2026, our clearest example of a Lovable prototype reaching production is Looph, customer-feedback software its founder shaped in Lovable. Our engineers took over everything underneath it on 4 August 2026. By 29 September 2026, after 28 working days with engineering commits, it was live in production with row-level security on all 172 database tables and 10,387 automated tests passing in CI, up from 1,152 at handover. The work covered the hosting, the database security, the email pipeline, the release process and the gates that prove a change is safe.

This article is the method behind that result: what we checked first, what we changed and in what order, and what you would need to repeat it. The results themselves are on the [Looph case study](https://www.plutonapps.com/work/looph). Every Looph figure here is as that page states it. Platform facts come from vendor documentation checked on 2 October 2026, listed under Sources.

## What did the Lovable prototype look like at handover?

It was a working product, not a mockup. The founder had built public boards where customers post, vote and comment, a roadmap and a changelog. There was also a rewards engine with points, badges and bounties, automations, integrations, a Chrome extension, a Zapier app and an operator area for running the platform.

The screens were not the problem. Four things underneath were:

- Nothing could be verified. Type checking had never run, lint reported 19,849 problems, and two tests failed on code nobody had touched.
- No email had ever reached a customer, in a product whose whole promise is that people hear back.
- The operator console, which can see every customer's workspace, sat inside the customer app.
- The browser talked to the database directly, so every permission had to hold in the database itself.

The prototype also ran on Lovable's own hosting, compiled for Cloudflare Workers. It had no container, no health check and no second copy to try a change on before customers saw it.

## What did we do first?

We measured before we changed anything. The first job on an inherited AI-built app is to find out what can be trusted. That means asking four questions. Does it build? Does it type-check? Do the tests pass? Who can read which table? Until those answers exist, no change is safe, because nobody can tell whether it broke something.

On Looph, the answers were the baseline above: 1,152 tests, 19,849 lint problems, no type checking and two failing tests. We recorded those numbers as they were. We did not try to fix them all at once.

Ownership belongs in the same first step: the code, the database and every service account in your company's name. Lovable can sync a project to GitHub in both directions, on one branch at a time. Its documentation also says it can export to GitHub but cannot import an existing repository. So a founder can keep prompting in Lovable while engineers work in the repository, as long as both sides agree who edits which branch.

## How do you make an AI-built codebase safe to change?

Turn the baseline into gates. On Looph, every gate now runs in CI against the recorded baseline, and a count that goes up fails the build. Old debt is tolerated; new debt is refused. An architecture check also fails the build when one layer reaches into another.

This is the step that makes everything after it possible. With 19,849 lint problems, a real new problem is invisible. With a baseline that may only go down, every new problem is caught on the change that introduced it. Tests can then grow with each change instead of waiting for a separate project. Our guide on [how to test an AI-built app](https://www.plutonapps.com/resources/how-to-test-an-ai-built-app) covers which tests to write first.

## How did we secure the data?

In the database, not in the screens. Looph's browser talks to the database with the signed-in person's token. A permission checked only in the interface is no permission at all, because anyone can call the database without the interface.

Supabase's documentation is direct about this. It says to enable row-level security on every table in an exposed schema. It also warns that a table without it is readable and writable by any role with a grant on it.

On Looph, row-level security is now on for all 172 public tables, with 1,180 policies. They decide what a browser, an API key, an AI agent or an anonymous visitor may read or write. One database function answers every permission question for every caller, so there is no second copy of the rules to drift.

Rules like these need their own tests. Looph has 110 pgTAP suites, tests that run inside a real database, beside 253 migrations. Supabase supports pgTAP as its database test runner. We also found three privileged functions that any signed-in user could call. We closed them and checked production before and after. Our [Supabase RLS policy examples](https://www.plutonapps.com/resources/supabase-rls-policy-examples) show the patterns and how to test each one.

## How did the app move off Lovable's hosting?

To a platform of its own, with a second copy. Looph now builds into a Node server in Docker. Its health check proves the database answers, not only that the process is up. Production has run on DigitalOcean App Platform since 16 September 2026, from its own release branch.

Staging is a full second copy, with its own database and test-mode payments, sign-in and email. Database migrations never ride along with a deploy. They are applied by a separate, deliberate step, so a code release cannot quietly change the data.

Custom domains came next. Every workspace gets its own subdomain, and customers can serve their board on their own domain through Looph's own edge. Only a domain that has passed its DNS check resolves at all. On it, people stay signed in through a first-party session that uses a single-use, sixty-second handoff code. This went live on 17 September 2026.

## What else had to change before customers relied on it?

The parts that make the product's promise true. For Looph, that promise is that whoever asked hears when it ships. When we measured the email pipeline, 23 notifications pointed at templates that did not exist, and no invitation had ever reached anyone.

- Notifications: one typed pipeline now carries 63 events to five channels: in-app, email, push, Slack and webhook. Each has its own preference check and idempotency key.
- Email speed: on staging, one email takes a median of 6 seconds end to end, down from about 100. A burst of 100 was accepted in 3.1 seconds.
- Operator console: rebuilt as a separate app on its own host, importing nothing from the product. Operators hold one of three roles, and nobody can remove their own access or the last super-admin's.
- AI agents: an MCP server, a separate app with its own OAuth sign-in and consent screen. It mints a sixty-second database token per request for the person who connected it, so their own row-level security decides every row. It offers 28 tools and went live on 29 September 2026.

The Model Context Protocol's authorization specification is based on a draft of OAuth 2.1, and it treats authorization as optional. Looph's server requires its own sign-in anyway, because an agent must never do more than the person who connected it.

## What did we leave in Lovable?

The product design. Looph's founder shaped the product in Lovable, and the case study quotes Looph on how the work runs now: "We prompt a version on Monday and their engineers have the same thing on staging for our test users by Thursday."

What moved to engineering was everything a customer never sees but always depends on: hosting, access rules, releases, email delivery and the gates. That split is the point. A Lovable prototype is a fast way to decide what to build. Production is the work of making it hold.

## What does the case study not claim?

We publish only what we can show. The Looph case study states no load or stress figure, no uptime figure, no compliance badge and no customer counts. If you read another prototype-to-production story, check which of those it claims and what evidence it gives. Our article on [what production-ready means](https://www.plutonapps.com/resources/what-does-production-ready-mean) lists the questions worth asking.

## What would it take to repeat this with your prototype?

The same order of work, adjusted to your app:

1. **Take ownership** Code in a GitHub organization you own, the database in your own account, and every service registered to your company.
2. **Measure the baseline** Build, type check, tests, lint and who can read which table. Write the numbers down.
3. **Gate the baseline** Make CI fail when any count gets worse, so new debt stops at once.
4. **Move access rules into the database** Row-level security on every exposed table, with tests that run inside a real database.
5. **Give it a real platform** Your own hosting, a health check, a staging copy, and migrations applied separately from deploys.
6. **Fix the promise** Whatever the product must always do, such as email arriving, measure it and make it hold.

Looph took 28 working days with engineering commits, between 4 August and 29 September 2026. Your app will differ in size and in what it promises, so treat that as one data point, not a quote. Looph did this on our Starter plan, priced below. The step-by-step version is in our guide to [taking a Lovable app to production](https://www.plutonapps.com/guides/lovable-app-to-production).

> **The same path for your prototype** You keep prompting in Lovable, and our engineers turn each version into the live product. Looph runs on the Starter plan: every change code-reviewed, security checks on every change, and 2 production deployments a week.

Starter is $2,999 a month paid annually, or $3,999 month to month; Growth is custom. See [pricing](https://www.plutonapps.com/pricing). To see how far your app is from production first, take the free [production-readiness check](https://www.plutonapps.com/tools/production-readiness-check): 19 questions, a score out of 100 and your three biggest risks.

## Sources

Platform facts were checked on 2 October 2026. Looph facts are as our case study states them.

- Lovable documentation: GitHub integration, on two-way sync, one active branch and export-only (docs.lovable.dev/integrations/github).
- Supabase documentation: Row Level Security, on enabling it for every table in an exposed schema (supabase.com/docs/guides/database/postgres/row-level-security).
- Supabase documentation: Testing your database, on pgTAP and supabase test db (supabase.com/docs/guides/database/testing).
- Model Context Protocol specification, current version 2026-07-28: Authorization, on the OAuth 2.1 draft and authorization being optional (modelcontextprotocol.io/specification/2026-07-28/basic/authorization).
- Case-study facts: our Looph case study, as published on this site on 30 September 2026 (plutonapps.com/work/looph).

## Frequently asked questions

### Can a Lovable prototype become a production app?

Yes. Looph was shaped in Lovable and went live in production in September 2026. Its founder designed the product in Lovable; our engineers rebuilt everything underneath it, including the hosting, database security, notifications and release process.

### How long does it take to take a Lovable app to production?

It depends on the app. Looph took 28 working days with engineering commits, between 4 August and 29 September 2026. A smaller app with fewer promises may take less; one with payments, many roles or AI agents may take more.

### Do I have to stop using Lovable?

No. Lovable syncs with GitHub on one branch at a time, so you can keep designing in Lovable while engineers work in the repository. Agree who edits which branch, and merge engineering work through reviewed pull requests.

### What is the first thing engineers check in an AI-built app?

Whether it can be verified: does it build, does it type-check, do the tests pass, what does lint report, and who can read which table. Those numbers become the baseline every later change is measured against.

### Is row-level security enough to secure a Supabase app?

It is the foundation when the browser talks to the database directly, but it needs tests. Looph pairs 1,180 policies with 110 database test suites, and three privileged functions that any signed-in user could call still had to be found and closed.