Lovable limitations: what it cannot do, and what to do about it

Lovable's main limit is not what it can draw but what it can prove. As of 2 October 2026, it builds web apps, not native mobile apps. Every prompt draws on credits. Most tests run only when you ask for them. From 5 October 2026, each Lovable Cloud project runs on one database, with no separate test copy. None of this stops you shipping a prototype. It does decide when you need an engineer next to the prompt box.

This guide lists each limit, what it looks like when you hit it, the workaround, and whether you can handle it yourself. Platform facts are from Lovable's own documentation and pricing page as of 2 October 2026, listed under Sources.

What are Lovable's main limitations?

Lovable is an AI app builder: you describe what you want, and it writes and changes the code. That makes it fast at screens and flows, and weaker wherever correctness cannot be seen in the preview. The table maps each limit to its fix.

Load and performance are a separate topic. Our guide to scaling a Lovable app covers what breaks first under traffic.

Why do Lovable credits run out so fast?

Because every attempt is charged, whether it fixes the problem or not. As of 2 October 2026, Lovable's documentation says a Plan mode message costs 1 credit, plus any research Lovable runs while planning. Build mode is priced on the work done, so bigger or multi-step changes cost more. Lovable's own examples run from 0.50 credits to make a button gray to 2.00 credits for a landing page with generated images. Its pricing page puts a similar landing page at 1.70.

On the Free plan you get 5 build credits a day, up to 30 a month. Pro and Business plans get their monthly plan credits plus 5 daily build credits. Daily build credits reset at 00:00 UTC and expire at the end of the day. Unused monthly plan credits roll over while your subscription is active, but they still expire: two months after they are issued on monthly plans, and one month after the annual period ends on annual plans.

The trouble is the fix loop. When a bug sits in the backend, the AI cannot see it in the preview. It tries a change, the preview looks fine, the bug is still there, and you prompt again. Each round costs credits and can change code that was working. Three habits help.

• Use Plan mode first. It never changes your code, so the AI sets out what it will change before anything changes.
• Ask for one small change per prompt, and test it before the next one. The menu under each reply shows what it cost.
• After two failed attempts at the same bug, stop prompting and have someone read the code.

Credits also pay for more than prompts. Lovable's documentation says hosting, the built-in backend and AI features inside your published app all use credits. Each starts with a small monthly grant, which Lovable calls temporary, then draws on your general credits. Cloud usage grows with visitors, stored data and files. A launch can raise your credit use even if you stop editing.

Can Lovable handle complex backend and business logic?

It can write it. It cannot tell you it is right. Lovable apps use Lovable Cloud, which Lovable says is built on Supabase's open-source foundation, or a Supabase project you connect. The AI writes the tables, access rules and edge functions as you prompt. The preview shows the screens, not whether a rule lets one customer read another customer's data, or whether a payment is recorded twice.

We saw this in Bell, an AI email assistant whose founder designed it in Lovable. In the prototype, the review of its row-level security rules covered about 12 of its 143 tables. Its outbox for sending mail was never wired up, and its AI cost breakers had no callers. Each screen looked finished. The gaps were all underneath.

The workaround is a review, not a better prompt. Someone has to read the access rules, the functions that move money or send messages, and the secrets. Our Lovable security checklist lists what to check. If your product takes payments or holds personal data, this is the point where an engineer pays for themselves.

Can you test a Lovable app properly?

Partly. As of 2 October 2026, Lovable's documentation describes browser testing, frontend tests with Vitest and React Testing Library, and edge function tests with Deno's test runner. The same page says most of these run only when you ask for them. The agent may start one while it investigates a problem, but verification does not run silently in the background.

That matters because each prompt can change code you did not mention. A fix today can break checkout tomorrow, and nothing warns you. The workaround is to keep the tests in the code and run all of them on every change, before it goes live. Lovable does not do that on its own today. A developer can set it up through the GitHub sync, so every change Lovable pushes is tested before release.

Does Lovable have a staging environment?

Not with a second database. Lovable's documentation, checked on 2 October 2026, says the beta Test and Live split for Cloud projects is retired on 5 October 2026. From then on, each Cloud project runs on a single database, as new Cloud projects already did. Lovable points to drafts instead. A draft lets you preview app changes before you publish, but it does not come with its own database.

A staging environment is a copy of your app where changes are tried before real users see them. Without one, a change to the database is tested on the live data. For a prototype, that is fine. With paying users, it is how a bad migration deletes real records. The workaround is a second backend that mirrors production, with each change deployed there first. Lovable's documentation says you cannot keep two databases inside Lovable, so this lives outside it. That is an engineering setup, not a setting.

Can Lovable build a mobile app?

Not a native one. Lovable's FAQ says it builds web applications that can be mobile friendly, and does not generate React Native projects. It names two routes to a phone: make the app a Progressive Web App that users add to their home screen, or wrap it with a tool such as Capacitor and submit it to the App Store or Google Play.

A PWA needs no store review and is the cheapest route. A wrapped app reaches the stores, but it has to pass each store's review, and each release becomes a separate build to keep in step with the web app. Push notifications, deep links and in-app payments add work on both sides. Plan that before you promise a store launch.

What about code ownership and moving off Lovable Cloud?

You can take your code with you. Lovable's documentation says you can download the codebase as a zip or sync it to GitHub. The repository is created in the GitHub account or organization you choose, and it is private by default. GitLab and Bitbucket are also supported. The sync works both ways, but on one branch at a time, and you cannot start a Lovable project from code that already exists.

The database is less portable. Lovable's Cloud documentation says you cannot change a project's region once Cloud is enabled, and there is no one-click migration to your own Supabase project. You export the data, connect a Supabase project to a new Lovable project and rebuild the schema there. Our guide to migrating off Lovable Cloud walks through it. Many apps never need to move. Reasons to move include a region Cloud does not offer, wanting the database in your own account, or a buyer's due diligence.

When should you keep Lovable and add engineers?

Usually, keep Lovable. It is a fast way to design and change screens, and your team already knows it. What changes is who is responsible for what Lovable cannot see. Bring engineers in when any of these is true.

• The same bug has survived more than two prompts.
• Real users pay you, or you store their personal data.
• A change has broken something that used to work.
• You need a store release, a staging copy or a region move.
• An investor or a large customer asks how the app is secured and tested.

The split that works: the founder keeps prompting in Lovable, and engineers review each change through GitHub, add tests, fix the backend and release it. We call that the last 30%. It is not a measured share. It is the part that decides whether the product survives real users.

Starter is $2,999 a month paid annually, or $3,999 month to month; Growth is custom. See pricing, or take the free production-readiness check first: 19 questions, a score out of 100 and the three risks to fix first.

Sources

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

• Lovable documentation: Credits and usage (docs.lovable.dev/introduction/credits-and-usage), Plan and Build mode costs, credit examples, daily build credits, rollover and expiry, Cloud and AI usage.
• Lovable pricing page (lovable.dev/pricing), credit examples per task and credit expiry.
• Lovable documentation: FAQ (docs.lovable.dev/introduction/faq), web apps only, PWA and Capacitor, code download, no import of existing code.
• Lovable documentation: Sync your Lovable project with GitHub (docs.lovable.dev/integrations/github), two-way sync, one branch at a time, repository location and visibility, other Git providers.
• Lovable documentation: Lovable Cloud (docs.lovable.dev/features/cloud), Supabase foundation, fixed region, manual migration.
• Lovable documentation: Migration guide: retiring beta Test and Live environments (docs.lovable.dev/features/environments), retirement on 5 October 2026, single database, drafts.
• Lovable documentation: Test and verify your app (docs.lovable.dev/features/testing), test types and when they run.
• Case-study facts: our Bell case study (plutonapps.com/work/bell), as published on this site.