Zeitpläne in der App-Entwicklung gehören zu den Zahlen, die in unserer Branche am konsequentesten falsch genannt werden. Wir haben Versprechen von „8 Wochen bis zum App Store" ebenso erlebt wie „12-Monate"-Schätzungen für Projekte, die in drei Monaten live gehen. Nach über 30 produktiven App-Launches auf iOS, Android und Cross-Platform-Stacks finden Sie hier die Aufschlüsselung, die wir tatsächlich verwenden, wenn wir einen Auftrag kalkulieren.
Die vier echten Kostentreiber
Die meisten App-Zeitpläne werden von vier Phasen bestimmt — nicht von der Anzahl der Codezeilen:
- Discovery und Architektur — aus einem Briefing eine umsetzbare Spezifikation machen.
- Design — UX-Flows, Designsystem, Motion, Edge Cases.
- Engineering — Feature-Implementierung, Integrationen, QA.
- Store-Readiness — App Store Connect, Play Console, ASO, Review-Prozess.
Wird eine dieser Phasen übersprungen oder zusammengestaucht, entstehen die meisten „verspäteten" Projekte. Die Engineering-Phase gerät selten von allein in Verzug — sie gerät in Verzug, weil die Discovery nicht tief genug war oder das Designsystem noch nicht fertig war.
Realistische Zeitrahmen
Minimum-Viable-Apps (MVP, 4–8 Wochen)
Enger Scope, keine komplexe Authentifizierung, zunächst eine Plattform, keine Drittanbieter-Integrationen außer Analytics und Crash-Reporting. Beispiele: eine Content-App mit handkuratiertem Feed, ein Single-Purpose-Tool, eine begleitende Marketing-App.
Die Kompromisse: begrenzter Feinschliff bei Animationen, kein Admin-Panel, manuell gepflegte App-Store-Metadaten, keine Segmentierung von Push-Benachrichtigungen. Sie können eine brauchbare v1 ausliefern — werden aber im nächsten Quartal wahrscheinlich die Hälfte davon neu schreiben.
Produktionsreife Apps (8–16 Wochen)
Authentifizierung (E-Mail, Apple, Google), ein bis zwei Integrationen (Payments, Analytics, Push), ein echtes Designsystem und CI/CD-Pipelines vom ersten Tag an. Die meisten B2C-Apps, die wir ausliefern, liegen hier.
Typischer Scope auf diesem Niveau:
- Vollständiger Sign-up- und Onboarding-Flow
- 5–10 Hauptscreens mit Motion und Übergängen
- Echtzeit-Datensynchronisation über WebSockets oder Polling
- In-App-Käufe oder Abonnements (StoreKit, Google Play Billing, RevenueCat)
- Analytics + Crash-Reporting + Remote Config
Plattform-Apps (16–28 Wochen)
Wenn die App das Produkt ist und nicht nur Beiwerk. Mandantenfähige Daten, Offline-First-Architektur, komplexe Berechtigungen, native Module, umfangreiche Content-Bibliotheken.
Beispiele aus unserer Praxis: eine B2B-Logistik-App für die Disposition mit Echtzeit-Routenupdates, eine Healthtech-Wellness-Plattform mit personalisierten Content-Engines, ein Marktplatz, auf dem Anbieter und Nutzer unterschiedliche App-Varianten verwenden.
Nativ oder Cross-Platform?
Diese Entscheidung erhöht oder senkt den Engineering-Aufwand um 20–40 %, je nachdem, wie Sie sich entscheiden.
Nativ (Swift + Kotlin) ist die richtige Wahl, wenn:
- Sie immersive UX ausliefern (AR, individuelle Kamera, komplexe Animationen)
- plattformspezifische Features wichtig sind (Live Activities, Widgets, Wear OS)
- die App das Produkt ist und nicht nur Beiwerk
Cross-Platform (Flutter, React Native) ist die richtige Wahl, wenn:
- Sie gleichzeitig auf iOS und Android starten müssen
- Ihr Team einen Stack besser betreuen kann als zwei
- 95 % der UX plattformübergreifend identisch sind
Für die meisten B2C-Apps sind Flutter und React Native 2026 ausgereift genug, dass der Performance-Unterschied für Endnutzer nicht spürbar ist. Die ausführliche Abwägung steht auf unserer Seite zur Cross-Platform-Entwicklung, plattformspezifische Details unter iOS.
Was Verzögerungen wirklich verursacht
Nach über 30 Launches ist das Muster der Verzögerungen immer dasselbe. Nach Häufigkeit geordnet:
- Scope Creep nach dem Design-Freeze — „Können wir nicht schnell noch …" in Woche 6 ist der Klassiker.
- Instabile Drittanbieter-APIs — bei Payment-, Identitäts- und Versanddienstleistern ist Sandbox nicht gleich Produktion.
- Überraschungen im App-Store-Review — Lücken in der Datenschutzerklärung, IAP-Regeln, App Tracking Transparency.
- Backend nicht bereit — Mobile hängt der API nach. Ist die API nicht versioniert und stabil, wird Mobile zur permanenten Regressionsmaschine.
- Design-Nacharbeit nach dem ersten Usability-Test — der richtige Zeitpunkt zum Testen ist Woche 2, nicht Woche 10.
Budgetrahmen passend zu diesen Zeitplänen
Für Senior-Teams, die 2026 produktionsreife Apps ausliefern:
- MVP, 4–8 Wochen → 25.000–60.000 €
- Produktionsreif, 8–16 Wochen → 60.000–150.000 €
- Plattform-App, 16–28 Wochen → 150.000–400.000 €
Diese Zahlen setzen durchgängig Senior-Engineers und -Designer voraus. Junior-Teams kosten pro Stunde weniger, brauchen aber typischerweise 1,5- bis 2-mal so lange und erzeugen mehr technische Schulden — die Gesamtbetriebskosten sind selten niedriger. Was die einzelnen Bänder im Detail treibt, steht in Was kostet App-Entwicklung 2026?; der App-Entwicklung Kosten-Rechner macht aus Ihrer eigenen Konfiguration eine Spanne und eine Laufzeit.
Wohin die Zeit tatsächlich geht
Eine nützliche Plausibilitätsprüfung für jeden genannten Zeitplan ist die Aufteilung. Bei einer produktionsreifen App sehen wir typischerweise:
- Discovery und Architektur — 10–15 %. Hier zu kürzen erzeugt genau die „verzögerten" Projekte weiter unten.
- Design — 20–25 %. Der größte Teil entfällt auf Zustände, die niemand vorführt: Laden, Leer, Fehler, Offline.
- Entwicklung — 40–50 %. Der Teil, den alle schätzen — und der am wenigsten aus dem Ruder läuft.
- QA und Store-Vorbereitung — 15–25 %. Über das Projekt verteilt, nicht am Ende angehängt.
Wenn ein Anbieter 80 % in die Entwicklung legt, hat er die anderen drei nicht geplant, sondern verschoben. Fragen Sie im Zweifel nach dieser Aufteilung — die Antwort sagt mehr über die Belastbarkeit des Termins aus als die Gesamtzahl. Wie das Testen konkret aussieht, steht in unserem QA-Leitfaden.
Wie wir bei runIT kalkulieren
Bevor wir uns auf einen Zeitplan festlegen, führen wir einen einwöchigen Discovery-Sprint durch:
- Tag 1–2: Stakeholder-Workshops, technisches Audit, falls Sie bereits eine App haben
- Tag 3–4: Informationsarchitektur, User Flows, technisches Risikoregister
- Tag 5: durchgeplantes Backlog, Sprint-Plan, Festpreisangebot
Das Ergebnis ist ein Linear-Board mit Epics, Akzeptanzkriterien und Terminen, auf die wir uns verbindlich festlegen. Alles, was in Produktion geht, lässt sich auf ein von Ihnen freigegebenes Item zurückführen. Wie wir Projekte danach aufsetzen, steht auf unserer Seite zur Mobile-App-Entwicklung.
Wenn Sie ein Mobile-Projekt starten und den genannten Zeitplan auf Plausibilität prüfen lassen möchten, erzählen Sie uns davon — wir senden Ihnen innerhalb von 48 Stunden eine kostenlose Zweitmeinung.