Finishing a stalled Lovable app

More than most builders. Lovable writes a React front end with Tailwind, and a Supabase backend for the database, login, file storage and server functions. It syncs the whole project to a GitHub repository, two ways: edits in Lovable land in the repository, and changes pushed to the repository flow back into Lovable. That matters, because it means the app can leave the tool without leaving the tool behind.

Since July 2026 Lovable has also had explicit Export, Pause and Remove controls in the project settings, so getting the code out is a supported route rather than a workaround.

So if your Lovable app has stalled, you're not starting again. You're finishing.

The backend, by default. Many Lovable apps run on Lovable Cloud, which bundles the database, authentication, storage and functions behind one managed backend. The code is yours, but the data and the users live there, and as of September 2026 there's no one-click move from Lovable Cloud to a Supabase project you own. The official export route resets every user's password. Third-party tools move the tables, users and files without that, and we've read them closely enough to know where they break.

Whether to move off Lovable Cloud is a decision, not a reflex. For an internal tool with six users, staying may be fine. For a customer-facing app with real accounts, owning the database is the first job.

The same list as any AI-built app, with Lovable's particular shape:

• Supabase security rules. The database is reachable from the browser by design. Without row-level security on every table, any logged-in user can read every other user's data, and sometimes a logged-out one can too. This is the most common and most serious finding.
• Secrets in the front end. Keys that should be server-side, sitting in the client bundle.
• Server functions half-built. The edge functions that were going to send the email, take the payment or talk to Xero exist as a stub or a first attempt.
• No transactions, no constraints. A failure halfway through leaves half a record; the same customer exists three times.
• No tests, no staging. Every change was tried on the live app, because that's the only app there was.
• Deployment nobody controls. Hosted by Lovable, with no backup anyone has tested.

Usually finish. The front end is real React, the data model is usually close, and the screens your team has already used are the specification. The work is foundations first (security rules, integrity, tests, a deployment in your accounts), then the unfinished features in order of value.

Rebuild only when the security holes run through the structure or the data model fights every change. Even then the Lovable screens carry across as the design, so it's a short rebuild. The general keep, finish or replace reasoning applies, and the assessment makes the call from the code.

1. Connect GitHub, if it isn't already, so the repository is in your organisation. From this point the code exists outside Lovable.
2. Read the code and the database. Every table's security rules, every function, every secret, every place the app talks to something outside itself. This is the assessment.
3. Decide about Lovable Cloud. Stay, or move the database, users and storage to a Supabase project you own. If moving, the migration is tested on a copy and run in staging with every user and record reconciled before anything switches.
4. Foundations. Security rules on every table. Secrets out of the front end. Constraints and transactions where the data needs them. A test environment and a staging environment. A backup that's been restored.
5. Finish the features, one at a time, each priced before you commit.
6. Keep using Lovable if you want to. With the code in your repository and the foundations in place, Lovable's two-way sync means your team can keep prompting for small changes, and we review what comes back.

It never meets a change until the change has proven itself somewhere else. Any move out of Lovable Cloud is tested against a copy in a test environment, then run in staging alongside the live app with users, records and files reconciled. Only when the tests have shown it's safe does anything connect to live, and the Lovable-hosted version stays available as a fallback until you're confident.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Lovable app it's mostly reading code and testing the parts a demo never exercises, and the report gives a fixed price for finishing. What drives the price and the payment terms each have a page.

Read the code before promising anything. Marc Allington builds with AI tooling daily, so he can tell quickly what a generated codebase has and hasn't got. Everything we finish runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment.