Der echte Zeitplan der App-Entwicklung: von der Idee bis zum Launch

Fragen Sie zehn Agenturen, wie lange die Entwicklung einer App dauert, bekommen Sie zehn selbstbewusste Antworten — und keine davon stimmt. Die ehrliche Antwort lautet: Am ersten Tag kann es Ihnen niemand genau sagen. Aber jeder, der wirklich schon Software ausgeliefert hat, kann Ihnen den groben Verlauf beschreiben: welche Phasen es gibt, welche davon still und leise den Kalender auffressen und an welchen Stellen Ihre eigenen Entscheidungen das Tempo erhöhen oder zum Stillstand bringen. Genau dieser Verlauf, klar aufgeschrieben.

Ich habe viele Unternehmerinnen und Unternehmer in ein App-Projekt gehen sehen, die einen sauberen, geradlinigen Marsch von der Skizze bis zum App Store erwarteten. Was sie stattdessen bekommen, fühlt sich eher wie eine Folge von Plateaus und plötzlichen Sprüngen an. Wochen, in denen scheinbar nichts passiert, und dann ein Tag, an dem auf einmal alles zusammengreift. Nichts davon ist ein Zeichen, dass etwas falsch läuft. So entsteht Software nun einmal — und sobald Sie die Phasen benennen können, hört der ganze Prozess auf, eine Blackbox zu sein, in die Sie zahlen und das Beste hoffen.

Setzen wir also realistische Erwartungen. Für eine fokussierte erste Version einer Business-App — keine ausufernde Plattform, sondern eine erste Version, die eine Aufgabe gut erledigt — bewegen Sie sich meist im Bereich von drei bis fünf Monaten, vom ernsthaften Start bis zum echten Launch. Wo Sie innerhalb dieser Spanne landen, hängt weniger von der Technologie ab als davon, wie klar Sie sind, wie schnell Sie entscheiden und wie viel Sie vor dem Launch unbedingt noch hineinpacken wollen. Gehen wir es durch.

Warum die Schätzung, die man Ihnen genannt hat, vermutlich falsch ist

Die Sechs-Wochen-Angabe ist nicht direkt gelogen — sie ist die Zeit, die der Teil braucht, den sich jeder vorstellen kann. Die Bildschirme. Die Buttons. Das, was man vorführen kann. Was diese Zahl stillschweigend ausblendet, ist alles rund um die sichtbare App: die Entscheidungen, die Daten, die Anbindung an Werkzeuge, die Sie bereits nutzen, das Testen, die Prüfung im App Store, die unvermeidliche Runde „kann sie eigentlich auch das?“

Eine hilfreiche Sichtweise: Das Programmieren ist selten der Engpass. Der Engpass ist die Klarheit. Jede Stunde, die Ihr Entwickler auf eine Entscheidung wartet — welcher Zahlungsanbieter, was passiert bei einer Stornierung, wer darf was sehen — ist eine Stunde, um die der Zeitplan rutscht. Die Projekte, die schnell fertig werden, sind nicht die mit den besten Entwicklern. Es sind die, bei denen die Inhaberin Fragen in einem Tag statt in zwei Wochen beantwortet.

Achten Sie also beim Lesen der folgenden Phasen auf die Momente, in denen der Ball in Ihrem Feld liegt. Das sind die Punkte, an denen ein Projekt entweder sein Tempo hält oder still für drei Wochen ins Stocken gerät, weil eine E-Mail unbeantwortet blieb. Der Zeitplan ist eine geteilte Verantwortung, und die Hälfte des Kunden ist die, die am häufigsten unterschätzt wird.

Phase 1: Klärung und Scoping (1–3 Wochen)

Bevor irgendjemand einen einzigen Bildschirm gestaltet, gibt es eine Phase, die nicht nach Fortschritt aussieht, aber alles bestimmt: herauszufinden, was Sie tatsächlich bauen und, wichtiger noch, was nicht. Hier wird aus einer vagen Idee („eine App für meine Kunden“) eine konkrete, abschließbare Liste von Funktionen für Version eins.

Gut gemacht besteht diese Klärungsphase vor allem aus Gesprächen und unbequemen Fragen. Wer nutzt das, und auf welchem Gerät? Was ist die eine Sache, die brillant funktionieren muss? Was kann bis Version zwei warten? Ein guter Partner widerspricht hier, und das sollen Sie sich wünschen — jede Funktion, die Sie jetzt streichen, sind Wochen, die Sie zurückbekommen. Das Ergebnis ist meist ein kurzes schriftliches Scope und ein grober Wireframe, etwas, das Sie in der Hand halten und sagen können: ja, genau das ist es.

Phase 2: Design und Prototyp (2–4 Wochen)

Jetzt wird die App zu etwas, das Sie sehen und anklicken können, bevor eine einzige Zeile echter Code Sie auf irgendetwas festlegt. Designer machen aus dem Wireframe echte Bildschirme — die Farben, den Ablauf, das tatsächliche Gefühl der Nutzung — meist als interaktiven Prototyp, durch den Sie sich auf dem eigenen Smartphone tippen können.

Diese Phase ist Gold wert, aus einem Grund: ein Design zu ändern ist billig, gebaute Software zu ändern ist teuer. Einen Button im Prototyp zu verschieben dauert fünf Minuten. Ihn zu verschieben, nachdem die Funktion programmiert, getestet und mit Ihren Daten verdrahtet ist, kann einen Tag kosten. Das ist also der Moment, wählerisch zu sein, das Ganze einigen echten Kunden oder Mitarbeitenden zu zeigen und die „oh, das versteht niemand“-Probleme aufzuspüren, solange sie sich noch schmerzlos beheben lassen.

Der häufigste Grund, warum diese Phase überlang wird, ist nicht der Designer — es ist Unentschlossenheit auf Ihrer Seite. Endlose Runden kleiner Anpassungen oder drei Personen mit Vetorecht, die sich nie einig werden. Legen Sie früh fest, wer freigibt, geben Sie Feedback gebündelt statt tröpfchenweise, und diese Phase bleibt straff.

Phase 3: Build (6–12 Wochen)

Das ist der Teil, den sich jeder vorstellt, wenn er an „eine App machen“ denkt, und es ist die längste einzelne Strecke — aber selten die unberechenbarste, wenn die ersten beiden Phasen ordentlich erledigt wurden. Entwickler bauen die App in Häppchen, meist in kurzen Zyklen, in denen Sie alle ein bis zwei Wochen funktionierende Teile sehen, statt drei Monate zu verschwinden und mit einem fertigen Produkt wieder aufzutauchen.

Dieser Rhythmus ist wichtig. Sie wollen früh auf echte, laufende Software reagieren, nicht auf einen Statusbericht. Wenn Sie den Buchungsablauf in Woche vier wirklich nutzen können, fallen Ihnen Dinge auf, die keine Spezifikation hätte erfassen können — und sie in Woche vier zu beheben ist weit günstiger als in Woche zehn. Ein guter Build-Prozess macht die App für Sie laufend sichtbar, nicht erst am Ende.

Was den Build still in die Länge zieht

Zwei Dinge blähen einen Build mehr auf als alles andere. Das Erste sind Integrationen — jedes externe System, mit dem die App sprechen muss (Ihr Zahlungsanbieter, Ihr bestehendes Buchungstool, Ihre Buchhaltungssoftware, ein Lieferdienst), bedeutet zusätzliche Arbeit, und jedes kann eigene Überraschungen bereithalten. Das Zweite ist Scope Creep: das stetige Tröpfeln kleiner Ergänzungen, die einzeln winzig wirken, den Launch zusammen aber um einen Monat nach hinten schieben. Beides ist beherrschbar, aber nur, wenn Sie es kommen sehen.

• Jede externe Integration kostet Tage, manchmal Wochen — planen Sie sie ausdrücklich ein, nehmen Sie sie nicht als gratis an.
• „Nur noch eine kleine Funktion“ ist die mit Abstand häufigste Ursache für einen verpassten Launch-Termin.
• Echte Daten sind unübersichtlicher als Testdaten; planen Sie Zeit für die Sonderfälle ein, die Ihre Tabelle still toleriert hat.
• Benutzerkonten, Zahlungen und Benachrichtigungen sind trügerisch tief — sie kosten immer mehr, als sie aussehen.
• Freigaben und Inhalte, die Sie dem Team schulden (Logos, Texte, Rechtstexte), können einen Build genauso sicher aufhalten wie ein Bug.

Phase 4: Testen und Korrigieren (2–4 Wochen)

Hier ist eine Phase, deren Existenz die Leute vergessen — und über die sie sich dann ärgern, wenn sie auftaucht. Sobald die App gebaut ist, muss sie auf Herz und Nieren geprüft werden: auf verschiedenen Smartphones, mit schlechtem Internet, von Menschen, die sie nicht gebaut haben und die Dinge tun werden, mit denen niemand gerechnet hat. Testen ist keine Formsache. Es ist der Unterschied zwischen einer App, der Ihre Kunden vertrauen, und einer, die sie nach dem ersten Absturz wieder löschen.

Rechnen Sie damit, dass hier eine Liste an Fehlern und rauen Kanten auftaucht. Das ist kein Zeichen, dass der Build schlecht lief; es ist der ganze Sinn dieser Phase. Manche sind schnelle Korrekturen, manche legen eine Entscheidung offen, die noch einmal überdacht werden muss. Die Teams, die das gut handhaben, behandeln es als normalen, eingeplanten Teil der Arbeit — nicht als Notfall und nicht als etwas, das man überspringt, weil der Launch drängt. Das Testen zu überspringen spart keine Zeit. Es verschiebt die Fehler nur von Ihrem Testgerät auf die Smartphones Ihrer Kunden, wo sie zehnmal so viel kosten.

Phase 5: Launch und das Warten im App Store (1–2 Wochen, plus Prüfung)

Der Launch ist weniger ein einzelner Moment als ein behutsamer Roll-out. Bei einer Web-App steuern Sie das Timing vollständig — Sie legen den Schalter um, wenn Sie bereit sind. Geht es in Apples App Store oder zu Google Play, geben Sie einen Teil des Zeitplans an sie ab: Ihr Prüfprozess kann von einem Tag bis über eine Woche dauern, und gelegentlich kommt die App mit etwas zu Behebendem zurück. Das sollten Sie vorab wissen, damit es einen Launch-Termin, den Sie Kunden versprochen haben, nicht aus dem Hinterhalt trifft.

Der kluge Weg zu launchen ist keine Knallbumm-Enthüllung vor Ihrem gesamten Kundenstamm. Es ist erst eine leise Veröffentlichung an eine kleine Gruppe — eine Handvoll wohlgesonnener Kunden oder Ihre eigenen Mitarbeitenden — damit Sie die Probleme der echten Welt fangen, bevor sie alle sehen. Dann öffnen Sie die Tür weiter. Ein Launch, der sich langweilig ereignislos anfühlt, ist ein Launch, der gut lief.

1. 1
   Soft-Launch an eine kleine Gruppe

   Veröffentlichen Sie zuerst an eine Handvoll wohlgesonnener Nutzer oder Mitarbeitender. Echte Nutzung findet, was das Testen verpasst hat — bei minimalem Risiko.
2. 2
   Früh einreichen, wenn Sie in die App Stores gehen

   Apple und Google bestimmen die Prüfuhr, nicht Sie. Reichen Sie mit Puffer ein, damit eine langsame Prüfung oder eine Ablehnung Ihren versprochenen Termin nicht sprengt.
3. 3
   Die erste Woche genau beobachten

   Halten Sie jemanden bereit, der schnell reagiert. Die erste Woche bringt die realen Sonderfälle ans Licht, die keine Testumgebung je erzeugt.
4. 4
   Die Arbeit für den Tag danach vor dem Launch einplanen

   Eine App ist beim Launch nie „fertig“. Klären Sie vorab, wer sich um die unvermeidlichen kleinen Korrekturen und die erste Feedback-Runde kümmert.

Den gesamten Zeitplan zusammensetzen

Hintereinandergelegt ergeben diese Phasen ein realistisches Bild. Keine davon ist exotisch; was die Leute aus dem Tritt bringt, ist zu vergessen, dass die unglamourösen — Klärung, Testen, das Warten im App Store — echte Zeit im Kalender sind, keine Rundungsfehler. So verteilt sich eine fokussierte erste Version ungefähr über die Monate.

Zählen Sie es zusammen, und Sie sehen, warum drei bis fünf Monate die ehrliche Spanne für eine echte erste Version sind und warum die Leute, die sechs Wochen versprechen, still und leise neu definieren, was „eine App“ bedeutet. Das ist kein Pessimismus — es ist der Unterschied zwischen einem Termin, den Sie wirklich halten, und einem, für den Sie sich das ganze Projekt über entschuldigen.

Wie Sie es wirklich beschleunigen (und wie nicht)

Sie können schneller werden, aber die echten Hebel sind nicht die, nach denen die Leute greifen. Mehr Entwickler auf ein halb definiertes Projekt zu werfen macht es meist langsamer, nicht schneller. Die ehrlichen Beschleuniger sind unglamourös: entscheiden Sie, was weggelassen wird, beantworten Sie Fragen schnell und widerstehen Sie dem Drang, mitten im Build Dinge hinzuzufügen.

Der mit Abstand größte ist ein gnadenloser Scope. Je kleiner und klarer Ihre erste Version, desto eher launcht sie — und eine gelaunchte App, die ihr Geld verdient, lehrt Sie in zwei Wochen mehr als weitere zwei Monate Planung es je könnten. Hinzufügen können Sie immer. Die Monate, die Sie damit verbringen, Funktionen zu bauen, die am Ende niemand wollte, bekommen Sie nicht zurück.

Es gibt eine verwandte Wahrheit, die man laut aussprechen sollte: Nicht alles muss überhaupt eine individuelle App sein. Manchmal ist das eigentliche Problem ein Stück manueller Arbeit, das eine Automatisierung still erledigen könnte, ganz ohne App. Ein guter Partner sagt Ihnen, wenn das der Fall ist, statt Ihnen den größeren Build zu verkaufen — denn die günstigste App ist die, die Sie gar nicht bauen mussten.

Häufige Fragen