What the audit checks
Authorisation and database access rules, secrets in the code and its history, dependencies, the separation between development and production, then tests and the deployment process.
Start with an audit: targeted repairs if the foundations hold, gradual replacement if only some parts are fragile, a rewrite as a last resort. This guide draws on 10 years of web development, application takeovers included, and daily work with coding agents.
Published 13 October 2026 · Jean-Baptiste Thery · EURL jCode
AI-generated code tends to fail in the same places. When a researcher scanned 1,645 apps built with Lovable in 2025, about 10% let anyone read or write their database tables, because row-level access rules were missing.
Authorisation and database access rules, secrets in the code and its history, dependencies, the separation between development and production, then tests and the deployment process.
In GitGuardian's March 2026 report, public commits co-written with Claude Code exposed secrets in 3.2% of cases, more than twice the 1.5% average.
A written report of the issues, their risk and the work needed, estimated by work package. When I take over an application, this fixed-price audit is the first step.
Superblocks, on CVE-2025-48757: superblocks.com/blog/lovable-vulnerabilities
GitGuardian, State of Secrets Sprawl 2026, March 2026: gitguardian.com/state-of-secrets-sprawl-report-2026
Repairs fit when the foundations hold and the problems are local.
The data model fits the business, access rules can be added without a redesign, and most defects sit in a few places.
Close the security gaps first, then fix defects by priority and add tests around each part you change. The application keeps running throughout.
Gradual replacement fits when some parts are sound and others are not.
The application has users and data to keep, but some modules are too fragile to repair. A stable interface can sit between the old and the new parts.
Replace one module at a time behind that interface, migrate its data, then remove the old code once the new part runs in production.
A rewrite is a last resort, not a starting point. Sometimes it is still the cheapest path.
The data model or the security foundation is wrong throughout, nobody can explain how the code works, and every fix breaks something else.
Keep the product knowledge, the data and what users rely on, then rebuild in small releases, with tests and a clear architecture from the first one.
Coding agents help with the repair too, under the same rules as any other change.
They help me map the codebase, write the missing tests and draft fixes on the points the audit raised. I review and test every change before delivery.
Tell me what you want to build or improve, your budget and your target date.