Fixing AI-built apps, starting with an honest audit
Send Quantum Craft the repository for your Lovable, Bolt.new, Replit or v0 app. In our AI-built app audit, a senior engineer reads it in about a week, for a fixed £3,500 excluding VAT, and recommends whether to harden, refactor or rebuild, with what each would cost. Most AI-built apps are worth keeping. The urgent ones handle money, health data or customer records.
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.
- £3,500 fixed, excluding VAT
- About a week
- Read-only access
Last reviewed
- First step
- An AI-built app audit
- Includes
- A UK GDPR data-flow review
- Outcome
- A written plan to harden, refactor or rebuild
- You keep
- The report, the repository, the accounts and the data
Is your vibe-coded app secure? What we usually find
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.
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.
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.
Founders see symptoms first. These are the common ones.
| Symptom | Usual cause | Usually means |
|---|---|---|
| Users can see each other's data | Row-level security missing or too loose, or access checked only in the interface | Harden, unless the data model has no real notion of accounts |
| An API key is visible in the browser | Secrets shipped in client code, sometimes the database's service key | Harden: move it to the server and rotate it |
| Payments and orders disagree | Payment status taken from the browser, not from the payment provider's webhooks | Harden, or refactor if payment logic is spread across screens |
| Every fix breaks something else | No tests, and the same rule copied across several screens | Refactor, starting with tests around what works today |
| The AI bill jumps without warning | Model calls made from the browser, with no limit per user | Harden: move the calls server-side and cap them |
| Nobody knows if the backups work | Backups never restored, or nothing beyond the platform's defaults | Harden: restore one, and write down how |
| Nobody can log in to the hosting | Accounts held by a freelancer, or inside the builder's workspace | Fix first: move every account into your name |
| Each feature takes longer than the last | A data model that fights the product | Rebuild, keeping the product and the data |
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.
| Factor | Harden | Refactor | Rebuild |
|---|---|---|---|
| When it fits | The product works and the data model is sound. The gaps are at the edges: access rules, secrets, validation, backups, monitoring | The core works, but parts cannot be changed safely: business logic in the browser, rules copied between screens, no tests | No data model worth keeping, accounts that cannot be separated properly, or a stack nobody can hire for |
| What it involves | Access rules written and tested for every table, keys moved server-side and rotated, server-side checks, restore-tested backups, error alerts, caps on AI spend | Tests around today's behaviour first, then logic moved behind an API and the schema reshaped with migrations, one area at a time, while the app stays live | A specification written from the working app, a build to production standard, and a migration that brings your users and data across |
| Typical duration | One to three weeks | 4 to 10 weeks, in stages | 6 to 12 weeks for a focused product |
| Cost shape | A fixed price for the fix list in the audit | A fixed price per stage, each scoped before it starts | Priced as a new build, against our published bands |
A rebuild keeps more than people expect. Your screens, your flows and what your users have taught you become the specification, and only the code is replaced.
What a vibe code rescue costs, and how long it takes
Each 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.
Send us the repository
Day oneA 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 weekA 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, excluding VAT
- You keep
- The report, to act on with us or with anyone else
Hardening sprint
One to three weeksThe 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 neededA 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 we stay
Your choiceA written handover, or we stay on for the features that come next.
From the hardening sprint on, we work on your app the way we work on every product we build: a written specification, a senior engineer's review of every change, automated tests that must pass before anything ships, and UK hosting where the data needs it. How we work has the rest.
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.
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 an 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
It is an engineering review, not legal advice. Karu, a practice platform we built for UK therapists, was designed around the same questions and runs in Google Cloud's London region.
Lovable, Bolt.new, Replit and v0 apps we take over
We take over repositories generated with Lovable, Bolt.new, Replit and v0, code written in Cursor or with help from ChatGPT or Claude, and the Supabase or Firebase back ends most of them run on.
We harden the stack you have. Moving you off Supabase or Firebase is an option we will price when there is a reason for it, never a condition of working with us.
Apps a freelancer or an agency took over halfway get the same audit.
What you keep
All of it, from the first day. A rescue should leave you less dependent on outsiders, us included.
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. AI works on your code only through business accounts whose terms bar training on it. It never holds production credentials, and client personal data stays out of it.
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
AI does much of our own coding too. The difference is what happens before anything ships: a written specification, a senior engineer's review and automated tests. Fixing an AI-built app is mostly a matter of judging which code to trust, and that takes someone who has read a great deal of other people's code.
The platforms we build are designed to prevent the gaps AI-built apps tend to have. On Karu, every database query filters by account, taken from the login token, before any other condition. On NForge, a query that crosses accounts fails to compile, and a payment split that does not add up is refused before it is saved. The senior engineers who review the work have more than two decades in production software between them.
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.
Who a rescue suits, and who it doesn't
Best for
- Apps built with Lovable, Bolt.new, Replit, v0 or Cursor 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
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.
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 excluding VAT, 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.
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. 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. Someone is alerted when the app fails. Any 'no' is where the rescue starts.
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 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, Cursor 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, excluding VAT.
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, not a salesperson, 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.