Wie läuft eine App-Entwicklung ab?

Eine App-Entwicklung ist kein einzelner Block, sondern fünf Phasen mit unterschiedlicher Logik. Wer das Ablaufmuster nicht kennt, plant entweder zu eng (alles in vier Wochen, Submission als „Detail” am Ende) oder zu breit (sechs Monate Konzept, V1 wird nie geliefert). Hier ist der typische Verlauf, wie er in den meisten Sovion-Projekten läuft — und wo die häufigsten Reibungspunkte sitzen.

Phase 1: Konzept und Spec — 1 bis 4 Wochen

Bevor jemand Code schreibt, wird der Scope geschnitten. In dieser Phase passieren drei Dinge:

• Problem-Spec. Welches Problem löst die App in einem Satz, wer ist die erste Nutzergruppe, was ist der Aha-Moment? Mehr zur Scope-Disziplin im Sub-Guide MVP oder direkt komplett.
• MoSCoW-Schnitt. Must-have, Should-have, Could-have, Won’t-have-this-time. Verhältnisse von etwa 60/20/0/20 sind ein gesunder V1-Start.
• Architektur- und Stack-Entscheidungen. Plattform (Native, Cross-Plattform, PWA), Hosting-Region, externe Dienste, Auth-Provider. DSGVO-relevante Entscheidungen müssen hier fallen — siehe DSGVO bei der App-Entwicklung.

Was Auftraggeber:innen aktiv entscheiden müssen: Ziel, Zielgruppe, Top-5-Features, Branding-Vorgaben, vorhandene Systeme, mit denen die App sprechen muss. Was nicht in dieser Phase entschieden werden muss: jedes UI-Detail, jede Edge-Case-Behandlung, jede Marketing-Frage.

Häufiger Reißpunkt: zu kurze Phase. Eine Woche reicht selten — drei Wochen sind oft die Untergrenze, in der ein belastbarer V1-Schnitt entsteht.

Phase 2: Sprint Zero — Setup und Designsystem

Sprint Zero ist die Woche zwischen Spec und erstem Feature-Code. Was darin passiert:

• Repos und CI/CD aufsetzen. Build-Pipeline, automatisierte Tests, Code-Review-Prozess.
• Designsystem. Komponenten-Bibliothek mit Farben, Typografie, Buttons, Formulare. Im Idealfall in Figma plus eine erste Code-Übersetzung in der App.
• Datenmodell-Erstentwurf. Entitäten, Relationen, Lifecycle-States. Erste DSGVO-Bestandsaufnahme: welche Daten werden wo gespeichert, welcher Auftragsverarbeiter trägt was.
• Tracking-Konzept. Wenn Crash-Reporting, Analytics oder Performance-Monitoring Teil des Plans sind, werden die Tools hier ausgewählt.

Häufiger Reißpunkt: Designsystem wird mit „bauen wir nebenher” verschoben. Nach drei Wochen Build sieht jede Komponente anders aus, und die Aufräumung kostet eine Woche, die nicht eingeplant war.

Phase 3: Build — 6 bis 16 Wochen

Hier passiert die eigentliche Entwicklung. Drei Eigenschaften, die einen guten Build-Modus auszeichnen:

Wöchentliche Demos

Jede Woche zeigt das Team einen funktionsfähigen Stand. Nicht „der Login ist fertig”, sondern „der Login läuft, hier ist der Klick-Pfad”. Auftraggeber:innen sehen früh, ob das Gebaute zum Konzept passt — und können in der laufenden Iteration nachjustieren, statt erst am Ende.

Iterativer Scope

Kein Wasserfall. Jede Woche werden konkrete Aufgaben aus der Backlog-Spitze gezogen, am Ende der Woche ausgeliefert. Was sich im Verlauf als überflüssig herausstellt, fällt raus. Was als Lücke auftaucht, kommt rein — wenn es Must-have-Charakter hat. Should-haves werden V1.5, nicht V1.

Tests laufen mit, nicht hinterher

Automatisierte Tests entstehen parallel zum Code, nicht in einer „Test-Phase” am Ende. Tests am Ende sind in der Praxis Tests, die nie geschrieben werden — und eine App ohne Tests wird in der Wartung 30–50 % teurer pro Jahr.

Häufiger Reißpunkt: Auftraggeber-Feedback erst in Woche 8. Bis dahin ist der Stack zementiert, und Korrekturen werden teuer. Wöchentlicher Rhythmus mit kurzen Demo-Checks ist die wichtigste Disziplin in dieser Phase.

Phase 4: Submission und Store-Review

Submission ist kein Tag, sondern ein bis zwei Wochen. Was hier passiert:

• Privacy-Manifest (Apple-Pflicht seit 2024) und Data-Safety-Form (Google-Pflicht). Beide müssen mit der tatsächlichen Datennutzung konsistent sein. Reproduzierbare Reject-Quelle, wenn das erst am Submission-Tag geprüft wird.
• Beta-Review über TestFlight (iOS) und Google Play Internal Testing. Eine bis zwei Wochen vor Public-Launch werden externe Beta-Tester:innen gezielt durch die App geschickt.
• Public-Submission. Apple weist im App-Store-Connect-Hilfsdokument typische Review-Zeiten unter 24 Stunden aus, lehnt aber regelmäßig ab. Apple hat 2024 laut eigenem Transparenzbericht 1,93 Mio. von 7,77 Mio. Submissions abgelehnt — eine Quote von rund 25 %. Die Top-Gründe sind Performance, Privacy und Design.
• Marketing-Assets. Screenshots, Beschreibungstexte, App-Icon, Promo-Videos. Sollte parallel zur Beta laufen, nicht hinterher.

Häufiger Reißpunkt: das Team plant einen Submission-Tag und einen Launch-Tag. In der Realität läuft Apple-Review oft glatt, kann aber auch eine zweite Runde verlangen. Eine Woche Puffer zwischen geplanter Submission und kommuniziertem Launch ist Pflicht.

Phase 5: Launch und erste Iteration

Der Launch ist nicht das Ende — er ist der Punkt, an dem du das erste echte Feedback bekommst. Was in den ersten vier bis acht Wochen passiert:

• Crash-Spikes durch Geräte oder OS-Versionen, die nicht im Test-Lab waren. Crash-Reporting (Sentry, Firebase Crashlytics, Bugsnag) wird hier wichtiger als alles andere.
• Onboarding-Friktion zeigt sich in den Drop-off-Daten. Welche zehn User schaffen den Aha-Moment, welche zehn nicht? Erste konkrete UX-Hypothesen für V1.5.
• Erste Support-Anfragen. Welche Top-3-Fragen kommen wiederholt? Das ist die Roadmap der nächsten zwei Wochen.
• Compliance-Drift beginnt schon hier. Die ersten neuen iOS-Beta-Versionen kommen, Google-Play-Target-SDK-Anhebungen stehen ins Haus, der BSI-Lagebericht IT-Sicherheit 2025 verzeichnet durchschnittlich 119 neue CVEs pro Tag.

Häufiger Reißpunkt: das Team löst sich nach dem Launch auf. Niemand sieht die Crash-Spikes, niemand reagiert auf Compliance-Pflichten — siehe Guide AppCare. Die ersten 90 Tage nach Launch sind die wichtigsten der ersten zwölf Monate.

Wer was entscheidet — eine kurze Rollen-Karte

In jeder Phase gibt es Entscheidungen, die nur Auftraggeber:innen treffen können — und solche, die das Entwicklungsteam besser allein trifft. Drei Trennlinien, die in der Praxis tragen:

• Auftraggeber-Entscheidungen. Ziel, Zielgruppe, Scope-Reduktion, Branding, Compliance-Anforderungen, Roadmap-Prioritäten.
• Team-Entscheidungen. Stack-Detail, Library-Wahl, Test-Strategie, Code-Architektur, CI/CD-Setup.
• Gemeinsame Entscheidungen. Plattform-Wahl, Hosting-Region, Auftragsverarbeiter-Auswahl, externe Dienste mit Lizenzfolgen.

Wer hier die Linien verschwimmen lässt, baut entweder ein Produkt, das das Team nicht versteht, oder einen Stack, der zum Geschäft nicht passt.

Realistische Gesamt-Timeline

Für die meisten App-Klassen ergibt sich daraus folgender Verlauf:

• Wochen 1–3: Konzept und Spec.
• Woche 4: Sprint Zero.
• Wochen 5–14: Build (10 Wochen für mittelgroße Apps; 6 für schlanke MVPs, 14–16 für komplexere V1s).
• Wochen 15–16: Submission, Beta, Launch.
• Wochen 17–24: erste Iteration nach Launch (V1.5).

Die Zahlen sind keine Garantie — sie sind die Verteilung, gegen die wir Zeitpläne stresstesten. Wer in vier Wochen einen V1 will, baut entweder etwas, das nicht trägt, oder definiert „V1” um.

Wenn du gerade mit einer Idee in dieser Logik landen willst: beschreib uns die App in drei Sätzen — was sie tut, wer sie nutzt, ob du eine harte Deadline hast — über das Kontaktformular. Wir antworten in 24 Stunden mit einer realistischen Phasen-Schätzung. Mehr Kontext: Was kostet eine App-Entwicklung? für die Budget-Logik dahinter, und Native vs. Cross-Plattform vs. PWA für die Stack-Entscheidung in Phase 1.