Eine App ist selten nur eine App. Sobald sie Kundendaten nutzt, Bestellungen aus einem Shop übernimmt, Termine mit einem ERP abgleicht oder sensible Gesundheitsdaten verarbeitet, wird sie Teil Ihrer Systemlandschaft. Genau deshalb ist die Frage „Wie lange dauert Appentwicklung?“ für mittelständische Unternehmen keine reine Kalenderfrage. Sie entscheidet darüber, wann Fachbereiche eingebunden werden müssen, welche Budgets realistisch sind und ob der Go-Live ohne Schweißperlen gelingt.
Die kurze, ehrliche Antwort lautet: Eine fokussierte App mit klar definiertem Funktionsumfang kann in drei bis sechs Monaten produktiv gehen. Für eine individuell entwickelte Unternehmens-, Kunden- oder Commerce-App mit Schnittstellen sind eher sechs bis zwölf Monate realistisch. Bei digitalen Gesundheitsanwendungen, komplexen Plattformen oder Vorhaben mit mehreren Altsystemen kann die Umsetzung zwölf Monate und länger dauern. Nicht die Anzahl der Bildschirme bestimmt dabei den Aufwand, sondern Prozesse, Daten und die Konsequenzen eines Fehlers.
Wie lange dauert Appentwicklung wirklich?
Wer nur eine Zahl erwartet, bekommt schnell eine falsche Sicherheit. Eine App zur Erfassung von Serviceaufträgen kann technisch überschaubar sein. Wenn sie aber offline funktionieren, Rollen und Rechte verwalten, Bilder hochladen und Daten mit ERP, CRM und Lagerbestand abgleichen soll, verändert sich die Größenordnung deutlich.
Für die zeitliche Einordnung helfen drei typische Projektklassen. Ein MVP mit einer klaren Kernfunktion, wenigen Nutzerrollen und einem vorhandenen Backend benötigt häufig drei bis sechs Monate. Es ist sinnvoll, wenn eine konkrete Annahme getestet oder ein bisheriger manueller Prozess digitalisiert werden soll.
Eine marktreife App für Kunden, Mitarbeitende oder Vertriebsteams liegt meist bei sechs bis zwölf Monaten. Dazu gehören ein belastbares UX/UI-Konzept, technische Architektur, Benutzerverwaltung, Qualitätssicherung, App-Store-Veröffentlichung, Monitoring und die Anbindung bestehender Systeme. Der Aufwand steigt, wenn Android und iOS nativ bedient werden sollen oder Prozesse nicht nur abgebildet, sondern neu geordnet werden müssen.
Bei einer DiGA oder einer Plattform mit regulatorischen Anforderungen sollten Unternehmen mit zwölf bis achtzehn Monaten oder mehr planen. Datenschutz, Informationssicherheit, klinische beziehungsweise fachliche Nachweise, Dokumentation und Anforderungen für eine BfArM-Listung sind keine Punkte, die man kurz vor dem Launch ergänzt. Sie beeinflussen Konzept, Architektur und Teststrategie von Beginn an.
Die Phasen, die den Zeitplan bestimmen
Ein verlässlicher Zeitplan entsteht nicht, indem man möglichst früh ein Launch-Datum festlegt. Er entsteht, wenn Entscheidungen und Abhängigkeiten sichtbar werden. In der Praxis gliedert sich die Entwicklung in mehrere Phasen, die teilweise überlappen können.
1. Ziele, Prozesse und Anforderungen klären
In den ersten zwei bis sechs Wochen wird aus der Idee ein belastbarer Auftrag. Welche Nutzergruppe hat welches Problem? Welcher Prozess soll schneller, sicherer oder transparenter werden? Welche Daten sind führend, und wo liegen sie heute? Diese Fragen verhindern, dass eine App am Ende nur eine schönere Oberfläche für Excel-Chaos und Doppelpflege wird.
Gerade bei gewachsenen Systemlandschaften lohnt der genaue Blick. Ein Vertriebsteam braucht vielleicht aktuelle Preise aus dem ERP, während der Onlineshop Produktdaten aus einem PIM erhält und Kundendaten im CRM liegen. Ohne eine klare Entscheidung zu Datenhoheit, Schnittstellen und Verantwortlichkeiten entstehen später Wartezeiten, Workarounds und unnötige Kosten.
2. UX/UI und technisches Konzept entwickeln
Für Design, Prototyp und Architektur sind meist vier bis acht Wochen sinnvoll. Das ist nicht nur eine kreative Vorstufe. Klickbare Prototypen machen Abläufe konkret, bevor teure Entwicklung beginnt. Fachbereiche erkennen dann früh, ob ein Freigabeprozess tatsächlich funktioniert oder ob wichtige Sonderfälle fehlen.
Parallel wird entschieden, ob eine native Entwicklung für iOS und Android oder eine Cross-Platform-App die bessere Wahl ist. Cross-Platform kann die Entwicklungszeit deutlich senken, wenn beide Plattformen weitgehend denselben Funktionsumfang bieten. Native Apps sind sinnvoll, wenn besonders hohe Anforderungen an Geräteschnittstellen, Performance oder plattformspezifische Funktionen bestehen. Es gibt keine pauschal bessere Technik - entscheidend sind Nutzen, Wartbarkeit und die nächsten Ausbaustufen.
3. Entwicklung in planbaren Etappen
Die eigentliche Umsetzung dauert häufig drei bis acht Monate. Gute Projekte arbeiten in kurzen Entwicklungszyklen: Funktionen werden entwickelt, getestet, mit den Fachbereichen abgestimmt und anschließend erweitert. Das schafft Transparenz. Gleichzeitig bleibt genug Raum, um aus realen Rückmeldungen zu lernen, ohne den Gesamtplan bei jeder neuen Idee neu zu schreiben.
Zeit benötigen insbesondere Backend-Logik, Schnittstellen und Rechtekonzepte. Eine Login-Maske ist schnell gebaut. Ein Single Sign-on mit bestehenden Unternehmenskonten, differenzierten Berechtigungen und nachvollziehbaren Zugriffsprotokollen nicht. Ähnlich verhält es sich mit einer Produktanzeige: Daten zu lesen ist einfacher als Bestände, Preise und Aufträge zuverlässig in beide Richtungen zu synchronisieren.
4. Test, Freigabe und Go-Live
Für Tests und Veröffentlichung sollten mindestens vier bis acht Wochen eingeplant werden. Neben technischen Tests gehören dazu Tests mit echten Nutzenden, Sicherheitsprüfungen, Datenschutzeinstellungen, Fehlerbehebung und die Vorbereitung der Stores. Bei B2B-Apps kommen oft Schulungen, Rollout-Wellen und interne Freigaben hinzu.
Der Store-Upload ist dabei nur ein kleiner Teil des Go-Lives. Entscheidend ist, ob Support, Monitoring, Backups und Verantwortlichkeiten stehen. Eine App, die am ersten Tag funktioniert, aber bei einer Schnittstellenänderung unbemerkt falsche Daten zeigt, ist kein erfolgreicher Launch.
Was Projekte häufig verlängert
Nicht jede Verlängerung ist ein Planungsfehler. Manche Erkenntnisse entstehen erst, wenn Prozesse und Daten gemeinsam betrachtet werden. Es gibt aber wiederkehrende Ursachen, die sich früh entschärfen lassen.
Erstens: unklare Entscheidungen auf Kundenseite. Wenn Fachbereich, IT, Datenschutz und Geschäftsführung unterschiedliche Ziele verfolgen, kann ein Sprint noch so schnell sein - Freigaben bleiben liegen. Ein benannter Product Owner mit Entscheidungsbefugnis hält das Projekt beweglich.
Zweitens: unterschätzte Altsysteme. Fehlende Schnittstellendokumentationen, unvollständige Daten oder individuelle Anpassungen im ERP zeigen sich häufig erst bei der Integration. Ein früher technischer Check ist günstiger als ein später Umbau unter Zeitdruck.
Drittens: wachsende Anforderungen. Neue Ideen sind normal und oft wertvoll. Sie sollten jedoch in ein priorisiertes Backlog wandern, statt ungeprüft in den nächsten Sprint zu rutschen. Sonst wird aus einem klaren MVP still und leise eine umfassende Plattform.
Viertens: Compliance wird zu spät einbezogen. Bei Gesundheitsdaten, Zahlungsdaten oder personenbezogenen Unternehmensdaten müssen Datenschutz, Sicherheitsanforderungen und Aufbewahrungsregeln Teil des Konzepts sein. Nachträgliche Korrekturen an Rollen, Verschlüsselung oder Datenflüssen kosten erheblich mehr Zeit als eine frühe Prüfung.
So wird die Appentwicklung planbar
Planbarkeit bedeutet nicht, jede Funktion auf den Tag genau vorherzusagen. Planbarkeit bedeutet, dass Aufwand, Risiken und Entscheidungen transparent sind. Dafür braucht es zu Beginn einen abgegrenzten ersten Release: Welche drei bis fünf Kernprozesse müssen zum Start funktionieren? Was kann bewusst in eine spätere Ausbaustufe?
Ebenso wichtig ist ein gemeinsamer Blick auf die Systemlandschaft. Eine Schnittstellenmatrix schafft Klarheit: Welches System liefert welche Daten, wer ist fachlich verantwortlich, wie oft werden Daten synchronisiert und was passiert bei Fehlern? Diese Arbeit wirkt zunächst gründlich, spart aber später viele Abstimmungsschleifen.
Bei Inter Medien Networks wird die technische Umsetzung deshalb nicht vom Geschäftsprozess getrennt betrachtet. Ein Shop, ein Odoo-ERP, ein CRM oder eine Lagerlösung sind keine Randbedingungen, sondern bestimmen mit, wie die App zuverlässig arbeiten kann. Das Ziel ist ein System statt zehn Insellösungen - und ein Projektplan, der auch nach dem Go-Live noch trägt.
Ein realistischer Zeitplan enthält zudem feste Zeitfenster für Rückmeldungen und Abnahmen. Wenn Designfreigaben, Testdaten oder Zugänge erst nach Wochen vorliegen, verschiebt sich nicht nur ein einzelnes Ticket. Oft wartet ein ganzes Entwicklungspaket. Kurze Wege und klar benannte Ansprechpartner sind deshalb ein echter Zeitfaktor.
Schneller starten, ohne an der falschen Stelle zu sparen
Wer Tempo braucht, sollte nicht automatisch Funktionen streichen. Häufig ist es sinnvoller, den ersten Release enger zu schneiden. Eine Service-App kann zunächst Aufträge anzeigen, Status erfassen und Fotos dokumentieren. Automatische Tourenplanung, Ersatzteilprognosen oder ein Kundenportal folgen, wenn die Grundlage im Alltag bewiesen ist.
Auch vorhandene Komponenten können Zeit sparen: etablierte Authentifizierung, klar dokumentierte APIs, ein bestehendes Designsystem oder eine Cross-Platform-Basis. Sparen sollte man dagegen nicht bei Architektur, Tests und Betrieb. Dort entstehen die Kosten, die nach einem hektischen Go-Live besonders unangenehm werden.
Der beste nächste Schritt ist kein vorschnelles Versprechen von „in acht Wochen fertig“. Legen Sie den konkreten Prozess auf den Tisch, prüfen Sie Daten, Abhängigkeiten und Verantwortlichkeiten - dann wird aus einer groben App-Idee ein Vorhaben, das verlässlich starten und langfristig funktionieren kann.