8 Anzeichen, dass Ihre KI-App nur eine Demo ist – und kein echtes Produkt
Ein Freund schickte mir freitags abends einen Link. „Probier das mal aus, ist noch nicht fertig, aber funktioniert."
Schon ein schlechtes Zeichen: localhost:3050. 😬
TL;DR: 8 Anzeichen, dass deine KI-App nicht produktionsreif ist. Für jedes Problem: was kaputt geht, warum es kaputt geht und ein Claude Code Prompt zur Lösung. Unverzichtbar, wenn du bereits etwas ausgeliefert hast – auch wenn es nur ein persönliches Tool ist, von dem noch niemand weiß.
Ich sagte es ihm. Zehn Minuten später schickte er einen ordentlichen Link.
Ich öffnete die App, schaute mich um. Die Idee war solide. Aber Berufskrankheit – ich drückte F12. Öffnete die Konsole.
Was ich fand, war eine Sammlung von allem, was Apps in der Produktion killt.
CORS-Fehler drei Ebenen tief gestapelt. Ein OpenAI API-Schlüssel im Klartext in den Netzwerk-Requests. Ein SELECT * bei jedem Tastendruck im Suchfeld. Nirgendwo Rate Limiting. Als ich fragte, wie er Fehler in der Produktion überwacht, sagte er: „Ich schaue einfach, ob es abstürzt."
Kein Produkt. Eine Demo mit Domain-Name.
Klassisch.
Es gibt eine Version von „fertig", die genauso aussieht wie das echte Ding. Gleiche UI. Gleiche URL. Manchmal sogar zahlende Nutzer. Aber darunter läuft es auf Annahmen, die nur funktionieren, wenn nichts schief geht.
Eine Demo ist darauf optimiert zu beeindrucken. Ein Produkt ist darauf optimiert zu überleben. Das sind nicht zwei Punkte auf einem Spektrum, das sind zwei völlig verschiedene Build-Modi. Eine Demo ist erfolgreich, wenn sie einmal vor jemandem funktioniert. Ein Produkt muss zehntausend Mal funktionieren, während du nicht hinschaust.
Jedes Anzeichen auf dieser Liste ist eine direkte Konsequenz dieser einen Unterscheidung.
1. Du hast null Einblick in das, was in der Produktion passiert
Wenn deine Monitoring-Strategie „Ich merke schon, wenn es abstürzt" ist, hast du kein Monitoring. Du hast Hoffnung.
Keine strukturierten Logs. Keine Fehler-Alerts. Keine Uptime-Checks. Im Demo-Modus führst du die App selbst aus, siehst alles, nichts überrascht dich. In der Produktion können Features drei Tage lang stillschweigend kaputt sein. Nutzer kommen nicht mehr zurück. Du hast keine Ahnung warum.
Ich hatte einen n8n Webhook, der 48 Stunden lang nicht mehr verarbeitet hat. Fand es zufällig heraus, während ich etwas anderes debuggte. Dann las ich einen Kommentar unter einem meiner Medium-Artikel, der fragte, warum das Tool, das ich erwähnt hatte, 503er zurückgibt. Der Artikel war drei Tage alt. Das Tool war down, seit ich ihn veröffentlicht hatte.
Fix: Sentry Free Tier für Runtime-Fehler. UptimeRobot für Uptime. Insgesamt fünfzehn Minuten. Keine Ausrede.
„Richte grundlegendes Produktions-Monitoring für diese App ein. Füge Sentry für Error Tracking hinzu, integriere UptimeRobot über einen /health Endpoint und füge einen Slack Webhook Alert für jede unbehandelte Exception in der Produktion hinzu."
Du brauchst keinen Kriegsraum. Du brauchst einen Rauchmelder.
2. Du hast keine Staging-Umgebung
Die App meines Freundes lief auf einem Server. Demselben Server, auf dem er aktiv entwickelte. Das bedeutete: jedes Mal, wenn er einen Fix pushte, war die Produktion die Test-Umgebung.
Ich habe mal OpenClaws Auth für zwei Stunden kaputt gemacht, weil eine Umgebungsvariable in der Produktion einen etwas anderen Namen hatte als lokal. Die Art von Sache, die du sofort in Staging abfängst. Die Art von Sache, die Nutzer denken lässt, deine App loggt sie zufällig aus, und dann kommen sie nicht mehr zurück.
Staging muss nicht fancy sein. Ein $3 VPS (ich betreibe meins auf einer $5 Kiste – gleiches Prinzip). Ein Vercel Preview Branch. Ein GitHub Actions Workflow, der bei jedem PR auf Staging und nur bei Merge zu main auf Produktion deployed.
Alles, was eine Schicht zwischen „Ich habe gerade etwas geändert" und „echte Nutzer treffen darauf" schafft. Der Punkt ist nicht, einen perfekten Prozess zu haben. Der Punkt ist, ein Deployment zu haben, das nicht direkt auf echte Nutzer zeigt.
„Erstelle ein Staging-Environment-Setup für dieses Projekt. Separate .env.local und .env.production, füge einen GitHub Actions Workflow hinzu, der bei PR auf Staging und bei Merge zu main auf Produktion deployed, und füge eine Pre-Deploy-Checkliste zur README hinzu."
3. Deine API-Schlüssel stehen im Code
Das ist, was die KI standardmäßig generiert:
const openai = new OpenAI({ apiKey: "sk-proj-..." });Es funktioniert. Es ist auch einen git push davon entfernt, öffentlich zu sein.
Ich erkläre nicht wie, aber ich habe Freunde, die nie für ein einziges SaaS-Tool zahlen. Nicht weil sie etwas raubkopieren. Weil sie alle paar Monate einen zweiminütigen Scan laufen lassen und genug geleakte Schlüssel finden, um ihren Stack für das nächste Quartal zu decken. Sitzen in öffentlichen Repos. Vergessen in der Commit-History. Wie eine postapokalyptische Welt, wo die Türen offen stehen und die Kühlschränke noch voll sind. Niemand hat aufgeräumt, bevor sie gegangen sind.
Dein Schlüssel ist wahrscheinlich gerade in einem dieser Kühlschränke.
Die KI hat kein Konzept davon, ob du eine persönliche Todo-App oder ein SaaS mit zahlenden Kunden baust. Sie setzt den Schlüssel dahin, wo es bequem ist. „Das wird auf GitHub landen" ist nicht in ihrem Bedrohungsmodell.
Fix: .env Datei, .gitignore, fertig. Dann führe git log -p | grep -i "api_key" auf deinen bestehenden Repos aus. Du magst nicht mögen, was du findest.
„Prüfe diese Codebase auf hardcodierte API-Schlüssel, Token und Secrets. Liste jedes Vorkommen mit Datei und Zeilennummer auf. Generiere die vollständige .env Migration und aktualisiere alle Referenzen auf process.env."
(Das ist kein Anfängerfehler. Das ist ein „schnell bewegen ohne Checkliste"-Fehler. Erwischt jeden irgendwann.)
4. Du hast kein Rate Limiting
Jemand wird deinen API-Endpoint finden. Könnte ein Bot sein. Könnte ein neugieriger Nutzer sein. Könnte ein Scraper sein, der deine URL in einer Sitemap gefunden hat. Egal wer. Wichtig ist, dass sie ihn 400 Mal in drei Minuten treffen werden und du es auf deinem Billing-Dashboard herausfindest.
Bei ContentForge hatte ich einen Generation-Endpoint ohne Limits. Ein Scraper traf ihn, bevor ich überhaupt öffentlich gelauncht hatte. Kein Schaden, weil ich es schnell erwischt habe. Aber der mentale Alarm war laut: hätte ich die Logs an diesem Morgen nicht beobachtet, hätte ich mein gesamtes API-Budget verbrannt, bevor der erste echte Nutzer aufgetaucht wäre.
Fix: express-rate-limit in Node. Rate Limiting auf Traefik- oder Nginx-Ebene, wenn du selbst hostest. Fünf Zeilen Config. Stoppt 90% des dummen Zeugs, bevor es zu teurem Zeug wird.
„Füge Rate Limiting zu allen API-Endpoints in dieser Codebase hinzu. Verwende express-rate-limit mit 100 Requests pro 15 Minuten pro IP als Standard. Wende strengere Limits auf Auth-Routen und jeden Endpoint an, der einen externen API-Call auslöst."
5. Du hast nie getestet, was passiert, wenn jemand etwas Dummes macht
Die KI generiert den Happy Path. Jedes Mal.
Der Nutzer füllt das Formular korrekt aus, klickt den richtigen Button, hat eine stabile Verbindung, doppelklickt nicht auf Submit. Was sie nicht generiert: leere Feld-Submissions. File-Uploads mit 0 Bytes. Sessions, die mid-form ablaufen. Derselbe Button zweimal geklickt, weil der erste Klick sich langsam anfühlte.
Bei ContentForge submitete ein Nutzer einen leeren Prompt. NaN wurde in die Datenbank geschrieben. Was in kaputte Metadaten bei jedem danach generierten Artikel kaskadierte. Fand es zwei Tage später, während ich etwas völlig anderes debuggte.
Fix: bevor du den Link mit jemandem teilst, verbringe zehn Minuten damit, aktiv zu versuchen, deine eigene App kaputt zu machen. Keine Unit Tests erforderlich. Einfach Chaos. Klicke Sachen in der falschen Reihenfolge. Lass Felder leer. Submitte zweimal. Refreshe mid-operation.
Oder führe das zuerst in Claude Code aus:
„Agiere als böswilliger Nutzer, der versucht, diese App kaputt zu machen. Teste jedes Formular mit leeren Inputs, Sonderzeichen und übergroßen Payloads. Versuche dasselbe Formular zweimal in schneller Folge zu submitten. Lass die Session mid-flow ablaufen. Dokumentiere jeden Crash, unerwartetes Verhalten oder unbehandelte Edge Cases, die du findest."
Die KI wird das nie für dich machen, außer du fragst explizit. Und selbst dann wird sie die Hälfte übersehen.
6. Deine Prod- und Dev-Configs sind dieselben Dateien 😱
Dieselbe .env. Dieselbe Datenbank. Derselbe S3 Bucket.
Die KI macht nicht die Unterscheidung zwischen Umgebungen. Sie konfiguriert für „es funktioniert", nicht für „es funktioniert sicher, wenn du eine destruktive Migration lokal testest." Umgebungstrennung steht nicht im Prompt, also schafft sie es nicht in den Code.
Das ist nicht nur ein technischer Fix. Es ist eine strukturelle Entscheidung, die vor dem ersten Deploy getroffen werden muss, nicht sechs Wochen später entdeckt, wenn ein lokaler Test eine Tabelle mit echten Nutzerdaten löscht. Diese Grenzen vorab zu definieren ist die Art von architektonischem Vertrag, der Glücksspiel vom Shipping trennt. Deshalb existiert das Prompt Contracts Framework – Grenzen definieren, bevor du dazu gezwungen wirst.
Fix: .env.local, .env.production, zwei separate Datenbanken. Auch für ein Side Project mit drei Nutzern. Besonders für ein Side Project mit drei Nutzern.
„Prüfe die Environment-Konfiguration dieses Projekts. Identifiziere jeden Ort, wo Prod und Dev dieselbe Config, Datenbank oder Storage teilen. Generiere einen vollständigen Environment-Separation-Plan mit separaten .env-Dateien, Datenbankverbindungen und Storage Buckets für jede Umgebung."
7. Deine Fehler sind stumm
Die KI schreibt try/catch-Blöcke. Sie füllt sie auch mit console.error oder gar nichts.
Der Fehler wird abgefangen. Niemand weiß es. Der Nutzer sieht ein leeres Ergebnis oder einen eingefrorenen Spinner. Sie gehen. Du siehst nichts.
Ich hatte ein Kontaktformular auf einem Side Project, das zwei Wochen lang stillschweigend jede Submission gedroppt hatte. Der Mailer crashte wegen eines Config-Problems. Abgefangen, nirgendwo geloggt, verschluckt. Fand es heraus, als jemand in den Kommentaren fragte, warum ich nie auf ihre Nachricht geantwortet hatte.
Zwei Wochen tote Leads. Null Anzeichen, dass etwas auf meiner Seite falsch war.
Fix: Sentry Free Tier. Es ist eine Error-Tracking-Plattform, die jede unbehandelte Exception in Echtzeit abfängt, mit dem vollständigen Stack Trace, dem Browser des Nutzers, der exakten Code-Zeile und einem Reproduction Count. Zehn Minuten Setup. Nicht optional, wenn du echte Nutzer hast.
Noch kein Sentry? Mindestens das hier zuerst:
„Prüfe jeden try/catch-Block in dieser Codebase. Ersetze leere Catches und console.error-only Catches mit strukturiertem Error Logging. Füge einen globalen unhandledRejection Handler hinzu. Gib eine Zusammenfassung jedes stillen Failure-Points aus, den du gefunden hast."
Stille Fehler sind keine Bugs. Sie sind Geister.
8. Du weißt nicht, was du in Echtzeit ausgibst
Die Rechnung kommt an. Du öffnest sie. Du erkennst die Zahl nicht.
In der Entwicklung rufst du die API zehn Mal auf. Du testest ein Feature, es funktioniert, du machst weiter. In der Produktion: ein Nutzer mit einer aggressiven Retry-Loop, ein Suchfeld, das bei jedem Tastendruck feuert, eine unindexierte Query, die Full Table Scans auf einem wachsenden Dataset ausführt. Jedes davon kann ein $20/Monat Budget in eine $200 Überraschung verwandeln, bevor du deinen Kaffee ausgetrunken hast.
Die KI generiert Code, der funktioniert. Sie generiert keinen Code, der unter Last ökonomisch sicher ist. Sie hat kein Konzept von deinem Budget-Cap, deiner Marge oder was passiert, wenn jemand, der nicht du bist, den Endpoint 400 Mal trifft.
Fix: Billing Alerts auf jedem Service, für den du zahlst. AWS, OpenAI, Anthropic, Supabase. Sie alle haben Threshold Alerts. Setze sie, bevor du den Link öffentlich teilst. Harte Limits auf API-Calls pro Nutzer pro Tag. Ein grundlegendes Cost Dashboard, auch ein Spreadsheet, wöchentlich überprüft.
Nicht glamourös. Rettet deinen Monat.
„Füge Billing-Schutz zu dieser App hinzu. Implementiere tägliche API-Call-Limits pro Nutzer, füge harte Caps auf jede Loop hinzu, die eine externe API aufruft, und generiere einen README-Abschnitt mit Schritt-für-Schritt-Anweisungen zum Einrichten von Budget Alerts auf OpenAI, Anthropic, AWS und Supabase."
Ship It Right oder Ship It Twice
Mein Freund hat übrigens alles gefixt. Hat ihn ein Wochenende gekostet. Die App ist wirklich gut, besser als das meiste, was ich von Teams mit echten Budgets shipped sehe. Das ist das Ding bei richtig gemachten vibe-coded Apps: die Idee und die Ausführung können außergewöhnlich sein. Die Infrastruktur-Schicht ist es, die sie killt. Und dieser Teil ist fixbar.
Die Industrie wird diese Demos noch weitere achtzehn Monate „Produkte" nennen. Die Screenshots sehen gleich aus. Die Launch-Posts klingen identisch.
Die Builder, die wirklich shippen, checken diese Liste, bevor sie den Link teilen. Nicht nach dem Breach. Nicht nach der $14k Rechnung. Vorher.
Eine Demo beeindruckt. Ein Produkt überlebt.
Wenn das dir einen schlechten Freitagabend erspart hat, gibt es mehr davon. Ich schreibe über das Bauen echter Dinge mit KI, die Teile, die die Tutorials auslassen.
(*) Das Cover ist KI-generiert. Geprompted, nicht gemalt, aber die Horror-Geschichten im Artikel sind alle zu real.
Dieser Artikel kann Affiliate-Links enthalten, und ich kann eine kleine Provision verdienen.
Wenn deine KI-App mehr nach Demo als Produkt aussieht, ist es Zeit, die Realität der Produktionsumgebung zu verstehen. In der wöchentlichen Rentier Digital Newsletter findest du echte Einblicke und Strategien.