"Und wie lange dauert das?" Die Frage kommt fast immer direkt nach dem Preis, und sie klingt so einfach, dass eine Zahl die einzig höfliche Antwort scheint. Acht Wochen. Ende Oktober. Wer dir das ohne Nachfrage nennt, hat entweder nicht zugehört oder sagt dir, was du hören willst. Ein Datum ist ein Versprechen. Eine Schätzung ist etwas anderes, und die ehrliche Version ist wertvoller.
Software zu bauen ist nicht wie eine Mauer zu setzen. Bei der Mauer weisst du, wie viele Steine, wie viel Mörtel, wie schnell einer mauert. Bei Software entdeckst du die Hälfte der Arbeit erst, während du sie machst. Das ist keine Ausrede, das ist die Natur der Sache. Und je ehrlicher wir am Anfang darüber reden, desto verlässlicher wird der Termin am Ende.
Warum niemand ein einzelnes Datum kennt
Am Anfang eines Projekts weisst du am wenigsten. Du hast eine Idee, ein paar Skizzen, eine Vorstellung davon, was rauskommen soll. Was du noch nicht weisst: an welcher Stelle die Fremdschnittstelle zickt, welche Anforderung sich im dritten Gespräch verdreifacht, welcher Sonderfall in deinen Daten steckt, den bisher niemand erwähnt hat.
Deshalb schätzen wir in Spannen, nicht in Punkten. "Sechs bis acht Wochen bis zur ersten nutzbaren Version" ist keine Ausflucht, das ist die ehrliche Form. Die Spanne wird enger, je weiter wir sind. Nach zwei Wochen echter Arbeit wissen wir mehr über dein Projekt als nach zwei Wochen Planung auf Papier, und genau dann wird aus der Spanne ein Termin, auf den du dich verlassen kannst.
Ein früher Termin, der stimmt, ist unmöglich. Ein früher Termin, der gut klingt, ist einfach. Wir liefern lieber die Spanne, die hält, als das Datum, das du gern hättest.
Woran die Zeit wirklich hängt
Wenn Projekte länger dauern als gedacht, liegt es selten am Tippen von Code. Es liegt fast immer an einer Handvoll Dinge, die man am Anfang unterschätzt.
Der Umfang, der wächst. Aus "ein Buchungsformular" wird "ein Buchungsformular, aber mit Gutscheinen, Warteliste und Anbindung an den Kalender". Jeder dieser Zusätze ist berechtigt, und jeder kostet Zeit. Wir halten den ersten Umfang deshalb bewusst klein. Warum das kein Geiz ist, sondern Methode, steht in Warum wir manchmal Nein sagen.
Die Abhängigkeiten von aussen. Sobald deine Software mit etwas anderem reden muss, mit der Buchhaltung, dem Zahlungsanbieter, einem Altsystem, hängst du an einer fremden Uhr. Ein Testzugang beim anderen Anbieter dauert manchmal länger als die Anbindung selbst. Mehr dazu in Wenn Systeme miteinander reden müssen.
Die Unbekannten. Manche Teile eines Projekts hat so noch niemand gebaut. Da ist Ausprobieren dabei, und Ausprobieren lässt sich nicht auf den Tag genau planen. Ehrlich ist, das offen als das zu benennen, was es ist: Forschung, nicht Fliessband.
Die letzten zehn Prozent
Es gibt einen Punkt in fast jedem Projekt, an dem alles fertig aussieht. Die Software läuft, die Klicks funktionieren, die Demo überzeugt. Gefühlt sind es neunzig Prozent. Und dann dauert der Rest noch einmal so lange wie alles davor.
Das ist kein Missmanagement, das ist die Regel. Die letzten zehn Prozent sind die unsichtbaren: der Fall, wenn zwei Leute gleichzeitig dasselbe buchen. Die kaputte E-Mail-Adresse in echten Daten. Der Moment, in dem das Netz wegbricht. Das sieht in der Demo niemand, und genau daran merkt man später, ob die Software taugt.

Neunzig Prozent sichtbar, zehn Prozent entscheidend
Die erste Hälfte der Strecke fliesst schnell, weil die Fälle einfach sind. Die letzte kurze Strecke zieht sich, weil dort die Ausnahmen sitzen: die Sonderfälle, die echten Daten, der Moment, in dem etwas schiefgeht. Wer den Termin auf das "sieht fertig aus" legt, plant die Hälfte der Arbeit weg. Wir rechnen die letzte Strecke von Anfang an mit ein.
Ein Teil der Uhr tickt bei dir
Das sagt kaum jemand offen, also sagen wir es: Ein Projekt wartet genauso auf dich wie auf uns. Wenn eine Frage drei Tage auf Antwort wartet, steht dieser Teil drei Tage still. Wenn eine Entscheidung ansteht, die nur du treffen kannst, geht es erst weiter, wenn du sie triffst.
Das ist keine Beschwerde, das ist Planung. Wir sagen dir am Anfang, wo wir dich brauchen: für Rückmeldungen, für Freigaben, für Zugänge, für Inhalte. Wer das früh einplant, verliert keine Woche daran. Wer denkt, er gebe das Projekt ab und hole es fertig zurück, wundert sich über den Terminverzug, den er selbst mit angeschoben hat.
Wie wir den Termin nutzbar machen
Statt ein grosses Datum in weiter Ferne zu versprechen, schneiden wir das Projekt in Stücke, die du sehen kannst. Nicht in sechs Monaten ist alles fertig, sondern in ein paar Wochen läuft die erste echte Version, und danach kommt in kurzen Abständen mehr dazu. Wie das konkret aussieht, zeigt Ein MVP in sechs Wochen.
Der Vorteil ist nicht nur das gute Gefühl. Ein Termin, der in kleinen Schritten kommt, verrät früh, ob die Schätzung stimmt. Läuft der erste Schritt schneller oder langsamer als gedacht, weisst du das nach zwei Wochen und nicht nach fünf Monaten. Und wenn sich unterwegs herausstellt, dass die eigentliche Software sowieso nie ganz fertig ist, ist das kein Fehler im Plan, sondern das Wesen der Sache. Warum, steht in Software ist nie fertig.
Die Faustregel
Frag nicht nach einem Datum, frag nach einer Spanne und danach, woran sie hängt. Wer dir sofort einen einzelnen Tag nennt, ohne nach deinem Umfang, deinen Schnittstellen und deiner eigenen Verfügbarkeit zu fragen, schätzt nicht, sondern rät. Und ein geratenes Datum kostet dich am Ende mehr als eine ehrliche Spanne.
Du hast ein Vorhaben und willst wissen, was realistisch drin ist bis wann? Erzähl uns davon, wir sagen dir ehrlich, woran die Zeit hängt.



