A new kind of gig is landing in freelancers' inboxes. Non-technical founders, an app built entirely by AI, real users on the way. And one question: "can you finish the job?"
TL;DR: I just lived that gig. My rule: never quote on a phone call. One day of scoping audit, unpaid but time-boxed, before any number. AI-generated apps share documented vulnerability patterns, and a tight budget gets a quote split into lots, security first. The precise findings stay with the client. The method is worth sharing.
This article is for freelancers receiving these requests, and for founders about to send one.
The typical 2026 meeting
The scene is becoming standard. Two founders, no developer on the team. An app built on an AI app builder, Lovable or similar, until the credits ran out.
Then a developer friend takes a look and raises the alarm: personal data exposed. The founders freeze all changes and look for a professional.
Add the classic constraints. A budget of a few thousand euros. A store deadline in weeks, not months. Several freelancers competing.
I just lived that meeting. It is about to become routine.
Why I never quote on a call
Without reading the code, a takeover estimate swings by a factor of ten. Mine melted after reading: the code was better than feared.
The trap cuts both ways. Quote too high and you scare away a viable client. Quote too low and you lock yourself into a losing fixed price.
My rule: a one-day scoping audit before any quote. Unpaid, because it is pre-sales against competitors. Time-boxed, because unlimited unpaid work is a slope.
The deliverable is double: a report readable by non-technical people, and a split quote the report justifies line by line.
What I look at in one day
One day does not buy exhaustiveness. It buys the patterns that decide the quote. My reading order never changes.
First, the data access model. Who talks to the database, with which privileges? That question dominates all the others.
Then the public endpoints: what they return, field by field. Then everything that touches money: types, validations, payment provider webhooks.
Then the git history and the migrations. The real state of an AI-generated database often diverges from what the files claim.
Finally, secrets and their hygiene. And the good parts, noted with the same seriousness: they make the rest of the report credible.
The patterns you will find
The flaws of AI-generated apps are not artisanal surprises. They are documented, and they repeat.
The public reference: CVE-2025-48757. A researcher scanned apps built with Lovable. About 10% had Row Level Security missing or broken. RLS is the Postgres mechanism that filters rows per user.
The sneakiest pattern is subtler: correct RLS policies, but a server that queries the database with the admin key. The barrier exists, everything steps over it. A bypassed policy protects nothing.
The next ones show up almost every time. Public endpoints returning every field instead of the strict minimum. No rate limiting, so enumeration is trivial. Money handled as floating-point numbers, with no database constraints.
My favorite: AI-generated security helpers, clean, tested, and never wired in. The tool writes the masking function, then never calls it.
In the app I just audited, several of these patterns showed up. I will not say which ones: precise findings belong to the client. The patterns belong to everyone.
A quote in lots, or nothing
The announced budget rarely covers the dream scope. The gap is handled by splitting, not by haggling.
Lot 1: data security. Close the leaks, control access, add the critical constraints. This lot fits the envelope, and it covers what can hurt users.
Lot 2: reliability of the money flows. Lot 3: production readiness. Each has its price, and the client chooses with full knowledge.
And one red line: never a global fixed price "until store approval". Review round-trips do not depend on me. Promising a deadline a third party controls is manufacturing a dispute.
What I tell the founders
Three messages, straight.
One: your generated app is not garbage. The structure was readable, tests existed, some reflexes were right. The report says so, because it is true and because it makes the warnings credible.
Two: security comes before features, because real data and real payments are flowing. Lot 1 is not negotiable in content, only in schedule.
Three: regulatory obligations do not vanish by switching providers. What is mandatory with one will be mandatory with the next.
The scoping audit checklist
One day, in this order. The quote almost writes itself.
- [ ] Time-box the audit: one day, a written deliverable, not an hour more
- [ ] Start with the access model: who talks to the database, with which privileges
- [ ] Hunt for paths that bypass RLS with an admin key
- [ ] List public endpoints and every field they return
- [ ] Follow the money: types, database constraints, webhooks and their checks
- [ ] Compare the database's real state with what the migrations claim
- [ ] Check secrets in git, across the whole history
- [ ] Note the good parts, and split the quote into lots, security first
What to remember
AI-built app takeovers are about to fill freelancers' inboxes. The differentiating skill is not despising that code. It is auditing it fast, and quoting honestly.
One audit day, known patterns, a quote in lots. The rest is execution.
Have a generated app to secure before launch, or a takeover to scope? Let's talk.
Sources: Matt Palmer, CVE-2025-48757 (missing RLS in Lovable apps) · NVD, CVE-2025-48757 entry · Supabase, Row Level Security documentation
Top comments (0)