Zero-Feature-Sprint: 30 Polish-Commits vor dem Launch

Polishing ist rentabler als Features. In 48 Stunden und 30 Commits ohne neue Funktionen habe ich meine App stabiler gemacht als in sechs Monaten voller Ergänzungen. Hier ist, warum ein "Zero-Feature"-Sprint vor einem Launch die beste Entscheidung ist, die ein Solo-Entwickler treffen kann.

Warum einen Sprint ohne Features vor dem Launch machen?

Sechs Monate lang fügte jeder Entwicklungstag etwas Neues hinzu. Ein Feature, ein Bildschirm, eine Pipeline, eine Integration. Der Commit-Zähler stieg, die Dateien stapelten sich, und die App wuchs mit über 650 Commits.

Und dann kommt ein Punkt, an dem man aufhören muss. Nicht aus Müdigkeit, sondern aus Klarheit. Die App funktioniert für 12 Alpha-Tester, die ihre Grenzen kennen. Aber die breite Öffentlichkeit verzeiht nicht. Laut einer Studie von Apptentive lesen 77% der Nutzer mindestens eine Bewertung, bevor sie eine App herunterladen. Und ein einziger sichtbarer Bug zur falschen Zeit ist eine 1-Stern-Bewertung.

Diese Woche habe ich also das Gegenteil von allem getan, was ich bisher gemacht hatte: 30 Commits in 48 Stunden. Null Features. Nur Polishing, Korrekturen und Vorbereitung auf den Moment, in dem die App aus der Alpha-Phase in die reale Welt eintritt.

Wie behebt man 15 Bugs auf einem einzigen KI-Personalisierungsbildschirm?

Die KI von TAMSIV ermöglicht es Benutzern, sich per Sprache vorzustellen. Du drückst, erzählst dein Leben in 30 Sekunden, und der Assistent passt sich deiner Persönlichkeit an. Das Problem: Der Konfigurationsbildschirm hatte 15 subtile Bugs, die automatische Tests nicht erkannten.

Ein Button, der von einem Overlay verdeckt wurde. Ein Text, der auf kleinen Bildschirmen abgeschnitten war. Eine Endlosschleife, wenn der Benutzer die KI mitten in der Antwort unterbrach. Der Prompt, der sich nach jeder Änderung zurücksetzte. Die Aktionsbuttons, die übereinander gestapelt waren, anstatt vertikal platziert zu werden.

Keiner dieser Bugs wäre bei einem schnellen Test gefunden worden. Man musste die App wie ein echter Benutzer verwenden – überall tippen, im falschen Moment unterbrechen, zurückgehen, es erneut versuchen. Das ist es, was die Nielsen Norman Group als exploratives Usability-Testing bezeichnet: kein Skript, nur ein Mensch, der versucht, die Oberfläche zu zerstören.

15 Commits, um einen einzigen Bildschirm zuverlässig zu machen. Das scheint übertrieben. Aber wenn es der Bildschirm ist, der definiert, wie die KI dich versteht, verschlechtert jeder Mikro-Bug das gesamte Erlebnis.

Was ist der Unterschied zwischen "es funktioniert in Alpha" und "es ist bereit für die Produktion"?

Das Free/Pro/Team-Abonnementsystem existierte seit Februar. Es funktionierte in Alpha. Aber "in Alpha funktionieren" und "bereit für die Produktion sein" sind zwei sehr unterschiedliche Dinge.

In Alpha wissen 12 Tester, dass es sich um eine laufende Arbeit handelt. Sie akzeptieren ungenaues Wording, ein nicht ganz abgestimmtes Design, vage Grenzen zwischen den Plänen. In der Produktion kostet jede Unklarheit einen Benutzer. Laut ProfitWell kann eine verwirrende Preisgestaltungsseite die Konversionen um 20 bis 40% reduzieren.

Die Überarbeitung betraf drei Bereiche:

• Das Wording: Jeder Text wurde überarbeitet, um zu klären, was kostenlos und was kostenpflichtig ist. Keine zweideutigen Formulierungen mehr.
• Das Design des Alpha-Modals: Es hat in der Produktion keinen Grund mehr zu existieren. Entfernt und durch einen natürlichen Fluss zu den RevenueCat-Plänen ersetzt.
• Die Grenzen des kostenlosen Plans: Jeder Bildschirm wurde auf 3 verschiedenen Bildschirmgrößen überprüft, jeder Text responsiv.

Die Art von Arbeit, die in einem Changelog nicht sichtbar ist, aber den Unterschied macht zwischen einem Benutzer, der versteht, wofür er bezahlt, und einem Benutzer, der die App aus Verwirrung deinstalliert.

Welche "kleinen Details" haben den größten Einfluss auf die Retention?

Drei kleinere Anpassungen haben das tägliche App-Erlebnis verändert.

Der TTS-Stopp-Button. Wenn die KI dir laut antwortet und du sie stoppen möchtest, musstest du früher den Ton des Telefons ausschalten. Jetzt reicht ein Toggle. Das mag trivial erscheinen, aber es ist genau die Art von Reibung, die einen Benutzer zur Deinstallation drängt. Das Diktiergerät ist das Herzstück von TAMSIV – es muss tadellos sein.

Der strikte Umfang des LLM. Die KI neigte dazu, Fragen außerhalb des Themas zu beantworten – Wetter, Allgemeinwissen, Philosophie. In der Produktion muss sie konzentriert bleiben: Aufgaben, Memos, Ereignisse. Punkt. Ein Backend-Schutz, der alles andere höflich ablehnt. Wie der Prompt-Engineering-Leitfaden von OpenAI erklärt, ist die Festlegung klarer Grenzen für das LLM für ein konsistentes Benutzererlebnis unerlässlich.

Der Toggle für generierte Bilder. Jede Konversation kann ein Titelbild per KI generieren, dank der Runware-Integration im Diktiergerät. Aber das kostet Credits. Ein Schalter im Header des Diktiergeräts ermöglicht es nun, die Bildgenerierung spontan zu deaktivieren. Transparenz und Kontrolle.

Was bedeutet versionCode 30 für einen Solo-Entwickler?

Jeder Android-Build hat eine Nummer. Wir sind beim 30. Die 29 vorherigen waren Alpha-Builds – Builds für 12 Tester, die Bugs im Austausch für die Vorabversion akzeptierten. Build 30 ist der letzte, bevor jeder TAMSIV im Play Store herunterladen kann.

Es ist eine banale Zahl. Aber sie repräsentiert den Moment, in dem "meine App" zu "einer App" wird. Wo der Code nicht mehr durch den wohlwollenden Filter der Beta-Tester geschützt ist. Wo jeder Bug eine potenzielle 1-Stern-Bewertung ist.

Um das ins rechte Licht zu rücken: Der vorherige Qualitätssprint hatte bereits Dutzende von Problemen behoben. Build 30 ist das Ergebnis von zwei Wochen intensiven Polishing, nicht nur von 48 Stunden. Es ist die letzte Schicht vor der Veröffentlichung.

Wie entscheidet man, wann man aufhören sollte, Features hinzuzufügen?

Die Versuchung des Solo-Entwicklers ist es, immer mehr hinzuzufügen. Ein Feature ruft ein anderes hervor. Das Backlog leert sich nie. Und je größer die App wird, desto mehr unerwartete Interaktionen erzeugt jede Ergänzung mit dem Rest.

Ich habe eine einfache Regel angewendet: Wenn ein Bug in den ersten 5 Minuten der Nutzung auftreten kann, hat er Vorrang vor jedem Feature im Backlog. Das ist es, was Marty Cagan den "Reference Customer Test" nennt – wenn dein Referenzkunde den grundlegenden Workflow nicht ohne Reibung abschließen kann, zählt nichts anderes.

Dieser Sprint hat mich etwas gelehrt: Polishing ist nicht der Feind des Fortschritts. Es ist das Gegenteil. Das Beheben von 15 Bugs auf einem einzigen Bildschirm hat die App stabiler gemacht als jedes neue Feature. Benutzer sehen keine Commits. Sie sehen eine App, die funktioniert – oder die nicht funktioniert.

Wie sieht der Workflow eines Polishing-Sprints in der Praxis aus?

Konkret habe ich diese 48 Stunden wie folgt organisiert:

1. Audit pro Bildschirm: Ich habe jeden Bildschirm der App auf 3 verschiedenen Geräten (klein, mittel, groß) geöffnet und jede visuelle oder funktionale Anomalie notiert.
2. Priorisierung nach Auswirkung: Bugs, die in den ersten 5 Minuten sichtbar sind, oben, Edge Cases unten.
3. Atomare Commits: Ein Commit = ein Fix. Keine Sammel-Commits. Das ermöglicht ein chirurgisches Rollback, wenn ein Fix etwas anderes kaputt macht.
4. Regressionstest: Nach jedem Fix erneute Überprüfung der angrenzenden Bildschirme. Wenn du die Architektur einer gemeinsamen Komponente berührst, ist der Dominoeffekt real.

Dieser Workflow ist nicht spektakulär. Es gibt keine neue Technologie, kein heroisches Refactoring. Nur Disziplin und Zeit, die man damit verbringt, die eigene App wie ein normaler Benutzer zu verwenden.

Warum ist Polishing für einen Launch rentabler als Features?

Die Zahlen sind klar. Im Play Store verlieren Apps mit einer Bewertung unter 4 Sternen bis zu 50% ihrer potenziellen Downloads. Und die ersten Bewertungen sind entscheidend: Sie bestimmen die Entwicklung der App für die folgenden Monate.

Ein Feature hinzuzufügen, das 10% der Benutzer beeindruckt, aber für 5% von ihnen einen Bug erzeugt, ist ein schlechter Kompromiss. Im Gegensatz dazu ist das Beheben von 30 Mikro-Bugs, die potenziell jeden betreffen, eine Investition mit garantierter Rendite.

Dieser Polishing-Sprint betraf den gesamten Benutzerpfad: vom Onboarding über die Abonnementverwaltung bis hin zum Kern der App – das Sprachdiktiergerät. Und der Unterschied liegt in diesen 30 unsichtbaren Commits.

Build 30 ist bereit. Die App ist sauberer, stabiler, klarer als je zuvor. Als Nächstes kommt die breite Öffentlichkeit.