Erstes Demo-Video und Qualitätssprint: 7 kritische Korrekturen

Nach 6 Monaten Entwicklung und über 700 Commits hatte TAMSIV alles: eine funktionierende Sprachpipeline, ein Gamification-System, kollaborative Gruppen, Unterstützung für 6 Sprachen. Aber etwas Wesentliches fehlte – ein Video. Denn eine Sprach-App lässt sich nicht beschreiben. Man muss sie zeigen. Diese Woche habe ich das erste Demo-Video von TAMSIV gedreht und parallel dazu einen Qualitätssprint abgeschlossen, der 7 kritische Probleme behoben hat.

Wichtige Erkenntnisse:
- Ein Demo-Video ist für eine Sprach-App unerlässlich – "sprich und die KI versteht" reicht nicht aus, man muss sehen, wie das Mikrofon aktiviert wird und die Aufgabe erstellt wird.
- Ein Qualitätssprint (0 Features, 7 Korrekturen) hat genauso viel Einfluss wie ein Monat Entwicklung, wenn er auf alltägliche Reibungspunkte abzielt.
- Der Stopp-Knopf eines Diktiergeräts muss zu 100% funktionieren – selbst 1% Fehler zerstört das Vertrauen.
- Den Singleton-Cache beim Logout auf einem gemeinsam genutzten Gerät immer leeren – ein Datenleck zwischen Sitzungen ist ein kritisches Sicherheitsproblem.

Warum ist ein Demo-Video für eine Sprach-App unerlässlich?

Seit 6 Monaten existierte TAMSIV in Text und Screenshots. Auf der Website, in Blogartikeln, in den Play Store-Einträgen. Aber eine Sprach-App hat ein grundlegendes Kommunikationsproblem: Die Hauptinteraktion ist unsichtbar.

Du kannst so oft du willst schreiben "sprich, die KI versteht und organisiert". Solange der Besucher nicht gesehen hat, wie das Mikrofon aktiviert wird, die Echtzeit-Transkription, die Aufgabe, die sich von selbst im richtigen Ordner erstellt – versteht er nicht wirklich, was die App macht.

Wie Wyzowl in seinem Video-Marketing-Report 2026 erklärt, sehen sich 96% der Verbraucher ein Erklärvideo an, bevor sie ein Produkt kaufen oder eine App herunterladen. Für eine Sprach-App ist diese Zahl wahrscheinlich noch höher – das Konzept selbst erfordert eine visuelle Demonstration.

Das Video ist jetzt auf YouTube sichtbar und direkt in den Hero-Bereich der Website tamsiv.com integriert. Der Besucher sieht sofort, wie TAMSIV funktioniert, ohne die App herunterladen oder eine Dokumentation lesen zu müssen.

Wie integriert man ein Video in den Hero-Bereich einer Next.js-Website?

Die Integration in die Next.js-Website war offensichtlich – aber mit einigen technischen Einschränkungen:

• Performance: kein Autoplay, kein Preload der gesamten Videodatei. Ein YouTube-Embed mit Fassade (Platzhalterbild + Play-Button), um das Laden des Iframes beim ersten Rendern zu vermeiden.
• Mobile Responsive: Das 16:9-Verhältnis muss sich ohne schwarze Balken oder Überlauf auf alle Bildschirme anpassen.
• SEO: VideoObject-Tag in JSON-LD, damit Google das Video indiziert und in den Rich Results anzeigt.

Das Ergebnis: Der Hero-Bereich der Website zeigt jetzt eine Vorschau des Videos mit einem Play-Button. Ein Klick lädt das YouTube-Embed. Das ist der beste Kompromiss zwischen visueller Wirkung und Performance – der Largest Contentful Paint wird nicht beeinträchtigt.

Warum verändert ein 0-Feature-Sprint alles für die Retention?

Parallel zum Video habe ich eine Woche einem 100%igen Qualitätssprint gewidmet. Keine neuen Funktionen – nur Feinschliff, Zuverlässigkeit und stille Korrekturen, die im Alltag den Unterschied machen. 7 Commits. 0 neue Features.

Das ist kontra-intuitiv, wenn du ein Solo-Entwickler bist. Du hast eine ellenlange Liste von Features, die hinzugefügt werden müssen. Jeder Tag ohne neue Features scheint dir verloren. Aber das Gegenteil ist der Fall: Jede beseitigte Mikro-Reibung, jeder behobene stille Fehler bedeutet einen Benutzer mehr, der die App nicht nach 3 Tagen deinstalliert.

Dieser Sprint folgt dem vorherigen Qualitätssprint, der bereits Erinnerungen und E-Mails korrigiert hatte. Diesmal betreffen die Korrekturen den Kern der App.

Wie macht man einen Stopp-Knopf auf einem Sprach-Diktiergerät zu 100% zuverlässig?

Der frustrierendste Fehler der App: Manchmal reagierte der "Stopp"-Knopf nicht. Das Mikrofon nahm weiter auf, der Benutzer musste das Stoppen erzwingen. Absoluter UX-Albtraum.

Die Ursache? Ein Timing-Problem zwischen der Initialisierung des nativen STT (Spracherkennung des Telefons) und dem React-State. Wenn der Benutzer während eines Fensters von wenigen Millisekunden, in dem sich das STT zwischen zwei Zuständen befand, auf Stopp drückte, wurde der Stopp-Callback einfach ignoriert.

Die technische Lösung in 3 Punkten

• "Standby"-Modus für das native STT: Anstatt das STT bei jedem Drücken des Mikrofon-Buttons vollständig zu initialisieren, bleibt es in einem aktiven Standby-Zustand. Ergebnis: 2x schnellerer Start, keine Wartezeit auf Callbacks.
• Absoluter Stopp-Knopf: Unabhängig vom internen Zustand des STT (Initialisierung, Hören, Verarbeitung) löst der Stopp-Knopf einen erzwungenen Stopp aus. Keine Bedingung, kein "warte, bis der Callback zurückkommt".
• Sicherheits-Cleanup: Ein 30-Sekunden-Timeout bereinigt automatisch alle Restzustände – inspiriert vom Muster, das im AudioPlayerService verwendet wird.

Dieser Fix ist vielleicht der wichtigste des gesamten Sprints. Die Sprachpipeline ist das Herzstück von TAMSIV. Wenn der Aufnahme-Button nicht zu 100% zuverlässig ist, spielt nichts anderes eine Rolle.

Wie bringt man einer Sprach-KI bei, Datumsbereiche zu verstehen?

Früher funktionierte die Frage "was habe ich diese Woche?" an die KI nur für einen Tag. Der System-Prompt beschränkte die Anfragen auf ein einziges Datum. Ein typisches Problem bei der Gestaltung von Prompts für konversationelle KI.

Die Lösung erforderte zwei Änderungen:

1. Erweiterung des System-Prompts: Hinzufügen von Beispielen für Datumsbereiche ("Montag bis Freitag", "die nächsten 3 Tage", "diese Woche") in den Anweisungen der KI.
2. Änderung des Function Calling: Das Tool create_calendar_event akzeptiert jetzt einen optionalen Parameter end_date für Anfragen, die einen Bereich betreffen.

Jetzt versteht der Assistent Bereiche: "Montag bis Freitag", "die nächsten 3 Tage", "diese Woche". Das ist eine subtile Änderung, die aber die tägliche Nutzung des Kalenders verändert.

Warum von SDXL zu HiDream für die KI-Bildgenerierung wechseln?

Die Coverbilder der Ordner in TAMSIV werden von KI generiert. Wir verwendeten SDXL 0.9, das zwei große Probleme hatte: Es verstand komplexe Prompts schlecht (gemischter Text, ignorierte Anweisungen) und die Qualität war inkonsistent.

Der Wechsel zu HiDream-I1-Fast über Runware hat alles verändert. Besseres Prompt-Verständnis, konsistentere Ergebnisse und Kosten von ~0,003 EUR pro Bild. Es ist dasselbe Modell, das ich für die Inline-KI-Bilder im Diktiergerät verwende – die visuelle Konsistenz bleibt in der gesamten App erhalten.

Wie erkennt man ein Datenleck zwischen Benutzersitzungen?

Ein kritischer Fehler, der während dieses Sprints entdeckt und behoben wurde: Auf einem gemeinsam genutzten Gerät konnten die Daten des vorherigen Benutzers bei einem Kontowechsel kurzzeitig erscheinen. Der Singleton-Cache wurde beim Logout nicht geleert.

Dies ist ein kritischer Sicherheitsfehler. Auch wenn die Exposition kurz ist (einige hundert Millisekunden), kann ein Benutzer die Aufgaben, Notizen oder Ereignisse eines anderen Benutzers sehen. In einer Produktivitäts-App, die persönliche Daten verwaltet, ist das inakzeptabel.

Die Korrektur: Vollständige Bereinigung beim Logout

Die Lösung ist theoretisch einfach, erfordert aber Sorgfalt: Jeder Singleton-Dienst (ContentCacheService, CalendarService, GamificationService) erhielt eine clearAll()-Methode, die bei jeder Abmeldung systematisch aufgerufen wird. Das Sicherheitssystem von TAMSIV beinhaltet jetzt eine Überprüfung, dass alle Caches leer sind, bevor eine neue Sitzung initialisiert wird.

Welche kombinierten Auswirkungen haben das Video und der Qualitätssprint?

Das Video und der Qualitätssprint sind zwei Seiten derselben Medaille:

• Das Video ist das Schaufenster – es macht das Projekt für jemanden greifbar, der die App noch nie benutzt hat. Es ist das Akquise-Tool.
• Der Qualitätssprint ist das Fundament – er macht den Unterschied zwischen einer App, die man ausprobiert, und einer App, die man behält. Es ist das Retention-Tool.

Beide ergänzen sich perfekt. Benutzer mit einem schönen Video anzuziehen, um sie dann wegen eines fehlerhaften Stopp-Buttons zu verlieren, wäre eine Katastrophe. Umgekehrt nützt eine perfekt polierte App, die niemand kennt, nichts.

Genau diese Logik erläutere ich im Artikel über den Verlauf der über 650 Commits: Jede Phase des Projekts wechselt zwischen sichtbaren Features und unsichtbarem Feinschliff.

Welche Lehren kann ein Solo-Entwickler, der seine App startet, daraus ziehen?

Nach dieser Woche nehme ich Folgendes mit:

1. Dreh dein Video frühzeitig. Warte nicht, bis die App "perfekt" ist. Ein 2-minütiges Video mit einem funktionierenden Produkt ist besser als monatelange Textbeschreibungen.
2. Plane deine Qualitätssprints. Blockiere jede zweite Woche ohne neue Features. Der Zero-Feature-Sprint ist für mich zu einem Ritual geworden.
3. Der Hauptknopf muss unfehlbar sein. Für TAMSIV ist es der Mikrofon-Knopf. Für dich ist es der Knopf, der dein Kernwertversprechen darstellt. Wenn er einmal versagt, verlierst du das Vertrauen.
4. Überprüfe die Sicherheit der Singletons beim Logout. Wenn du In-Memory-Caches in einer mobilen App verwendest, stelle sicher, dass sie bei jedem Sitzungswechsel geleert werden.

Häufig gestellte Fragen

Wie lange dauert es, ein Demo-Video für eine mobile App zu drehen?

Für TAMSIV dauerte das 2-minütige Video etwa einen halben Tag: Szenariovorbeitung, 3 Takes, grundlegende Bearbeitung. Es ist kein professionelles Studio nötig – gute Beleuchtung und ein gut gerahmter Bildschirm reichen aus. Wichtig ist, die reale Interaktion zu zeigen, nicht ein Mockup.

Sollte ein Qualitätssprint vor oder nach dem Launch stattfinden?

Beides. Vor dem Launch zielt ein Qualitätssprint auf die sichtbarsten Reibungspunkte ab (wie den Stopp-Knopf). Nach dem Launch leiten Benutzerfeedback die Prioritäten. Ich empfehle einen Qualitätssprint alle 2 Wochen während der Beta-Phase.

Verbraucht der Standby-Modus des STT mehr Batterie?

Nein, der Standby-Modus hält das STT-Modul im Speicher, startet aber nicht das aktive Hören. Der Batterieverbrauch ist im Vergleich zur aktiven Aufnahme vernachlässigbar. Es ist vergleichbar mit dem Halten einer initialisierten SpeechRecognizer-Verbindung, ohne sie zu starten.

Wie vermeidet man Datenlecks zwischen Sitzungen auf einem gemeinsam genutzten Gerät?

Drei Regeln: (1) Jeder Singleton-Dienst muss eine clearAll()-Methode haben, (2) diese Methode wird im Logout-Handler aufgerufen, (3) ein automatisierter Test überprüft, dass alle Caches nach dem Logout leer sind. Das ist grundlegend, wird aber oft in Singleton-basierten Architekturen vergessen.

Ist HiDream-I1-Fast besser als SDXL für die Generierung von App-Bildern?

Für Coverbilder und kontextbezogene Illustrationen, ja. HiDream versteht komplexe Prompts besser und liefert konsistentere Ergebnisse. SDXL bleibt für reinen Fotorealismus relevant, aber für funktionale Bilder in einer mobilen App ist HiDream eine bessere Wahl zu ähnlichen Kosten (~0,003 EUR/Bild).