Was sich nach dem Launch einer mobilen App wirklich ändert

Während der Entwicklung lässt sich ein Produkt in klar getrennten Aufgaben betrachten: Oberfläche, Logik, Accounts, Stores und Veröffentlichung. Im laufenden Betrieb greifen diese Bereiche ineinander. Eine scheinbar kleine Änderung an einer Entscheidung kann bestehende Spielverläufe, gespeicherte Zustände oder die Verständlichkeit anderer Bereiche beeinflussen.

Für ReLife bedeutet das, nicht nur neue Inhalte zu bauen. Jede Version muss zur vorhandenen Produktlogik passen, auf iOS und Android verlässlich auslieferbar sein und für Menschen verständlich bleiben, die bereits einen Verlauf begonnen haben.

Ein Life-Simulator besteht nicht aus unabhängigen Formularen. Karriere, Geld, Beziehungen, Gesundheit und Gewohnheiten beeinflussen sich gegenseitig. Je mehr Systeme hinzukommen, desto größer wird die Gefahr, dass einzelne Entscheidungen zwar technisch funktionieren, für Nutzer aber nicht mehr nachvollziehbar sind.

Die zentrale Produktaufgabe ist deshalb nicht maximale Komplexität. Sie besteht darin, Zusammenhänge so zu schneiden, dass Entscheidungen Wirkung haben und trotzdem erklärt werden können. Dieselbe Frage entsteht auch bei Kundenportalen, Konfiguratoren oder internen Werkzeugen mit mehreren Rollen und Regeln.

In-App-Käufe und Accounts lassen sich nicht sinnvoll kurz vor dem Release ankleben. Kaufstatus, Wiederherstellung, Plattformunterschiede, Fehlerzustände und Supportwege wirken direkt auf Vertrauen. Dasselbe gilt für gespeicherte Verläufe und den Wechsel zwischen Versionen.

Deshalb plane ich Monetarisierung und Identität als Kernabläufe. Nicht jeder Sonderfall muss in der ersten Version gelöst sein. Aber das Datenmodell und die Zuständigkeiten dürfen spätere verlässliche Lösungen nicht blockieren.

Die wichtigste Erkenntnis ist unspektakulär: Eine Anwendung muss nicht nur bei der Abnahme funktionieren. Sie muss veröffentlicht, beobachtet, erklärt und verändert werden können. Genau deshalb gehören Release- und Betriebsfragen bereits in den ersten Scope.

Das führt nicht automatisch zu einem größeren MVP. Häufig wird der erste Umfang dadurch kleiner, weil klarer zwischen notwendigem Kern, späterem Ausbau und vermeidbarer Komplexität getrennt werden kann.