The production checklist AI-built apps fail (7 things that break after the demo)

You built an app with an AI app builder, or vibe-coded it prompt by prompt over a few evenings. It works. But look at the conditions under which it works: your phone, your Wi-Fi, your account, data you typed in yourself, a build generated an hour ago. A demo is an app tested exclusively under friendly conditions.

Production ready means the opposite: the app keeps working once the friendly conditions are gone. Strangers instead of you, a reviewer instead of an audience, months instead of an afternoon.

We have already written about why this gap exists: our article on the seven walls between a prototype and the stores maps the structural distance, and our piece on building an app versus running one names the work that starts after launch. Those articles end in questions worth asking yourself. This one turns the questions into experiments: seven checks, each with a concrete procedure and a pass condition you cannot argue with, all of them runnable this week. If a check feels boring, that is the point. Production is where the boring bugs live.

1. A stranger can create an account, leave, and come back

The demo never signs out. You built the app already authenticated, on a device that remembers you, so the entire account machinery went untested: the confirmation email that lands in spam, the password reset that never arrives, the session that dies on every restart, the account that exists on your phone and nowhere else. Accounts are the first thing a stranger touches and the last thing a demo tests.

The check: on a device that has never seen your app (a relative's phone works, and for a web app, a private browsing window), create an account with an email address you own but have never used with it. Confirm it. Sign out. Reset the password. Sign back in. Close the app and come back the next day.

Pass when: every step works without you touching a dashboard, resending anything by hand, or explaining a workaround.

2. The app survives empty, offline, and double-tapped

Your demo runs on data you typed in, over a good connection, driven by the one person who knows where not to click. A real user starts with none of that: a brand-new account sees zero content, the subway kills the connection mid-action, and an impatient thumb taps the pay button twice. These are the boring states, and generated apps tend not to handle them, because nobody prompted for them. Apple gets to them before your users do: in our publishing team's experience, an app is routinely opened offline during review, and what it shows without a network counts.

The check: install fresh, or open the app in a private window, and use it in airplane mode; cut the connection mid-action too. Then walk through every screen with a new account that has zero data. Then tap every button that creates or pays for something twice, fast. Keep the payment side in your provider's test mode, or use a cheap item you refund right after: what you are looking for is whether two orders appear, not whether money moved.

Pass when: no blank screens, no infinite spinners, no crash, and no duplicate order.

3. The App Store and Google Play will take it

This is where your builder's output meets the outside world. The stores want signed native binaries, developer accounts (99 USD a year at Apple, a 25 USD one-time fee at Google), store metadata, and privacy declarations that did not exist a few years ago: Google Play's Data safety section has been required since July 2022, Apple's privacy manifests since May 2024. Many prompt-to-app tools generate web applications, because a web app is what a prompt can deploy in one step, so this wall tends to arrive late. A web app is a legitimate surface (GoodBarber ships a Progressive Web App alongside native), but it gives up the stores' distribution and, for most iOS users, push. And then comes review: of the first submissions our publishing team handled in the 12 months to April 2026, roughly 42% came back from Apple rejected, and that is the baseline for a prepared team, not a penalty for beginners.

The check: three questions, answered with names rather than guesses. Can your tool produce signed iOS and Android binaries? Do you have Apple and Google developer accounts? Can you state, today, what data the app collects, where it is stored, and which third-party services touch it?

Pass when: three yeses, in writing, before you book a launch date.

4. A push scheduled tonight is on the lock screen tomorrow

Push is the reason an app beats a website at retention, and it is also the feature a demo fakes best: everything looks wired until the first locked phone. Delivery is binary, which is why this check is an overnight experiment rather than a question. Since iOS 16.4 (March 2023), iOS delivers web push only to web apps the user has deliberately added to their Home Screen; in the browser, nothing rings. So an AI-built web app can look identical to a native app on your screen and still go silent the moment the phone locks. If you cannot even find where in your tool a push notification gets scheduled, you have your answer already: the check has failed.

The check: schedule a push notification to your own phone for 7:00 tomorrow morning, and lock the phone tonight.

Pass when: the message is sitting on the lock screen when you wake up.

5. You can name every service the app depends on, and every bill

A generated app is an assembled app. Under the demo sits a stack the prompt chose for you: hosting here, a database there, an email sender, image storage, analytics, maybe a payment processor. Each one has a login, a free tier that ends, keys that expire, and a bill that scales on its own curve. The demo hides all of this because for one user on one afternoon, everything is free and nothing has broken yet. Production asks a harder question: when the app is down at 2 a.m., which of these services do you check first, and who answers?

The check: write the inventory, starting where a non-developer actually can: search your inbox for every “Welcome to” and “Verify your email” message received while you were building, add every login you created along the way, every recurring charge on your card statement, and whatever your builder's integrations and billing pages list. For each line: who owns the account, what it costs at 1,000 users, and whether it renews silently.

Pass when: every line has an owner and a price. If drawing up the list surprised you, the surprise is the finding.

That inventory has a second use later on. The services on it are also what you would have to replace if you ever moved off your builder, which is where the real lock-in lives: we took that apart in you can own your app, but can you leave your AI app builder.

6. One change ships without dragging the rest along

The first update is the hardest test an AI-built app faces, because two clocks start ticking at launch. The first clock is yours: users find bugs, and fixing them by prompt can quietly rewrite parts that already worked, what we call regeneration drift. On a generated codebase, the one-label loop has a particular shape: change the label, regenerate, then discover which of the screens you did not touch changed anyway. The second clock belongs to Apple and Google: each ships a major OS every year, Google raises the minimum Android version an app must target annually, and Apple removes apps that go three years without an update and see almost no downloads, after a 90-day notice. An app you cannot safely change is an app you cannot keep published; we wrote up what quietly breaks when an app stops updating for the slow-motion version.

The check: change one visible detail (a label, a price, a color) and ship it: as a store update if you are live, or by regenerating and redeploying if you are not. Then verify that three things that worked before still work.

Pass when: the change shipped, the three re-tested flows still work, and the whole loop took an afternoon, not a week.

7. Someone can run the app without reopening the builder

Six months from now, what the app needs is operational, not generative: publish this week's article, change a price, answer a customer, send the promo push, read the numbers. If each of those means reopening the tool that generated the app and re-prompting carefully around what must not break, the app has a single point of failure: you, in the builder, forever. An app is operable when its daily tasks live in an interface built for them, or can be handed to someone else: a teammate, or an AI agent connected through an open protocol like MCP. Who does the running half of the job, and with what, decides more of your app's future than any screen you generated.

The check: list the five tasks your app will need every week. For each, name who does it and in which tool.

Pass when: none of the five answers is “me, re-prompting the builder and hoping”.

Score it honestly. Seven passes: announce the launch. One or two failures: you know what this week's work is. Three or more: what you have is a validated idea, which is genuinely valuable, and it deserves a foundation built for the part that comes next.

Here is why we can publish this checklist without flinching: on GoodBarber, most of it is not your job.

Checks 1 and 2 are pre-built. Accounts, sessions, offline behavior and empty states ship as native components, hardened across the thousands of live apps the platform hosts rather than generated fresh for yours. Check 3 is a service. GoodBarber compiles real native binaries, Swift for iOS and Kotlin for Android, plus a Progressive Web App from the same configuration. The privacy declarations Apple and Google ask for share their source of truth with the build itself, the features you switched on, so declaration and binary cannot drift apart. And if you would rather not face review alone, the publishing team that can take over your submission recovered 91% of Apple's first-submission rejections (internal publishing-team tracking, 12 months to April 2026).

Check 4 is infrastructure: the push pipeline runs end to end on the platform and moves several million notifications a week. Check 5 collapses into one line, because hosting, database, CMS, push, analytics and payment gateways live in one subscription, with 0% GoodBarber commission on e-commerce transactions. That consolidation is most of why total cost of ownership lands at roughly one tenth of custom development. And check 6 is absorbed upstream: when Apple or Google moves a requirement, GoodBarber patches it once, and your next update delivers it.

Check 7 is where AI comes back in, on the right side of the demo this time. Every GoodBarber app can be operated by an AI agent through the platform's MCP server: tell your assistant what you need, and the article goes out, the push gets scheduled, the price changes, and last week's numbers come back in plain language, from Claude, ChatGPT, Cursor or any MCP-aware client. The whole of check 7 becomes a delegation decision. And agent ready means the app can be operated by an agent, not that it runs itself: the rules and the final review stay with you.

GoodBarber's scope is content apps and mobile commerce: it does not build games, and a marketplace built on heavy custom logic deserves a different answer, which we would rather give you now. Inside that scope, this checklist is what the platform is built to carry. Somewhere, a GoodBarber app is downloaded every 4 seconds, and the platform's paying customers are spread across 152 countries. That is what passing these checks, year after year, adds up to.

What does “production ready” mean for a mobile app?

A production-ready app survives the three things a demo never contains: real users, real store review, and real time. Concretely: strangers can create accounts unassisted, the app handles empty and offline states, the stores accept its signed binaries and privacy declarations, push notifications are delivered, every service in its stack has a named owner, it can be updated without breaking what already works, and its weekly operation does not depend on one person.

Is my AI-built app production ready?

Run seven checks: account creation and recovery on a device that has never seen the app, empty and offline states, store submission with a signed native binary, push delivery on a locked phone, a priced inventory of every service in the stack, one update that changes nothing but what it meant to change, and week-to-week operation outside the builder. Pass all seven and you are ready to announce. The likeliest failures are store submission, push and the first update, because many AI app builders generate web applications rather than signed native binaries, and generation does not cover store compliance or maintenance.

Can an AI-built app pass App Store review?

Only as a real native app. Apple requires signed binaries, completed privacy declarations, and an app that is more than a repackaged website (Guideline 4.2). Rejection is normal rather than exceptional: Apple turned down roughly 42% of the first submissions GoodBarber's publishing team handled in the 12 months to April 2026, and 91% of those rejections were later accepted after rework.

What breaks first after launching an AI-built app?

The boring things, roughly in this order: authentication (confirmation emails, password resets, dead sessions), then empty and offline states, then push delivery, then the first update, where fixing one bug by prompt can rewrite parts that worked. The pattern behind all of them is the same: a demo is tested under friendly conditions, and production removes them one by one.

Do I need a developer to keep an AI-built app running?

If the app is generated code on an assembled stack, someone has to own that code and that stack, and that is developer work whether or not you can do it. On a managed platform like GoodBarber, the platform's engineering team maintains the code, hosting, push infrastructure and store compliance; you operate the app from a back office, or hand day-to-day tasks to an AI agent through the MCP server. You keep the operator's role, not the engineer's.

Next step: nothing you built is wasted. The demo settled the expensive question, whether the idea deserves an app, and your screens are now the spec. Start a free GoodBarber trial, rebuild the idea against that spec, and run this same checklist on the result: the first six checks are carried by the platform, and the seventh takes one sentence to an agent.