CALLJOE.COBook now with Joe

AI

AI built 80% of your app. Here is what is missing

25 July 2026 · 7 min read · Updated 26 August 2026

AI

Fixing AI-built apps

7 min read

The tools work. You describe an app and it appears. Then you try to put it live, take a payment or let a second person log in, and it stops.

I get this call regularly, and I want to be clear first: building something instead of talking about it for a year was the right instinct. The problem is not what you did, it is what these tools quietly leave out.

Why it stalls around 80 percent

AI builders are strong at the visible part. Screens, layouts, components, the flow between them. That is most of what you can see and a minority of what an app is.

They are weaker underneath. Who is allowed to read what. What happens when two people act at once. Where the data lives and whether it is protected. What happens when a payment fails halfway through. None of that shows in a demo, and all of it shows the week after launch.

The five things I find every time

API keys and secrets in client-side code. Anything shipped to the browser can be read, so a Stripe secret key or a service role key in there is not hidden, it is published.

No row level security on the database. In Supabase the public key is meant to be public, and policies are what stop one user reading every other user's rows. New projects often start with tables open, and generated code rarely adds the policies. Firebase security rules are the same story in a different syntax.

Authentication checked only in the interface. Hiding a button does not protect anything. If the check is not enforced on the server or in the database, anyone can call the endpoint directly.

No backups and no error tracking. When something breaks you find out from a customer, and there is nothing to restore.

Input going straight into queries or prompts without validation. That is how you get SQL injection, and its newer equivalent where user text rewrites what your AI feature was told to do.

The five gaps I find in AI-generated apps, and what each one exposes
GapWhat it means in practiceFix
Secrets in client codeAnyone can read your API keys from the browserMove to server-side environment variables, rotate the keys
No row level securityAny logged-in user can query everyone else's rowsWrite Postgres RLS policies, or Firebase security rules
Auth checked in the UI onlyHiding a button protects nothing; the endpoint is still openEnforce on the server and in the database
No backups or error trackingYou learn it broke from a customer, with nothing to restoreAutomated backups plus an error reporting service
Unvalidated inputSQL injection, and prompt injection in AI featuresValidate and parameterise everything crossing the boundary

Usually worth rescuing

The first thing I do is look at what exists and tell you whether it is a rescue or a rebuild. Most of the time it is a rescue.

The work you did defining what the app should do is the valuable part and it survives. The screens generally survive too, often ported into Next.js so they render fast and can be maintained. What gets rebuilt is the data model, the access rules, payments and deployment.

Sometimes it genuinely is a rebuild, and I will say so plainly rather than patching something that fails in three months and costs more.

Why I am useful on this specifically

I use the same tools daily. I know where they are strong and exactly where they stop. So I am neither precious about generated code nor mystified by it, and I am not going to charge you to rewrite work that is already fine.

I also follow this area properly. Models, agents, automation that runs a business process overnight, hardware and printing in the corner of the studio. Not because it is my industry, but because it is the most interesting thing happening right now, and it means the advice you get is current rather than from a course taken in 2021.

Where this is going

More people will build their own first version, and that is good. More ideas get tested and fewer get talked out of existence in a meeting.

It moves where the expertise sits. Less typing code, more knowing what is missing, what is unsafe, and what will not survive contact with real users. If you have built something and hit a wall, get it checked before someone quotes you to bin it and start again.

Built something with AI and stuck before launch? Send it over and I will tell you what is missing and whether it is worth saving.

Get it checked

Questions

Yes, that is a service in its own right. I assess what exists, keep what is worth keeping, and rebuild the parts that will not survive real users. Most of the time it is a rescue rather than a fresh start.

Not without a review. The recurring problems are API keys left in client-side code, databases with no row level security, authentication that works but is not enforced on the server, and no backups. All fixable, none obvious unless you know to look.

In Supabase or any Postgres backend, row level security policies decide which rows each logged in user can read or change. The key in your browser code is public by design, so without policies anyone can query the whole table. Firebase has the equivalent in its security rules.

Usually not. The product thinking and most of the screens carry over. What gets rebuilt is the data layer, authentication and deployment, which is the part you were never going to enjoy.

More from the blog

Book a call

Loading calendar…

No time that suits? Message Joe on WhatsApp or email hello@calljoe.co.

Chat with Joe