# Apps built with Lovable that run in production

Source: https://www.plutonapps.com/resources/apps-built-with-lovable

Published 2026-10-02. By Plutonapps Engineering.

Lists of Lovable apps mix weekend demos with running businesses. Here are real examples, sourced and dated, and what separates a Lovable build from a product in production.

As of 2 October 2026, real apps built with Lovable do run in production, but most public examples are internal tools and early products. In our own work, every product that holds customer data or takes payments needed engineering after the Lovable build. Lovable's own customer pages show companies replacing paid software with apps they built themselves. Our own work shows the other half: what a Lovable-designed product needed before it could be trusted with users.

This page separates the two. It sets out what "in production" should mean, shows our four products that began with Lovable work, with their status stated plainly, lists public examples with the source for each, and ends with the patterns: what each app needed after Lovable.

## What does "in production" mean for a Lovable app?

A demo that loads is not a product in production. For this page, an app counts as in production when real people outside the team who built it rely on it, and it meets five tests. Our glossary entry on [what production-ready means](https://www.plutonapps.com/resources/what-does-production-ready-mean) covers the idea in more depth.

| Test | What it means | Why it matters |
| --- | --- | --- |
| Real users | People outside the build team use it with their own data | A demo has no data to lose |
| Access rules | Each user sees only their own records, enforced by the database | One missing rule exposes everyone |
| Money and messages | Payments, emails and alerts happen once, and failures are caught | A double charge or lost email reaches a customer |
| Tests | Automated tests run on every change | Each new prompt can break an old feature |
| Ownership and hosting | The code, data and accounts belong to the business, with a way back from a bad release | Someone has to fix it at 2 a.m. |

Most lists of Lovable apps skip these tests. They mix weekend demos, landing pages and running businesses. That is fine for inspiration, but it does not tell a founder whether their own app can carry customers.

## Which of our Lovable-based products are live?

Four of our case studies began with the founder's work in Lovable: three products designed there, and one public site built there. One is in production today. Three are pre-launch. We say so on each case study, and we say so here.

Looph is customer-feedback software: public boards where customers post and vote on ideas, a roadmap, and a changelog that tells every voter when their request ships. The founder shaped it in Lovable as a working product. From 4 August 2026 our engineers rebuilt everything underneath it, over 28 working days with engineering commits. Row-level security now covers all 172 database tables with 1,180 policies, and 10,387 automated tests passed in CI on 29 September 2026, up from 1,152 at handover. It runs in production on DigitalOcean App Platform. Read the [Looph case study](https://www.plutonapps.com/work/looph).

Bell is an AI email assistant for Gmail users. The founder built a full proof of concept in Lovable, with 51 pages, 151 backend functions and 143 database tables, then used its screens as the specification. Our engineers built the system underneath in 27 working days: exactly-once sending with a two-minute undo, daily limits on AI spend, and more than 13,000 automated tests. Bell is pre-launch and runs on staging. Read the [Bell case study](https://www.plutonapps.com/work/bell).

Ekko is a viral waitlist platform with real rewards. The founder designed both halves in Lovable on our Starter plan, and our engineers built the system underneath in 36 working days. Stress-tested with 25,000 synthetic waitlist entries, it sent zero duplicate rewards. Ekko is pre-launch. Read the [Ekko case study](https://www.plutonapps.com/work/ekko).

Inkwave is a newsletter and publishing platform. Here only the public site came from Lovable: a landing page, pricing and twenty feature pages, each a promise the product had to keep. Our engineers built the platform behind it with the founder's team: 14 apps and packages, guarded by 2,978 automated tests. Inkwave is pre-launch and deploys to staging on every merge. Read the [Inkwave case study](https://www.plutonapps.com/work/inkwave).

A fifth case study, Zulu, began from a client prototype, but its page does not say which tool built it, so we leave it out of this list.

## What are public examples of apps built with Lovable?

These come from Lovable's own pages, opened on 2 October 2026. The figures are the companies' and Lovable's claims, not ours, and we could not check them independently.

| App | Who built it | What it does | What the source says |
| --- | --- | --- | --- |
| Custom CRM | Atonom | Leads, pipeline, revenue tracking and sales dashboards | Replaced a $40,000-a-year Salesforce contract; the CRM now costs about $1,200 a year, hosting included; first prototype in 3 hours |
| Dialed, Estimator and an event hub | O3 World | Resource planning, project estimates and conference management | Dialed replaced a resource-planning tool and saves about $35,000 a year and an estimated 5 to 10 hours a week |
| Country sites and The Hub | eXp Realty | A CMS for 26 country sites and a community platform for 83,000 agents | More than $2 million a year saved across its projects |
| Plinq | Sabrine | An app against gender-based violence in Brazil | More than 10,000 users in 3 months |
| Lumoo | Henrik and Peter | An AI fashion platform | EUR 700,000 in annual recurring revenue in 9 months |

Three things stand out. First, most of the detailed stories are internal tools: a CRM, planning tools, a hub for a company's own agents. An internal tool has a known set of users and usually sits behind a company sign-in, so it carries less risk than a public product. eXp's country sites are the main public-facing exception. Second, the companies with the biggest stories already had technical people. O3 World is a digital product consultancy, and its page says its own technical expertise and security practices support apps as they become business-critical. eXp's page says some HR tools run in separate Lovable and Supabase environments to meet compliance requirements. Third, the two examples from Lovable's blog, Plinq and Lumoo, report users and revenue, but not how they handle access rules, payments or testing. That does not mean those apps lack them. It means the public record does not say.

For a wider browse, Made with Lovable (madewithlovable.com) is a community directory with its own site, separate from Lovable's, listing more than 530 projects as of 2 October 2026. It says it uses automated checks that each project was built with Lovable, and it offers a paid option for more exposure. It does not say it checks users or revenue. Of the categories its home page counts, tools and utilities is the biggest, at 163 projects.

## What did each app need after Lovable?

Across our four products the same jobs came up, in roughly the same order. None of them were about the screens. In each one, the founder's Lovable work set what the product had to do.

1. **Make the code checkable** Looph arrived with type checking that had never run and nearly 20,000 lint problems. Nothing else is safe until a change can be verified.
2. **Lock down the data** Bell's prototype let the browser query the database directly, and the review of its row-level security rules covered about 12 of its 143 tables. Looph now has row-level security on all 172 tables, and Bell's browser no longer touches the database at all.
3. **Make money and messages happen once** Bell sends each email exactly once through a ledger. Ekko's rewards are worth real money, and its stress test sent zero duplicates. Inkwave records each batch of a newsletter send as done exactly once, so a retry never re-sends.
4. **Make email actually arrive** In Looph's prototype no email had ever reached a customer. Its median delivery on staging is now 6 seconds, down from about 100.
5. **Separate the operator tools** Looph's console, which can see every customer, sat inside the customer app. It now runs as its own app.
6. **Put tests behind every change** Looph went from 1,152 tests to 10,387. Bell has more than 13,000, Inkwave 2,978.
7. **Give the app a real home and a second copy** Looph's prototype ran on Lovable's hosting with no second copy to try a change on. It moved to DigitalOcean App Platform on 16 September 2026, with a full staging copy.

Our [guide to taking a Lovable app to production](https://www.plutonapps.com/guides/lovable-app-to-production) walks through these steps in order, so you can check your own app against them.

## Is Lovable good enough to build a real business on?

Yes, as a way to design and prove the product. Every example on this page used it, and in our four the founder's Lovable work set what the engineers built. The public examples show that companies already run real work on Lovable-built tools.

The line falls at risk, not at size. An internal tool used by a known team can often run as Lovable built it. A public product that holds other people's data, takes their money or sends messages in their name needs the work in the steps above. The more users and money involved, the earlier that work should start.

## How do you get your own Lovable app into production?

1. Write down who will use it, what data it holds and whether it takes payments. That sets how much engineering it needs.
2. Check where your access rules live. If the browser talks to the database, every table needs a rule.
3. List every action that must happen exactly once: charges, refunds, emails, rewards.
4. Make sure you own the GitHub repository, the database project and every account.
5. Decide who reviews and tests each change before it reaches users.

> **Your app as the next production example** You keep prompting in Lovable, and our Product Owner and engineers turn each version into the live product. Every change is reviewed by an engineer other than its author, security-checked and tested before release, and the code, data and infrastructure belong to you from the start.

Starter costs $2,999 a month paid annually or $3,999 month to month, and Growth is custom; see [pricing](https://www.plutonapps.com/pricing). To see where your app stands 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

Each external fact above comes from one of these pages, checked on 2 October 2026.

- Lovable: Customer stories (lovable.dev/customers).
- Lovable: Atonom customer story (lovable.dev/customers/atonom).
- Lovable: O3 World customer story (lovable.dev/customers/o3world).
- Lovable: eXp Realty customer story (lovable.dev/customers/exprealty).
- Lovable blog: One year of Lovable, published 18 November 2025 (lovable.dev/blog/one-year-of-lovable).
- Made with Lovable: project directory home page (madewithlovable.com).
- Case-study facts: our Looph, Bell, Ekko and Inkwave case studies, as published on this site.

## Frequently asked questions

### What apps have been built with Lovable?

Lovable's customer pages list internal tools such as Atonom's CRM, O3 World's planning tools and eXp Realty's country sites, and its blog names products such as Plinq and Lumoo. Our own Lovable-designed products include Looph, which is in production, and Bell, Ekko and Inkwave, which are pre-launch.

### Can a Lovable app handle real users and payments?

It can, once the work behind the screens is done: access rules enforced by the database, payments and emails that happen exactly once, automated tests on every change, and hosting the business controls. Lovable gives you the design and a first build; production needs those checks too.

### Are Lovable apps mostly internal tools?

Most of the detailed public examples are. Internal tools have a known group of users, usually behind a company sign-in, so they carry less risk than a public product that holds strangers' data.

### Do I have to rebuild my Lovable app to launch it?

Usually not the screens. In our case studies the founder's Lovable work set what the product had to do, and engineers built or rebuilt what sat underneath it, such as data access, email, payments and hosting.

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

It depends on what the app does. In our case studies the engineering took between 27 and 36 working days for Bell, Looph and Ekko, and only Looph is in production so far.