Blog
Build in Public
3. Oktober 20259 min

Warum ich einen sprachgesteuerten Aufgabenmanager mit KI entwickelt habe

TAMSIV entstand aus einer alltäglichen Frustration: Einkaufslisten auf Papier, die am Kühlschrank kleben, ein Tauchclub, der alles über WhatsApp verwaltet, und das ständige Gefühl, dass Informationen zwischen Post-its und Diskussionsgruppen verloren gehen. Eines Tages dachte ich mir: Warum können wir nicht einfach sprechen, um unser Leben zu organisieren? Sechs Monate und über 700 Commits später ist TAMSIV eine komplette Android-App mit konversationeller KI, Echtzeit-Sprachpipeline und kollaborativer Verwaltung. Hier ist, wie alles begann.

Wichtige Erkenntnisse:
- Die besten Produktideen entstehen aus wiederholten persönlichen Frustrationen – nicht aus abstrakten Marktstudien.
- React Native mit der New Architecture (Fabric) ermöglicht es einem einzelnen Webentwickler, eine leistungsstarke mobile App ohne reines Native zu liefern.
- Supabase bietet alles, was ein Soloprojekt benötigt (Auth, DB, Storage, Realtime) in einem einzigen Dienst.
- Der erste funktionierende Prototyp (Sprache zu erstellter Aufgabe) ist der beste Ideen-Validierer – besser als jeder Businessplan.
Kühlschranktür bedeckt mit handgeschriebenen Einkaufslisten und bunten Post-its
Die Realität der familiären Aufgabenverwaltung: Zettel am Kühlschrank, die jede Woche verloren gehen.

Woher kommt die Idee für einen sprachgesteuerten Aufgabenmanager?

Alles begann mit einer alltäglichen Frustration. Meine Frau und ich verwalten eine vierköpfige Familie. Die Einkaufslisten? Auf einem Zettel, der am Kühlschrank klebt. Die Hausarbeiten? In unseren Köpfen. Und wenn wir etwas vergessen – was oft passiert – ist das die kleine tägliche Spannung. "Hast du nicht gesagt, du kümmerst dich darum?" Ja, aber ich habe es vergessen. Wie immer.

Parallel dazu bin ich Mitglied in einem Tauchclub. Und dort herrscht organisiertes Chaos: Alles läuft über WhatsApp. Ausflüge, Anmeldungen, Ausrüstung, Berichte. Dutzende Nachrichten pro Tag in einer Gruppe, in der Informationen untergehen. Du suchst das Datum des nächsten Ausflugs? Viel Glück, es zwischen Memes und Fischfotos zu finden.

Zwei verschiedene Kontexte, dasselbe Problem: Informationen gehen verloren, weil die verwendeten Tools dafür nicht gemacht sind. Papier erinnert nicht. WhatsApp organisiert nicht. Und die bestehenden Aufgaben-Apps? Zu kompliziert, zu viele Felder zum Ausfüllen, zu viel Reibung.

Warum ist die Stimme die Antwort auf die mentale Überlastung?

Die Erkenntnis, die alles auslöste: Wir denken und kommunizieren durch Sprache, nicht durch Formulare. Wenn du deinem Partner sagst "vergiss nicht, morgen Milch zu kaufen", ist das eine klare Anweisung. Aber wenn du eine Aufgaben-App öffnest, musst du:

  1. Die App öffnen
  2. Auf "+" tippen
  3. Den Titel eingeben
  4. Ein Datum auswählen
  5. Ein Projekt/Tag auswählen
  6. Speichern

Sechs Schritte für eine Aktion, die 3 Sekunden dauert, um sie auszusprechen. Das ist genau das Problem, das das Konzept der Capture Friction in David Allens GTD (Getting Things Done)-Methodik beschreibt: Je einfacher die Erfassung einer Idee ist, desto mehr wird das System genutzt.

Ich dachte mir: Warum können wir nicht einfach sagen, was wir tun wollen? "Füge Milch zur Einkaufsliste hinzu." "Erinnere mich daran, die Flaschen für Samstag vorzubereiten." Ohne eine App zu öffnen, ohne zu tippen, ohne das richtige Feld in einem Formular zu suchen.

So entstand TAMSIV. Ein Aufgaben- und Notizmanager, der sprachgesteuert ist, mit einer konversationellen KI, die versteht, was du willst, und entsprechend handelt.

Welche technischen Entscheidungen für einen Solo-Entwickler, der ein mobiles Projekt startet?

Entwickler konfiguriert ein neues Projekt auf einem Laptop mit den ersten Codezeilen
Der erste Commit: Oktober 2025. Ein Monorepo, drei Ordner und ein Berg von Entscheidungen, die getroffen werden mussten.

Erster Commit im Oktober 2025. Jede technische Entscheidung in diesem Stadium ist kritisch – du bist allein, du hast keinen Spielraum für Fehler, und ein Rückschritt ist teuer.

Warum React Native und nicht reines Native?

Ich bin von Haus aus Webentwickler. Reines Native (Kotlin/Swift) hätte mich um mehrere Monate verlangsamt, für ein gleichwertiges Ergebnis. React Native mit der New Architecture (Fabric) bietet eine hervorragende Leistung – das Ruckeln und die Bridge-Probleme, die frühere Versionen plagten, sind behoben.

Die Wahl des Monorepos mit drei Ordnern war offensichtlich:

  • frontend/ — React Native TypeScript für die mobile App
  • backend/ — Node.js Express mit WebSocket für den KI-Server
  • website/Next.js für die Landingpage und das Web-Dashboard

Ein einziges Repo, ein einziges git log, geteilte TypeScript-Typen zwischen Frontend und Backend. Die Kohärenz ist maximal.

Warum Supabase statt Firebase oder ein benutzerdefiniertes Backend?

Supabase bietet alles, was ein Soloprojekt benötigt, in einem einzigen Dienst: verwaltetes PostgreSQL, integrierte Authentifizierung (E-Mail, Magic Links und später QR-Code), Dateispeicher und Realtime für die Echtzeit-Synchronisierung.

Firebase wäre die andere offensichtliche Option gewesen, aber das NoSQL-Modell (Firestore) eignet sich nicht für relationale Daten wie Aufgaben, Notizen, Gruppen und Ereignisse. PostgreSQL ist dafür gemacht – und Supabase macht es zugänglich, ohne einen Server verwalten zu müssen.

Die Strukturierung der Datenbank würde später kommen, aber die Wahl von Supabase von Anfang an ermöglichte es, schnell zu iterieren, ohne sich um die Infrastruktur kümmern zu müssen.

Wie funktioniert die Sprachpipeline im Herzen von TAMSIV?

Person spricht in ihr Smartphone, während sie draußen geht
Der ideale Anwendungsfall: Sagen, was man tun möchte, mit freien Händen, ohne Menüs zu öffnen oder Formulare auszufüllen.

Das Herzstück des Projekts ist die Sprachpipeline. Schon im ersten Prototyp habe ich die gesamte Kette verdrahtet:

  1. Audio PCM 16kHz — Aufnahme vom Telefonmikrofon
  2. Echtzeit-WebSocket — Senden des Audiostreams an das Backend
  3. STT (Speech-to-Text) — Transkription durch die native Engine des Geräts (mit Deepgram-Fallback)
  4. LLM (Large Language Model) — Textanalyse und Aktionsentscheidung über OpenRouter
  5. Function Calling — Das LLM ruft eine Funktion auf (create_task, create_memo, etc.)
  6. TTS (Text-to-Speech) — Sprachantwort über OpenAI TTS

Der Benutzer spricht, das Backend transkribiert, sendet den Text an ein LLM, das entscheidet, was zu tun ist, und sendet eine Sprachantwort zurück. All das in wenigen Sekunden.

Die ersten Tests waren magisch. "Erstelle eine Aufgabe 'Brot kaufen' für morgen" zu sagen und die Aufgabe mit dem richtigen Datum erscheinen zu sehen... das ist die Art von Moment, die dir bestätigt, dass du auf dem richtigen Weg bist. Man braucht keinen 50-seitigen Businessplan – wenn der Prototyp funktioniert und du dir sagst "das will ich jeden Tag benutzen", ist die Idee validiert.

Welche Herausforderungen hat ein Solo-Entwickler bei einem so ehrgeizigen Projekt?

Als Solo-Entwickler hast du völlige Freiheit bei technischen Entscheidungen. Keine Meetings, keine Kompromisse, kein "darüber reden wir am Montag". Du siehst ein Problem, du behebst es. Du hast eine Idee, du programmierst sie.

Aber es ist auch die Einsamkeit angesichts von Bugs um 23 Uhr. Niemand, der deinen Code überprüft, niemand, der deine Entscheidungen in Frage stellt, niemand, der dir sagt "du bist auf dem richtigen Weg", wenn du zweifelst. Das ist ein Gefühl, das viele technische Solo-Gründer kennen.

Das Build in Public – das Erzählen des Abenteuers über diesen Blog und die sozialen Netzwerke – ist meine Art geworden, diese Einsamkeit zu kompensieren. Jeder Artikel ist ein Checkpoint, ein Beweis, dass das Projekt voranschreitet, ein Mittel, um Feedback zu erhalten, auch ohne Team.

Wie sind wir vom ersten Commit zu über 700 Commits in 6 Monaten gekommen?

Der Weg seit diesem ersten Commit folgte einer Entwicklung, die ich nicht hätte planen können:

Der detaillierte Artikel über die über 650 Commits zeichnet jeden Schritt detailliert nach.

Welche Lehren sind für den Start eines Soloprojekts zu ziehen?

  1. Gehe von deiner eigenen Frustration aus. Die besten Produkte lösen ein Problem, das der Ersteller täglich erlebt. Du wirst dein erster Benutzer und dein bester Tester sein.
  2. Wähle Tools, die deine Produktivität vervielfachen. React Native, Supabase, OpenRouter – jede Wahl sollte dir Wochen, nicht Stunden, einsparen.
  3. Prototypisiere schnell, validiere schnell. Die erste funktionierende Sprachpipeline dauerte 3 Tage. Dieser Prototyp hat die Idee besser validiert als jede Studie.
  4. Dokumentiere das Abenteuer. Das Build in Public ist kein Marketing – es ist ein Logbuch, das dich zwingt, einen Schritt zurückzutreten und eine Community um das Projekt herum aufzubauen.

Häufig gestellte Fragen

Muss man nativ programmieren können, um eine mobile App mit KI zu erstellen?

Nein. React Native mit TypeScript ermöglicht es einem Webentwickler, eine leistungsstarke mobile App zu erstellen. Für KI bieten Dienste wie OpenRouter und OpenAI APIs an, die keine Machine-Learning-Kenntnisse erfordern. Am wichtigsten ist es, die Client-Server-Architektur und WebSockets zu verstehen.

Wie viel kostet die Entwicklung einer App wie TAMSIV als Solo-Entwickler?

An direkten Kosten: Supabase (anfangs kostenloser Plan, dann ~25 EUR/Monat), OpenRouter (~0.001 EUR/LLM-Nachricht), OpenAI TTS (~0.015 EUR/1000 Zeichen), Runware für Bilder (~0.003 EUR/Bild). Die Hauptkosten sind die Zeit: 6 Monate Teilzeit, also etwa 500-600 Arbeitsstunden.

Warum ein Monorepo statt separater Repos?

Für einen Solo-Entwickler ist Kohärenz entscheidend. Ein einziges Repo bedeutet einen einzigen Git-Verlauf, geteilte TypeScript-Typen und keine Versionssynchronisation zwischen Paketen. Das Monorepo wird ab 3-4 Entwicklern komplexer zu verwalten, aber für ein Soloprojekt ist es ideal.

Funktioniert die Sprachpipeline offline?

Teilweise. Das native STT des Geräts funktioniert ohne Internet (lokale Spracherkennung). Aber das LLM und TTS benötigen eine Verbindung zum Backend. Ein Offline-Modus mit Warteschlange ist auf der Roadmap – Sprachbefehle würden lokal gespeichert und bei Wiederverbindung verarbeitet.

Ist WhatsApp nicht ausreichend, um Aufgaben in Gruppen zu verwalten?

Nein, und genau das ist das Problem, das TAMSIV inspiriert hat. WhatsApp ist ein Kommunikationstool, keine Organisationshilfe. Informationen gehen im Nachrichtenfluss unter, nichts ist strukturiert, es gibt keine Erinnerungen, keine Fälligkeitsdaten, keine Zuweisungen. Es ist organisiertes Chaos – und die kollaborativen Gruppen von TAMSIV lösen genau dieses Problem.