KI-Sprach-App in 650 Commits: Erfahrungsbericht Solo-Entwickler

Wichtige Punkte: Ein sprachgesteuerter KI-Aufgabenmanager im Alleingang zu entwickeln, bedeutet über 650 Commits, eine Echtzeit-Audio-Pipeline (Deepgram + OpenRouter + OpenAI TTS), eine React Native New Architecture und vor allem 6 Monate voller Lektionen darüber, was man nicht tun sollte. Dieser Artikel behandelt den kompletten Stack, kostspielige Fehler und die Entscheidungen, die den Unterschied gemacht haben.

Vor 6 Monaten hatte ich ein ganz einfaches Problem. Zu Hause waren wir zu viert und hatten Zettel für Einkäufe am Kühlschrank kleben. Im Tauchclub lief alles über WhatsApp – es war unmöglich, eine drei Tage alte Information wiederzufinden. Die bestehenden Apps? Zu kompliziert, zu viele Klicks, nicht an das echte Leben angepasst.

Heute ist TAMSIV eine komplette Android-App mit einem KI-Sprachassistenten, hierarchischen Kollaborationsgruppen, einem Kalender mit Wiederholungen, Gamification und sie spricht 6 Sprachen. Über 650 Commits. Solo-Entwicklung. Und ich werde dir genau erzählen, wie ich dorthin gekommen bin.

Warum einen sprachgesteuerten Aufgabenmanager im Jahr 2025 erstellen?

Die kurze Antwort: Weil klassische Produktivitäts-Apps davon ausgehen, dass du vor einem Bildschirm sitzt und beide Hände frei hast. Aber im echten Leben fährst du Auto, kochst, gehst mit dem Hund spazieren oder trägst Einkäufe.

Ich habe Dutzende von Apps getestet – Todoist, Any.do, Google Tasks, Microsoft To Do. Alle auf dem Papier exzellent. Aber keine stellte die Stimme in den Mittelpunkt. Sie hatten vielleicht einen versteckten Mikrofon-Button, aber die Hauptinteraktion blieb die Tastatur.

Meine Wette: Die Stimme als Hauptschnittstelle. Du drückst, du sprichst, die KI versteht und erstellt die Aufgabe. Keine Formulare, keine Dropdown-Menüs, keine Reibung. Wenn du mehr darüber erfahren möchtest, warum klassische Produktivitäts-Apps scheitern, spreche ich darüber in diesem Artikel über die Ermüdung durch Produktivitäts-Apps.

Welcher technische Stack für eine KI-Sprach-App?

Die Wahl des richtigen Stacks ist die wichtigste Entscheidung. Hier ist, was ich nach 6 Monaten gelernt habe:

• Frontend: React Native 0.81 (TypeScript) mit der New Architecture (Fabric). Native Leistung, eine einzige Codebasis. Die Wahl fiel darauf, weil ich React kenne und schnell liefern wollte.
• Backend: Node.js/Express + WebSocket. WebSocket ist unerlässlich für Echtzeit-Audio-Streaming – HTTP reicht nicht aus.
• Datenbank: Supabase PostgreSQL mit 3 separaten Schemata (privat, collaborative, gamification). Ich erkläre diese Architektur detailliert in meinem Artikel über die Datenbankstrukturierung.
• Website: Next.js 16 + Tailwind CSS 4, bereitgestellt auf Vercel. Ich habe den Bau in 3 Tagen in diesem speziellen Artikel beschrieben.

Wie funktioniert die Sprach-Pipeline der App?

Das ist das technische Herzstück des Projekts. Der Benutzer drückt den Knopf, spricht und erhält eine strukturierte Sprachantwort in 1,5 bis 3 Sekunden. Unter der Haube:

Audio PCM 16kHz mono → WebSocket (JWT) → Deepgram STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Sprachantwort

1. Audioaufnahme: Das Telefon sendet rohe Audio-Chunks in PCM 16 Bit, 16 kHz, Mono über WebSocket.
2. Speech-to-Text: Deepgram transkribiert im Streaming mit automatischer Spracherkennung (VAD).
3. LLM: OpenRouter leitet zu über 400 Modellen mit automatischem Fallback. Das Modell versteht die Absicht und verwendet Function Calling, um Aufgaben, Notizen oder Ereignisse zu erstellen.
4. Text-to-Speech: OpenAI TTS (Stimme "nova") generiert die Audioantwort, die über denselben WebSocket zurückgestreamt wird.

Jeder Schritt kann unabhängig voneinander fehlschlagen. Ich habe intelligente Retries, Circuit Breaker und Fallbacks auf jeder Ebene implementiert. Für die vollständigen technischen Details der Pipeline lies den Artikel über die Sprach-Pipeline.

Welche Funktionen haben die meiste Arbeit erfordert?

In über 650 Commits haben einige Funktionen ganze Wochen verschlungen. Hier sind die Top 3.

Hierarchische Kollaborationsgruppen

Auf dem Papier: "Füge Gruppen hinzu". In Wirklichkeit: ein hierarchisches System mit 6 Ebenen Tiefe und 4 Rollen (Admin, Manager, Member, Viewer), rekursive PostgreSQL-Abfragen (CTE) und 31 RLS-Richtlinien, die einzeln geschrieben und getestet werden mussten.

Mein Tauchclub war der perfekte Anwendungsfall: Club → Technische Kommission → Stufe 1 → Dienstagsgruppe. Die Vererbung von Berechtigungen zwischen den Ebenen war die wahre Herausforderung. Ich spreche ausführlich darüber in dem Artikel über hierarchische Gruppen.

Der Kalender mit Wiederholungen

LLMs sind nicht gut mit Daten. Wenn du sagst "jeden Dienstag um 14 Uhr", muss das Modell die Wiederholung, die Zeitzone verstehen und die richtigen Vorkommen generieren. Ich musste eine Zuordnungstabelle und ein robustes Validierungssystem erstellen. Die technischen Details findest du in dem Artikel über den Kalender und die Filter.

Die Gamification

12 Level, 10 Abzeichen, Streaks bis zu 365 Tagen, tägliche Herausforderungen und eine Bestenliste. Ein dediziertes Schema mit 5 Tabellen und automatischen Triggern. Gamification ist kein Gadget – sie verändert das Engagement der Benutzer grundlegend. Ich habe die Architektur in dem Artikel über das Gamification-Schema detailliert beschrieben.

Welche Fehler sollte man bei der Solo-Entwicklung vermeiden?

Ich werde ehrlich sein: Ich habe kostspielige Fehler gemacht. Wenn du ein Solo-Projekt entwickelst, lerne aus meinen Fehlern.

Fehler Nr. 1: Sechs Monate lang kein Marketing

650 Commits und kein einziger Beitrag darüber. Keiner. Ich war so sehr im Code vertieft, dass ich den Teil der Sichtbarkeit komplett ignoriert habe. Als ich kommunizieren wollte, fing ich bei Null an – keine Zielgruppe, kein Inhalt, keine Historie.

Die Lektion: Beginne mit dem Marketing ab dem ersten Commit. Selbst ein einfacher Tweet "Ich starte ein neues Projekt" ist besser als Schweigen.

Fehler Nr. 2: Die Internationalisierung unterschätzen

Der Übergang von 100% Französisch zu 6 Sprachen (FR, EN, DE, ES, IT, PT) betraf 35 Dateien und 1993 Übersetzungs-Keys. Das ist eine enorme Aufgabe, wenn man es nachträglich macht. Heute wird jede neue Funktion von Anfang an übersetzt. i18n ist zu einem echten Akquisitionskanal geworden – ich spreche darüber in diesem Artikel über i18n als Wachstumstreiber.

Fehler Nr. 3: Die Datenbankstruktur nicht von Anfang an festlegen

Ich hatte das Glück, diese Wahl richtig zu treffen, aber ich habe so viele Projekte gesehen, bei denen alles im public-Schema ist, dass ich es erwähne. Drei separate Schemata vom ersten Tag an ändern alles für die Wartbarkeit. Die Details findest du in dem Artikel über die Umstrukturierung der Datenbank.

Wie manage ich ein Solo-Projekt dieser Größenordnung?

650 Commits in 6 Monaten, das sind durchschnittlich 3-4 Commits pro Tag. An manchen Tagen habe ich 10 gemacht, an anderen null. Das hat mir geholfen:

• Atomare Commits: Jeder Commit macht nur eine Sache. Das macht das Debuggen und Zurücksetzen viel einfacher.
• Ein Monorepo: Frontend, Backend und Website im selben Repo. Ein einziges git log, um die komplette Projekthistorie zu sehen.
• Singleton Services: ConversationService, CalendarService, GamificationService... jeder Bereich hat seinen dedizierten Service, einfach zu testen und zu warten.
• Das PendingCreation-Muster: Die Stimme erstellt eine Vorschau, der Benutzer validiert, bearbeitet oder bricht ab, bevor die Speicherung in der Datenbank erfolgt. Keine Überraschungen.

Wie hoch sind die Betriebskosten einer KI-Sprach-App?

Eine Frage, die jeder stellt. Hier ist die Aufschlüsselung pro Sprachinteraktion:

• Natives STT (Gerät): kostenlos. Deepgram Cloud als Fallback: ~$0.0059/Min.
• LLM über OpenRouter: variabel je nach Modell, typischerweise $0.001-0.01 pro Anfrage.
• TTS OpenAI: ~$0.015 für 1000 Zeichen.
• Supabase: großzügiger kostenloser Plan, dann ~$25/Monat im Pro-Plan.
• Backend Railway: ~$5-10/Monat je nach Nutzung.

Insgesamt kostet eine vollständige Sprachinteraktion zwischen $0.01 und $0.03. Das ist mit einem Freemium-Modell machbar – ich habe die Abonnementstufen in dem Artikel über RevenueCat und Abonnements detailliert beschrieben.

Wo steht das Projekt heute?

TAMSIV ist als Alpha-Version im Google Play Store verfügbar. 12 aktive Tester. Der öffentliche Produktionsstart steht unmittelbar bevor.

Die wichtigen Metriken:

• 650+ Commits im Monorepo
• 6 unterstützte Sprachen (FR, EN, DE, ES, IT, PT)
• 3 WebSocket-Modi (Live, Realtime, Batch)
• 31 RLS-Richtlinien für die Datensicherheit
• 12 Gamification-Level mit Abzeichen und Streaks
• 6 Tabs: Diktiergerät, Feed, Kalender, Gruppen, Social, Profil

FAQ

Wie lange dauert es, eine KI-Sprach-App im Alleingang zu entwickeln?

Für TAMSIV dauerte es 6 Monate Vollzeit. Allein die Sprach-Pipeline (STT + LLM + TTS) dauerte etwa 3 Wochen. Die Kollaborationsgruppen und die Gamification fügten jeweils 2 Monate hinzu. Wenn du dich nur auf das sprachgesteuerte MVP konzentrierst, rechne mit 2-3 Monaten.

Warum React Native statt Flutter oder nativ?

Ich kannte React bereits. Die New Architecture (Fabric) von React Native 0.81 bietet nahezu native Leistung. Flutter war eine gültige Option, aber das npm-Ökosystem und die React-Community gaben den Ausschlag. Reines Nativ hätte die Entwicklungszeit verdoppelt, ohne signifikante Vorteile für diese Art von App.

Ist das native Speech-to-Text so gut wie Deepgram?

Für die meisten Fälle ist das native STT des Geräts ausreichend und kostenlos. Deepgram glänzt in lauten Umgebungen und für nicht-europäische Sprachen. TAMSIV verwendet standardmäßig das native STT und wechselt bei Bedarf zu Deepgram. Ich habe beide detailliert in dem Artikel "Natives STT vs. Deepgram" verglichen.

Wie monetarisiert man eine KI-Sprach-App, ohne die Kosten explodieren zu lassen?

Das Freemium-Modell mit täglichen Limits im kostenlosen Plan. Kostspielige Funktionen (Cloud STT, KI-Bildgenerierung) sind den Pro- und Team-Plänen vorbehalten. RevenueCat verwaltet In-App-Abonnements. Das Geheimnis ist, die Kosten pro Interaktion zu optimieren – das kostenlose native STT deckt 90% der Nutzungen ab.

Braucht man ein Backend für eine Sprach-App oder kann alles lokal laufen?

Du brauchst ein Backend für das LLM (Function Calling, Orchestrierung) und das TTS (die APIs sind serverseitig). Das STT kann lokal laufen. WebSocket ist unerlässlich für Echtzeit-Streaming – klassische HTTP-Aufrufe verursachen zu viel Latenz.