Was zu tun ist, wenn deine mit KI gebaute App um 2 Uhr nachts kaputtgeht (und du keine Entwicklerin bist)

Deine App lief gestern. Jetzt ist mitten in der Nacht, und etwas stimmt nicht. Hier ist ein ruhiges, nicht-technisches Playbook für das, was du tatsächlich tun solltest — ohne Code lesen zu können.

Du hast eine App gebaut, ohne eine Zeile Code zu schreiben. Sie lief die ganze Woche. Dann schreibt dir um 1:47 Uhr ein:e Nutzer:in, dass der Registrieren-Button nichts macht, und du wachst auf, weil dein Handy auf dem Nachttisch leuchtet.

Wenn du noch nie eine Live-App reparieren musstest, kann sich dieser Moment furchtbar anfühlen. Du liest keinen Code. Du weißt nicht, was “die Datenbank” wirklich heißt. Du bist nicht sicher, ob es richtig-kaputt oder nur-seltsam ist, und die Leute, die normalerweise helfen würden, schlafen.

Hier ist ein ruhiges, geordnetes Playbook für das, was zu tun ist, wenn eine mit KI gebaute App kaputtgeht und du keinen Code schreiben kannst. Das meiste davon dreht sich darum, es nicht schlimmer zu machen — der Teil, vor dem dich niemand warnt.

Zuerst: nicht neu deployen

Es gibt irgendwo in deinem KI-App-Builder einen Button, der so etwas sagt wie “neu veröffentlichen”, “neu deployen” oder “ausliefern”. Du wirst ihn gleich drücken wollen. Tu es noch nicht.

Auf einer halb kaputten App neu zu deployen kann den kaputten Zustand zementieren, alle Debug-Informationen wegfegen, die noch herumlagen, und es für jeden — auch den KI-Builder selbst — schwerer machen herauszufinden, was schiefgelaufen ist.

Der erste Zug ist immer hinzuschauen, nicht zu handeln. Du hast noch nicht mal bestätigt, was kaputt ist.

Schritt 1 — Stell das Problem selbst nach

Öffne die App in einem frischen Browser-Fenster — Inkognito- oder privater Modus ist am besten, weil er jeden alten Login oder Cache entfernt, der die Dinge für dich anders verhalten lassen könnte als für deine:n Nutzer:in.

Versuch, genau das zu tun, was der oder die Nutzer:in gemeldet hat. Wenn die Person sagte, der Registrieren-Button funktioniere nicht, versuch dich zu registrieren. Wenn sie sagte, das Dashboard sei leer, versuch dich einzuloggen und das Dashboard anzusehen.

Du suchst nach einer von drei Sachen:

  1. Es ist für alle kaputt. Du stößt auf dasselbe Problem. Das ist tatsächlich die einfachste Sorte zu beheben, weil es konsistent ist.
  2. Es funktioniert für dich. Das ist das schwerste Szenario, weil etwas an der spezifischen Situation des oder der Nutzer:in (ihr Browser, ihr Konto, ihre Daten) das Problem ist.
  3. Es ist sporadisch. Es funktioniert einmal und geht beim nächsten Mal kaputt. Das ist das stressigste, aber auch das informativste — es bedeutet meist, dass etwas in eine Zeitüberschreitung läuft oder eine Ressource ausgeht.

Schreib auf, welche der drei du gesehen hast. Du brauchst es, wenn du um Hilfe bittest.

Schritt 2 — Prüf die offensichtlichen externen Dinge, bevor du deine App beschuldigst

Eine überraschende Zahl von “meine App ist kaputt”-Momenten ist nicht deine App. Bevor du in deinen KI-Builder hinabsteigst, prüf:

  • Ist das Internet selbst in Ordnung? Öffne ein paar andere Seiten. Wenn dein WLAN wackelig ist, ist deine App vielleicht in Ordnung und du bist vielleicht die kaputte.
  • Hatte der KI-Builder selbst eine Störung? Die meisten KI-App-Builder haben eine Status-Seite (such den Produktnamen plus “status”). Wenn die eine schlechte Nacht haben, musst du nichts weiter herausfinden.
  • Ist eines deiner verbundenen Tools ausgefallen? Wenn deine App Stripe für Zahlungen, einen E-Mail-Dienst für Benachrichtigungen oder einen Datenbank-Dienst zum Speichern von Daten nutzt, kann jedes davon Störungen haben. Jedes hat seine eigene Status-Seite. Prüf die, von denen deine App abhängt.

Etwa eins von fünf Malen ist die Antwort “es ist eigentlich nicht meine App”, und du kannst wieder schlafen gehen.

Schritt 3 — Sieh dir die Fehlermeldung an, auch wenn sie dich erschreckt

Wenn deine App einen Screen mit Text darauf zeigt — selbst kauderwelsch aussehenden Text —, lies ihn. Mach einen Screenshot. Besonders wenn da eine lange Kette aus Buchstaben und Zahlen ist (Leute nennen das einen “Stack Trace”; es sieht aus wie Buchstabensuppe, aber es ist das Nützlichste, was du beim Hilfesuchen haben kannst).

Die meisten KI-App-Builder haben auch einen Ort, an dem du kürzlich aufgetretene Fehler sehen kannst. Er heißt vielleicht Logs, Aktivität, Fehler oder Konsole. Öffne ihn. Du musst das meiste, was du siehst, nicht verstehen — du suchst nach dem neuesten roten Text oder dem neuesten Fehler und der Uhrzeit, zu der er passiert ist. Die Zeit ist wichtig: Ein Fehler von gestern Morgen ist wahrscheinlich nicht der Grund, warum dein:e Nutzer:in sich gerade eben nicht registrieren konnte.

Kopier diesen Fehler. Du wirst ihn gleich an einen hilfreichen Ort einfügen.

Schritt 4 — Frag den KI-Builder, was sich geändert hat

Das ist der Zug, den die meisten nicht-technischen Builder unterschätzen. Öffne den Chat mit deinem KI-Builder und sag, in einfacher Sprache:

“Meine App ist kaputt. Nutzer:innen können sich nicht registrieren — der Button tut nichts. Hier ist der Fehler aus den Logs: [einfügen]. Was hat sich in den letzten 24 Stunden geändert, und was könnte das verursachen?”

Ein guter KI-Builder wird dir sagen, welche kürzliche Änderung am wahrscheinlichsten verantwortlich ist. Manchmal erkennst du sie sofort (“ach, ich habe es gestern gebeten, das Formular schöner aussehen zu lassen, und das hat wahrscheinlich die Absende-Logik kaputtgemacht”). Manchmal zeigt es auf etwas, an das du dich nicht erinnerst, angefasst zu haben, was auch nützlich ist — es bedeutet, dass sich etwas automatisch geändert hat, etwa ein verbundenes Tool, das sich aktualisiert.

Lass den KI-Builder noch keine Korrekturen machen. Du bist noch im Diagnose-Modus. Der häufigste Weg, auf dem ich Leute ein kleines Problem schlimmer machen sehe, ist, eine KI “Dinge reparieren” zu lassen, bevor irgendjemand versteht, was kaputt ist.

Schritt 5 — Entscheide, ob du zurückrollst

Fast jeder KI-App-Builder lässt dich zu einer früheren Version deiner App zurückgehen. Manchmal heißt es “Verlauf”, “Versionen”, “Checkpoints” oder “Rollback”.

Wenn du dich klar an eine Stunde oder einen Tag erinnern kannst, in dem die App funktionierte, ist das Zurückgehen zu dieser Version der zuverlässigste einzelne Zug. Er kostet dich, welche Änderungen du dazwischen auch gemacht hast (die du vielleicht ohnehin nicht mehr willst), und er gibt dir eine funktionierende App, mit der du aufwachst.

Eine gute Regel: Wenn das Kaputte etwas ist, das Nutzer:innen täglich tun (Registrieren, Login, Zahlung), roll zuerst zurück und repariere später vorwärts. Funktionierend-aber-veraltet schlägt kaputt-und-aktuell jedes Mal.

Wenn das Kaputte ein Feature ist, das du heute hinzugefügt hast und von dem noch niemand abhängt, kannst du es bis zum Morgen kaputt lassen und es mit klarem Kopf reparieren.

Schritt 6 — Wenn du den KI-Builder es reparieren lassen musst

Wenn ein Rollback nicht möglich ist oder du dich dagegen entschieden hast, dann lass den KI-Builder eine Behebung vorschlagen. Zwei Dinge, die du dabei im Kopf behalten solltest:

Lies, was er zu ändern plant, bevor du zustimmst. Du wirst nicht alles davon verstehen, aber du kannst erkennen, ob er ein fokussiertes Ding bearbeitet oder die halbe App neu schreibt. Kleine, fokussierte Änderungen sind viel sicherer als weitreichende um 2 Uhr nachts.

Teste die Behebung auf die langweiligste mögliche Weise. Frag nicht einfach “ist es repariert?” und vertrau der Antwort. Geh tatsächlich selbst in einem Inkognito-Fenster zur App und tu das, was kaputt war. Wenn die Behebung funktioniert hat, funktioniert das Kaputte jetzt. Wenn nicht, akzeptier die Änderung nicht nur, weil der KI-Builder sagte, sie funktioniere.

Schritt 7 — Schreib dem oder der Nutzer:in zurück, auch wenn du es nicht repariert hast

Der oder die Nutzer:in, der dir um 1:47 Uhr geschrieben hat, erwartet nicht, dass du online bist. Aber wenn du es bist, zählt eine kurze Antwort mehr, als eine Behebung es täte:

“Danke, dass du mir Bescheid gibst — ich schau mir das gerade an. Ich melde mich, sobald es wieder läuft.”

Wenn die Person ein:e zahlende:r Nutzer:in ist, ist diese eine Nachricht der Unterschied zwischen “sie erzählen Leuten, dass du schnell reagierst” und “sie erzählen Leuten, dass du sie ghostest”. Die Behebung kann bis zum Morgen warten. Die Antwort kann es nicht.

Die größere Lektion: bau deine App, als könnte sie kaputtgehen

Wenn du das stressig fandest, ist der Silberstreif, dass die Erfahrung umformen wird, wie du baust. Nach deinem ersten 2-Uhr-Vorfall fängst du an, Dinge anders zu machen:

  • Du fügst eine Statusprüfung hinzu. Eine simple Seite, die dir sagt, ob die wichtigen Teile deiner App funktionieren, damit du dich nicht einloggen musst, um es herauszufinden.
  • Du behältst ein Backup der Nutzerdaten. Die meisten KI-Builder exportieren deine Daten auf Anfrage. Das einmal pro Woche zu machen dauert 30 Sekunden und rettet dich im schlimmsten Fall.
  • Du schreibst auf, wovon deine App abhängt. Eine kurze Liste jedes verbundenen Tools (Zahlungen, E-Mail, Datenbank, Speicher), damit du, wenn um 2 Uhr nachts etwas kaputtgeht, eine Checkliste statt Vermutungen hast.
  • Du änderst eine Sache nach der anderen. Wenn du 10 Änderungen auf einmal machst und die App kaputtgeht, hast du keine Ahnung, welche Änderung sie kaputtgemacht hat. Wenn du eine Änderung nach der anderen machst, schon.

Du kannst eine App ohne Programmieren bauen. Du kannst sie auch am Laufen halten, ohne Entwickler:in zu sein — aber die nötigen Fähigkeiten sind andere als die Bau-Fähigkeiten. Du lernst sie meist auf die harte Tour, üblicherweise zu einer ungelegenen Stunde.

Die gute Nachricht: Jedes Mal, wenn es passiert, wird es weniger beängstigend. Beim dritten Mal ist es nervig statt erschreckend. Beim zehnten ist es einfach Dienstag.