Es ist Montagmorgen, 09:00 Uhr, und ich sitze in einem Konferenzraum, in dem die Luft so dick ist, dass man sie schneiden könnte. Vor mir sitzt ein Gründer, der gerade drei Jahre seines Lebens und knapp 450.000 Euro in eine Plattform investiert hat, die heute offiziell live gehen sollte. Das Problem? Die Server halten der Last nicht stand, die Kernfunktion wirft Fehlermeldungen aus, die niemand versteht, und das Marketingbudget ist aufgebraucht. Er starrt auf seinen Laptop und flüstert, dass das doch alles nur kleine Bugs seien. Ich muss ihm die Wahrheit sagen: Das Projekt ist d.o.a. - dead or alive, bevor der erste echte Kunde überhaupt die Kreditkartendaten eingegeben hat. Er hat den klassischen Fehler gemacht, Perfektion in der Theorie zu jagen, während die technische Basis unter dem Gewicht von schlecht dokumentiertem Code und unnötigen Features kollabiert ist. Ich habe dieses Szenario in den letzten fünfzehn Jahren so oft gesehen, dass ich das Muster bereits in der Konzeptionsphase erkenne. Es ist schmerzhaft, teuer und in neun von zehn Fällen absolut vermeidbar, wenn man aufhört, sich selbst zu belügen.
Die Falle der unendlichen Entwicklung im d.o.a. - dead or alive Kontext
Wer denkt, dass ein Produkt erst fertig sein muss, bevor es die Welt sieht, hat den ersten Schritt in den Abgrund getan. In der Praxis bedeutet das oft, dass Teams monatelang an Details feilen, die am Ende kein Mensch braucht. Ich habe ein Team erlebt, das sechs Wochen lang über das Design des Dashboards gestritten hat, während die Datenbank im Hintergrund bei mehr als hundert gleichzeitigen Zugriffen einfach den Dienst quittierte. Das ist die Realität der Fehlplanung. Man investiert Zeit in die Fassade, während das Fundament aus Sand besteht.
Der Fehler liegt in der Annahme, dass technischer Fortschritt linear verläuft. Er ist es nicht. Wenn man zu lange im Verborgenen baut, häufen sich Annahmen an, die nicht validiert sind. Jede dieser Annahmen ist eine potenzielle Zeitbombe. Anstatt sechs Monate zu entwickeln, sollte man nach drei Wochen etwas haben, das zwar hässlich ist, aber ein echtes Problem löst. Wer das nicht versteht, produziert Software-Leichen, die nur darauf warten, beim ersten Kontakt mit der Realität zu zerbrechen. Es geht darum, den kritischen Pfad zu finden. Was muss unbedingt funktionieren, damit das Ganze Sinn ergibt? Alles andere ist Ballast, den man sich am Anfang nicht leisten kann.
Warum das Budget immer an der falschen Stelle verbrennt
Viele Entscheider glauben, dass mehr Geld das Tempo erhöht. Das ist ein Irrglaube, der direkt in die Sackgasse führt. Ich habe erlebt, wie Firmen das Budget für Senior-Entwickler gekürzt haben, um stattdessen fünf Junioren einzustellen, in der Hoffnung, dass mehr Hände schneller arbeiten. Das Ergebnis war ein unlesbares Chaos aus Code-Fragmenten, das nach drei Monaten komplett neu geschrieben werden musste. Diese Sparmaßnahme hat am Ende das Dreifache gekostet.
Echtes Geld spart man nicht durch billige Arbeitskräfte, sondern durch klare Grenzen. Ein Projekt scheitert selten an fehlenden Funktionen, sondern an der Komplexität, die niemand mehr beherrscht. Wenn man 100.000 Euro zur Verfügung hat, sollte man 40.000 Euro als Puffer behalten. Wer sein gesamtes Kapital in die erste Version steckt, steht nackt da, wenn die ersten echten Nutzer Feedback geben, das eine Kurskorrektur erfordert. Und diese Korrektur wird kommen, immer. Es ist eine Frage der mathematischen Wahrscheinlichkeit.
Der Irrtum der Skalierbarkeit am ersten Tag
Ein weiterer teurer Fehler ist der Aufbau einer Infrastruktur, die für Millionen von Nutzern ausgelegt ist, wenn man noch nicht einmal zehn hat. Ich nenne das die „Cloud-Falle“. Da werden komplexe Microservice-Architekturen aufgebaut und teure Server-Instanzen gemietet, die pro Monat Tausende Euro fressen, nur weil man Angst hat, am Tag des Erfolgs nicht bereit zu sein.
Die Wahrheit ist: Wenn man das Luxusproblem hat, dass die Server wegen zu vieler Nutzer rauchen, findet man auch das Geld oder die Zeit, das zu fixen. Aber wenn man pleitegeht, bevor der erste Nutzer kommt, hilft einem die schönste Architektur nicht weiter. Man muss so primitiv wie möglich starten. Ein einzelner, gut konfigurierter Server reicht für den Anfang fast immer aus. Wer hier zu groß denkt, verbrennt Kapital, das später für das Überleben entscheidend wäre.
Das Team als unsichtbarer Kostenfaktor
Ich habe Projekte gesehen, die technisch brillant waren, aber an der internen Kommunikation zerbrochen sind. Wenn der Produktmanager nicht versteht, was die Technik tut, und die Technik nicht weiß, warum sie etwas baut, entstehen Reibungsverluste, die monatlich Zehntausende Euro kosten. Das ist kein theoretisches Problem, das ist bares Geld. Jedes Meeting ohne klares Ergebnis, jede Anforderung, die nach der Hälfte der Entwicklung wieder geändert wird, ist eine Verschwendung von Ressourcen.
In einem Fall, den ich begleiten musste, wurden drei Monate lang Funktionen entwickelt, die der Vertrieb bereits als „unverkäuflich“ eingestuft hatte. Die Information kam nur nie bei den Entwicklern an. Hier wurde buchstäblich Geld im Hinterhof verbrannt. Die Lösung ist radikale Transparenz. Jeder im Team muss wissen, was das Ziel ist und wie viel Zeit noch bleibt. Wenn die Zeit knapp wird, müssen Funktionen sterben, nicht die Qualität. Wer an der Qualität spart, um den Termin zu halten, zahlt später mit Zinsen in Form von technischer Schuld zurück.
Ein Vorher-Nachher-Vergleich der strategischen Ausrichtung
Schauen wir uns ein konkretes Beispiel an, wie sich ein falscher Ansatz von einer klugen Strategie unterscheidet.
Nehmen wir an, ein Unternehmen möchte ein neues Buchungssystem für Handwerker entwickeln. Der falsche Weg sieht so aus: Das Management erstellt ein Lastenheft mit 200 Seiten. Es werden fünf Entwickler für ein Jahr eingestellt. Man baut eine App für iOS, eine für Android und eine Web-Plattform gleichzeitig. Nach zwölf Monaten ist das Budget von 300.000 Euro aufgebraucht. Beim ersten Testlauf stellt man fest, dass die Handwerker die App auf der Baustelle nicht bedienen können, weil die Schaltflächen zu klein für schmutzige Hände sind. Das System muss komplett überarbeitet werden, aber das Geld ist weg. Das Projekt ist d.o.a. - dead or alive.
Der richtige Weg sieht anders aus: Man beginnt mit einer einfachen Web-Seite, die nur eine einzige Funktion hat: Termine eintragen. Man gibt zwei Entwicklern zwei Monate Zeit und ein Budget von 30.000 Euro. Nach diesen acht Wochen geht man zu fünf Handwerksbetrieben und lässt sie das System im Alltag testen. Man beobachtet sie dabei. Man sieht sofort, dass sie die Weboberfläche am Smartphone nutzen und wo sie hängen bleiben. Man korrigiert diese Fehler innerhalb von zwei Tagen. Erst wenn diese fünf Betriebe das System lieben und bereit sind, dafür zu zahlen, baut man die nächste Funktion ein. Man skaliert erst dann, wenn der Kern stabil ist. Man hat nach drei Monaten ein funktionierendes, umsatzgenerierendes Produkt und noch 250.000 Euro auf der Bank.
Warum einfache Lösungen oft ignoriert werden
Es klingt logisch, aber warum machen es so wenige? Weil es Disziplin erfordert, „Nein“ zu sagen. Es ist einfach, eine Liste mit 50 Features zu schreiben. Es ist verdammt hart, sich auf die zwei zu konzentrieren, die wirklich zählen. Oft spielt auch das Ego eine Rolle. Man möchte mit einem großen Wurf glänzen, anstatt sich mit kleinen, hässlichen Schritten vorwärts zu bewegen. In der Praxis gewinnt aber immer derjenige, der am schnellsten lernt, nicht derjenige, der am längsten plant.
Die unterschätzte Gefahr der technischen Schulden
Wenn es schnell gehen muss, neigen Teams dazu, Abkürzungen zu nehmen. Das ist bis zu einem gewissen Grad okay, solange man weiß, was man tut. Aber wenn man Abkürzung auf Abkürzung türmt, ohne jemals aufzuräumen, wird das System irgendwann unbeweglich. Ich habe Systeme gesehen, bei denen eine Änderung an der Farbe eines Buttons dazu führte, dass der Bezahlvorgang nicht mehr funktionierte. Das ist der Moment, in dem die Wartungskosten die Entwicklungskosten übersteigen.
Man muss ein Gleichgewicht finden. Man darf nicht in Schönheit sterben, aber man darf auch kein Kartenhaus bauen. Ein erfahrener Praktiker weiß, an welchen Stellen man schlampen darf und wo absolute Präzision herrschen muss. Die Datenintegrität und die Sicherheit sind nicht verhandelbar. Das Design der Benutzeroberfläche oder die Eleganz des Codes in einem unwichtigen Modul hingegen schon. Wer diesen Unterschied nicht kennt, wird früher oder später von seinem eigenen System erdrosselt.
Der Realitätscheck für den langfristigen Erfolg
Jetzt mal ganz ehrlich unter uns: Die meisten Projekte in diesem Bereich scheitern nicht an der Technik. Sie scheitern an der mangelnden Bereitschaft, der Realität ins Auge zu sehen. Wenn du gerade merkst, dass dein Projekt seit Monaten keinen echten Fortschritt macht, obwohl alle hart arbeiten, dann stimmt etwas Grundlegendes nicht. Mehr Arbeit wird das Problem nicht lösen. Mehr Geld auch nicht.
Du musst bereit sein, Dinge wegzuwerfen. Wenn eine Funktion nicht genutzt wird, lösche sie. Wenn ein Prozess zu kompliziert ist, vereinfache ihn radikal. Es gibt keine magische Abkürzung zum Erfolg. Es gibt nur den harten Weg der ständigen Validierung und Korrektur. Wer denkt, er könne den Markt austricksen oder technische Mängel durch Marketing ausgleichen, wird scheitern.
Erfolg bedeutet hier, dass man am Ende des Tages ein Werkzeug hat, das funktioniert und für das jemand bereit ist, echtes Geld zu bezahlen. Alles andere ist nur Beschäftigungstherapie. Sei brutal ehrlich zu dir selbst: Würdest du dein eigenes Produkt nutzen, wenn du nicht der Erfinder wärst? Wenn die Antwort nicht ein klares „Ja“ ist, dann hör auf zu bauen und fang an zu denken. Es braucht Nerven aus Stahl, ein laufendes Projekt zu stoppen oder radikal umzubauen, aber es ist immer billiger, als sehenden Auges gegen die Wand zu fahren. Wer das nicht kann, sollte sein Geld lieber aufs Sparbuch legen – da schmilzt es wenigstens langsamer weg.
Es geht nicht darum, Recht zu haben oder die schönste Vision zu verfolgen. Es geht darum, am Ende des Tages ein System zu haben, das atmet, lebt und Wert schafft. Alles andere ist Zeitverschwendung. Wenn du diesen pragmatischen Ansatz nicht verinnerlichst, wirst du immer wieder an denselben Hürden hängen bleiben, während andere an dir vorbeiziehen, die vielleicht weniger Vision, aber dafür mehr Bodenhaftung haben. Das ist die harte Wahrheit, die man in keinem Lehrbuch findet, die man aber auf die harte Tour lernt, wenn man einmal zu oft vor den Trümmern einer investierten Million gestanden hat.
- d.o.a. - dead or alive (Erster Absatz)
- d.o.a. - dead or alive (H2-Überschrift)
- d.o.a. - dead or alive (Im Vorher/Nachher-Vergleich)
