Wie lange dauert eine App-Entwicklung?

Direkt nach dem Preis kommt im Erstgespräch fast immer diese Frage: „Und wie lange dauert das Ganze?“ Meistens steckt ein Termin dahinter – eine Messe, ein Saisonstart, ein Altsystem, das abgeschaltet wird. Deshalb hier die ehrliche Version: unsere Spannen, die einzelnen Phasen und – der wichtigste Teil – was Projekte in der Praxis wirklich verzögert. Vorweg: Nach unserer Erfahrung liegt die häufigste Ursache nicht in der Technik.

Die kurze Antwort

• Starter-App: in der Regel 4–6 Wochen – ein fest umrissenes Paket mit einem klaren Kernnutzen, iOS und Android aus einer Codebasis.
• Fokussiertes MVP: 6–8 Wochen – eine Plattform, klein geschnittener Funktionsumfang.
• Typisches App-Projekt: 10–16 Wochen – beide Plattformen, eigenes Design, Nutzerkonten, Cloud-Backend.
• Komplexe Produkte: deutlich länger. Sobald ein eigenes Backend, mehrere Schnittstellen zu Fremdsystemen oder Bezahlfunktionen dazukommen, reden wir über mehrere Monate statt Wochen.

Diese Zeiträume sind Erfahrungswerte, keine Zusage: Sie gelten für ein Projekt, das mit geklärtem Umfang startet und in dem Freigaben zügig kommen.

Wichtig zur Einordnung: Die Dauer hängt am Aufwand, nicht am Preisschild. Mehr Umfang bedeutet mehr Kalenderzeit – umgekehrt lässt sich eine Woche aber nicht durch Budget wegkaufen, denn zusätzliche Leute in ein laufendes Projekt zu holen kostet zuerst Einarbeitungszeit. Nach unten liegt die Grenze bei etwa sechs Wochen, auch bei kleinem Umfang – genau dafür gibt es die Starter-App zum Festpreis von 9.900 €. Wie sich Umfang in Geld übersetzt, steht im Artikel „Was kostet eine App? Ehrliche Zahlen“; der App-Kosten-Rechner zeigt dir zu deiner Konfiguration direkt Preisspanne und Umsetzungsdauer. Alle Preise netto zzgl. Umsatzsteuer – unser Angebot richtet sich an Unternehmen, Selbstständige und Organisationen.

Die Phasen – und was sie realistisch dauern

Die folgenden Angaben beziehen sich auf ein typisches Projekt im Bereich 10–16 Wochen. Bei der Starter-App ist alles deutlich kompakter, weil der Umfang von Anfang an feststeht.

Konzept und UX (etwa 1–2 Wochen). Kernnutzen schärfen, Abläufe festlegen, Wireframes, Funktionsschnitt für Version 1. Der Block wirkt verzichtbar und ist der wertvollste im ganzen Plan: Änderungen kosten hier Minuten, an fertigem Code Tage.

Design (etwa 1–3 Wochen). Designsystem, finale Screens, klickbarer Prototyp. Läuft in der Regel teilweise parallel zur beginnenden Entwicklung – die ersten Screens gehen in die Umsetzung, während die späteren noch entstehen.

Entwicklung in Sprints (der größte Block). Wir arbeiten in Abschnitten von ein bis zwei Wochen, an deren Ende etwas Lauffähiges steht, das du selbst auf dem Gerät ausprobieren kannst. Du siehst früh, wohin es läuft, und Kurskorrekturen sind dann noch günstig. Dass beide Plattformen aus einer Codebasis entstehen, hilft auch hier – Cross-Platform-Entwicklung spart beim Plattform-Anteil der Entwicklung bis zu 40 %, aufs Gesamtprojekt gerechnet typischerweise 10–15 %.

Test auf echten Geräten (laufend, plus Endphase). Simulatoren zeigen nicht alles: Kamera, Push, Offline-Verhalten, ältere Geräte, kleine Displays, langsame Verbindungen. Getestet wird sprintbegleitend, am Ende noch einmal konzentriert über alle Abläufe.

Beta über TestFlight und Play Console (etwa 1–2 Wochen). Die App geht an einen kleinen Kreis echter Nutzer – Team, Pilotkunden, Freundeskreis. Hier tauchen die Dinge auf, die intern niemand gefunden hätte. Streiche diese Phase nicht im Zeitdruck: Ein Bug, der in der Beta auffällt, kostet Stunden; derselbe Bug nach dem Launch kostet Bewertungen.

Store-Einreichung (Puffer einplanen). Store-Eintrag, Screenshots, Beschreibung, Datenschutzangaben, dann die Prüfung bei Apple und Google. Wie lange die dauert, entscheiden Apple und Google – nicht wir und nicht du. Apple nennt als Durchschnitt, dass 90 % der Einreichungen in weniger als 24 Stunden geprüft werden; Google weist darauf hin, dass die Prüfung bei bestimmten Entwicklerkonten bis zu sieben Tage und in Ausnahmefällen länger dauern kann (Stand 2026, nach den offiziellen Angaben von Apple und Google). Das sind Angaben der Anbieter, keine Zusage für dein Projekt. Rechne zusätzlich mit einer Rückfrage oder einer nicht bestandenen Prüfung – dann folgt eine weitere Runde. Deshalb gilt: Der Launchtermin liegt nie auf dem Tag der Einreichung.

Was Projekte wirklich verzögert

Wenn ein Zeitplan reißt, liegt es nach unserer Erfahrung selten am Code. Die häufigsten Gründe:

1. Unklarer Umfang. Was beim Start offen bleibt, wird mitten im Projekt geklärt – und jede Klärung, die zu einer Änderung führt, kostet doppelt: einmal die neue Umsetzung, einmal das schon Gebaute. Ein während der Entwicklung nachgeschobenes Feature verschiebt den Termin fast immer weiter, als es der reine Aufwand vermuten lässt.

2. Langsame Freigaben und Feedback-Schleifen. Ein Design kann zehn Tage auf eine Rückmeldung warten, wenn drei Personen mitentscheiden und eine davon im Urlaub ist. Solche Wartezeiten summieren sich unauffällig, aber gnadenlos: Vier Freigaben mit je einer Woche Verzug ergeben rechnerisch einen Monat.

3. Fehlende Inhalte. Texte, Bilder, Logos, Rechtstexte, Produktdaten, Zugänge zu bestehenden Systemen, Entwicklerkonten in App Store und Google Play. Eine App ohne Inhalte lässt sich nicht abschließen, egal wie fertig der Code ist.

4. Schnittstellen zu Fremdsystemen. Sobald die App an Warenwirtschaft, CRM, Kassensystem oder Kalender andockt, hängt der Zeitplan an Dritten: an Zugangsdaten, an einem Testsystem, an einer Dokumentation, an einem Ansprechpartner beim anderen Anbieter, der eigene Prioritäten und eigene Zeitpläne hat. Das ist niemandes Schuld, aber ein Risiko, das früh auf den Tisch gehört.

5. Die Store-Prüfung. Siehe oben: nicht von uns steuerbar, deshalb immer mit Puffer.

So sparst du selbst Zeit

• Einen Entscheider benennen. Eine Person, die für dich verbindlich Ja sagen darf – idealerweise mit Vertretung für Urlaub und Krankheit.
• Feedback-Fenster verabreden. Zum Beispiel: Rückmeldungen innerhalb von zwei Werktagen, gesammelt an einer Stelle statt in fünf Einzelmails.
• Inhalte früh sammeln. Beginne parallel zum Design, nicht erst, wenn danach gefragt wird.
• Entwicklerkonten früh beantragen. Für Organisationen setzen beide Stores eine D-U-N-S-Nummer von Dun & Bradstreet voraus. Apple nennt dafür bis zu fünf Werktage, Google bis zu 30 Tage (Stand 2026, nach den offiziellen Angaben von Apple und Google). Plane mit der längeren Zahl – das ist der Posten, der Zeitpläne am unauffälligsten frisst.
• Version 1 klein halten. Der wirksamste Beschleuniger überhaupt – nachzulesen in „Das MVP-Prinzip: Weniger App, mehr Erfolg“.
• Vorbereitet ins Erstgespräch gehen. Kernnutzen, Abläufe, Schnittstellen, Entscheider: Die sieben Punkte in „So bereitest du dein App-Projekt vor“ verkürzen die Konzeptphase spürbar.
• Puffer auf harte Termine legen. Setze den internen Zieltermin einen Monat vor den echten – nicht auf die Woche davor.

Fazit

4–6 Wochen für eine Starter-App, 10–16 Wochen für ein typisches Projekt, deutlich mehr für komplexe Produkte: Das sind belastbare Größenordnungen, solange der Umfang steht und Freigaben zügig kommen. Die Kalenderzeit entscheidet sich weniger in der Entwicklung als in den Wartezeiten drumherum – und die kannst du zu einem guten Teil selbst kurz halten.

Du hast einen Termin, auf den es hinauslaufen soll? Erzähl uns im kostenlosen Erstgespräch davon. Wir antworten werktags innerhalb von 24 Stunden und sagen dir ehrlich, ob dein Zeitfenster realistisch ist – auch dann, wenn die Antwort „so nicht, aber anders“ lautet.