For people building with AI
Keep the AI builder. Replace what it generated underneath.
The front end these tools produce is genuinely good. The database, permissions and books they generate alongside it are where the trouble starts — and that part you can simply not generate.
Keep the AI builder. It is genuinely good at the thing it is for — turning a description into a working interface faster than any human can. Just stop asking it to invent your database, your permissions and your books at the same time. Point it at a backend that already has them.
It is in the name, honestly. You bring the front — designed by hand or generated in a minute, styled however you like, changed whenever you feel like changing it. We bring the back: the customer records, the permissions, the payments, the books, and the part where none of it leaks.
This page is deliberately specific, and every problem below is a published, checkable fact rather than a sales line. If you arrived here after something went wrong, start with the one that matches.
What people actually run into
“The app it generated left customer data readable by anyone”
What is documented: In 2025 a security researcher found 303 endpoints across 170 AI-generated projects where database tables could be read by anyone holding the app’s public key — exposing emails, addresses and in some cases API keys — because row-level protection was never switched on for the generated tables. It was assigned CVE-2025-48757 with a CVSS score of 9.3, and a later audit of 50 live apps reported that most had the same protection disabled or misconfigured. CVE-2025-48757 analysis ↗
Why it happens: Not carelessness by the tool or the builder. When an assistant creates your tables, it is also creating the rules about who may read them — and a rule nobody wrote is a rule nobody enforces. The table works perfectly in testing either way, so nothing tells you.
Here instead: Your assistant never creates a table here, so it can never create an unprotected one. The data layer already exists, already knows which organization a record belongs to, and already refuses a request that has not earned it. That is not a setting you can forget to enable — there is no version of the system where it is off.
“Password reset and account takeover through a table nobody protected”
What is documented: The same 2025 disclosure documented password-reset token tables left readable by anonymous users, which allowed full account takeover. CVE-2025-48757 analysis ↗
Why it happens: Auth tends to get generated alongside everything else, and the parts of auth that must never be readable look exactly like the parts that must be.
Here instead: Authentication is not something you or your assistant assembles. It ships already built and already hardened, along with sessions, permissions and the audit trail — so there is no reset-token table of yours to leave open.
“It built a beautiful front end and then the real work started”
What is documented: Reviewers describe the pattern directly: a founder types “build me a SaaS dashboard”, a beautiful UI appears in about a minute, and then the magic evaporates at “connect your database account” and “debug this build error”. AI app builder review roundup ↗
Why it happens: Generating a screen is a genuinely solved problem now. Generating permissions, books, consent, tax records and the thousand unglamorous things a business runs on is not — and that half is invisible in the demo.
Here instead: The unglamorous half is what you are pointing at. Customer records, quotes, payments through your own Stripe, scheduling, messaging, member portals and real double-entry books are running before you write your first screen.
“It gets stuck in a loop and I burn credits fixing its own mistakes”
What is documented: Reviews consistently name two frustrations: inconsistent results between prompts, and credit-based pricing that makes cost hard to forecast — including debugging loops the user has to break manually, paying for each attempt. Lovable review, Superblocks ↗
Why it happens: An assistant that owns the whole stack has to keep the whole stack in its head. The more of the system it invented, the more of it it has to re-derive on every prompt — and each re-derivation is another chance to contradict itself.
Here instead: Give the assistant a smaller job. When the data layer, the rules and the conventions already exist and are published, it is writing a page against a fixed contract rather than inventing a system — which is the difference between a task it does reliably and one it does eventually.
“My whole backend depends on one vendor’s architecture”
What is documented: Reviewers note these tools are fundamentally front-end-first: the backend is effectively a single partnered provider, so anything that does not map neatly onto that provider’s model means leaving the tool and writing it yourself. AI app builder review roundup ↗
Why it happens: A partnership is a commercial arrangement, and commercial arrangements change on a schedule you do not control.
Here instead: Your front end is MIT-licensed code in your own repository, your money settles in your own Stripe account, and your data exports on demand. Leaving is a decision rather than a negotiation — which is also the reason we have to keep earning it.
“An assistant with full access did something I did not ask for”
What is documented: Security guidance for AI-built apps flags that assistants holding an all-powerful service key can bypass access rules entirely, including through instructions hidden in content they read. AI-generated app security guide ↗
Why it happens: The convenient thing to hand an assistant is a key that can do everything, because then nothing blocks it. That is also precisely why it is dangerous.
Here instead: There is no key here that can do everything — no admin scope, no wildcard, nothing to request. Access is granted one named capability at a time, asking for nothing gets you nothing rather than everything, and a credential can narrow itself but never widen. Money-moving actions are held separately, so something allowed to create work still cannot accept it on your behalf.
“If the AI gets something wrong, can I even tell what it changed?”
What is documented: Security reviews of AI-generated applications repeatedly note missing audit and verification layers — the code works, but nothing records what happened or lets you reconstruct it afterwards. AI-generated app security guide ↗
Why it happens: An audit trail is invisible when everything is fine, so it is the first thing left out and the last thing anyone thinks to ask for.
Here instead: The financial record is append-only: entries are added, never edited away and never deleted, so the history of what happened cannot be quietly rewritten — by a person, a bug, or an assistant having a bad day. Records that leave your working views are retained rather than destroyed, so “undo” is a real question with a real answer.
Where you should stay exactly where you are
If you are building a landing page, a prototype, a weekend project, or anything that will never hold a stranger's personal data or take a payment, the tool you are already using is the right answer and this page is not for you. The generated data layer is only a liability once real customers are in it.
We are also not the right answer if what you want is total control of the schema itself. The whole reason the failure class above cannot happen here is that the data layer is not yours to invent — and if inventing it is the point of your project, that constraint will feel like a cage rather than a floor.
How this actually works
Generate your front end however you like — Lovable, v0, Bolt, Claude, Cursor, or by hand — and point it at the API. Or start from our open-source template, which is already wired and which you can customize past recognition while still receiving upstream improvements.