Your AI-built app works. Here's what it's missing.

Cursor, Claude Code, Lovable, Bolt and Replit can take an idea to a working app in a weekend. That part is real. What they build is usually the demo: the path you clicked through while you were building it. Real users don't walk that path. They walk every branch off it.

This is the list I go through when someone sends me an app like that. None of it means starting over. Most of it is a week or two of the work an AI tool doesn't do unless you ask, because you didn't know to ask.

1. The screens nobody looked at

Every screen that shows data has five states: empty, loading, partial, error and the full one. AI tools build the full one, because that's what the prompt described and what the preview showed. I wrote about all five in detail.

The quick test: create a brand new account and look at every screen before adding anything. Then turn on airplane mode and do it again. Blank white screens, spinners that never stop and raw error text like TypeError: undefined are the most common findings, and the cheapest to fix.

2. Who can read your data

This is the one that matters most, and it doesn't show up in a demo at all.

Apps built on Supabase or Firebase talk to the database straight from the phone. That's fine, and fast, as long as the database itself decides who can see what. In Supabase that's row level security: a rule on each table that says "a user can only read rows where user_id is theirs". If it's off, anyone who signs up can read everyone's rows with a few lines of code. The app's screens hide that; the database doesn't.

What to check:

• Row level security is on for every table, with a policy for each action, and you've tested it while signed in as a second user.
• No secret keys in the app. The service role key, Stripe secret keys and AI provider keys belong on a server or in an edge function. Anything shipped inside an app can be pulled out of it.
• The server checks, not the button. Hiding the "delete" button isn't permission. The rule has to live where the data lives.

3. Errors and bad networks

Phones lose signal in lifts and on trains. A request that took 200 milliseconds on your Wi-Fi takes six seconds on a weak connection, or never comes back.

• Every network call has a timeout and a message a person can act on, with a way to retry.
• Saving doesn't lose what someone typed when it fails.
• Tapping a button twice doesn't create two orders.
• The app survives being closed in the middle of something.

4. Consistency

Generated code tends to style each screen on its own. One button is 44 points tall, the next is 48; three slightly different greys; corners that don't match. Nobody can name the problem, but people feel the app is cheap.

The fix is a small design system: a set of colour, type and spacing tokens, and a handful of components every screen uses. Once that exists, the details that make an app feel expensive become possible: one press behaviour, one spring, haptics that mean something.

5. Speed

AI-built apps often fetch everything, every time. A list loads all rows instead of the first twenty. Images are full size. The same query runs on every screen focus.

Paginate lists, cache what you just loaded, size images for the screen, and add database indexes for the columns you filter on. Test on an older Android phone, not your newest iPhone.

6. Ready for review

App Store and Google Play reviewers install the app and walk the real flow. They'll reject it for a missing account deletion option, a permission prompt with no explanation, a paywall without restore purchases, placeholder text, or a listing that describes features the build doesn't have. I wrote about getting Mend through review; most of that list applies here.

7. Knowing what happens after launch

If you can't see where people drop off, you'll guess what to fix next. Add basic analytics (sign up, the core action, the paywall) and crash reporting before launch, not after the first bad review.

What to keep, and what to rewrite

Founders often ask whether they need to throw it away. Usually not. The screens, the flows and the logic you've been testing for weeks are worth keeping. The layers that decide who can do what are the ones to redo properly.

Screens and flowsrestyle on tokenskeep

Business logicadd tests around itkeep

Data modelindexes, constraintsfix

Stylesone token setfix

Auth and access rulesserver decidesrewrite

Secrets and keysout of the apprewrite

How a revamp works

This is the work I do on design and revamps. It starts with an audit: $300, two to three days, a marked-up review of your app with every fix ranked by impact, and a walkthrough call. If you go ahead, a revamp starts at $2,500 and takes three to five weeks. Your core flows get redesigned and built into your own codebase, so you keep the app and the momentum, and you get working code rather than a design file.

---

If your app works in the demo and you're not sure it's ready for real people, send it to me. I'll tell you what's missing, in order of what it costs you.