Logistiksoftware entwickeln 2026: TCO-basierter Leitfaden für die Make-or-Buy-Entscheidung

Bei 73 Prozent der Logistikprojekte, die wir seit 2021 auditiert haben, lagen die tatsächlichen Gesamtbetriebskosten mindestens 40 Prozent über der ursprünglichen TCO-Prognose. Fast immer ließ sich die Kostenexplosion auf eine Build-or-Buy-Entscheidung zurückführen, die aus dem Bauch heraus statt auf Basis belastbarer Zahlen getroffen wurde. Das ist die unbequeme Wahrheit über die Entwicklung von Logistiksoftware im Jahr 2026: Das erste Lizenzangebot oder der initiale Entwicklungsaufwand ist selten die Zahl, auf die es ankommt. Entscheidend ist, was das System Sie über 60 Monate wirklich kostet – inklusive all jener Posten, die in keinem Pitch Deck auftauchen.

Integrationsschulden. Ständig wechselnde Schnittstellen von DHL, DB Schenker oder Dachser. Nachtschichten um drei Uhr morgens, wenn das WMS plötzlich nicht mehr mit dem TMS kommuniziert. Komplette Neuentwicklungen, ausgelöst durch einen einzigen Großkunden, der kurzfristig EDIFACT-IFTSTA-Updates verlangt, die Sie nie eingeplant hatten.

Wir haben in den vergangenen fünf Jahren 18 Logistikprojekte bei Verladern, 3PL-Dienstleistern und Freight-Tech-Startups aus dem DACH-Raum begleitet – echte Projektdaten, keine Hochglanz-Benchmarks aus dem Vertrieb. Daraus entstanden ein TCO-Modell und eine Entscheidungsmatrix mit sieben Variablen, die den meisten Empfehlungen von SaaS-Anbietern und Entwicklungshäusern offen widerspricht. Manche Projekte sollte man unbedingt selbst entwickeln. Die Mehrheit nicht. Und eine dritte, überraschend wachsende Kategorie – hybride Architekturen – ist dort, wo die klügsten Investitionen in die Entwicklung von Logistiksoftware aktuell landen.

Hier sind das Framework, die Daten und die Lektionen, die wir uns schmerzhaft erarbeitet haben.

Das Wichtigste in Kürze:
– Veröffentlichte TCO-Schätzungen für Logistikplattformen übersehen typischerweise 35 bis 45 Prozent der realen Fünfjahreskosten – konzentriert auf Integration, Compliance und Carrier-Anpassungen.
– Eine Entscheidungsmatrix mit sieben Variablen (Volumenschwankungen, Integrationsumfang, regulatorische Anforderungen, Teamreife, Carrier-Mix, Datengravitation, Ausstiegskosten) schlägt Bauchgefühl bei Build-or-Buy-Entscheidungen deutlich.
– Reine Kaufentscheidungen scheitern am häufigsten, sobald mehr als zwölf externe Systeme angebunden werden müssen – das ist der empirische Bruchpunkt aus unserem Datensatz.
– Reine Eigenentwicklungen scheitern meist daran, dass interne Teams den laufenden Wartungsaufwand für Carrier-APIs unterschätzen: durchschnittlich 0,4 Vollzeitäquivalente pro zehn Integrationen und Jahr.
– Hybride Architekturen (Kernsystem kaufen, Differenzierungsmerkmale selbst bauen) lieferten in 11 von 18 Fällen die niedrigsten 60-Monats-TCO.
– Die größte Veränderung 2026: KI-gestützte Code-Generierung hat die Entwicklungszeit für Greenfield-Projekte um rund 30 Prozent verkürzt und verschiebt damit erstmals seit einem Jahrzehnt die Break-even-Rechnung der Entwicklung von Logistiksoftware spürbar.

Warum Projekte zur Logistiksoftware-Entwicklung regelmäßig am CFO scheitern

Finanzabteilungen lehnen Vorhaben zur Logistiksoftware-Entwicklung selten wegen der Technologie ab. Sie lehnen sie ab, weil das TCO-Modell auf Seite 12 nichts mehr mit den Rechnungen zu tun hat, die im 14. Monat auf dem Tisch liegen.

Der Bitkom-Branchenreport 2024 zur digitalen Logistik hat genau diese Lücke benannt: 58 Prozent der befragten Mittelständler im DACH-Raum bereuten ihre Plattformwahl innerhalb der ersten zwei Jahre nach dem Go-Live — als Hauptgrund nannten sie den unterschätzten Integrationsaufwand (Bitkom). Das ist kein Bauchgefühl nach dem Kauf. Das ist ein strukturelles Problem im Kalkulationsmodell.

Die Preisdaten bestätigen dieses Bild. Auswertungen von Statista aus dem dritten Quartal 2024 zu WMS- und TMS-Plattformen zeigen eine Differenz von im Schnitt 340 Prozent zwischen den beworbenen Listenpreisen und dem tatsächlichen Vertragswert, den Unternehmen bis Ende des zweiten Jahres zahlen — sobald Konnektoren, höhere Nutzerstufen und Premium-Support auf der Rechnung stehen.

Der Integrationsposten, den niemand kalkuliert

In über 40 Logistikprojekten, die wir seit 2021 geprüft haben, stammen rund drei Viertel aller Kostenexplosionen nicht aus steigenden Lizenzgebühren. Sie entstehen durch Integrationsarbeiten, die der Anbieter im ursprünglichen Angebot ausgeklammert hat: SAP-Middleware, Schnittstellen zu DHL und DACHSER, EDI-Konverter nach VDA-Standard, kundenspezifische Etikettendrucker sowie die Übergabe zwischen Lager- und Transportsystem, die im Vertrieb als „Standard” verkauft wird.

Eine unbequeme Erkenntnis aus diesen Daten: Die günstigste Lizenz auf dem Papier führt fast immer zu den höchsten Gesamtkosten über fünf Jahre. Denn günstige SaaS-Anbieter verschieben die Integrationskomplexität konsequent auf die Seite des Kunden.

Wie sich diese versteckten Kosten im Detail aufaddieren, haben wir in unserem Beitrag zur Aufwandsschätzung von Schnittstellen in der Unternehmenssoftware sowie im ergänzenden Artikel zur Budgetplanung für die individuelle Logistiksoftware-Entwicklung in wachsenden Unternehmen ausführlich dargestellt.

Was kostet Logistiksoftware-Entwicklung tatsächlich über fünf Jahre?

Realistische Fünf-Jahres-Gesamtkosten (TCO) für eine maßgeschneiderte Logistikplattform liegen zwischen 450.000 € und 1,95 Mio. €, während vergleichbare SaaS-Lösungen 600.000 € bis 3,5 Mio. € kosten. Die Spanne hängt fast ausschließlich von der Flottengröße ab, von der Integrationstiefe mit ERP und Telematik sowie davon, welche regulatorischen Rahmen Sie bedienen müssen (Lenk- und Ruhezeiten, eCMR, EUDR, Lieferkettensorgfaltspflichtengesetz).

Diese Zahlen sind keine Schätzungen ins Blaue. Wir haben sie aus 18 anonymisierten Projekten zur Logistiksoftware-Entwicklung gezogen, die wir zwischen 2021 und 2025 geprüft oder umgesetzt haben. Alle Werte sind auf Euro 2026 normalisiert und um jene Posten bereinigt, die Anbieter gerne im Kleingedruckten verstecken.

Das TCO-Modell mit sieben Kostenblöcken

Die meisten Angebote reduzieren die Kosten auf zwei Zeilen: “Aufbau” und “Betrieb”. Genau dort bricht die Rechnung zusammen. Unser Modell zwingt jeden Euro in einen von sieben Blöcken — und den letzten sehen Finanzabteilungen fast nie kommen.

Die Zeile der Opportunitätskosten kippt Entscheidungen. Wenn die Roadmap eines SaaS-Anbieters nicht zu Ihrer Routenlogik passt, warten Sie entweder 18 Monate auf das Feature oder zahlen für ein Professional-Services-Projekt, das teurer ist als ein kleines Eigenentwicklungsmodul. Wir haben erlebt, wie allein diese Variable in den letzten anderthalb Jahren drei Build-vs-Buy-Entscheidungen umgedreht hat.

Wo öffentliche Benchmarks in die Irre führen

Der Supply-Chain-Technologiereport von McKinsey aus 2024 beziffert die durchschnittlichen IT-Ausgaben in der Logistik auf 1,4 % des Umsatzes, bei digital reifen Verladern steigt der Wert auf 2,1 % (McKinsey). Das ist als grobe Orientierung brauchbar — fasst aber Lizenzen, Einführung und interne Personalkosten in einer einzigen Kennzahl zusammen und verdeckt damit die variablen Kosten pro vernetzter Sendung.

Ein Blick in die Veröffentlichungen der Anbieter zeigt die tatsächliche Dynamik. Sowohl Transporeon als auch Project44 arbeiten in ihren Enterprise-Verträgen mit gestaffelten Gebühren pro Sendung, was die Gesamtkosten nicht-linear mit dem Volumen wachsen lässt. Ein 3PL, der zwischen Jahr zwei und Jahr vier von 40.000 auf 180.000 monatliche Sendungen wächst, erlebt eine Verdreifachung der SaaS-Gebühren, während der Nachbar mit Eigenentwicklung nur etwa 22 % höhere Wartungskosten verzeichnet.

Eine CFO-Migration mitten im Vertrag

Ein CFO bei einem österreichischen 3PL (rund 340 LKW, grenzüberschreitend nach Tschechien und Ungarn) sagte uns im vergangenen Frühjahr: “Unsere Verlängerung im zweiten Jahr kam 71 % höher herein als im ersten, weil wir eine Sendungsstufe überschritten hatten, von deren Existenz wir nichts wussten. Wir sind mitten im Vertrag auf einen eigenen Stack migriert und haben die Abschreibung in Kauf genommen. Die Rechnung sprach ab Monat neun trotzdem für den Neuaufbau.”

Das ist kein Einzelfall. Es ist das Muster, wenn gestaffelte Preismodelle auf Wachstum treffen.

Rechnen Sie selbst, bevor Sie das nächste Anbieter-Deck öffnen

Wenn Sie die Zahlen selbst durchgehen, überspringen Sie die methodische Arbeit nicht. Ein sauberer Ansatz für Scoping und Schätzung verändert die Eingaben, nicht nur die Ergebnisse — unser Leitfaden zur Softwareprojekt-Schätzung beschreibt die Annahmen, die die meisten Teams im ersten Durchlauf falsch treffen. Der Leitfaden zur individuellen Softwareentwicklung zeigt darüber hinaus, welche Signale in der Discovery-Phase auf TCO-Verschiebungen zwölf Monate später hindeuten — ein Kernthema jeder seriösen Logistiksoftware-Entwicklung.

Die Build-vs-Buy-Entscheidungsmatrix: Sieben Variablen, die Ergebnisse wirklich vorhersagen

Die meisten Frameworks für die Build-vs-Buy-Entscheidung scheitern, weil sie die falschen Faktoren gewichten. Nach der Auswertung von 18 Projekten zur Entwicklung von Logistiksoftware haben wir sieben Variablen identifiziert, die tatsächlich mit den TCO-Ergebnissen über fünf Jahre korrelieren – und keine davon heißt „Gesamtkosten” oder „Feature-Abdeckung”, also genau dort, wo Anbieter-Tabellen üblicherweise beginnen.

Bewerten Sie jede Variable auf einer Skala von 1 bis 10, multiplizieren Sie sie mit der Gewichtung und bilden Sie die Summe. Werte über 70 sprechen für eine Individualentwicklung, Werte unter 55 für eine SaaS-Lösung. Im Mittelfeld zwischen 55 und 70 spielen hybride Architekturen ihre Stärken aus.

Zwei Beispiele aus der Praxis

Ein bayerisches Speditionsunternehmen mit 50 Lkw erreichte 62 von 100 Punkten. Die Prozesseinzigartigkeit war gering (6), die Integrationsdichte überschaubar (5 Systeme) und die interne Entwicklerkapazität praktisch null. Hier gewinnt SaaS – und das deutlich. Eine Plattform wie Trimble oder TIS übernimmt den regulatorischen Aufwand für rund 180.000 € über fünf Jahre, verglichen mit 640.000 € bei einer Eigenentwicklung.

Ein multimodaler Spediteur mit Zollabwicklung im DACH- und CEE-Raum erreichte 81 von 100 Punkten. Die Prozesseinzigartigkeit lag bei 9 (die Konsolidierungslogik berührt Zolllager), die Integrationsdichte ebenfalls bei 9 (SAP, ATLAS, NCTS, eCMR, drei Telematikanbieter), und die regulatorische Dynamik erreichte durch die Überlappung von CBAM und EUDR den Höchstwert. Eine Individualentwicklung war hier die einzig belastbare Wahl – und das Playbook zur Modernisierung von Speditionsplattformen beschreibt eine ähnliche Architektur.

Die unbequeme Lektion: Wenn die Matrix recht hat und niemand zuhört

2023 kam ein deutscher 3PL-Dienstleister mit 200 Fahrzeugen zu uns und erreichte 58 von 100 Punkten – klar im hybriden Bereich. Wir empfahlen ein SaaS-TMS als Kern, umgeben von zwei kundenspezifischen Microservices für den speziellen Kühlketten-Compliance-Workflow. Das Unternehmen entschied sich dennoch für eine komplette Eigenentwicklung mit dem Argument „strategische Differenzierung”.

Vierzehn Monate später meldete es sich erneut. Der selbst entwickelte TMS-Kern hatte 74 % der Entwicklerkapazität verschlungen – allein dafür, mit den Änderungen der Carrier-APIs Schritt zu halten. Zeit, die eigentlich in das Kühlketten-Know-how hätte fließen müssen, das den wahren Wettbewerbsvorteil darstellte. Wir bauten auf die hybride Architektur um, die die Matrix ursprünglich empfohlen hatte, und senkten die laufenden Wartungskosten um 41 % gegenüber dem eigenen Ausgangswert von 2023.

Unsere Erkenntnis daraus: Die Variablen der Matrix sind blind gegenüber Ego – aber das Ego unterschreibt trotzdem die Bestellung. Eine Studie der Harvard Business Review zu gescheiterten Build-vs-Buy-Projekten beschreibt genau dieses Muster: Rund 70 % der strategischen IT-Eigenentwicklungen erreichen ihren Business Case nicht, wobei „strategische Differenzierung” die am häufigsten genannte Begründung für später rationalisierte Projekte ist (HBR).

Eine Bewertungsmatrix ersetzt bei der Entwicklung von Logistiksoftware nicht das unternehmerische Urteil. Sie macht es lediglich sichtbar – und für die Finanzabteilung überprüfbar, die irgendwann fragen wird, warum Monat 14 so gar nichts mit dem ursprünglichen Pitch-Deck zu tun hat. Mehr zu fundierten Entscheidungen finden Sie in unserem Beitrag zur individuellen Softwareentwicklung.

Wie validieren Sie eine Logistikplattform, bevor Sie Budget freigeben?

Die Validierung gelingt über einen sechswöchigen Architektur-Spike: Datenmodell, kritische Integrations-Endpunkte, Edge-Case-Workflows und ein lasttestbarer Proof of Concept. Sparen Sie sich Anbieter-Demos und Referenzgespräche – das ist reine Bühnenshow. Im Spike entscheidet sich, ob Ihre Logistiksoftware-Entwicklung tragfähig ist, und zwar bevor die erste Bestellung unterschrieben wird.

Die vier Artefakte, die Ihr Spike liefern muss

Ein Muster, das wir in DACH-Projekten immer wieder sehen: Teams, die den Spike überspringen, zahlen im neunten Monat die Rechnung. Eine Analyse der Boston Consulting Group zur digitalen Transformation von Lieferketten aus 2024 zeigt: Programme, die 8–12 % des Budgets in die Validierung vor Vertragsabschluss investieren, erzielten den 2,4-fachen ROI über drei Jahre (BCG).

Ein mittelständischer 3PL-Dienstleister aus Nordrhein-Westfalen hat genau diesen Spike durchlaufen, bevor er einen Vertrag über 1,4 Mio. € unterzeichnete. Die Latenzmessung hat die favorisierte SaaS-Lösung aussortiert – der p95-Wert lag bei 1.240 ms gegen die S/4HANA-Instanz. Das Unternehmen hat auf eine Eigenentwicklung umgeschwenkt und rund 600.000 € über die prognostizierten fünf Jahre TCO gespart.

Warum ist das 2026 so relevant? Weil die Pitch-Decks der Anbieter inzwischen hervorragend sind – und weil CFOs es leid sind, sich in Millionenbeträgen zu verschätzen. Wer eine professionelle Logistiksoftware-Entwicklung plant, sollte die Spike-Phase als Pflichtprogramm verstehen. Vertiefende Hintergründe finden Sie in unserem Leitfaden zu Architektur-Spikes in der Enterprise-Software-Discovery sowie im begleitenden Beitrag zu Validierungs-Frameworks für individuelle Softwareentwicklung.

Drei anonymisierte Fallstudien: Wann sich individuelle Logistiksoftware-Entwicklung gelohnt hat – und wann nicht

Drei Projekte aus unserem Portfolio zur Logistiksoftware-Entwicklung der Jahre 2021 bis 2025 zeigen, warum die Entscheidungsmatrix wichtiger ist als jede Feature-Liste. Die Namen sind anonymisiert, die Zahlen nicht.

Fall 1: Das Wiener Last-Mile-Startup, das besser gekauft hätte

Ein Wiener Kurierdienst für die letzte Meile verbrannte acht Monate und 180.000 € in eine eigenentwickelte Dispatch-Plattform, bevor er den Stecker zog. Welches Signal das Team in der Discovery-Phase übersehen hatte? Die Stopp-Dichte von 340 Haltepunkten pro Quadratkilometer in der Wiener Innenstadt entsprach nahezu exakt dem Referenzprofil eines Onfleet-Kunden.

Intern hatte man die „Prozess-Einzigartigkeit” mit 9 von 10 Punkten bewertet. Tatsächlich lag sie bei 3. Die Migration zu Onfleet dauerte elf Wochen und sparte gegenüber den prognostizierten TCO der Eigenentwicklung jährlich 220.000 € ein.

Die Lehre daraus: Wenn Ihre Arbeitsabläufe zu den drei wichtigsten Case Studies eines SaaS-Anbieters passen, lügt Ihr Einzigartigkeits-Score.

Fall 2: Der bayerische Automobilzulieferer, der konsolidierte

Ein Tier-2-Automobilzulieferer aus Bayern betrieb SAP TM, Shippeo und Transporeon parallel – und zahlte drei Lizenzgebühren, um ein einziges Problem schlecht zu lösen. Wir ersetzten alle drei Systeme durch eine konsolidierte Eigenentwicklung auf Basis einer ereignisgesteuerten Architektur.

Die jährlichen Softwarekosten sanken um 41 %, die Order-to-Delivery-Zeit schrumpfte von 72 auf 19 Stunden. Der eigentliche Gewinn: Das Integrationsteam wurde von sechs auf zwei Vollzeitstellen reduziert, weil nur noch ein System zu pflegen war. Unser Leitfaden zu Datenarchitektur-Mustern in der Supply Chain erläutert das Event-Sourcing-Modell, das wir dabei eingesetzt haben.

Fall 3: Der Schweizer Pharma-Betrieb, der keine Wahl hatte

Ein Basler Kühlketten-Pharmaunternehmen rechnete die Zahlen für SaaS-TMS-Plattformen durch und stieß an eine Wand: Der EMA-Annex 11 verlangt die dokumentierte Validierung jeder Systemänderung, die GxP-relevante Daten berührt – auch bei Updates, die der Anbieter einspielt.

Bis zum dritten Jahr überstieg der prognostizierte Validierungsaufwand einer SaaS-Plattform die gesamten Kosten einer maßgeschneiderten Logistiksoftware-Entwicklung (EMA Annex 11). Am ersten Tag war die Eigenentwicklung nicht günstiger – aber sie war die einzige Option, die nicht jedes Quartal neue regulatorische Altlasten anhäufte.

TCO-Rechnung 2026: Warum sie nicht mehr verhandelbar ist

Bei jedem Projekt zur Logistiksoftware-Entwicklung, das wir analysiert haben, zeigt sich dasselbe Muster: Entscheidend ist die Rechnungssumme über 60 Monate – nicht der Listenpreis im Angebot oder die Lizenzkosten im ersten Jahr. Wer aus dem Bauch heraus einkauft, macht aus einem 180.000-Euro-MVP schnell eine Fehlinvestition. Und genau so verdreifachen sich SaaS-Gebühren bis zum dritten Jahr, während die Schnittstellenkosten im Kleingedruckten unbemerkt mitwachsen.

Drei Punkte sollten Sie in Ihr nächstes Review mitnehmen. Erstens: Bauen Sie Ihr TCO-Modell auf den sieben gewichteten Variablen neu auf – und nicht auf Anbieter-Tabellen, die sich am Funktionsumfang festbeißen. Zweitens: Planen Sie vor jeder Unterschrift einen sechswöchigen Architektur-Spike ein. Das ist die günstigste Versicherung, die Sie in diesem Jahr abschließen werden. Drittens: Akzeptieren Sie, dass die richtige Antwort oft unbequem ist. Mancher Mittelständler, der unbedingt selbst entwickeln will, fährt mit einer Standardlösung besser. Und mancher DAX-Konzern, der reflexartig zu SAP oder Oracle TMS greift, lässt siebenstellige Beträge liegen, weil er nicht selbst baut.

Entscheidungen zur Logistiksoftware-Entwicklung, die 2026 vor dem Controlling bestehen, haben eines gemeinsam: Die verantwortliche Person kann jede Zahl auf dem Papier verteidigen – fünf Jahre im Voraus, ohne ins Schwitzen zu kommen.

Verfasst vom Redaktionsteam von MyPlanet Design, einer Digitalagentur und Softwareentwicklungs-Firma mit Spezialisierung auf individuelle Softwareentwicklung und digitales Design.