Fixing AI‑built apps
We read your Lovable, Bolt.new, Replit or v0 app and tell you whether to harden, refactor or rebuild.
- £3,500 fixed
- About a week
- Read-only access
Is your vibe-coded app secure?
Quantum Craft's vibe code rescue is a UK service for apps built mostly by prompting an AI app builder such as Lovable, Bolt.new, Replit or v0: senior engineers audit the app for a fixed £3,500, then you choose whether to harden, refactor or rebuild it.
A vibe-coded app is software generated mostly by prompting an AI tool, where nobody has read and taken responsibility for the code that shipped. In Quantum Craft's AI-built app audit, a senior engineer reads the code, the database rules and every path money or personal data takes, and the written report prices each option. Most AI-built apps are worth keeping. The urgent ones handle money, health data or customer records.
Last reviewed
AI app builders are good at screens and the happy path. The trouble starts where nobody prompted: a user who edits a request in the browser, or a card payment that fails halfway. Public research keeps finding the same gaps. What we check first in an AI-built app lists the checks in the order they hurt, and the six faults a green build hides covers what passing tests miss. Check your app in five questions.
In March 2025 a researcher scanned 1,645 apps that Lovable had featured publicly and found 170, about one in ten, whose database access rules were missing or wrong, so user data was left open. It was logged as CVE-2025-48757 (opens in a new tab). The researcher worked for Replit, a Lovable competitor, and Lovable disputes the finding. Missing row-level security is still the first thing we check.
The finding above, drawn to scale: 170 of the 1,645 featured apps scanned in March 2025 had missing or wrong access rules, about one in ten. Lovable disputes the finding. Highlighted: the 170.
Escape (opens in a new tab), a security vendor, scanned more than 5,600 public apps built on vibe-coding platforms in 2025. It found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 cases of exposed personal data, medical records and IBANs among them. Most of the apps were built on Lovable, and the figures are totals, not a rate per app.
- Users can see each other's data
Usual cause: Row-level security missing or too loose, or access checked only in the interface. Usually means: Harden, unless the data model has no real notion of accounts.
- Every fix breaks something else
Usual cause: No tests, and the same rule copied across several screens. Usually means: Refactor, starting with tests around what works today.
- Each feature takes longer than the last
Usual cause: A data model that fights the product. Usually means: Rebuild, keeping the product and the data.
Common symptoms, their usual cause, and what they usually mean
Symptom
Users can see each other's data
- Usual cause
- Row-level security missing or too loose, or access checked only in the interface
- Usually means
- Harden, unless the data model has no real notion of accounts
An API key is visible in the browser
- Usual cause
- Secrets shipped in client code, sometimes the database's service key
- Usually means
- Harden: move it to the server and rotate it
Payments and orders disagree
- Usual cause
- Payment status taken from the browser, not from the payment provider's webhooks
- Usually means
- Harden, or refactor if payment logic is spread across screens
Every fix breaks something else
- Usual cause
- No tests, and the same rule copied across several screens
- Usually means
- Refactor, starting with tests around what works today
The AI bill jumps without warning
- Usual cause
- Model calls made from the browser, with no limit per user
- Usually means
- Harden: move the calls server-side and cap them
Nobody knows if the backups work
- Usual cause
- Backups never restored, or nothing beyond the platform's defaults
- Usually means
- Harden: restore one, and write down how
Nobody can log in to the hosting
- Usual cause
- Accounts held by a freelancer, or inside the builder's workspace
- Usually means
- Fix first: move every account into your name
Each feature takes longer than the last
- Usual cause
- A data model that fights the product
- Usually means
- Rebuild, keeping the product and the data
Scan, audit or penetration test: which does your app need?
A scan, an audit and a penetration test answer different questions, and an app that takes payments or holds health data usually needs more than the scan its builder runs.
Your app and the three checks the table below compares, each looking at it a different way: a scan is software checking for known patterns, an audit is engineers reading the app, and a penetration test is a specialist attacking it while it runs. Highlighted station: the audit, the check we do. Our audit does not include a penetration test.
| Check | What it is | What it finds | What it leaves out |
|---|---|---|---|
| Automated scan | Software tests the app against known patterns: database settings, dependencies with known flaws and exposed keys. Lovable and Bolt.new run their own, and separate scanning services sell the same idea. | Common mistakes and known flaws, quickly. Some builders run a scan on every publish. | Business logic, and anything it has no rule for. Lovable's own documentation says its scans "cannot guarantee complete security". |
| Audit by senior engineers | Senior engineers read the code, the database rules, the hosting set-up and every path money or personal data takes. Ours is a fixed £3,500 and takes about a week. | What needs judgement: access rules that are missing or wrong, business logic that runs only in the browser, payment status taken from the browser instead of the payment provider, and where personal data goes. It ends in a written plan to harden, refactor or rebuild, with the cost of each. | It reads the app but does not attack the live system. It is an engineering review, not legal advice. |
| Penetration test | A specialist tries to break into the running app the way an attacker would, within a scope agreed beforehand. | Whether a weakness can really be used, including ones that only appear when the parts run together. | How the code is built and how it will change: it tests the system as it stands on the day. It is most useful once the gaps an audit finds are closed. Our audit does not include one. |
Read on 28 October 2026. Lovable's security documentation (opens in a new tab) also suggests an additional professional security review for apps that handle sensitive data or critical functionality. The UK National Cyber Security Centre (NCSC) puts the wider principle in its blog on the vibe coding spectrum (opens in a new tab), 18 June 2026: "The risk isn't in using AI. The risk is not applying the right safeguards when the stakes are high."
What the audit reads and what it hands over: the code, the database rules, the hosting set-up and every path money or personal data takes go in, and a written plan to harden, refactor or rebuild, with the cost of each comes out. Highlighted station: the audit.
- 1. The code
- 2. The database rules
- 3. The hosting set-up
- 4. Every path money or personal data takes
Harden, refactor or rebuild?
Hardening is the answer more often than not. The code tends to be React on Supabase or Firebase, which is ordinary, well-documented technology, and the product has already met real users. We recommend a rebuild only when hardening or refactoring would cost more, and the report shows the arithmetic.
One audit, three routes, each drawn in proportion to the upper end of its typical duration. Highlighted: Harden, the route the section calls the answer more often than not.
- Iron mark: after the report, you choose the route.
- Lengths: the typical durations in the table below, to scale.
How we choose between hardening, refactoring and rebuilding
Factor
Tell us which tool built your app and what is breaking, and a senior engineer will say whether the £3,500 audit is the right next step.
Request a free 30-minute callWhat a vibe code rescue costs, and how long it takes
The audit is a fixed £3,500 and takes about a week. Each later step is priced before it starts, and you can stop after any of them. Everything we write for you, the audit report included, is yours to keep. Every first-step fee is on the pricing page.
Send us the repository
Day one
A repository link, read-only access to the hosting and database consoles, and a short call about the app and its users. If the code still lives inside the builder, we first export it to a repository you own.
AI-built app audit
About a week
A senior engineer reads the code, the database rules, the hosting set-up and every path money or personal data takes. The written report ranks the findings by what would hurt first, maps where your users' data goes, and recommends hardening, refactoring or rebuilding, with what each would cost.
- Fee
- £3,500, fixed
- You keep
- The report, to act on with us or with anyone else
Hardening sprint
One to three weeks
The fixes the audit ranked highest, in that order: access rules, secrets, server-side checks, restore-tested backups, error alerts and tests on the paths that take money. It is priced as a fixed list before work starts.
Refactor or rebuild
Only if needed
A refactor runs in stages while the app stays live. A rebuild runs alongside the current app, and your users and data move across when the new version is ready.
Handover or ongoing work
Your choice
A written handover, or we stay on for the features that come next.
What an audit report looks like
Every finding in the report has the same four parts. This extract uses three generic findings.
- Any signed-in user can read other users' recordsBefore more users sign up
- A payment provider key is visible in the browserThe same week
- No backup has ever been restoredBefore launch
What the audit report hands over
| Finding | Why it matters | Shape of the fix | Order |
|---|---|---|---|
| Any signed-in user can read other users' records | The screens show only your own rows, so nothing looks wrong. Anyone who asks the API directly sees every row. | Write an access rule for each table, then test each one with a second account. It is cheap if every row records its owner. | 1. Before more users sign up |
| A payment provider key is visible in the browser | Anyone can copy a key that ships with the page and act as the app. | Rotate the key, then move the call to the server. | 2. The same week |
| No backup has ever been restored | Backups exist, but nobody knows whether they work or how long a restore takes. | Restore one to a test database, time it and write down the steps. | 3. Before launch |
The full report ranks every finding like this, maps where personal data goes and prices harden, refactor and rebuild.
Where does your users' data go?
Every audit includes a UK GDPR data-flow review, because security scans do not ask where personal data travels. AI app builders make it easy to plug in services, and each one that receives personal data on your behalf is a processor you answer for.
Where the app's personal data goes: the app, then each service that receives it. Highlighted station: your app.
- Region: the audit records where each service stores data, and whether that matches what your privacy notice says.
What we map
- Every service that receives personal data: hosting, database, sign-in, email, analytics, payments and any AI model API
- The region each one stores data in, and whether that matches what your privacy notice says
- Whether each has a data processing agreement, and whether any AI provider may keep or train on what the app sends
- How long data is kept, and whether a deletion request can be carried out
- Special category data such as health information, which needs an Article 9 condition and often a data protection impact assessment
- Significant decisions the app makes about people automatically, which UK GDPR has its own rules for
What you get
- A map of where personal data enters, where it is stored and where it leaves
- A ranked list of gaps, written for your data protection lead or solicitor
- The fixes that are engineering work, priced in the same report
Vibe coding rescue for Lovable, Bolt.new, Replit and v0 apps
We take over repositories generated with Lovable, Bolt.new, Replit and v0, code written with help from a chat assistant, and the Supabase or Firebase back ends most of them run on. Each builder keeps the code, the data and the hosting in a different place, and the first job is finding out where.
| Builder | Where the code and data usually live | What we check first | Moving it into your accounts |
|---|---|---|---|
| Lovable | The code sits in a Lovable project that can sync both ways with a GitHub repository in your account or organisation. The data sits in Lovable Cloud, its built-in backend, or in a Supabase project you own. Lovable hosts the published app. | Row-level security on every table. Lovable's documentation says missing policies are the most common way app data gets exposed. | Sync the code to a repository in your organisation. Moving from Lovable Cloud to your own Supabase takes several steps: export the database, restore it, then move the files and code and set up sign-in and secrets again. |
| Bolt.new | The code sits in a Bolt.new project, with optional GitHub sync in both directions. Bolt Cloud hosts the published app at a bolt.host address and creates a database when the project needs one. Some projects use Supabase for the data and Netlify for hosting instead. | Who can read and change each record, and which keys the browser holds. Bolt.new has its own security check, and its documentation says some fixes are left to you. | Connect a GitHub repository in your account or organisation, or download the project as a zip. A Bolt.new database can be claimed into Supabase, which needs you to be the owner of a Supabase organisation. Bolt.new's documentation says there is no supported way back, so we settle the direction before moving anything. |
The table's last column as a map: each builder's code reaches a repository in your own account or organisation, and the hosting and database sit in accounts you control. Highlighted station: your repository.
- 1. Lovable
- 2. Bolt.new
- 3. Replit
- 4. v0
- 5. Another builder, or code a freelancer or agency left halfway
| Builder | Where the code and data usually live | What we check first | Moving it into your accounts |
|---|---|---|---|
| Replit | The code sits in a Replit workspace, with import from and push to GitHub. The built-in database is managed PostgreSQL. Published apps run on Replit's cloud, and its documentation says they are hosted in the United States. | Where personal data is stored, against what your privacy notice says. Then secrets, sign-in and database access. | Push the code to a repository in your organisation, then move the deployment and database to hosting you control. Replit's documentation offers hosting in the European Union to Enterprise customers on request. |
| v0 | The code sits in a v0 project, which syncs with a GitHub repository owned by the account or organisation you choose. v0 publishes to Vercel, and a database arrives through an integration such as Supabase or Neon, with its keys stored as environment variables. | Which database and keys the project is connected to, and whether anyone wrote access rules for that database. | Keep the repository in your own GitHub organisation and check whose Vercel and database accounts the project uses. v0's FAQ says Vercel does not own the code generated from your prompts. |
| Another builder, or code a freelancer or agency left halfway | A repository and a hosted database, often with the accounts held by whoever built it. | Who holds every account, then the same checks on access rules, secrets, payments and backups. | Every account moves into your name and the repository into your organisation. That is the first fix, before any other work. |
Sources, read on 28 October 2026. Lovable: Cloud (opens in a new tab), GitHub (opens in a new tab), Supabase (opens in a new tab). Bolt.new: Bolt Cloud (opens in a new tab), GitHub (opens in a new tab), Supabase (opens in a new tab), projects and files (opens in a new tab). Replit: publishing (opens in a new tab), databases (opens in a new tab), version control (opens in a new tab). v0: GitHub (opens in a new tab), deployments (opens in a new tab), FAQs (opens in a new tab). Builders change their products, so the audit confirms each point against your own app.
What you keep
All of it, from the first day. A rescue should leave you less dependent on outsiders, us included.
What stays with you, from the first day: the repository, the accounts, the data and a written handover. We work in the repository through named accounts you can remove at any time. Highlighted station: you.
The repository
In your own GitHub or GitLab organisation. We work in it through named accounts you can remove at any time.
The accounts
Hosting, database, domain, payments and app store listings stay in your name. Where a freelancer or an agency holds any of them, moving them to you is the first fix.
The data
It stays in your infrastructure, and the data-flow review shows where it goes.
A written handover
What we changed and why, how to run and deploy the app, and what is still on the list, so another team could carry on without us.
Why this needs senior engineers
The platforms we build are designed to prevent the gaps AI-built apps tend to have: each customer's data is kept apart in the data layer instead of hidden on screen. Karu and NForge are examples. Senior engineers review the work, with more than two decades of production software experience in the team.
Investors look for the same gaps, and so does our technical due diligence for startups. Seven red flags that stop a funding round covers the findings that stall a raise; each costs less to fix in the quarter before one than during it.
The same three gates for every change, as the section lists them: a written specification, senior review and automated tests. Highlighted station: the senior engineer's review.
- Iron mark: a senior engineer's review of the change, where a person approves.
Who this is for
Best for
- Apps built with Lovable, Bolt.new, Replit or v0 that now take payments or hold health data or customer records
- Founders about to put paying users, an investor or a data protection review in front of the app
- Apps that have already been through a freelancer's or an agency's hands
- Teams that want to keep the stack they have and fix it in place
Not for
- An automated scan on its own. Cheaper services exist, and for a demo or an internal tool that holds no personal data, a scan may be enough
- Demos and experiments you plan to throw away: keep prompting, which is what the tools are good at
- Legal advice. The data-flow review is written for your data protection lead or solicitor to act on
Questions founders ask about a rescue
What is vibe code rescue?
Vibe code rescue, sometimes called vibe coding rescue, is the work of making an app built mostly by prompting an AI tool safe to run with real users. Senior engineers read the code and rank what could hurt first, and the app is hardened, refactored or rebuilt, whichever the audit shows is cheapest.
My Lovable, Bolt.new or Replit app keeps breaking. Can you fix it?
Usually, yes. The breakage tends to come from a few gaps: missing access rules, logic that only runs in the browser, and no tests, so each fix breaks something else. The audit finds which ones apply, and the hardening sprint closes them in order of harm, data and money first.
Do I need to start over?
Probably not. Real users have already tested the product, and the code is usually ordinary React on Supabase or Firebase, which can be fixed in place. A rebuild makes sense when there is no data model worth keeping or accounts cannot be separated properly. The audit says which, and why.
8 more questions
How much does a vibe code rescue cost?
It depends on what the audit finds, which is why the audit comes first, at a fixed £3,500, for a Lovable app or any other AI-built one. Hardening is then priced as a fixed list, a refactor stage by stage and a rebuild as a new build. You see each number before work starts, and can stop after the audit. If nothing needs fixing before you take payments, we say so and sell you nothing else.
How long does a vibe code rescue take?
The audit takes about a week. A hardening sprint then takes one to three weeks, a refactor 4 to 10 weeks in stages while the app stays live, and a rebuild 6 to 12 weeks for a focused product. The audit tells you which of those applies, and each step is priced before it starts.
Is AI-generated code a security risk?
Unread code is the risk. In Veracode's 2026 GenAI Code Security Report (opens in a new tab), about 44% of benchmark coding tasks produced code with a known security flaw. Veracode sells security tools, and its tasks are short test functions rather than real apps. The fix is what any code needs: someone who reads it, tests that fail when it breaks, and server-side access rules.
Can you work with our existing React and Supabase stack?
Yes, and in most cases we would keep it. Supabase's row-level security works well once someone writes and tests a policy for every table. Moving off it is something we suggest only when the audit finds a reason worth the cost of the move.
Do I keep control of the code and accounts?
Yes, throughout. The repository sits in your own organisation, and the hosting, database, domain and payment accounts stay in your name. We work through named logins you can remove at any time. The code we write for your project is yours on full payment.
Is my Lovable or Bolt.new app ready for paying users?
Check five things. Accounts are separated in the database as well as the interface. Staff and admin actions are refused by the server, not only hidden on screen. Keys stay on the server. Payments are confirmed by the payment provider's webhooks, never by the browser. A backup has been restored at least once. Any 'no' is where the rescue starts. Check your app in five questions.
Can Lovable apps scale?
Usually, once the gaps are closed. Underneath is ordinary React on Supabase, which is Postgres, and that stack carries far more users than most early products have. What stops a Lovable app growing is rarely the platform. It is a data model that fights the product, or AI calls made from the browser with no limit per user.
Can I make my Lovable app production-ready myself?
Some of it, yes. Turn on row-level security and write a policy for every table, move keys to the server, confirm payments with the provider's webhooks, and restore a backup once. The harder part is knowing what you have missed, and that is what an outside read of the code is for.
What happens after you send the repository: on day one, a repository link, read-only access to the hosting and database consoles and a short call; about a week later, the audit report; then you choose: harden, refactor or rebuild. Highlighted station: the audit. Iron mark: your choice.
Further reading
- Auditing an AI-built app: what we check first
Start with who can read whose data. The checks we run on apps built with Lovable, Bolt.new or Replit, in the order they hurt, and how to run each yourself.
- Harden, refactor or rebuild an AI-built app?
Harden it, usually. A decision table for a vibe-coded app: what forces a rebuild, when refactoring one area is enough, and what each path takes and costs.
- What it costs to rescue an AI-built app in the UK
UK first-look prices for an AI-built app run from £250 to £4,500. Hardening takes two to four senior engineer weeks and a rebuild £35,000 to £80,000.
What to tell us
Put these three things in the form below. The more we know at the start, the sooner the audit can begin.
The tool you used
Lovable, Bolt.new, Replit, v0 or something else, and whether a developer has worked on the code since.
Where the code lives
A link to the repository, or a note that it is still inside the builder. Keep it private; we ask for access once terms are agreed. Please leave passwords and keys out of the form.
What is breaking
What users report, what you have seen yourself, and whether the app takes payments or holds health data or customer records.
Send us your prototype.
Tell us which tool built the app, where the repository lives and what is breaking. We'll reply with how the audit would run. It costs a fixed £3,500.
What happens after you get in touch
We reply within one working day
By email, to arrange a time for the call.
A free 30-minute call
With a senior engineer, about what you are building or deciding.
The fee in writing first
If a first step is worth taking, you get its exact fee in writing before any work starts.