Audits and fixes for AI-built apps
You built fast with Lovable, Bolt, Cursor, v0 or Replit — and the app already has users. We look at what the AI doesn't show you: exposed data, misconfigured permissions and code that breaks as the business grows. Then we stay to fix it.
The app works. But nobody knows if it will hold.
It was built with AI, by you or a freelancer
Lovable, Bolt, Cursor, v0, Replit or "vibe coding". No senior engineer reviewed the code before it went to production.
You already have customers or real data in it
Payments, personal data, other companies' data. A mistake is no longer a bug — it is an incident.
Every change breaks something else
You fix one screen and another stops working. The AI generates, but it doesn't know what already exists.
An investor, a big customer or an audit is coming
Someone is going to look at the code. Better that you know first.
The problems we find most often in AI-built apps
They are not theoretical — they are patterns we found in real audits and fixes.
One customer's data visible to another
In multi-company apps, the database access rules (RLS in Supabase) are missing or badly written. In one real case we closed 16 of these leaks.
Users who promote themselves to admin
The API accepts changes to fields that should never be within the user's reach.
A database open to the world
The public Supabase or Firebase key is only safe with access rules; without them, anyone can read (or delete) the data in the exposed tables.
Errors pretending to be "no data"
The app fails silently and shows an empty screen, so nobody notices the problem.
Slowness that only appears with real customers
Queries without indexes and logic that runs row by row.
No tests and no CI
What gets fixed today breaks again tomorrow.
First, know what is at risk. Then fix it, in phases.
- 01
Free diagnosis (30 min)
We understand what you have in production and what worries you.
- 02
Audit
Code, architecture and database; findings by severity, with proof, before touching a single line.
- 03
Phased fixes
Critical issues first, without stopping the business and without rewriting from scratch when it isn't needed. Tests and CI so it doesn't come back.
What happens when someone takes a proper look
Multi-company financial SaaS for SMEs
From "we can't show it to two customers at the same time" to "ready for the first real customer" in three weeks.
16 cross-company data leaks closedRead the case →B2B platform built with vibe coding
Two customers in production and a flaw that let a regular user become an administrator.
Critical flaw identified and documentedRead the case →
What people ask us before we start
Any app built with Lovable, Bolt, v0, Cursor, Replit, Windsurf or another code-generation tool. What we audit is the result: the code, the architecture and the database — usually Supabase, Firebase or PostgreSQL.
For the full audit, yes: read access to the repository and the database (or a copy). Everything is covered by a confidentiality agreement and access is removed at the end.
Almost never. We stabilise what already exists: critical issues first, the rest in phases. We only recommend rebuilding parts when maintaining them costs more than rebuilding them — and we tell you that in the diagnosis.
Yes. We leave rules, tests and a CI pipeline that catch the most common mistakes before they reach production, so you can keep building fast, more safely.
It depends on the size of the app. A typical AI-built app is audited in one to two weeks; fixing what is critical starts right after.
It's the best time: fixing before you grow costs much less than fixing after an incident, a big customer or a due diligence.
Before someone finds out for you.
30 minutes to understand what is at risk in your app — and whether you really need an audit.