What Breaks When Real Users Arrive: Making an AI-Built App Production Ready

Before you do anything else, confirm a stranger cannot read your database. This is the most common failure in AI-built apps and it is completely invisible from the front end. The scale of it is documented. Symbiotic Security scanned 1,072 Supabase-backed apps built on vibe coding platforms and found at least one security flaw on 98% of them, with critical flaws on 16% (Symbiotic Security, June 2026). In that sample, 172 sites let anyone delete records with no authentication and 39 had tables fully readable by any visitor. Escape.tech ran a similar exercise across more than 5,600 publicly reachable vibe-coded apps and found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 cases of personal data on show, including medical records (Escape.tech, October 2025). It is not theoretical. CVE-2025-48757, published 29 May 2025 with a CVSS score of 9.3, covers missing row-level security in Lovable-generated projects that let unauthenticated attackers read and write arbitrary tables. In January 2026, Wiz found the AI social network Moltbook had left its database open the same way, exposing roughly 1.5 million API tokens and 35,000 email addresses (Wiz Research, February 2026). The mechanic is worth understanding once. In Supabase, the public key in your front end is meant to be public. Your security is the row-level security policies on each table, and the AI usually does not write them. Open your table list, confirm RLS is enabled on every table, and then load your app while signed out and try to read something private.

Every route that costs you money needs a limit on it before you launch. Without one, a single script can spend your entire budget overnight and you find out from a billing email. This is not hypothetical either. In March 2025, the builder posting as leojr94 announced publicly that his AI-built SaaS was under attack, describing maxed-out API keys, people bypassing the subscription and database records being altered. The app worked. It just had nothing standing between the internet and the expensive parts. What to put in place, in order of how much it saves you: - A hard spend cap at the provider. Every AI and email provider has usage limits and billing alerts. Set both. A cap that stops service is better than a bill you cannot pay. - Rate limiting on every public route, especially anything that calls a paid model, sends an email or writes to your database. Per IP and per signed-in user. - No unauthenticated route that calls a paid API. If a visitor can trigger it without signing in, assume a script will. - Input size limits. Cap the length of anything a user can type or upload before it reaches a model. - Move slow work to a queue so one heavy request cannot hold your app hostage. Rate limiting is a five-line change in most frameworks and almost never appears in generated code unless you ask for it by name. Ask for it by name.

You will need to undo something, and the worst time to learn how is the moment you need it. Data loss is more likely than a breach for a small app, and it is usually self-inflicted. In July 2025, SaaStr founder Jason Lemkin reported that Replit's AI agent deleted his live production database during a code freeze, against explicit instructions (Fortune, 23 July 2025). An agent with production credentials and no confirmation step is a very fast way to lose everything. Also worth knowing: the Supabase free plan includes no automatic backups at all. Supabase's own documentation tells free projects to export their data regularly with the CLI and keep the copies off-site. Paid plans get daily backups with a seven day window. Many builders assume backups exist because the platform feels managed. Check yours today rather than after the incident. The practical version: - Have a separate development database with fake data, and never point a coding agent at production. - Take one backup and actually restore it somewhere. An untested backup is a guess. - Prefer soft deletes, where a row is marked deleted rather than removed, for anything a user can destroy. - Require a human confirmation for any migration or script that drops or truncates. - Keep production credentials out of the environment your agent runs in. Fifteen minutes of this buys you the ability to recover from your own worst day.

Most solo builders learn their app is broken when a user tells them, or worse, when nobody tells them and the user quietly leaves. You need the app to report its own failures. Three things cover almost all of it, and all three are free at small scale. Error monitoring. Add an error tracking service that captures both browser and server errors, then send yourself an alert on new ones. The value is not the dashboard, it is finding out that six people hit a crash on the signup page this morning. Without it, a failure that only affects Safari users is invisible forever. An uptime check. One external service pinging your home page and one important API route every few minutes. It catches the whole category of failure where your app is not throwing errors because it is not running. A support address that reaches you. A real email on the page, checked daily in the first weeks. Early users will tell you exactly what is broken if there is somewhere to tell you. One more habit: know your normal numbers. If you cannot say roughly how many signups a good day produces, you cannot notice the day it drops to zero. A simple analytics tool and a glance each morning is enough. Agents are very good at adding all three when asked. They will not add any of them unprompted.

AI-built apps handle the path you demonstrated and almost nothing else, so real users hit blank screens, silent failures and forms that eat their work. That is what the registrant who worried about "the ergonomics of the product" was pointing at. The gaps are consistent enough to make a list: - Empty states. What a brand new account sees before there is any data. Usually a blank page with no instruction. - Loading states. Anything that takes more than a second needs to say so, or people click twice. - Error messages that say what to do. Not "something went wrong", but which field, and what to change. - Forms that survive failure. If submission fails, the text the user typed must still be there. - The unhappy paths you never opened. Password reset, sign out, an expired session, a failed payment, an AI call that times out. - A phone. Open your app on your actual phone and complete the main task with one thumb. The cheapest test in software is still the best one. Sit one person in front of it, give them a goal, and say nothing while they use it. Every place they hesitate is a defect, and you will find more in ten minutes than in a week of reading your own code. This is the same pre-launch pass we run in buildAcademy, where the point is a deployed app other people can use rather than a demo that works on the builder's laptop.

How do I know if my database is actually exposed? Open your app in a private browser window while signed out and try to load data that should be private. Then check your database dashboard and confirm row-level security is enabled on every table, not just the ones you remember creating. Do I really need all this for ten users? Most of it, yes, because the risks do not scale with your user count. A bot does not know you have ten users. Backups, database rules and spend caps matter from the first public URL. Full monitoring can wait a week. What is the single most expensive mistake? An open database. A leaked key can be rotated and a surprise bill can sometimes be argued down with the provider, but customer data that has been read by strangers cannot be unread, the damage to trust is permanent, and in Australia a leak of personal information may trigger notification obligations. Should I pay for a security audit before launch? Not for a small first release. Run the free checks yourself, ask your coding agent to review the app specifically for missing authorisation and rate limits, and spend money on an audit once you hold data that would genuinely hurt someone if it leaked. How long does this whole checklist take? About a day for your first app, and far less on every app after that, because most of it is configuration you set up once and copy forward. That is a great deal shorter than recovering from any single incident on this list.