Es ist meistens die zweite Frage. Direkt nach der Budgetfrage.
Du hast eine Idee. Du hast angefangen, über Funktionen nachzudenken. Und irgendwann brauchst du eine Antwort: Wie lange dauert es eigentlich, eine mobile App zu entwickeln?
Das Internet gibt dir Antworten zwischen sechs Wochen und zwei Jahren. Beides ist technisch gesehen korrekt. Beides ist wenig hilfreich.
Und im Jahr 2026 ist die Frage noch komplizierter geworden. Viele Gründer kommen mit etwas, das bereits gebaut ist — einem Prototypen, der über ein Wochenende mit KI-Tools zusammengestellt wurde. Manchmal ist er solide. Manchmal sieht er fertig aus, hat aber Lücken, die erst sichtbar werden, wenn echte Nutzer ihn verwenden.
So oder so: Der Ausgangspunkt hat sich verändert. Und das verändert auch den Zeitplan.
Warum jede Antwort, die du online findest, anders ist
Zwei Apps können fast identisch klingen und dennoch völlig unterschiedlich viel Arbeit erfordern.
Eine einfache App mit ein paar Screens und ohne Backend ist ein anderes Projekt als eine mit Nutzerkonten, Zahlungen, Drittanbieter-Integrationen und Inhalten, die verwaltet werden müssen. Beide könnten als „eine mobile App für mein Unternehmen" beschrieben werden.
Der Zeitplan für die eine könnte 8 Wochen betragen. Die andere könnte sechs Monate dauern.
Die wichtigsten Variablen sind Scope, Komplexität, Plattformwahl — und mehr als alles andere: wie klar das Projekt definiert ist, bevor die Entwicklung beginnt. Genau daran scheitern die meisten Zeitschätzungen.
Drei Projekte. Drei sehr unterschiedliche Zeitpläne.
Am besten lässt sich die Frage mit echten Beispielen beantworten.
Beredt - 8 wochen
Beredt ist eine Notfallvorsorge-App für norwegische Familien. Ein persönlicher Assistent, der dir hilft, Vorräte zu organisieren, Sicherheitspläne zu erstellen und auf unerwartete Situationen vorbereitet zu bleiben.
Der Kunde kam Ende Oktober zu uns. Ein anderes Entwicklungsteam hatte das Projekt begonnen, aber kam nicht weiter. Das Ziel war klar: Launch vor Weihnachten.
Wir haben die bestehende Codebasis überprüft, festgestellt, was fehlte, die Kernfunktionen fertiggestellt, die Benutzeroberfläche neu gestaltet und auf iOS und Android gelauncht.
Acht Wochen. Sechs Personen. Sechzig Screens.
Das ist schnell. Es war möglich, weil der Scope definiert und die Entscheidungen bereits getroffen waren. Das Team konnte entwickeln, ohne innehalten zu müssen, um Dinge zu klären.
Diese acht Wochen deckten den Launch bis zum MVP ab. Was folgte, waren weitere sechs Monate mit Verbesserungen, neuen Funktionen und Anpassungen auf Basis echten Nutzerfeedbacks. Der erste Zeitplan bringt dich live. Das Produkt bewegt sich danach weiter.
Mehr über die Beredt app erfahren.
Lengi - 6 monate
Lengi ist eine Sprachlern-App, die KI nutzt, um echte Gespräche mit Muttersprachlern zu simulieren. Du übst das Sprechen, erhältst Echtzeit-Feedback auf deine Nachrichten und verfolgst deinen Fortschritt durch Streaks und Statistiken.
Wir haben alles von Anfang an übernommen: Marktforschung, Wireframing, Prototyping, Nutzertests, KI-Integration, Backend-Architektur und Launch auf beiden Plattformen.
Sechs Monate. Ein kleines Team. Nach dem Launch: 3.000 Downloads, 12 bezahlte Abonnements in den ersten Wochen.
Der Zeitplan spiegelt den Scope wider. Echtzeit-KI-Feedback, mehrere Nutzerflüsse, ein Abo-Modell, Genauigkeitsprüfung über verschiedene Sprachen hinweg. Diese Dinge brauchen Zeit, um gut entwickelt zu werden. Wer das überstürzt, merkt es später.
Mehr über die Lengi app erfahren.
Pelican - 24 wochen
Pelican ist eine Finanzbildungs-App, die Nutzern hilft, Geld, Sparen und Investitionen zu verstehen — mit integrierter KI-gestützter Begleitung.
Wir haben sie zuerst als Web-App entwickelt und dann auf Mobile umgestellt. Das MVP umfasste ein personalisiertes Finanz-Dashboard, einen Wissens-Hub mit Artikeln und Podcasts sowie die Grundlagen für ein Abo-Modell.
Sechs Personen. Dreißig Screens. Vierundzwanzig Wochen für die erste Phase. Das Produkt wächst weiter, mit neuen Funktionen auf Basis echter Nutzerdaten.
Mehr über die Pelican app erfahren.
Was die Zahlen zeigen
Three projects. 8 weeks, 6 months, 24 weeks.
Drei Projekte. 8 Wochen, 6 Monate, 24 Wochen.
Beredt war schnell, weil der Scope fokussiert und die Deadline fest war. Es gab keinen Spielraum für „Was wäre, wenn wir noch... hinzufügen?" mitten im Build. Die Rahmenbedingungen haben geholfen.
Lengi hat länger gedauert, weil es von Grund auf mit komplexen KI-Funktionen entwickelt wurde, die von Anfang an gut funktionieren mussten. Der Zeitplan war durch die Komplexität gerechtfertigt.
Pelican liegt in der Mitte. Ein Produkt mit echter Tiefe, in Phasen entwickelt, beginnend mit Web, um das frühe Risiko zu reduzieren.
Verschiedene Produkte, verschiedene Zeitpläne. Alle waren angemessen für das, was sie waren.
Was sie gemeinsam haben: Keines wurde von der Dauer überrascht. Weil der Scope klar war, bevor der erste Sprint begann.
Wo die Zeit wirklich hingeht
Es ist selten die Entwicklung selbst
Scope, der immer weiter wächst. Mitten im Sprint wird eine neue Funktion hinzugefügt. Eine Priorität ändert sich. Jemand ändert seine Meinung zu einem Kernablauf. Jede Änderung mitten im Build kostet mehr Zeit als dieselbe Änderung vor Beginn der Entwicklung gekostet hätte.
Anforderungen, die nicht vorab definiert wurden. Wenn das Team stoppen und auf eine Entscheidung warten muss, die in Woche eins hätte getroffen werden sollen, verlangsamt sich die Arbeit. Manchmal stoppt sie vollständig.
KI-generierter Code, der fertig aussah, es aber nicht war. Ein Gründer entwickelt einen Prototypen mit KI-Tools, übergibt ihn an ein Entwicklungsteam — und das Team stellt fest, dass zentrale Abläufe, Registrierung, Zahlungen und Grenzfälle nie richtig fertiggestellt wurden. Der Code läuft, ist aber nicht produktionsreif. Bevor man weiterbaut, muss jemand zurückgehen. Das ist ungeplante Zeit, die niemand einkalkuliert hat.
Integrationen, die einfach aussahen. Die Anbindung an einen Zahlungsanbieter, ein CRM oder eine externe Datenquelle dauert fast immer länger als die Planungsschätzung. APIs sind uneinheitlich dokumentiert. Grenzfälle häufen sich.
Feedback-Zyklen, die sich ziehen. Eine zweiwöchige Verzögerung bei einem Design-Review, dreimal wiederholt, bedeutet sechs Wochen weniger auf deinem Zeitplan. Das ist eine der häufigsten und am besten vermeidbaren Ursachen für Verzögerungen.
Der eine Schritt, der alles andere vorhersagt
Projekte, die mit einer klaren Spezifikation starten, werden schneller fertig.
Nicht etwas schneller. Durchgehend, messbar schneller — mit weniger Überraschungen und weniger Kosten, die nicht im ursprünglichen Plan standen.
Wenn du eine mobile app entwickelst, ist diese Klarheit noch wichtiger — Mobile-Projekte tragen mehr Variablen als die meisten anderen.
Eine klare Spezifikation bedeutet: eine vereinbarte Feature-Liste für Version eins, dokumentierte User Flows, definierte technische Rahmenbedingungen und ein gemeinsames Verständnis davon, wie Erfolg beim Launch aussieht. Nicht in sechs Monaten. Am ersten Tag.
Genau dafür ist ein Discovery Workshop da.
Bevor der Build beginnt, erarbeiten wir das Produkt gemeinsam. Was gebaut wird, in welcher Reihenfolge und was auf Version zwei wartet. Welche Plattform sinnvoll ist. Welche Integrationen am ersten Tag gebraucht werden und welche später. Wo die Risiken liegen. Du gehst mit einem Dokument heraus — kein Pitch Deck, sondern eine echte Spezifikation, mit der ein Entwicklungsteam arbeiten kann.
Das ist der Schritt, den die meisten Projekte überspringen. Und der Schritt, den die meisten zu späten und zu teuren Projekte gerne nicht übersprungen hätten.
Willst du wissen, wie lange deine App wirklich dauert? Fang hier an.
