Die Produktions-Checkliste, an der mit KI gebaute Apps scheitern (7 Dinge, die nach der Demo kaputtgehen)

Sie haben eine App mit einem KI-App-Builder gebaut, oder sie an ein paar Abenden per Vibe Coding Prompt für Prompt entstehen lassen. Sie funktioniert. Aber sehen Sie sich die Bedingungen an, unter denen sie funktioniert: Ihr Telefon, Ihr WLAN, Ihr Konto, Daten, die Sie selbst eingetippt haben, ein Build, der vor einer Stunde generiert wurde. Eine Demo ist eine App, die ausschließlich unter freundlichen Bedingungen getestet wurde.

Produktionsreif heißt das Gegenteil: Die App funktioniert weiter, sobald die freundlichen Bedingungen wegfallen. Fremde statt Sie, ein Reviewer statt eines Publikums, Monate statt eines Nachmittags.

Warum diese Lücke existiert, haben wir bereits aufgeschrieben: Unser Artikel über die sieben Mauern zwischen einem Prototyp und den Stores kartiert die strukturelle Distanz, und unser Text über den Unterschied zwischen Bauen und Betreiben benennt die Arbeit, die nach dem Launch beginnt. Diese Artikel enden mit Fragen, die Sie sich stellen sollten. Dieser hier macht aus den Fragen Experimente: sieben Checks, jeder mit einem konkreten Ablauf und einer Bestehensbedingung, über die sich nicht streiten lässt, und alle noch diese Woche durchführbar. Wenn sich ein Check langweilig anfühlt, ist das Absicht. Die Produktion ist der Ort, an dem die langweiligen Bugs wohnen.

1. Ein Fremder kann ein Konto anlegen, gehen und wiederkommen

Die Demo loggt sich nie aus. Sie haben die App bereits angemeldet gebaut, auf einem Gerät, das Sie kennt, also blieb die gesamte Konto-Maschinerie ungetestet: die Bestätigungs-E-Mail, die im Spam landet, das Passwort-Reset, das nie ankommt, die Session, die bei jedem Neustart stirbt, das Konto, das auf Ihrem Telefon existiert und sonst nirgends. Konten sind das Erste, was ein Fremder anfasst, und das Letzte, was eine Demo testet.

Der Check: Legen Sie auf einem Gerät, das Ihre App noch nie gesehen hat (das Telefon eines Verwandten reicht, bei einer Web-App ein privates Browserfenster), ein Konto mit einer E-Mail-Adresse an, die Ihnen gehört, die die App aber noch nie gesehen hat. Bestätigen Sie es. Loggen Sie sich aus. Setzen Sie das Passwort zurück. Loggen Sie sich wieder ein. Schließen Sie die App und kommen Sie am nächsten Tag zurück.

Bestanden, wenn: jeder Schritt funktioniert, ohne dass Sie ein Dashboard anfassen, etwas von Hand nachsenden oder einen Workaround erklären müssen.

2. Die App überlebt leer, offline und doppelt angetippt

Ihre Demo läuft auf Daten, die Sie selbst eingetippt haben, über eine gute Verbindung, bedient von der einen Person, die weiß, wo man nicht hinklicken darf. Ein echter Nutzer startet ohne all das: Ein brandneues Konto sieht null Inhalte, die U-Bahn kappt die Verbindung mitten in der Aktion, und ein ungeduldiger Daumen tippt den Bezahl-Button zweimal. Das sind die unglamourösen Zustände, und generierte Apps behandeln sie in der Regel nicht, weil niemand danach gepromptet hat. Apple findet sie vor Ihren Nutzern: Nach der Erfahrung unseres Publishing-Teams wird eine App im Review routinemäßig offline geöffnet, und was sie ohne Netz zeigt, zählt.

Der Check: Installieren Sie frisch, oder öffnen Sie die App in einem privaten Fenster, und benutzen Sie sie im Flugmodus; kappen Sie die Verbindung auch mitten in einer Aktion. Gehen Sie dann mit einem neuen Konto ohne jegliche Daten durch jeden Screen. Tippen Sie anschließend jeden Button, der etwas anlegt oder bezahlt, zweimal, schnell hintereinander. Lassen Sie den Zahlungsteil im Testmodus Ihres Anbieters, oder nehmen Sie einen günstigen Artikel, den Sie direkt danach erstatten: Sie wollen wissen, ob zwei Bestellungen auftauchen, nicht, ob Geld geflossen ist.

Bestanden, wenn: keine leeren Screens, keine endlosen Ladekringel, kein Absturz und keine doppelte Bestellung.

3. Der App Store und Google Play nehmen sie an

Hier trifft das Ergebnis Ihres Builders auf die Außenwelt. Die Stores verlangen signierte native Binaries, Entwicklerkonten (99 USD pro Jahr bei Apple, einmalig 25 USD bei Google), Store-Metadaten und Datenschutzangaben, die es vor wenigen Jahren noch nicht gab: Der Abschnitt „Data safety“ bei Google Play ist seit Juli 2022 Pflicht, Apples Privacy Manifests seit Mai 2024. Viele Prompt-to-App-Tools generieren Webanwendungen, weil eine Web-App das ist, was ein Prompt in einem Schritt deployen kann, also taucht diese Mauer meist spät auf. Eine Web-App ist eine legitime Oberfläche (GoodBarber liefert eine Progressive Web App neben der nativen App aus), aber sie verzichtet auf die Distribution der Stores und, für die meisten iOS-Nutzer, auf Push. Und dann kommt das Review: Von den Ersteinreichungen, die unser Publishing-Team in den zwölf Monaten bis April 2026 betreut hat, kamen rund 42% von Apple abgelehnt zurück, und das ist die Ausgangslage für ein vorbereitetes Team, keine Strafe für Anfänger.

Der Check: Drei Fragen, beantwortet mit Namen statt mit Vermutungen. Kann Ihr Tool signierte iOS- und Android-Binaries erzeugen? Haben Sie Entwicklerkonten bei Apple und Google? Können Sie heute sagen, welche Daten die App sammelt, wo sie gespeichert werden und welche Drittdienste darauf zugreifen?

Bestanden, wenn: dreimal Ja, schriftlich, bevor Sie einen Launch-Termin festlegen.

4. Ein heute Abend geplanter Push liegt morgen auf dem Sperrbildschirm

Push ist der Grund, warum eine App eine Website bei der Retention schlägt, und zugleich das Feature, das eine Demo am besten vortäuscht: Alles wirkt angeschlossen, bis zum ersten gesperrten Telefon. Zustellung ist binär, deshalb ist dieser Check ein Experiment über Nacht und keine Frage. Seit iOS 16.4 (März 2023) stellt iOS Web-Push nur an Web-Apps zu, die der Nutzer bewusst zu seinem Home-Bildschirm hinzugefügt hat; im Browser klingelt nichts. Eine mit KI gebaute Web-App kann auf Ihrem Bildschirm also identisch mit einer nativen App aussehen und trotzdem verstummen, sobald sich das Telefon sperrt. Wenn Sie nicht einmal finden, wo in Ihrem Tool eine Push-Benachrichtigung geplant wird, haben Sie Ihre Antwort schon: Der Check ist durchgefallen.

Der Check: Planen Sie eine Push-Benachrichtigung an Ihr eigenes Telefon für morgen früh um 7:00 Uhr, und sperren Sie das Telefon heute Abend.

Bestanden, wenn: die Nachricht beim Aufwachen auf dem Sperrbildschirm liegt.

5. Sie können jeden Dienst nennen, von dem die App abhängt, und jede Rechnung

Eine generierte App ist eine zusammengesetzte App. Unter der Demo liegt ein Stack, den der Prompt für Sie ausgewählt hat: Hosting hier, eine Datenbank dort, ein E-Mail-Versender, Bildspeicher, Analytics, vielleicht ein Zahlungsdienstleister. Jeder davon hat einen Login, einen Gratis-Tarif, der endet, Schlüssel, die ablaufen, und eine Rechnung, die auf ihrer eigenen Kurve wächst. Die Demo versteckt all das, weil für einen Nutzer an einem Nachmittag alles gratis ist und noch nichts kaputtgegangen ist. Die Produktion stellt eine härtere Frage: Wenn die App um 2 Uhr nachts down ist, welchen dieser Dienste prüfen Sie zuerst, und wer geht ran?

Der Check: Schreiben Sie das Inventar, und beginnen Sie dort, wo ein Nicht-Entwickler tatsächlich beginnen kann: Durchsuchen Sie Ihr Postfach nach jeder „Welcome to“- und „Verify your email“-Nachricht, die während des Bauens angekommen ist, ergänzen Sie jeden Login, den Sie unterwegs angelegt haben, jede wiederkehrende Abbuchung auf Ihrer Kartenabrechnung und alles, was die Integrations- und Abrechnungsseiten Ihres Builders auflisten. Für jede Zeile: Wem gehört das Konto, was kostet es bei 1.000 Nutzern, und verlängert es sich stillschweigend?

Bestanden, wenn: jede Zeile einen Eigentümer und einen Preis hat. Wenn Sie die Liste beim Aufstellen überrascht hat, ist die Überraschung der Befund.

Dieses Inventar hat später noch einen zweiten Nutzen. Genau diese Dienste müssten Sie ersetzen, wenn Sie Ihren Builder eines Tages verlassen wollen, und dort sitzt der eigentliche Lock-in: Wir haben das in unserem Artikel darüber auseinandergenommen, warum eine App, die Ihnen gehört, noch lange keine App ist, die Sie mitnehmen können.

6. Eine Änderung geht raus, ohne den Rest mitzureißen

Das erste Update ist der härteste Test für eine mit KI gebaute App, denn beim Launch beginnen zwei Uhren zu ticken. Die erste Uhr ist Ihre: Nutzer finden Bugs, und wer sie per Prompt behebt, kann dabei stillschweigend Teile umschreiben lassen, die bereits funktionierten, was wir regeneration drift nennen (das stille Abdriften des Codes bei jeder Neugenerierung). Auf einer generierten Codebasis hat die Ein-Label-Schleife eine eigene Form: das Label ändern, neu generieren und dann entdecken, welcher der Screens, die Sie gar nicht angefasst haben, sich trotzdem verändert hat. Die zweite Uhr gehört Apple und Google: Beide liefern jedes Jahr ein großes OS aus, Google hebt jährlich die Android-Mindestversion an, auf die eine App zielen muss, und Apple entfernt Apps, die drei Jahre ohne Update bleiben und fast keine Downloads mehr verzeichnen, nach einer Ankündigungsfrist von 90 Tagen. Eine App, die Sie nicht gefahrlos ändern können, ist eine App, die Sie nicht veröffentlicht halten können; die Zeitlupenfassung steht in unserem Artikel darüber, was leise kaputtgeht, wenn eine App keine Updates mehr bekommt.

Der Check: Ändern Sie ein sichtbares Detail (ein Label, einen Preis, eine Farbe) und liefern Sie es aus: als Store-Update, wenn Sie live sind, oder per Neugenerierung und Redeploy, wenn nicht. Prüfen Sie danach, ob drei Dinge, die vorher funktioniert haben, immer noch funktionieren.

Bestanden, wenn: die Änderung ausgeliefert ist, die drei erneut getesteten Abläufe weiterhin funktionieren und die ganze Schleife einen Nachmittag gedauert hat, keine Woche.

7. Jemand kann die App betreiben, ohne den Builder wieder zu öffnen

In sechs Monaten braucht die App operative Arbeit, keine generative: den Artikel dieser Woche veröffentlichen, einen Preis ändern, einem Kunden antworten, den Promo-Push verschicken, die Zahlen lesen. Wenn jede dieser Aufgaben bedeutet, das Tool wieder zu öffnen, das die App generiert hat, und vorsichtig um das herumzuprompten, was nicht kaputtgehen darf, hat die App einen Single Point of Failure: Sie, im Builder, für immer. Eine App ist betreibbar, wenn ihre täglichen Aufgaben in einer Oberfläche leben, die dafür gebaut ist, oder wenn sie sich weiterreichen lassen: an einen Kollegen oder an einen KI-Agenten, der über ein offenes Protokoll wie MCP verbunden ist. Wer die Betriebshälfte des Jobs übernimmt, und womit, entscheidet mehr über die Zukunft Ihrer App als jeder Screen, den Sie generiert haben.

Der Check: Listen Sie die fünf Aufgaben auf, die Ihre App jede Woche brauchen wird. Benennen Sie für jede, wer sie erledigt und in welchem Tool.

Bestanden, wenn: keine der fünf Antworten „ich, per Prompt im Builder, und Daumen drücken“ lautet.

Werten Sie ehrlich aus. Sieben Mal bestanden: Kündigen Sie den Launch an. Ein oder zwei Fehlschläge: Sie wissen, was die Arbeit dieser Woche ist. Drei oder mehr: Was Sie haben, ist eine validierte Idee, und das ist wirklich wertvoll, aber sie verdient ein Fundament, das für den Teil gebaut ist, der jetzt kommt.

Warum wir diese Checkliste veröffentlichen können, ohne zu zucken: Auf GoodBarber ist das meiste davon nicht Ihr Job.

Die Checks 1 und 2 sind fertig eingebaut. Konten, Sessions, Offline-Verhalten und leere Zustände kommen als native Komponenten, gehärtet an den Tausenden live geschalteter Apps, die die Plattform hostet, statt frisch für Ihre generiert zu werden. Check 3 ist ein Service. GoodBarber kompiliert echte native Binaries, Swift für iOS und Kotlin für Android, plus eine Progressive Web App aus derselben Konfiguration. Die Datenschutzangaben, die Apple und Google verlangen, teilen ihre Quelle der Wahrheit mit dem Build selbst, den Features, die Sie aktiviert haben, sodass Erklärung und Binary nicht auseinanderdriften können. Und wenn Sie dem Review lieber nicht allein gegenübertreten wollen: Das Publishing-Team, das Ihre Einreichung übernehmen kann, hat 91% der von Apple abgelehnten Ersteinreichungen am Ende doch noch durchgebracht (internes Tracking des Publishing-Teams, zwölf Monate bis April 2026).

Check 4 ist Infrastruktur: Die Push-Pipeline läuft Ende zu Ende auf der Plattform und bewegt mehrere Millionen Benachrichtigungen pro Woche. Check 5 schrumpft auf eine Zeile, weil Hosting, Datenbank, CMS, Push, Analytics und Zahlungs-Gateways in einem Abo leben, mit 0% GoodBarber-Provision auf E-Commerce-Transaktionen. Diese Konsolidierung ist der Hauptgrund, warum die Gesamtkosten bei ungefähr einem Zehntel einer Individualentwicklung landen. Und Check 6 wird vorgelagert abgefangen: Wenn Apple oder Google eine Anforderung ändert, patcht GoodBarber sie einmal, und Ihr nächstes Update liefert sie mit.

Check 7 ist die Stelle, an der die KI zurückkommt, diesmal auf der richtigen Seite der Demo. Jede GoodBarber-App lässt sich von einem KI-Agenten über den MCP-Server der Plattform steuern: Sagen Sie Ihrem Assistenten, was Sie brauchen, und der Artikel geht raus, der Push wird eingeplant, der Preis ändert sich, und die Zahlen der letzten Woche kommen im Klartext zurück, aus Claude, ChatGPT, Cursor oder jedem anderen MCP-fähigen Client. Der ganze Check 7 wird zu einer Delegationsentscheidung. Und agent-ready heißt, dass die App von einem Agenten gesteuert werden kann, nicht, dass sie von selbst läuft: Die Regeln und die letzte Prüfung bleiben bei Ihnen.

GoodBarbers Zuschnitt sind Content-Apps und Mobile Commerce: Es baut keine Spiele, und ein Marktplatz mit schwerer individueller Logik verdient eine andere Antwort, die wir Ihnen lieber jetzt geben. Innerhalb dieses Zuschnitts ist diese Checkliste genau das, wofür die Plattform gebaut ist. Irgendwo auf der Welt wird alle 4 Sekunden eine GoodBarber-App heruntergeladen, und die zahlenden Kunden der Plattform verteilen sich auf 152 Länder. Genau das kommt dabei heraus, wenn man diese Checks Jahr für Jahr besteht.

Was bedeutet „produktionsreif“ bei einer mobilen App?

Eine produktionsreife App überlebt die drei Dinge, die eine Demo nie enthält: echte Nutzer, echtes Store-Review und echte Zeit. Konkret: Fremde können ohne Hilfe Konten anlegen, die App beherrscht leere und Offline-Zustände, die Stores akzeptieren ihre signierten Binaries und Datenschutzangaben, Push-Benachrichtigungen werden zugestellt, jeder Dienst in ihrem Stack hat einen benannten Eigentümer, sie lässt sich aktualisieren, ohne Funktionierendes zu zerstören, und ihr wöchentlicher Betrieb hängt nicht an einer einzigen Person.

Ist meine mit KI gebaute App produktionsreif?

Führen Sie sieben Checks durch: Kontoanlage und Kontowiederherstellung auf einem Gerät, das die App noch nie gesehen hat, leere und Offline-Zustände, Store-Einreichung mit einem signierten nativen Binary, Push-Zustellung auf einem gesperrten Telefon, ein Inventar aller Dienste im Stack mit Preisen, ein Update, das nichts verändert außer dem, was es verändern sollte, und der Betrieb Woche für Woche außerhalb des Builders. Bestehen Sie alle sieben, können Sie den Launch ankündigen. Die wahrscheinlichsten Fehlschläge sind Store-Einreichung, Push und das erste Update, weil viele KI-App-Builder Webanwendungen statt signierter nativer Binaries generieren und die Generierung weder Store-Compliance noch Wartung abdeckt.

Kann eine mit KI gebaute App das Review im App Store bestehen?

Nur als echte native App. Apple verlangt signierte Binaries, vollständige Datenschutzangaben und eine App, die mehr ist als eine verpackte Website (Guideline 4.2). Ablehnung ist die Regel, nicht die Ausnahme: Apple hat rund 42% der Ersteinreichungen abgelehnt, die das Publishing-Team von GoodBarber in den zwölf Monaten bis April 2026 betreut hat, und 91% dieser Ablehnungen wurden nach Nacharbeit später angenommen.

Was geht nach dem Launch einer mit KI gebauten App zuerst kaputt?

Die unglamourösen Dinge, ungefähr in dieser Reihenfolge: die Authentifizierung (Bestätigungs-E-Mails, Passwort-Resets, tote Sessions), dann leere und Offline-Zustände, dann die Push-Zustellung, dann das erste Update, bei dem das Beheben eines Bugs per Prompt Teile umschreiben kann, die funktionierten. Das Muster dahinter ist immer dasselbe: Eine Demo wird unter freundlichen Bedingungen getestet, und die Produktion entfernt sie eine nach der anderen.

Brauche ich einen Entwickler, um eine mit KI gebaute App am Laufen zu halten?

Wenn die App generierter Code auf einem zusammengesetzten Stack ist, muss jemand diesen Code und diesen Stack verantworten, und das ist Entwicklerarbeit, ob Sie sie beherrschen oder nicht. Auf einer verwalteten Plattform wie GoodBarber pflegt das Engineering-Team der Plattform Code, Hosting, Push-Infrastruktur und Store-Compliance; Sie steuern die App aus einem Back-Office, oder Sie übergeben die täglichen Aufgaben über den MCP-Server an einen KI-Agenten. Sie behalten die Rolle des Betreibers, nicht die des Ingenieurs.

Der nächste Schritt: Nichts von dem, was Sie gebaut haben, ist verloren. Die Demo hat die teure Frage geklärt, ob die Idee eine App verdient, und Ihre Screens sind jetzt die Spezifikation. Starten Sie eine kostenlose GoodBarber-Testphase, bauen Sie die Idee entlang dieser Spezifikation neu, und lassen Sie dieselbe Checkliste über das Ergebnis laufen: Die ersten sechs Checks trägt die Plattform, und für den siebten genügt ein Satz an einen Agenten.