Geld ist komprimierte Zeit — und warum das die Build-or-Buy-Frage für immer verändert

Die meisten von uns lesen „Zeit ist Geld” falsch. Wenn man es richtig liest, trifft man bessere Entscheidungen.

Ich hab lange gebraucht, um zu verstehen, was Geld eigentlich ist. Nicht als Konzept aus dem VWL-Lehrbuch, sondern als etwas, das man spürt, wenn man Entscheidungen trifft. Der Moment, der es für mich verändert hat, war simpel: Ich stand vor der Wahl, ein System selbst zu bauen oder eine fertige Lösung zu kaufen. Und zum ersten Mal hab ich nicht in Euro gerechnet, sondern in Stunden.

Seitdem denke ich über Geld anders. Und über Build-or-Buy sowieso.

Was Geld wirklich ist

Stell dir vor, du baust einen Schrank. Du brauchst Holz, Werkzeug, Wissen und vor allem Zeit — vielleicht 40 Stunden für ein solides Ergebnis. Oder du gehst zu einem Tischler und zahlst 1.200 Euro.

Was kaufst du in diesem Moment? Nicht Holz und Schrauben. Du kaufst die 40 Stunden des Tischlers. Seine Lehrjahre. Seine Werkstatt. Sein Netzwerk an Zulieferern. Du kaufst kondensierte Lebenszeit — und zwar nicht nur seine, sondern die vieler Menschen entlang der gesamten Wertschöpfungskette.

Geld ist ein Speichermedium für Zeit. Es ist ein Transformator: Es wandelt deine vergangene Arbeitszeit in fremde spezialisierte Arbeitszeit um. Es ist ein Kompressor: Hunderte Stunden Erfahrung, verpackt in einen Eurobetrag.

Wenn man das einmal so sieht, stellt sich bei jeder Ausgabe eine neue Frage: Wie viel komprimierte Zeit kaufe ich hier — und ist das mehr wert als die Zeit, die ich selbst investieren müsste?

Genau diese Frage sollten wir uns als Entwickler viel öfter stellen.

Der Build-Reflex

Jeder Entwickler kennt den Moment. Du brauchst eine Funktion — Authentifizierung, Feature Flags, ein Monitoring-Dashboard, eine CI/CD-Pipeline — und der erste Gedanke ist: Das kann ich selbst bauen.

Und meistens stimmt das auch. Natürlich kannst du einen Auth-Service schreiben. Natürlich kannst du dir ein eigenes Deployment-System zusammenbauen. Du bist Entwickler. Du löst Probleme, indem du Dinge baust. Das ist kein Bug, das ist dein größtes Feature.

Aber genau hier liegt die Falle. Denn hinter dem Build-Reflex steckt oft nicht Kalkül, sondern ein Gefühl: der Wunsch nach Kontrolle. Wir wollen verstehen, was unter der Haube passiert. Wir wollen keine Abhängigkeit von Dritten. Und wir genießen den Prozess — das Gefühl, wenn ein System zum ersten Mal läuft, das man selbst geschrieben hat.

Das alles ist nachvollziehbar. Aber es verzerrt unsere Rechnung. Denn wir rechnen fast immer nur die Bauphase ein und vergessen alles, was danach kommt.

Die unsichtbaren Kosten

Ein konkretes Beispiel. Du entscheidest dich, ein internes Feature-Flagging-System zu bauen.

Die erste Version steht nach zwei Wochen. Es funktioniert, du bist zufrieden, das Team ist beeindruckt. Dann passiert das, was bei Software immer passiert: Die Realität meldet sich.

In Woche drei und vier kommen Edge Cases. Race Conditions, User-Segmente, Sonderfälle, an die vorher niemand gedacht hat. Im zweiten Monat braucht das Product-Team eine UI, weil nicht jeder im Unternehmen JSON-Configs editieren will. Ab Monat drei meldet sich Compliance: Audit-Logging, Rollback-Funktionalität, Security Review. Bis Monat sechs hast du ein halbes Produkt gebaut, das gewartet, dokumentiert und an neue Teammitglieder übergeben werden muss.

Was als überschaubares Projekt begann, hat über ein bis zwei Jahre leicht mehrere hundert Stunden verschlungen — verteilt auf mehrere Personen, plus die Opportunitätskosten all der Dinge, die in dieser Zeit nicht entstanden sind.

Eine fertige Lösung hätte vielleicht 500 Euro im Monat gekostet. Bei einem realistischen Vollkostensatz eines Entwicklers in Österreich entspricht das etwa drei bis vier Stunden Arbeitszeit. Pro Monat. Für ein System, das ein dediziertes Team weiterentwickelt, wartet und absichert.

Man kauft damit nicht Software. Man kauft tausende Stunden komprimierter Erfahrung und Wartungsarbeit. Das ist der Zeitkompressor in Aktion.

Warum wir den Aufwand unterschätzen

Es gibt ein Prinzip aus der Systemtheorie, das hier viel erklärt: Gall’s Law. Es besagt, dass jedes funktionierende komplexe System sich aus einem funktionierenden einfachen System entwickelt hat. Andersrum geht es nicht — ein System, das von Anfang an komplex entworfen wird, funktioniert fast nie.

Wenn du selbst baust, startest du mit dem einfachen System. Das ist gut und richtig. Aber der Weg vom funktionierenden Prototyp zum produktionsreifen System — mit echten Nutzern, Compliance-Anforderungen, Monitoring und Wartung — dieser Weg ist lang. Und er ist teuer. Nicht in Euro, sondern in der Währung, die wirklich zählt: deiner Zeit und der deines Teams.

Ein kommerzielles Produkt hat diesen Weg bereits hinter sich. Jeder Bug, der gefunden wurde, jeder Edge Case, jedes Security-Audit — das alles steckt im Preis. Es ist komprimierte Zeit von hunderten Entwicklern über Jahre. Dein Prototyp steht dagegen ganz am Anfang dieser Reise.

Wann Selberbauen die richtige Entscheidung ist

Das Ziel ist nicht, nie wieder selbst zu bauen. Das Ziel ist, bewusster zu entscheiden. Es gibt Situationen, in denen Build klar die richtige Wahl ist:

Wenn es dein Kernprodukt betrifft. Wenn die Differenzierung deines Unternehmens genau in diesem System liegt, ist die investierte Zeit keine Kosten — sie ist das Produkt selbst. Ein Fintech sollte seinen Payment-Layer wahrscheinlich selbst bauen. Aber nicht sein internes Ticketing-System.

Wenn keine passende Lösung existiert. Manchmal gibt es nichts am Markt, das dein spezifisches Problem löst. Dann baust du — aber mit einem ehrlichen Blick auf die Langzeitkosten.

Wenn die Abhängigkeit ein strategisches Risiko ist. Im europäischen Kontext mit DSGVO und AI Act kann Vendor-Abhängigkeit von US-Anbietern ein reales Problem sein. Eigene Infrastruktur ist dann kein Ego-Projekt, sondern eine bewusste Investition in Souveränität.

Wenn der Lerneffekt das Ziel ist. Du willst verstehen, wie etwas funktioniert? Dann bau es. Aber trenn das klar: Ist das ein Lernprojekt oder geht das in Produktion? Diese beiden Ziele vertragen sich selten.

Die Rechnung, die sich lohnt

Bevor du das nächste Mal entscheidest, ob du baust oder kaufst, nimm dir fünf Minuten für eine einfache Rechnung.

Erstens: Was kostet deine Zeit wirklich? Nimm dein Jahresbrutto, rechne Faktor 1,7 für Lohnnebenkosten und Overhead, und teil durch 1.500 produktive Stunden. Das ist dein wahrer Stundensatz — und er ist fast immer höher, als man intuitiv denkt.

Zweitens: Wie lang dauert es wirklich? Nimm deine Schätzung und multipliziere mit drei. Nicht aus Pessimismus, sondern weil systematische Unterschätzung in der Softwareentwicklung empirisch belegt ist. Das ist kein persönliches Versagen, das ist die Natur komplexer Systeme.

Drittens — und das ist die wichtigste Frage: Was baust du in dieser Zeit nicht? Denn das sind die eigentlichen Kosten. Nicht die Euros für eine Lizenz. Sondern die Features, die nicht entstehen. Die Kunden, die nicht gewonnen werden. Die Probleme, die liegen bleiben.

Komprimierte Zeit respektieren

Geld ausgeben fühlt sich für viele Entwickler falsch an — besonders wenn man weiß, dass man es selbst bauen könnte. Da schwingt etwas mit von „Das brauche ich nicht, ich kann das ja.” Und das stimmt oft sogar technisch.

Aber Geld für eine gute Lösung auszugeben ist kein Eingeständnis von Schwäche. Es ist die Anerkennung, dass andere Menschen ihre Lebenszeit in ein Problem investiert haben, das du nicht noch einmal lösen musst. Es ist ein Tausch: deine komprimierte Vergangenheit gegen ihre komprimierte Erfahrung. Und meistens ist das ein verdammt guter Deal.

Build-or-Buy ist keine technische Entscheidung. Es ist eine Zeitentscheidung. Und Zeit ist die einzige Ressource, die sich nicht skalieren lässt.

Dein zukünftiges Ich — das abends den Laptop zuklappt, statt ein selbstgebautes System zu warten — wird dir dankbar sein.

Dieser Beitrag erscheint auf stagl.systems — für Engineers und IT-Entscheider im DACH-Raum, die Systeme bauen, die funktionieren.