You built it with Lovable, Cursor or Supabase. Get an architect to look at it before your users, or your investors, do.
AI coding tools are genuinely good at building features. What they leave out is the part nobody asked for: who is allowed to see what, which keys must never reach the browser, and a structure that still makes sense after the fortieth prompt.
I review apps built this way, before launch, before fundraising, or once real users have made every change risky. A fixed-scope review, from $1,300 (£1,000), with a written report that tells you what to fix first.
I built the analysis engine I use, and I have run these boundaries in production. SystemAudit is my live codebase-analysis product, with a deterministic layer that produces file-and-line evidence before any AI interprets it. SureCiteAI enforces tenant isolation in four layers with Supabase row-level security as the first.
What goes wrong in apps built this way
It is documented, not anecdotal.
1 in 10
Lovable-built production apps leaking real user data - 170 of 1,645, CVE-2025-48757
400+
exposed secrets across 5,600 AI-built apps scanned by Escape.tech, October 2025
175
instances of exposed personal data, including medical records and bank accounts
CVE-2025-48757 recorded 170 of 1,645 Lovable-built production apps shipping with missing or misconfigured row-level security. Escape.tech’s scan of 5,600 AI-built apps found more than 400 exposed secrets and 175 instances of exposed personal data, all in live systems.
None of that is a verdict on the tools. An assistant asked for a table and a screen builds a correct table and a correct screen. Nothing in the request said who else would use the app, so the rule about who may see which rows never gets written — and the happy path works perfectly, which is why nobody notices until a stranger does.
The second failure is slower. Each prompt solves the problem in front of it, so the same logic ends up written four ways in four places. That is fine at ten screens. At forty, every change breaks something else, and the app that took a weekend to build takes a week to alter.
Two situations, one review
Before launch or fundraising
The app works and you are about to put real users, real data or an investor in front of it. The review finds what would embarrass you first, and separates the launch blockers from the list of things that can wait.
Live, with users, and hard to change
People are using it, and every change now breaks something else. The review finds the few structural problems causing most of that, and orders the fixes so you stabilise it without stopping to rewrite.
What the review checks
The same four areas every time, weighted by what your app actually does.
Data access
Row-level security on every table the browser can reach, policies read against the queries that really run, storage bucket rules, and admin checks that exist on the server rather than only in the interface.
Secrets and payments
API keys and service keys in the client bundle, webhooks that do not verify their signature, and prices or permissions the browser is trusted to send.
AI features
What the AI parts of the product can be talked into doing, what they can reach, and whether one user can run up your model bill.
Code health
Duplication, dead code, error handling that hides failures, and the structure that will decide how expensive the next ten features are. Evidence from my own analysis engine, with file and line references.
What you get
- A written report with the evidence behind every finding, so you or anyone you forward it to can check it rather than take it on trust.
- Findings ordered by exposure: what a user or a stranger could reach today comes first, style and tidiness last.
- A clear line between now and later: what to fix before launch or before the next funding conversation, and what can safely wait.
- A walkthrough call to go through it with you, and with your developer if you have one.
If you want the fixes done as well, I will quote them separately once the review is finished. You are under no obligation to use me for them, and the report is written so that any competent developer can work from it.
What it costs
From $1,300 (£1,000) for a single app. The price moves with size, not hours: a large codebase, several apps or services, a live database with real user data to test behaviour against, or AI features that need their own review. You get a fixed quote after a short call and before any work starts.
For something larger, such as redesigning how a multi-tenant platform separates its customers, the fuller engagements are below, and this guide explains what drives the cost of production AI work in general.
If your product is AI at its core
Some of the apps I am asked to look at are not just built with AI; the product is AI. Document intelligence, structured extraction, reasoning over technical material, and the question of where automated processing should stop and a professional’s judgement should take over. For those the review also covers how answers are grounded, which controls are deterministic rather than left to the model, and how each output can be explained to the person who has to sign it off. That is the same discipline behind my AI assurance work.
Who this is for
Founders who built a real product with Lovable, Cursor, Bolt, v0, Replit or similar, often on Supabase, and now need someone who has shipped production systems to tell them honestly what they have. That includes domain experts — engineers, clinicians, lawyers, analysts — who built working software in their own field and want an architect’s view before committing to the next stage.
I work with founders in the United States, the United Kingdom and Europe, remotely and across time zones. Where your users are in the EU or the UK, the report notes the data-protection points that follow from what it finds.
If you need more than a review
Frequently asked questions
What does the review cover?
Everything that decides whether the app is safe to put in front of users and investors: who can read and write which data (row-level security on every table the browser can reach, storage bucket rules, admin checks that happen on the server rather than only in the interface), secrets left in the client bundle, how payments and webhooks are verified, any AI features and what they can be made to do, and the health of the code itself - duplication, dead ends and the parts that will fight the next feature. You get a written report with the evidence for each finding and a clear split between what to fix before launch and what can wait.
How much does it cost?
From $1,300 (£1,000) for a single app. What moves it up is size rather than hours: a large codebase, more than one app or service, a live database with real user data to check behaviour against, or AI features that need their own review. You get a fixed quote after a short call, before any work starts, so the price is agreed rather than estimated.
My app already has users and the code has become a mess. Do I need a rewrite?
Usually not, and the review is how you find out. Most AI-built apps that have become hard to change have a small number of structural problems causing most of the pain - a missing data boundary, logic duplicated in several places, no separation between what the browser and the server are trusted to do. The report names those and orders the fixes so each one makes the next cheaper, which is almost always faster and safer than starting again with users on the system.
Is Lovable, Cursor or Supabase safe to launch on?
Yes. The tools are not the problem. What goes wrong is that an AI assistant asked for a feature builds the feature, and nothing in the request said who else would be using the app, so the rules about who may see what are left unwritten. CVE-2025-48757 recorded 170 of 1,645 Lovable-built production apps shipping with missing or misconfigured row-level security. The fix is usually small once someone has found it; finding it is the work.
Will this help with investor technical due diligence?
It is written to. Investors increasingly ask how an AI-built product handles security and data access, and whether the codebase can carry the next stage of growth. The report states what was checked, what was found, what has been fixed and what remains, in language a non-technical founder can forward to an investor or an incoming CTO without translating it.
Do you sign an NDA before seeing the app?
Yes. I am happy to sign yours before you share access, documentation or anything else about the product. Read access to the repository and a staging copy of the database is usually enough; where that is not possible, a schema export and the policy definitions still produce most of the findings.
How is this different from an automated vibe-coding scanner?
Automated scanners are worth running and are good at finding known patterns, such as a key in the client bundle or a table with no policy. What they cannot do is read a policy against the queries your app actually runs, tell a harmless finding from a launch blocker for your specific product, or say which fix to make first. I use my own analysis engine for the pattern-level evidence and spend the review on the judgement a scanner cannot make.
About to launch, raise, or build the next stage?
Tell me what the app does, what it was built with and what is worrying you. If a review is not what you need, I will say so and tell you what is.
Last updated