„Was können wir weglassen?“ ist die richtige Frage, wenn das Budget begrenzt ist. Sie hat nur eine zweite Hälfte: Was darf nicht weg, weil es sich später nur zum Preis eines Umbaus nachrüsten lässt?
Warum die erste Version klein geschnitten wird, steht in „Das MVP-Prinzip: Weniger App, mehr Erfolg“. Hier geht es um das Gegenstück: sieben Dinge, die in einem MVP bleiben, obwohl keines davon auf einem Screenshot gut aussieht.
Die Prüffrage
Funktionen sind nachlieferbar: Eine Auswertung oder eine Suche kommt in Version 1.2 dazu und kostet dann meist etwa so viel wie heute. Fundamente stecken in der Struktur – im Datenmodell, im Release-Prozess, in den Store-Angaben. Wer sie nachträglich einzieht, baut nicht dazu, sondern um.
Die Prüffrage für jede Streichung lautet deshalb nicht „brauchen wir das zum Start?“, sondern: Kostet dieser Punkt später ungefähr dasselbe wie heute – oder ein Vielfaches?
1. Datenhaltung, getrennt von der Anzeige
Jede App speichert etwas: Einträge, Kunden, Fotos. Entscheidend ist, wo dieser Code wohnt. Liegen Speichern und Lesen verstreut in den Bildschirmen, hängen die Daten an der Oberfläche – ein Server lässt sich dann meist nur mit einem Umbau großer Teile der App ergänzen.
Drei Punkte, die du im Angebot ansprechen kannst:
- Eine eigene Datenschicht. Ein Ort im Code, der speichert und liest; die Bildschirme fragen dort nur an.
- Eine eindeutige ID und ein Zeitstempel „zuletzt geändert“ an jedem Datensatz, auf dem Gerät erzeugt. Ohne beides wird ein späterer Abgleich mit einem Server unzuverlässig.
- Eine Versionsnummer am Datenbestand, damit ein späteres Update vorhandene Daten umziehen kann, statt sie zu verlieren.
Das ist meist Arbeit von Tagen, nicht von Wochen. Ob deine App überhaupt einen Server braucht, klärt Braucht meine App ein Backend? – die drei Punkte halten dir die Tür offen, ohne dass du heute entscheiden musst.
2. Absturzberichte ab dem ersten Tag
Beide Stores zeigen Abstürze im Entwicklerkonto – aber nur von Geräten, deren Nutzer Diagnosedaten teilen, und ohne die Vorgeschichte dazu (Stand 2026). Eigene Berichte schließen die Lücke.
Konkret: Die Absturzberichterstattung gehört vor den ersten Test mit fremden Geräten in die App, und zu jedem Release die archivierten Symboldateien – unter iOS die dSYM-Dateien, unter Android die Mapping-Datei der Code-Verschleierung. Ohne sie ist ein Bericht kaum lesbar, und später sind sie schwer zu beschaffen.
Datenschutzrechtlich sind die Berichte nicht automatisch harmlos – Gerätetyp, Version und Zeitpunkt lassen sich unter Umständen zuordnen; ob und wie sie in deiner Datenschutzerklärung auftauchen müssen, bewertet dein Anwalt oder Datenschutzbeauftragter. Wo die Grenze zwischen Absturzbericht, Nutzungsstatistik und Tracking verläuft, steht in App-Analytics ohne Datenschutz-Ärger – mehr als die Absturzrate und zwei, drei Nutzungszahlen braucht ein MVP nicht.
3. Kontolöschung, sobald es Konten gibt
Können Nutzer ein Konto anlegen, ist die Löschung keine Kür, sondern eine Bedingung beider Stores (Stand 2026). Apple verlangt in den App-Review-Richtlinien, dass Apps mit Konto-Registrierung die Kontolöschung in der App anbieten; Einzelheiten und Ausnahmen beschreibt Apple in einer eigenen Anleitung dazu. Google Play verlangt für solche Apps einen Weg in der App und zusätzlich einen Web-Link, über den sich die Löschung von Konto und zugehörigen Daten anfordern lässt – auch von Leuten, die die App längst deinstalliert haben.
Teuer wird nachträglich nicht der Knopf, sondern die Kaskade: Am Konto hängen Verknüpfungen, Dateien, Push-Token und Protokolle. Sieht das Datenmodell das Löschen über all diese Orte nicht vor, wird der Umbau aufwendig; mehr dazu in DSGVO in Apps.
Die günstigste Variante bleibt: kein Konto. Ob du eines brauchst und welcher Anmeldeweg passt, klärt Login in der App.
4. Store-Angaben und eine Datenschutzerklärung
Beide Stores fragen vor der Veröffentlichung strukturiert ab, welche Daten die App erhebt, und verlangen einen erreichbaren Link auf eine Datenschutzerklärung. Google Play verlangt Formular und Link ausdrücklich auch von Apps, die keine Nutzerdaten erheben; Apple bezieht die Daten eingebundener Fremd-Bibliotheken ausdrücklich mit ein (Stand 2026). Praktisch heißt das: Führ von Anfang an eine Liste, welche Bibliothek was sendet – rückwirkend ist das mühsam.
Den Text der Erklärung schreibt dein Anwalt oder Datenschutzbeauftragter, und die Bewertung deines Einzelfalls gehört ebenfalls dorthin – dafür brauchst du uns nicht. Unser Teil ist die Faktenbasis: welcher Dienst verarbeitet welche Daten, und wo. Wie der Rest der Veröffentlichung abläuft, beschreibt App im Store veröffentlichen.
5. Ein Weg, Daten herauszubekommen
Ein Knopf, der den Bestand als Datei ausgibt – Tabelle, PDF oder Sicherungsdatei –, löst drei Dinge auf einmal: Vertrauen beim Einstieg, Schutz vor Datenverlust beim Gerätewechsel, Grundlage, wenn jemand Auskunft über seine Daten verlangt (ob das genügt, klärt dein Anwalt).
Bleiben die Daten auf dem Gerät, gehört die Frage dazu, ob das Gerätebackup sie mitnimmt. Sonst ist ein verlorenes Handy ein verlorener Datenbestand.
6. Der erste Start
Ein MVP hat eine Funktion. Wer sie beim ersten Öffnen nicht findet, hat oft wenig Anlass für einen zweiten Versuch. Der Einstieg ist kein Feinschliff, sondern Teil des Kernnutzens.
Eine Bildschirmtour braucht es dafür meist nicht: Der erste Bildschirm zeigt den Nutzen statt eines Anmeldeformulars, leere Listen bekommen einen Satz dazu, was hier hinkommt, und einen Knopf, der genau das tut. Mehr dazu in Damit deine App wirklich genutzt wird.
7. Ein Rückmeldeweg
Ein Menüpunkt „Feedback“, der eine E-Mail oder ein Formular öffnet und App-Version, Gerätetyp und Betriebssystemversion mitschickt. Technisch eine Kleinigkeit, aber die Rückmeldungen aus den ersten Wochen bekommst du nur einmal. Fehlt der Weg, landet Ärger leichter in der öffentlichen Store-Bewertung.
Was dafür weg darf
Die Gegenrichtung, damit das nicht nach „alles ist wichtig“ klingt: Ein Admin-Dashboard darf am Anfang eine Tabelle sein. Animationen, Profilseiten, die zweite Nutzergruppe und oft auch Push-Nachrichten lassen sich nachliefern, ohne die Struktur anzufassen.
Und die Liste wird kürzer, als sie aussieht: Läuft deine App ohne Konten und bleiben die Daten auf dem Gerät, entfällt Punkt 3 ganz und Punkt 5 schrumpft auf einen Export-Knopf. Übrig bleiben sechs Fundamente – ein kleiner Teil des Projekts, aber der, der dir Version 2 offen hält.
Fazit
Weglassen ist richtig, solange du Funktionen weglässt und nicht Fundamente. Die sieben Punkte oben kosten heute wenig – nachträglich oft ein Vielfaches.
Beim Sortieren hilft die Vorbereitungs-Checkliste. Bist du unsicher, was bei deinem Vorhaben Funktion und was Fundament ist, gehen wir die Liste im kostenlosen Erstgespräch an deinem Entwurf durch. Wir antworten werktags innerhalb von 24 Stunden – auch dann, wenn die ehrliche Antwort lautet: Für die ersten Punkte reicht eine Stunde mit deinem Entwickler.