Build or Buy: Wann sich Individualsoftware 2026 wirklich lohnt

„Kannst du das nicht einfach selbst bauen?” Diese Frage hören wir bei TAISC gerade häufiger, seit KI-Tools wie Cursor, Claude Code oder App-Builder wie Lovable es möglich machen, in wenigen Stunden ein internes Trello, ein Dashboard oder ein kleines CRM zusammenzuklicken, ganz ohne Entwicklungshintergrund. Das ist beeindruckend. Es ist aber die falsche erste Frage.

Die richtige Frage lautet nicht “kann ich das bauen”, sondern: Lohnt es sich, und wem gehören am Ende die Daten, die dabei entstehen? Dieser Beitrag zeigt ein Stufenmodell, mit dem wir bei TAISC genau diese Entscheidung mit Kund:innen durchgehen, unterlegt mit aktuellen Studien zu Softwarekauf-Reue, Lock-in-Kosten und Datenhoheit im deutschen Mittelstand.

Warum “kann ich das bauen” die falsche Ausgangsfrage ist

Ein internes Tool in ein paar Stunden zusammenzuklicken, ohne je Software gebaut zu haben, klingt nach einem Produktivitätswunder. Die unbequeme Anschlussfrage kommt aber garantiert: Wie entwickelst du das in sechs oder zwölf Monaten weiter, wenn sich dein Prozess ändert? Wer pflegt es, wenn die Person, die es gebaut hat, im Tagesgeschäft eigentlich anderes zu tun hat? App-Builder wie Lovable sind für einen ersten Prototyp und um Eindruck zu schinden gut geeignet, für ein dauerhaft betriebenes, unternehmenskritisches System in der Regel nicht.

Die eigentliche Entscheidung hängt an vier Fragen, die mit reiner Baubarkeit nichts zu tun haben:

• Lock-in und Abhängigkeiten: Wie leicht kommst du wieder aus einem System heraus, wenn es nicht mehr passt?
• ROI und Priorisierung: Löst die Software ein Problem, das groß genug ist, um Entwicklungszeit zu rechtfertigen?
• Datenhoheit und Ownership: Wem gehören die Daten, die im Betrieb entstehen, technisch und vertraglich?
• Datenschutz und Sicherheit: Wer haftet, wenn im selbst gebauten Tool etwas schiefläuft?

Dass diese Fragen wichtiger werden statt unwichtiger, zeigt sich gerade an drei Entwicklungen, die im Sommer 2026 alle gleichzeitig greifen.

Drei Entwicklungen, die die Build-or-Buy-Rechnung 2026 verändern

SaaS wird teurer, nicht günstiger. Nach Marktbeobachtungen von SaaS-Ausgabenanalysten wie Zylo und Cledara stiegen die Preise für Software-Abos 2026 im Schnitt um rund 8 bis 9 Prozent gegenüber dem Vorjahr, bei aggressiveren Anbietern und KI-Feature-Bundles teils deutlich zweistellig. Ein Grund: Neukundenwachstum stagniert bei vielen SaaS-Anbietern, während bestehende Kund:innen durch Daten- und Workflow-Abhängigkeiten an ihr Tool gebunden sind, was Preiserhöhungen leichter durchsetzbar macht.

Der EU Data Act macht Lock-in seit September 2025 zum Rechtsthema, nicht nur zum Bauchgefühl. Seit dem 12. September 2025 gilt die EU-Datenverordnung, die Cloud- und SaaS-Anbieter in den Artikeln 23 bis 31 verpflichtet, den Wechsel zu einem anderen Anbieter oder zurück ins eigene System technisch, vertraglich und finanziell spürbar zu erleichtern: offene Schnittstellen, maximal zweimonatige Kündigungsfrist, höchstens 30 Tage Übergangszeit. Bis zum 12. Januar 2027 dürfen Anbieter für den Wechsel noch kostendeckende Gebühren verlangen, danach müssen reguläre Wechsel komplett gebührenfrei sein. Das Gesetz existiert, weil Lock-in bislang ein reales, teures Problem war, kein theoretisches.

Datenhoheit ist im deutschen Mittelstand zur Top-Priorität geworden. Eine 2026 durchgeführte Studie von otris software, Evergreen Media und Splendid Research unter 518 IT- und Rechtsentscheider:innen in mittelständischen und großen deutschen Unternehmen zeigt: Zwei Drittel der Befragten stufen Datenhoheit und regulatorische Konformität inzwischen höher ein als Innovationsgeschwindigkeit oder Kosten. Mehr als die Hälfte verlangt von Cloud-Anbietern entweder eine EU-Regulierung oder dedizierte Server, reines “EU-Hosting” reicht nur noch einem Viertel. Der Bitkom Cloud Report 2026 liefert dazu eine ernüchternde Ergänzung: 91 Prozent der deutschen Unternehmen würden am liebsten mit einem deutschen Cloud-Anbieter arbeiten, 71 Prozent nutzen trotzdem einen amerikanischen, meist aus Mangel an Alternativen mit vergleichbarem Funktionsumfang.

Diese drei Trends drehen die klassische Buy-Logik (“SaaS ist immer günstiger und weniger Risiko als Selbstbau”) nicht um, sie relativieren sie aber deutlich.

Das Stufenmodell: nicht alles selbst bauen, aber auch nicht alles einkaufen

Statt “alles selbst bauen” oder “alles einkaufen” hat sich in unseren Projekten ein gestuftes Vorgehen bewährt, das strukturell dem ähnelt, was Gartner in seinem Pace-Layered-Modell für Unternehmensanwendungen beschreibt: Systeme unterscheiden sich danach, wie oft sie sich ändern und wie sehr sie ein Unternehmen tatsächlich differenzieren, nicht danach, ob sie “wichtig” klingen.

Der Bruch zwischen Stufe 1 und Stufe 2 ist der wichtigste: Eine Potenzialanalyse vor der Entwicklung, in der Lock-in-Risiko, ROI und Datenmodell sauber durchgerechnet werden, kostet einen Bruchteil dessen, was ein falsch gestartetes Individualprojekt kostet. Genau hier zeigt eine aktuelle Gartner-Erhebung, wie teuer eine überstürzte Entscheidung wird, in beide Richtungen.

Was Studien über Softwarekauf-Reue zeigen, und warum das auch für Selbstbau gilt

Gartners “2024 Tech Trends”-Befragung von über 3.400 Softwarekäufer:innen in neun Ländern fand: 60 Prozent aller Käufer:innen bereuen ihre Software-Anschaffung im Nachhinein zumindest teilweise, bei schnell wachsenden Unternehmen sind es sogar 68 Prozent. Hauptgründe sind unerwartet hohe Gesamtkosten (33 Prozent) und eine zu langsame oder zu komplexe Einführung (32 Prozent). Bemerkenswert: Ausgerechnet die Unternehmen, die am zuversichtlichsten in den Kaufprozess starten, bereuen die Entscheidung später am häufigsten.

Diese Zahl wird oft als Argument für “dann bauen wir es lieber selbst” zitiert. Das greift zu kurz. Dieselben Mechanismen, unterschätzte Gesamtkosten und unterschätzter Aufwand für die eigentliche Einführung, gelten für selbst gebaute Tools genauso, nur dass hier niemand eine Rechnung schreibt, die die tatsächlichen Kosten sichtbar macht. Ein mit KI in einem Wochenende gebautes internes Tool erzeugt Wartungsaufwand, der einfach nicht auf einer Rechnung auftaucht, sondern sich über Monate in der Zeit des Teams versteckt. Das haben wir in der Praxis oft gesehen, etwa bei Kund:innen, deren Regalware-Software zwar gekauft, aber nie eingeführt wurde. Wir haben das in einem eigenen Beitrag zu ungenutzter Software mit konkreten Adoptionszahlen aufgearbeitet: Das Problem ist strukturell dasselbe, ob gekauft oder selbst gebaut.

Wo klassisches Einkaufen weiterhin die bessere Wahl ist

Nicht jedes System eignet sich für Stufe 2 oder 3. Der Unterschied liegt in der Standardisierbarkeit der Daten:

• CRMs sind gut ersetzbar. Die Datenstrukturen sind vergleichsweise einfach und branchenübergreifend ähnlich, viele Standardfunktionen werden ohnehin selten genutzt, aber mitbezahlt. Hier lohnt sich Stufe 1 (Automatisierung obendrauf) oder ein selbst gebautes, schlankes Ersatzsystem oft schneller als gedacht.
• ERPs sind es meist nicht. Komplexe, branchenspezifische Logik, viele Schnittstellen und jahrzehntelang gewachsenes Nischenwissen stecken in etablierten ERP-Systemen. Hier gegen einen etablierten Anbieter anzutreten, ist selten die beste Nutzung von Entwicklungsbudget, außer ein einzelner Teilprozess ist wirklich einzigartig (dann: Stufe 2, nicht Stufe 3).

Diese Abwägung, wann ein etabliertes System eine bessere Datenbasis liefert als ein Neubau, haben wir für einen Wärmepumpen-Betrieb aus der Handwerksbranche konkret durchgerechnet, inklusive Timeline und Funktionsumfang, im Beitrag Individualsoftware für Handwerksbetriebe.

Wie wir das bei TAISC mit Kund:innen angehen

In Projekten, bei denen wir die Build-or-Buy-Frage gemeinsam mit Kund:innen klären, läuft das in der Praxis so:

1. Potenzialanalyse vor jedem Commitment. Wir bilden den bestehenden Prozess ab, bevor eine Zeile Code geschrieben wird, und rechnen Lock-in-Risiko, laufende SaaS-Kosten über 3 Jahre und den Aufwand für Stufe 2 gegeneinander.
2. Start auf der niedrigsten sinnvollen Stufe. Wir empfehlen niemandem, direkt bei Stufe 3 anzufangen. Der Weg dorthin führt fast immer über Stufe 1 und 2, mit echten Nutzungsdaten als Entscheidungsgrundlage für den nächsten Schritt.
3. Datenhoheit von Anfang an im Vertrag, nicht als Nachgedanke. Wo Daten liegen, wer Exportrechte hat und was im Kündigungsfall passiert, klären wir vor dem ersten Sprint, nicht erst beim Anbieterwechsel.
4. Wartung eingepreist, nicht verdrängt. Ein selbst gebautes Tool ohne eingeplante Pflege ist in zwei Jahren die neue Regalware. Dazu mehr in unserem Grundlagenartikel zu KI-Agenten für Unternehmen, wo wir Governance über den reinen Bau-Moment hinaus beschreiben.

Wer die Entwicklung selbst nicht dauerhaft inhouse betreiben will oder kann, für den ist ein spezialisierter Partner wie eine KI-Agentur meist wirtschaftlicher als ein eigenes, wachsendes Entwicklerteam für ein einzelnes internes Tool.

Häufige Fragen

Häufige Fragen

Ist Selbstbau mit KI-Tools wie Lovable automatisch günstiger als SaaS?

Nicht automatisch. Die sichtbaren Baukosten sind oft niedrig, aber Wartung, Weiterentwicklung und Absicherung tauchen selten in derselben Rechnung auf. Ein mit KI gebauter Prototyp ist etwas anderes als ein produktiv betriebenes, unternehmenskritisches System.

Was ändert der EU Data Act konkret für Unternehmen, die SaaS nutzen?

Seit dem 12. September 2025 müssen Cloud- und SaaS-Anbieter den Wechsel zu einem anderen Anbieter oder zurück ins eigene System erleichtern: offene Schnittstellen, maximal zweimonatige Kündigungsfrist, höchstens 30 Tage Übergangszeit. Bis Anfang 2027 sind noch kostendeckende Wechselgebühren erlaubt, danach müssen reguläre Wechsel komplett gebührenfrei sein.

Wann lohnt sich Stufe 3, also der komplette Eigenbau?

Nur wenn Prozess, Kund:innen oder Branche so individuell sind, dass am Markt keine passende Lösung existiert und der Prozess groß genug ist, um laufende Entwicklungs- und Pflegekosten zu rechtfertigen. Für die meisten Standardprozesse (CRM, Buchhaltung, Standard-ERP-Funktionen) ist das selten der Fall.

Hilft TAISC auch bei der Potenzialanalyse, wenn am Ende vielleicht eine SaaS-Lösung die bessere Wahl ist?

Ja, ausdrücklich. Unsere Empfehlung richtet sich nach dem, was für dein Unternehmen am Ende wirtschaftlich und datenschutzrechtlich sinnvoll ist, nicht danach, was für uns als Entwicklungspartner am meisten Auftragsvolumen bedeutet. Manchmal ist das Ergebnis der Analyse: Stufe 1 reicht völlig aus.

Fazit

Build or Buy ist 2026 keine einmalige Architekturentscheidung mehr, sondern eine Frage, die mit steigenden SaaS-Preisen, dem EU Data Act und wachsendem Bewusstsein für Datenhoheit im Mittelstand regelmäßig neu gestellt werden sollte. Das Stufenmodell aus Erweitern, Teilbau und Vollbau verhindert die beiden teuersten Fehler: zu früh alles selbst bauen und ein Wartungsproblem erzeugen, das nie eingepreist wurde, oder zu lange auf einer SaaS-Lösung verharren, die den Prozess nie richtig abbildet und über Jahre Lock-in-Kosten anhäuft.

Unsicher, auf welcher Stufe dein nächstes Projekt starten sollte? Buche ein unverbindliches Erstgespräch, wir rechnen gemeinsam durch, was sich für euren Prozess wirklich lohnt.