Taking over an MVP built with Lovable or Bolt: audit, decision, checklist

What do Lovable and Bolt actually generate?

Both tools turn instructions written in plain language into a working web app. What they produce is standard code that you can take out of the platform, which is what makes a takeover possible.

Lovable generates a React app. According to its documentation, projects created since May 13, 2026 run on TanStack Start with server-side rendering; older ones use React and Vite and render in the browser. Data lives in PostgreSQL, either through the built-in backend (Lovable Cloud: managed database, user login, file storage) or through your own Supabase project. The code syncs with a GitHub, GitLab or Bitbucket repository, and paid plans let you download it as an archive.

Bolt.new sticks to JavaScript web technologies: a front-end framework that runs in the browser, Node.js on the server, Expo for mobile. PHP and Python aren't supported (Bolt documentation). New projects use a Bolt database by default, which Supabase can replace. A GitHub connection backs up the project with its full history and lets you keep working outside Bolt.

So you're not starting from a black box: any JavaScript or TypeScript developer can read this code. What remains to be seen is the state it's in.

Where do these MVPs struggle in production?

These tools are very fast at producing a screen and a user flow. We code with AI assistants every day ourselves, and the pattern repeats: the code comes fast, the review still has to happen. Trouble starts when real data and the first payments arrive. Here is what to look at first.

Data access rules

The most serious risk in an AI-generated MVP rarely sits in the visible code. It hides in the database configuration. In a Supabase setup, the web app often queries the database directly, with a public key present in every visitor's browser. What protects the data then are row-level security rules (RLS). Supabase’s documentation is blunt about it: a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Lovable itself writes, on its security page, that misconfigured RLS rules are a common cause of data leaks. The basic test is simple: create two accounts, try to read one account's data from the other, then try again while logged out.

Secrets and checks done in the browser

A payment, email or AI API key placed in the front-end code can be read by any visitor. Removing it from the code isn't enough: an exposed key must be revoked and regenerated. The same goes for checks: a price, a quota or a permission check computed in the browser can be bypassed with the developer tools. They have to run on the server, in a server function or an API.

Tests and code structure

A single prompt can change several files at once. Without automated tests, nobody knows what broke elsewhere. Request after request, the code thickens: components several hundred lines long, logic copied in three places, dependencies added and then forgotten. The app works, but each change costs a bit more than the last.

Performance and accounts

A list without pagination or a query re-run on every screen goes unnoticed with twenty rows in the database. With twenty thousand, the app crawls. One last point that often gets missed: who owns the database, the hosting, the domain and the email-sending account? The day you want to change tool or provider, the answer will matter.

Keep, consolidate or rewrite: how do you decide?

Taking over an MVP built with Lovable or Bolt leads to one of three decisions. Keeping means holding on to the code and fixing a few specific points: that works when the data is properly protected, the code is still readable and the product serves few users. Consolidating means keeping the validated interface and flows, then reworking what won't hold up in production: access rules, server-side logic, tests, structure, deployment. It's often the right trade-off for a prototype that has found its first users. Rewriting means starting from a clean base and using the prototype as a clickable spec. You choose it when the data model doesn't match the business, when the logic is scattered across the front end, or when the product needs things the generated stack handles poorly: offline mobile, strict compliance, heavy integrations. If you start over, plan for a regular MVP development timeline.

In all three cases, the prototype has already done its job: it validated a flow with real users.

How many days should you plan for a takeover?

It all depends on the state of the code, which is exactly what the audit measures. To get a rough idea in the meantime, here are orders of magnitude based on a senior day rate of €500 to €700, a common benchmark for an experienced freelance developer in France.

• Takeover audit: 3 to 5 days, roughly €1,500 to €3,500.
• Targeted fixes, if you keep the code: 3 to 10 days, i.e. €1,500 to €7,000.
• Consolidation: 10 to 40 days depending on how much needs reworking, i.e. €5,000 to €28,000.
• Rewrite: the budget of a new MVP. Market benchmarks range from €20,000 to €60,000 depending on the product type (details in how much an MVP costs), roughly 30 to 120 days.

These figures aren't a quote. They assume an MVP scope: a platform with several roles, payments and integrations falls outside them.

How does an audit of a Lovable or Bolt project work?

It starts with access: the Git repository, read access to the database and the list of accounts (platform, hosting, domain, payments). A non-disclosure agreement can be signed before anything is opened.

We then read the code and run it outside the platform, from the repository. We test the access rules with several accounts, look for secrets in the code and in the Git history, and list the dependencies and their known vulnerabilities. The data model gets the most attention: it's usually what tips the balance between consolidating and rewriting.

We present the findings in a live session. You get a report that ranks each issue by impact and effort, with a recommendation and a cost estimate. It's the format of our code audit: your team can carry out the plan on its own, with or without us.

Which checklist should you follow before going live?

Tick these off before opening the product to more people. If several lines are still empty, consolidation isn't finished.

1. The code lives in a Git repository owned by the company, not on a partner's or freelancer's personal account.
2. The company owns the accounts: platform, database, domain, transactional email, payments.
3. The project builds and starts outside the tool, from the repository, with a written procedure.
4. RLS is enabled on every exposed table and tested with a second account, then with no account.
5. No secrets in the front-end code or the Git history; keys that were already exposed have been revoked and regenerated.
6. Checks that commit the business (permissions, prices, quotas) run on the server.
7. Automated tests cover the critical flows: sign-up, login, payment, main action.
8. A staging environment exists, with its own database, separate from production.
9. Database backups are on, and a restore has already been tried.
10. Errors and response times are monitored, with an alert when something breaks.
11. Dependencies are up to date, with no known vulnerabilities.
12. Personal data is mapped for GDPR: where it's stored, who can access it, how long it's kept.

Should you stop using Lovable or Bolt?

No. To test an idea or show a flow to users and a first investor, these tools save weeks. The risk comes from drift: a prototype that takes in real customers without anyone having reviewed what it does with their data. Lovable says as much in its documentation: you remain responsible for your app's security, and a professional security review is recommended as soon as it handles sensitive data.

And at Neodev?

We audit and take over existing applications to bring them to production, and we build custom MVPs when starting from a clean base makes more sense. Whether you want to have your MVP built from your prototype or consolidate the one you have, we start with a short audit. If your application is already a few years old, our progressive rebuild approach applies too. To choose between improving and replacing, read rebuild or refactor; if the code can't be saved, look at the cost of a rebuild before deciding.

Tell us about your project: we reply within 24h, a detailed quote follows within 48h, and the code stays yours.