Ich habe eine AI-Rezepte-App gebaut, Apples Freigabe bekommen und sie nie veröffentlicht.

Ich habe Monate damit verbracht, eine iOS-App zu bauen. Ich habe sie designt, programmiert, mit Freunden getestet, bei Apple eingereicht und die Freigabe bekommen.

Dann habe ich meinen Laptop zugeklappt und nie auf Veröffentlichen gedrückt.

Klingt dramatisch? Vielleicht. Aber hier ist die Sache: Zu wissen, wann man aufhören muss, ist eine Fähigkeit, über die niemand spricht. Besonders wenn man bereits Hunderte Stunden in etwas investiert hat, das tatsächlich funktioniert.

Der Kühlschrank, mit dem alles begann

Es fing so an, wie die meisten Nebenprojekte anfangen. Mit einem simplen, alltäglichen Problem.

Ich habe meinen Kühlschrank geöffnet, ein Haufen zufälliger Zutaten gesehen und keine Ahnung gehabt, was ich kochen soll. Tomaten, ein Rest Hähnchen, eine halbe Gurke, Joghurt. Alles einwandfrei. Aber mein Gehirn war einfach leer.

Und dann kam der Gedanke: Was, wenn ich einfach ein Foto von meinem Kühlschrank mache und eine KI mir sagt, was ich daraus kochen kann?

Das war's. Die ganze Idee.

Ich habe noch am selben Tag die Domain wunderchef.ai gekauft. Wer mich kennt, weiß, dass ich eine Schwäche für das Wort "Wunder" habe. Meine Firma ist Wunderlandmedia. Meine macOS-App ist WunderType. Meine Deutsch-Lern-App heißt DeutschWunder. Mittlerweile ist es quasi eine Branding-Sucht.

Das Konzept war klar: Foto von deinen Zutaten machen, KI erkennt was du hast, generiert Rezepte basierend auf dem, was tatsächlich vor dir liegt. Kein Scrollen durch Rezeptblogs. Kein "du brauchst außerdem noch 17 Zutaten, die du nicht hast." Einfach nutzen, was da ist.

Ich wollte auch den Umwelt-Impact tracken. Jedes generierte Rezept zeigt, wie viel Lebensmittelverschwendung du verhindert hast, wie viel Geld du gespart hast. Ein kollektives Impact-Dashboard über alle Nutzer hinweg. Denn der eigentliche Sinn war Müllvermeidung, nicht nur Bequemlichkeit.

Der Tech Stack hinter den Kulissen

Jetzt wird es technisch. Wenn dich Code nicht interessiert, spring zum nächsten Abschnitt. Wenn doch, schnall dich an.

Meine anfängliche Architektur war SwiftUI für die iOS-App, Directus als Backend-CMS und eine Next.js-App für die serverseitigen KI-Komponenten. Die Idee war, Bilderkennung und Rezeptgenerierung über Next.js Server Actions abzuwickeln.

Es funktionierte. Aber es war quälend langsam.

Der Flaschenhals war der Next.js-Endpoint. Ein base64-kodiertes Bild an GPT-4o-mini zur Zutatenerkennung schicken, dann strukturierte Rezepte mit einem zweiten Call generieren, alles über Next.js Server Actions, diese Pipeline war einfach zu träge für eine mobile App. Nutzer warten keine 15 Sekunden auf einen Ladebildschirm.

Also habe ich Next.js für die API-Schicht rausgerissen und alles als eigenständige Express.js API mit TypeScript neu gebaut. Tag und Nacht Unterschied. Build-Zeit auf 30 Sekunden mit Coolify und Docker gesunken. KI-Antworten waren deutlich schneller.

So sah der finale Stack aus:

• iOS App: SwiftUI mit modernen async/await-Patterns, benutzerdefinierter Environment-basierter Dependency Injection, Keychain Token-Speicherung mit proaktivem 5-Minuten-Refresh-Puffer
• Backend API: Express.js (v5) + TypeScript, Zod-Validierung, Helmet Security-Headers, strukturiertes Error-Handling mit domänenspezifischen Error-Klassen
• KI-Engine: OpenAI GPT-4o-mini mit strukturiertem JSON-Output-Modus. Bilderkennung nutzt base64 JPEG mit Low-Detail für Geschwindigkeit. Rezeptgenerierung beinhaltet einen professionellen Koch-System-Prompt mit Diät-Einschränkungen, Allergie-Sicherheit ("MUST AVOID"-Betonung) und Nachhaltigkeits-Metrik-Berechnung
• CMS: Directus für Nutzerdaten, Rezepte, Credits, Transaktionen. Die Express API schreibt, Directus liest direkt von der iOS-App
• Auth: Apple Sign-In mit vollständiger JWKS-Verifizierung. Der Express-Server holt Apples öffentliche Schlüssel, verifiziert die RS256-Signatur, validiert die Audience gegen die Bundle ID. Erstellt oder aktualisiert dann den Nutzer in Directus mit einem kryptographisch zufälligen Passwort
• Payments: StoreKit 2 mit JWS-Transaktions-Verifizierung. Vier Credit-Pakete von 9,99$ bis 99,99$. Serverseitige Validierung vor der Gutschrift
• Sprachen: 55+ Sprachen in der Rezeptgenerierung unterstützt. Die iOS-App selbst unterstützt 5 Sprachen mit dynamischem Wechsel

Ich habe viel dabei gelernt. Base64-Bildgröße beeinflusst direkt die Kosten des Erkennungsmodells. Komprimierung ist wichtig: Die App nutzt eine Schleife, die bei 0,85 Qualität startet und in 0,05-Schritten reduziert, bis das Bild unter 1MB ist, und alles unter 1KB als über-komprimiert ablehnt.

Ich habe auch Prompt-Injection-Schutz in die API eingebaut. Input-Sanitierung, die Muster wie "ignore previous instructions" oder "system:" blockiert, bevor sie die KI erreichen. Wenn du Kochrezepte generierst, willst du wirklich nicht, dass jemand das Modell dazu bringt, gefährliche Kombinationen vorzuschlagen.

Eine Sache, die ich mit meinem ursprünglichen Next.js-Setup nicht zum Laufen bekommen habe, war Apple Sign-In mit Directus. Ich habe die gesamte Dokumentation gelesen. Zweimal. Ich habe den Token-Exchange-Flow einfach nicht verstanden. Der Wechsel zu Express mit den jose- und jwks-rsa-Libraries hat den Knoten gelöst. Manchmal liegt das Problem nicht am Konzept, sondern am Werkzeug.

Es hat tatsächlich funktioniert

Jetzt kommt der Teil, der diese Geschichte schwerer zu erzählen macht.

Die App war gut. Wirklich gut.

Ich habe ein ordentliches Onboarding gebaut. Erst Sprachauswahl, dann ein aufgeräumter Homescreen mit Quick Actions. Rezept generieren, gespeicherte durchstöbern, entdecken was andere kochen. Eine Profilseite mit Credits, Statistiken und Einstellungen.

Das Credit-System funktionierte. Credits über StoreKit kaufen, beim Rezeptgenerieren ausgeben. Bildanalyse war kostenlos, um die Nutzung zu fördern. Jede Rezeptgenerierung kostete einen Credit und trackte den Nachhaltigkeits-Impact: vermiedener Abfall in Kilogramm, gespartes Geld in Dollar, verwendete Zutaten.

Das kollektive Impact-Dashboard zeigte Community-weite Statistiken. Tausende Kilogramm vermiedener Abfall, Tausende Dollar gespart, Zehntausende verwendete Zutaten. Es gab den Leuten das Gefühl, Teil von etwas zu sein.

Freunde haben es getestet. Sie haben ihre Kühlschränke geöffnet, Fotos geschossen, und die App hat ihre Zutaten erkannt und Rezepte vorgeschlagen. Türkische Hähnchenwurst mit Tomaten. Mediterraner Kichererbsensalat. Trauben-Joghurt-Parfait mit Schokoladendrizzle. Echte Rezepte mit Zubereitungszeiten, Schwierigkeitsgraden und Schritt-für-Schritt-Anleitungen.

Ich habe Workflows erstellt, Tests geschrieben, die UI poliert. Die Next.js Landing Page für wunderchef.ai war fertig. Das Logo war clean. Das Farbschema, ein warmes dunkles Theme mit orangefarbenen Akzenten, wirkte premium.

Am 26. August 2025 habe ich die App bei Apples Review-Prozess eingereicht.

Sie wurde akzeptiert.

Ich habe sie nie veröffentlicht.

Vier Gründe, warum ich nie auf Veröffentlichen gedrückt habe

Du fragst dich vielleicht: All diese Arbeit, all diese Zeit, und du hast einfach... nicht?

Berechtigte Frage. Hier ist die ehrliche Antwort.

Wartung ist kein Teilzeit-Job

Ich betreibe eine Ein-Mann-Agentur. Ich baue Software für Kunden. Ich pflege bereits zwei live Apps. Ich weiß genau, was Wartung für einen Solo-Entwickler bedeutet.

Eine KI-Rezepte-App ist kein "einmal einrichten und vergessen"-Produkt. OpenAI ändert ihre API. Apple aktualisiert StoreKit-Anforderungen. Nutzer finden Edge Cases. Jemandes Allergien werden nicht korrekt behandelt. Das Directus-Backend braucht Updates. Der Express-Server braucht Security-Patches.

Ich weiß, dass ich dieses Projekt nicht mit vollem Einsatz pflegen könnte. Und hier unterscheide ich mich von vielen Indie Hackern: Ich werde nie verstehen, wie Leute 100 Apps raushauen und behaupten, ihre Nutzer zu supporten. Entweder kümmern sie sich nicht wirklich um die Leute, die ihre Software nutzen, oder meine Ethik erlaubt diese Art von Betrieb nicht.

Ich kann diese App nicht warten und gleichzeitig ordentlichen Support für meine Kunden bieten. So mache ich keine Geschäfte.

EU-Regulierungen und Rezept-Haftung

Das hat mich nachts wach gehalten. Ich sitze in Deutschland. In der EU. Ich baue eine App, die mit KI Kochanweisungen generiert.

Was, wenn ein Rezept jemanden krank macht? Was, wenn die KI eine Zutat halluziniert, gegen die jemand allergisch ist, trotz der Sicherheits-Prompts? Was, wenn jemand die Anweisungen befolgt und etwas schiefgeht?

Ich habe Allergie-Handling mit "MUST AVOID"-Betonung in die Prompts eingebaut. Ich habe Diät-Filter eingebaut. Aber KI ist probabilistisch. Nicht deterministisch. Und ich habe keinen Anwalt auf Kurzwahl.

In Europa KI-generierte Anleitungen anzubieten, die Menschen physisch konsumieren, ist ein Haftungs-Minenfeld, das ich als Ein-Mann-Betrieb nicht navigieren kann.

Das AI-Slop-Problem

Hätte ich im August 2025 veröffentlicht, hätte ich mir vielleicht eine Nische schaffen können. Aber seitdem hat sich etwas verändert.

Jeder baut jetzt eine App. Claude Code wurde richtig gut. Leute vibe-coden 10-20 Apps und pushen sie ohne nachzudenken in den App Store. Der Store wird geflutet mit KI-generierten Apps, die alle gleich aussehen, dasselbe machen und keinen langfristigen Support haben.

Meine App würde mit dem Slop in einen Topf geworfen. Es ist viel schwerer zu begründen, dass WunderChef ein sorgfältig gebautes, durchdacht designtes Produkt ist, wenn der App Store in Overnight-Klonen ertrinkt. Das Signal-Rausch-Verhältnis ist kollabiert.

Must-Have vs. Nice-to-Have

Das ist der Punkt, der mich wirklich erwischt hat.

WunderChef ist eine nette Idee. Kein Essen verschwenden. Nutze was du hast. Sieh deinen Umwelt-Impact. Alles toll.

Aber ist es ein Must-Have? Ist es eine App, die ein echtes, tägliches Problem löst, das Leute nicht lösen können, indem sie einfach "Hähnchen Tomate Joghurt Rezept" googeln?

Ich habe Zweifel. Es ist ein Nice-to-Have. Und Nice-to-Have-Apps sterben langsame, schmerzhafte Tode durch sinkende Engagement-Raten und schuldbehaftete Push-Benachrichtigungen.

Wissen, wann man aufhören muss

Es gibt ein türkisches Sprichwort, über das ich oft nachdenke: Kervan yolda düzülür. Die Karawane ordnet sich auf dem Weg. Man findet die Dinge unterwegs heraus.

Aber manchmal muss die Karawane anhalten.

Ich habe eine Menge gelernt beim Bauen von WunderChef. Base64-Bildoptimierung. StoreKit 2 Transaktions-Flows. Apple Sign-In JWKS-Verifizierung. Express API-Architektur. SwiftUI Dependency-Injection-Patterns. Sicherheitsaspekte, an die ich sonst nicht gedacht hätte, wie Prompt-Injection-Schutz für KI-Endpoints.

Nichts davon ist verschwendetes Wissen. Es macht mich schon jetzt besser in der Kundenarbeit.

Aber die App selbst? Sie liegt auf meinem Rechner, von Apple genehmigt, voll funktionsfähig, nie von der Öffentlichkeit gesehen. Und ich bin okay damit.

Am Ende des Tages müssen wir ehrlich zu uns selbst sein und wissen, wo wir aufhören. Nicht jedes Projekt muss live gehen. Nicht jede Idee muss ein Produkt werden. Manchmal ist das Bauen der eigentliche Sinn.

Ich werde nicht so tun, als wäre das eine große strategische Entscheidung gewesen. Ein Teil von mir hat einfach Angst. Angst vor der Wartungslast, Angst vor der Haftung, Angst davor, in einen Markt zu launchen, der bereits in KI-Apps ertrinkt. Vielleicht benutze ich diese Bedenken als Ausreden.

Ich habe keine saubere Antwort darauf.

Was ich weiß: Ich hätte lieber eine App, die ich nie veröffentlicht habe, als zehn Apps, die ich nicht supporten kann.

Wenn du etwas baust und dich fragst, ob du es launchen oder auf Eis legen sollst, kann ich dir nicht die richtige Antwort geben. Aber ich kann dir das sagen: Aufhören ist nicht immer Scheitern. Manchmal ist es einfach ehrlich sein darüber, was man wirklich durchhalten kann.

Du planst etwas zu bauen und willst eine zweite Meinung, bevor du Monate investierst? Lass uns reden. Ich war schon auf beiden Seiten des "Soll ich das bauen?"-Gesprächs.