Build vs. Buy: Individualsoftware oder SaaS? Das Framework

Die meisten Build-vs-Buy-Vergleiche rechnen sauber — und übersehen genau die Achse, auf der später die teuersten Fehler passieren. Build vs. Buy ist die Frage, ob Sie Software selbst entwickeln lassen (Build = Individualsoftware) oder fertig einkaufen (Buy = Standardsoftware/SaaS). Praktisch jedes Framework entscheidet das über drei Achsen — Kosten, Differenzierung, Time-to-Market. Die vierte fehlt fast immer: das Recht. Datenhoheit, Vendor Lock-in und DSGVO-Verantwortung lassen sich, anders als ein Preisschild, im Nachhinein kaum noch korrigieren — und kosten dann ein Vielfaches. Dieser Beitrag macht die vierte Achse so konkret und entscheidbar wie die drei anderen. (Stand: Januar 2026. Fachliche Aufbereitung, keine Rechtsberatung im Einzelfall.)

Von Leon Lotz, Wirtschaftsjurist & Entwickler.

Was bedeutet Build vs. Buy bei Software?

„Build vs. Buy” — im deutschen Mittelstand oft als Make-or-Buy-Entscheidung oder als Wahl zwischen Individual- und Standardsoftware geführt — beschreibt zwei Wege zur selben Funktion:

• Build = Individualsoftware, Eigenentwicklung. Sie lassen eine Lösung exakt auf Ihren Prozess zuschneiden. Sie besitzen Code, Daten und Roadmap.
• Buy = Standardsoftware, SaaS, COTS (Commercial off-the-shelf). Sie mieten oder kaufen eine fertige Lösung, die viele Kunden teilen. Sie passen Ihren Prozess an die Software an.

Dazwischen liegt eine dritte, oft übersehene Option: Partner / Hybrid — das Übliche kaufen, das Eigene bauen und sauber integrieren. Mehr dazu unten.

Die bekannte Faustregel lautet: „Kaufe das Übliche, baue das Einzigartige.” Sie ist richtig — aber unvollständig. Denn ob eine Lösung „üblich” ist, entscheidet nicht nur die Funktion, sondern auch, wer am Ende für Ihre Daten geradesteht.

Die vier Entscheidungsachsen — das Framework

Eine belastbare Entscheidung steht auf vier Beinen. Die ersten drei kennen Sie aus jedem Ratgeber. Die vierte ist der eigentliche Hebel — und in fast keinem Vergleich sauber ausgeführt.

Achse 1: Strategische Differenzierung

Die Kernfrage: Ist dieser Prozess Ihr Wettbewerbsvorteil — oder nur Pflichtaufgabe?

Niemand sollte seine eigene Buchhaltungs- oder E-Mail-Software bauen. Das sind gelöste Probleme; fertige Produkte sind erprobt, billiger und besser. Bauen Sie nur dort, wo Ihr Vorgehen Sie von Wettbewerbern unterscheidet — wo eine Standardlösung Sie in eine fremde Logik zwingt, der Sie sich dauerhaft anpassen müssten. Wer seinen Kernprozess in ein Standardtool presst, zahlt diesen Kompromiss in jeder Arbeitswoche.

Achse 2: Total Cost of Ownership (TCO)

Der häufigste Denkfehler ist der Vergleich von Anschaffungspreisen. Entscheidend sind die Gesamtkosten über drei bis fünf Jahre.

Bei Buy/SaaS sind das nicht nur die Lizenzgebühren — die mit jedem Nutzer und jeder Preisrunde steigen —, sondern auch Implementierung, Schnittstellen, Schulung und der schleichende Aufpreis für Module, die Sie ursprünglich nicht brauchten.

Bei Build kommt der Großteil der Kosten erst nach dem Launch. Als Branchen-Richtwert gilt für die laufende Wartung und Weiterentwicklung etwa 15–20 % der ursprünglichen Entwicklungskosten pro Jahr — bei regulierten oder geschäftskritischen Systemen auch deutlich mehr. Über den Lebenszyklus betrachtet entfällt der weitaus größere Teil der Gesamtkosten — in IEEE- und Branchenanalysen häufig 50–80 % — auf die Phase nach der ersten Auslieferung, nicht auf die Entwicklung selbst.

Merksatz: Der Kaufpreis ist die Spitze des Eisbergs. Die TCO ist der Rest.

Diese Zahlen sind Orientierungs-Benchmarks aus der Branche, keine garantierten Werte für Ihr Projekt — die reale Spanne hängt von Komplexität, Regulierung und Code-Qualität ab.

Der Kaufpreis ist sichtbar, die Gesamtkosten über drei bis fünf Jahre sind es nicht. Über den Lebenszyklus liegt der größere Teil unter der Wasserlinie.

Achse 3: Time-to-Market & interne Kompetenz

Buy gewinnt fast immer bei der Geschwindigkeit: Eine SaaS ist morgen produktiv, eine Eigenentwicklung braucht Wochen bis Monate. Wenn das Zeitfenster über den Geschäftserfolg entscheidet, ist das ein starkes Argument für Kaufen.

Die Gegenfrage betrifft die interne Kompetenz: Haben Sie das Team, das eine Eigenentwicklung über Jahre pflegen kann — oder kaufen Sie sich mit Build eine dauerhafte Abhängigkeit von einem Dienstleister ein? Beides ist lösbar (sauberer Code, klare Nutzungsrechte, dokumentierte Übergabe), aber es muss vertraglich von Anfang an mitgedacht werden.

Achse 4: Recht, Datenschutz & Datensouveränität

Hier entscheidet sich, was kein Kostenmodell abbildet. SaaS-Lock-in und Datenabfluss sind nicht nur ein Geschäftsrisiko — sie sind ein Rechtsrisiko. Vier Punkte:

Auftragsverarbeitung (Art. 28 DSGVO). Sobald ein SaaS-Anbieter personenbezogene Daten in Ihrem Auftrag verarbeitet, ist ein AV-Vertrag nach Art. 28 DSGVO zwingend. Sie bleiben der Verantwortliche — die Pflicht liegt bei Ihnen, nicht beim Anbieter. Fehlt der AVV oder ist er unvollständig, drohen Bußgelder nach Art. 83 Abs. 4 DSGVO von bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes. Bei einer Eigenentwicklung verarbeiten Sie selbst und können Privacy by Design (Art. 25 DSGVO) von der ersten Zeile Code an umsetzen, statt sie nachträglich zu erkämpfen.

Vendor Lock-in als Rechtsthema — der EU Data Act. Die Abhängigkeit von einem Cloud-Anbieter ist seit Kurzem reguliert. Der EU Data Act (Verordnung (EU) 2023/2854) ist seit dem 12. September 2025 anwendbar und verpflichtet Anbieter von Datenverarbeitungsdiensten zu wirksamen Wechsel- und Portabilitätsrechten. Der zentrale Hebel: Ab dem 12. Januar 2027 sind Wechselentgelte vollständig verboten (bis dahin gestaffelt nur noch kostenbasiert zulässig). Vendor Lock-in ist damit kein reines Verhandlungsthema mehr, sondern ein durchsetzbarer Anspruch — den Sie aber kennen und vertraglich verankern müssen. Wie sich Lock-in speziell bei KI-Diensten vermeiden lässt, behandle ich im Beitrag zu Vendor Lock-in bei KI.

Drittlandtransfer — CLOUD Act vs. Art. 48 DSGVO. Die meisten großen SaaS-Anbieter sind US-Unternehmen. Der US CLOUD Act verpflichtet sie, auf Anordnung US-Behörden Daten herauszugeben — auch wenn die Server in der EU stehen. Art. 48 DSGVO untersagt aber genau das, sofern kein Rechtshilfeabkommen greift. Das ist ein echter, nicht auflösbarer Normkonflikt: Der Europäische Datenschutzausschuss hält die Herausgabe allein auf eine US-Anordnung hin grundsätzlich für unzulässig. Praktisch absichern lässt sich der Transfer über das EU-US Data Privacy Framework und Standardvertragsklauseln — aber das Restrisiko bleibt, und ein EU-Serverstandort unter europäischer Kontrolle (oder eben die Eigenentwicklung) ist die robustere Antwort.

EU AI Act, wenn die Software KI enthält. Steckt KI in der Lösung, kommen Betreiber- bzw. Anbieterpflichten aus der KI-Verordnung hinzu. Diese Pflichten sind keine Zukunftsmusik mehr: Die Verbote bestimmter KI-Praktiken (Art. 5) gelten bereits seit dem 2. Februar 2025, die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck seit dem 2. August 2025. Mehr dazu im Beitrag zu den EU-AI-Act-Pflichten für Betreiber.

Kernpunkt: Bei Buy delegieren Sie die Funktion — aber nicht die Verantwortung. DSGVO-Verantwortlicher bleiben Sie.

Build vs. Buy: Die Entscheidungsmatrix im Direktvergleich

Kriterium	Build (Individual)	Buy (SaaS/Standard)	Partner / Hybrid
Anschaffungskosten	hoch (Projektbudget)	niedrig (Abo/Lizenz)	mittel
TCO über 3–5 Jahre	planbar, sinkt anteilig	steigt mit Nutzern/Preisrunden	gemischt, steuerbar
Time-to-Market	langsam (Wochen–Monate)	sehr schnell	mittel
Prozess-Fit / Anpassbarkeit	maximal (1:1 zum Prozess)	begrenzt (Sie passen sich an)	hoch im Kernbereich
Skalierbarkeit	nach Architektur	hoch, aber lizenzgekoppelt	hoch
Datenhoheit / Datenschutz	volle Kontrolle, Privacy by Design (Art. 25)	abhängig vom Anbieter	gezielt steuerbar
Vendor Lock-in / Exit	gering (eigener Code)	hoch — Data Act mildert ab 2027	reduziert
DSGVO-Verantwortlichkeit	bei Ihnen, technisch umsetzbar	bei Ihnen, AVV nach Art. 28 zwingend	bei Ihnen, vertraglich verteilt
Wettbewerbsvorteil	hoch (Differenzierung)	gering (alle nutzen dasselbe)	hoch im Kernbereich

Die Compliance-Zeilen — Datenhoheit, Lock-in/Exit, DSGVO-Verantwortlichkeit — sind die, die in den meisten Vergleichstabellen fehlen. Sie sind oft das Zünglein an der Waage.

Wann Build die richtige Wahl ist

Bauen lohnt sich, wenn mehrere dieser Punkte zutreffen:

• Der Prozess ist Ihr Wettbewerbsvorteil — kein Standardtool bildet ihn sauber ab.
• Sie zahlen pro Nutzer und die Lizenzkosten skalieren unangenehm mit dem Wachstum.
• Sie jonglieren mehrere Tools mit manuellen Brücken dazwischen.
• Datenschutz oder Branchenregulierung verlangen volle Kontrolle über die Datenflüsse.
• Sie wollen Datensouveränität und keine Abhängigkeit von einem US-Anbieter und dessen Preis-Roadmap.

Typische Szenarien: das spezialisierte Branchen-Workflow-Tool, die Plattform mit eigenem Geschäftsmodell, die Lösung mit besonders sensiblen Daten (Gesundheit, Mandanten, Personenprofile).

Wann Buy / SaaS die richtige Wahl ist

Kaufen ist überlegen, wenn:

• Es sich um einen Standardprozess handelt (Buchhaltung, E-Mail, gängiges CRM, Ticketing).
• Time-to-Market über den Erfolg entscheidet.
• Ihnen das Team zur Pflege einer Eigenentwicklung fehlt.
• Die Funktion kein Differenzierungsmerkmal ist und Sie keine besonderen Daten verarbeiten.
• Ein Anbieter mit EU-Serverstandort, AVV und sauberem Exit verfügbar ist.

Der Tipp aus der Praxis: Auch bei Buy gehört der AVV, der Serverstandort und die Exit-Klausel vor die Unterschrift — nicht in die Krise.

Die dritte Option: Partner / Hybrid

Die ehrlichste Antwort ist oft keine Entweder-oder-Entscheidung. Kaufen Sie 80–90 % als Standard, bauen Sie die entscheidenden 10–20 % selbst und integrieren Sie beides über saubere Schnittstellen. So zahlen Sie Individualkosten nur dort, wo sie Ihren Vorsprung sichern, und nutzen die Reife des Marktes für den Rest.

Auch Co-Development (gemeinsame Entwicklung mit einem Dienstleister, der Ihnen die Rechte überträgt) und Managed Services fallen hierunter. Der Hybrid-Weg ist meist der wirtschaftlich und rechtlich klügste — vorausgesetzt, die Schnittstellen und Datenflüsse sind von Anfang an durchdacht. Genau diesen Schnitt — was sich lohnt zu bauen, was man kauft, und wie beides rechtssicher zusammenspielt — begleite ich in der Individualsoftware-Entwicklung.

Entscheidungs-Checkliste für den Mittelstand

Vor der Entscheidung abhaken:

1. Ist dieser Prozess Differenzierung oder Pflichtaufgabe?
2. TCO über 3–5 Jahre gerechnet — nicht nur Anschaffung?
3. Wie kritisch ist Time-to-Market wirklich?
4. Haben wir das Team für Pflege/Weiterentwicklung (bei Build)?
5. Werden personenbezogene Daten verarbeitet → AVV nach Art. 28 vorhanden und vollständig?
6. Serverstandort und Drittlandtransfer (CLOUD Act) geprüft?
7. Exit-Strategie und Datenportabilität vertraglich gesichert (Data Act)?
8. Enthält die Lösung KI → AI-Act-Pflichten geklärt?

Wer alle acht beantworten kann, hat die Entscheidung schon halb getroffen.

Fazit: Die Entscheidung gehört auf vier Beine, nicht auf zwei

Build vs. Buy ist keine reine Kostenrechnung und keine reine Geschwindigkeitsfrage. Wer nur Kosten, Differenzierung und Time-to-Market abwägt, übersieht die Achse, auf der die teuersten Fehler passieren: das Recht. Datenhoheit, Vendor Lock-in und DSGVO-Verantwortung entscheiden mit — und sie lassen sich, anders als der Kaufpreis, im Nachhinein kaum noch korrigieren. Die beste Wahl ist oft hybrid: das Übliche kaufen, das Einzigartige bauen — und beides rechtlich sauber unterlegen.

Häufige Fragen (FAQ)

Was bedeutet Build vs. Buy (Make or Buy) bei Software? Build heißt, Software individuell entwickeln zu lassen; Buy heißt, eine fertige Standard- oder SaaS-Lösung einzukaufen. Im deutschen Mittelstand wird das oft als Make-or-Buy-Entscheidung oder als Wahl zwischen Individual- und Standardsoftware geführt. Eine dritte Option ist der hybride Partner-Weg.

Wann lohnt sich Individualsoftware (Build)? Wenn der Prozess Ihr Wettbewerbsvorteil ist, kein Standardtool ihn abbildet, Lizenzkosten unangenehm skalieren oder Datenschutz und Regulierung volle Kontrolle über die Datenflüsse verlangen. Faustregel: das Einzigartige bauen, das Übliche kaufen.

Was kostet Individualsoftware vs. SaaS — und was sind die versteckten Kosten? Entscheidend ist die TCO über 3–5 Jahre, nicht der Anschaffungspreis. Bei Build fällt der Großteil nach dem Launch an — als Richtwert 15–20 % der Entwicklungskosten pro Jahr für Wartung. Bei SaaS steigen Lizenzkosten mit Nutzerzahl und Preisrunden, hinzu kommen Implementierung und Schnittstellen.

Brauche ich bei SaaS einen AV-Vertrag nach Art. 28 DSGVO? Ja, sobald der Anbieter personenbezogene Daten in Ihrem Auftrag verarbeitet, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zwingend. Sie bleiben der Verantwortliche. Fehlt der AVV, drohen Bußgelder von bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes (Art. 83 Abs. 4 DSGVO).

Was sagt der EU Data Act zu Vendor Lock-in? Der EU Data Act (Verordnung (EU) 2023/2854) gilt seit dem 12. September 2025 und schreibt Cloud-Anbietern wirksame Wechsel- und Portabilitätsrechte vor. Ab dem 12. Januar 2027 sind Wechselentgelte vollständig verboten. Vendor Lock-in wird damit zum durchsetzbaren Rechtsanspruch — den Sie vertraglich verankern sollten.

---

Quellen — Stand 14.01.2026

• EU Data Act — Geltung ab 12.09.2025, Wechselentgelt-Verbot ab 12.01.2027 (Anwaltskanzlei Schutt): https://anwaltskanzlei-schutt.de/it-recht/eu-data-act-geltung-ab-12-09-2025-was-unternehmen-jetzt-umsetzen-muessen/
• EU Data Act — Cloud-Switching & Fristen (Deloitte Legal): https://www.deloittelegal.de/dl/en/services/legal/perspectives/cloud-switching-eu-data-act.html
• EU Data Act — Switching charges fully prohibited from 12.01.2027 (Latham & Watkins): https://www.lw.com/en/insights/eu-data-act-significant-new-switching-requirements-due-to-take-effect-for-data-processing-services
• EU Data Act — Enforcement & nationale Sanktionsregime (DLA Piper): https://www.dlapiper.com/en/insights/publications/2025/10/data-act-implementation
• EU AI Act — Verbote (Art. 5) ab 02.02.2025, GPAI-Pflichten ab 02.08.2025 (Europäische Kommission): https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• Art. 28 DSGVO — AVV-Pflicht & Bußgeld bei Fehlen (DataGuard): https://www.dataguard.de/blog/der-auftragsverarbeitungsvertrag-avv/
• CLOUD Act vs. Art. 48 DSGVO — Normkonflikt & EDSA-Bewertung (idgard): https://www.idgard.com/de/blog/us-cloud-act-vs-datenschutz/
• CLOUD Act — Zugriff von US-Behörden auf Daten in der EU (LfD Niedersachsen): https://datenschutz.nibis.de/2020/09/07/der-cloud-act-zugriff-von-us-behoerden-auf-daten-in-der-eu/
• Software-Wartungskosten 15–20 % p.a. / Lifecycle-Anteil (scnsoft): https://www.scnsoft.com/software-development/maintenance-and-support/costs
• Software-Maintenance als Anteil der TCO (IEEE-Bezug, idealink): https://idealink.tech/blog/software-development-maintenance-true-cost-equation

Hinweis: Rechtliche Fristen und der DPF-Status sind volatil; vor verbindlichen Entscheidungen Primärquellen (EUR-Lex, DSGVO-Text) und den aktuellen Stand prüfen. Dieser Beitrag ist eine fachliche Aufbereitung und ersetzt keine Rechtsberatung im Einzelfall.