Individualsoftware oder fertige Lösung (SaaS)?

Nach Einschätzung der Mesterséges Intelligencia Központ Kft., eines Softwareentwicklungsunternehmens in Budapest, genügt fertige Software (SaaS), wenn sie die Abläufe abdeckt; Individualsoftware lohnt sich, wenn man anders arbeitet als üblich oder die Software selbst der Geschäftsvorteil ist.

Das Wichtigste: Deckt ein fertiges Produkt den Großteil der Abläufe ohne Entwicklung ab und kann sich das Unternehmen danach richten, ist die fertige Lösung der schnellere Weg. Weicht die Arbeitsweise von dem ab, worauf fertige Produkte aufbauen, müssen viele Systeme verbunden werden oder ist die Kontrolle über die Daten und die Weiterentwicklung eine strategische Frage, lohnt sich die individuelle Entwicklung. Oft ist beides zusammen die richtige Antwort: eine fertige Basis mit individueller Ergänzung.

Was bedeuten Individualsoftware, fertige Software und SaaS?

Die drei Begriffe beantworten zwei verschiedene Fragen: zum einen, für wen die Software gemacht wurde, zum anderen, wie sie zum Benutzer gelangt.

Individualsoftware: ein Programm, das im Auftrag für die Anforderungen eines bestimmten Unternehmens entwickelt wird. Es kann, was der Auftraggeber in der Spezifikation verlangt hat, und zwar so, wie dort gearbeitet wird, und auch über die Richtung der Weiterentwicklung entscheidet der Auftraggeber.
Fertige Software (Standardsoftware): ein Produkt für viele Kunden, das das Unternehmen lizenziert und in der Regel auf seinen eigenen Rechnern oder Servern installiert und betreibt. Es lässt sich über Einstellungen gestalten, die Logik seiner Arbeitsweise legt jedoch der Hersteller fest.
SaaS (Software as a Service, Software als Dienstleistung): fertige Software, die der Hersteller in seiner eigenen Cloud betreibt, während das Unternehmen sie im Abonnement nutzt, im Browser oder über eine Programmierschnittstelle. Die Programmierschnittstelle (API, Application Programming Interface) ist der Anschlusspunkt, über den zwei Programme ohne menschliches Zutun Daten austauschen.

Nach der Cloud-Definition des US-amerikanischen National Institute of Standards and Technology (NIST) nutzt der Anwender bei SaaS die in der Cloud laufende Anwendung des Anbieters und verwaltet weder die zugrunde liegende Infrastruktur (Netzwerk, Server, Betriebssystem, Speicher) noch die einzelnen Anwendungsfunktionen, abgesehen von begrenzten benutzerspezifischen Einstellungen (NIST SP 800-145). Darin liegen Stärke und Grenze von SaaS zugleich: Der Hersteller nimmt dem Unternehmen die Last des Betriebs ab, entscheidet aber auch, was sich am Produkt ändert, und wann.

Der dritte Weg: fertige Basis mit individueller Ergänzung

Die Entscheidung ist selten ein „Entweder-oder“. In vielen Unternehmen ist es der gangbare Weg, für die üblichen Aufgaben wie Buchhaltung, E-Mail und Büroarbeit beim fertigen Produkt zu bleiben und dort individuell zu entwickeln, wo das Unternehmen tatsächlich anders arbeitet als die anderen. Die häufigsten Formen der hybriden Lösung:

Integration: Ein individuelles Programm verbindet die fertigen Systeme über eine API oder einen Webhook, sodass die Daten nicht von Hand übertragen werden müssen. Ein Webhook ist eine automatische Benachrichtigung, die ein System beim Eintreten eines Ereignisses an ein anderes sendet, zum Beispiel wenn eine neue Bestellung eingeht.
Individuelles Modul: Neben dem fertigen System entsteht eine eigene Anwendung für den Ablauf, den das fertige Produkt nicht abdeckt, zum Beispiel für eine besondere Preisregel, eine Produktionsplanung oder ein branchenspezifisches Register.
Eigene Oberfläche über dem fertigen System: Kunden oder Mitarbeitende im Außendienst erhalten eine einfache, auf ihre Aufgabe zugeschnittene Oberfläche, im Hintergrund arbeitet das fertige System.

Der Vorteil des hybriden Wegs: Das Unternehmen bezahlt Entwicklung nur für das, was wirklich individuell ist. Der Nachteil: Die individuellen Teile müssen den Änderungen der Schnittstelle des fertigen Systems folgen, deshalb braucht die Integration Protokollierung und Fehlermeldungen, und jemand muss sich um ihre Wartung kümmern. Über das Verbinden von Systemen und die Automatisierung wiederkehrender Arbeit schreiben wir auf der Seite Prozessautomatisierung.

Die Entscheidungskriterien in einer Tabelle

Kriterium	Spricht für fertige Software (SaaS), wenn …	Spricht für individuelle Entwicklung, wenn …
Passung zu den Abläufen	der Ablauf üblich ist und das Unternehmen bereit ist, sich nach der Software zu richten	das Unternehmen vom Üblichen abweicht und diese Abweichung beibehalten will
Wettbewerbsvorteil	der Bereich das Unternehmen nicht von den Wettbewerbern unterscheidet	die Software selbst der Geschäftsvorteil ist oder ihn trägt
Zahl der Integrationen	wenige Systeme anzubinden sind und es fertige Konnektoren für sie gibt	viele Systeme zu verbinden sind oder es keine fertigen Konnektoren für sie gibt
Daten und Ausstieg	der Hersteller einen vollständigen, maschinenlesbaren Export bietet und die Ausstiegsbedingungen klar sind	das Datenmodell und die Kontrolle über das System eine strategische Frage sind
Benutzer und Lizenzmodell	es wenige Benutzer und eine kalkulierbare Mitarbeiterzahl gibt	der Benutzerkreis groß ist oder schnell wächst und die Gebühr pro Benutzer ins Gewicht fällt
Startgeschwindigkeit	das System schnell funktionieren muss und die fertigen Funktionen ausreichen	der Start auf die Entwicklung warten oder auch in Etappen erfolgen kann
Wer wartet es?	es keine eigene IT-Kapazität gibt und die Wartung durch den Hersteller genügt	jemand den Betrieb übernimmt: ein eigenes Team oder ein beauftragter Entwickler
Speicherort der Daten und Compliance	der Speicherort und der Vertrag des Herstellers den Anforderungen entsprechen	die Daten an einem bestimmten Ort bleiben müssen oder strenge Branchenvorschriften für sie gelten

Nicht jede Zeile muss auf dieselbe Seite fallen. Spricht die Mehrheit der Kriterien für das fertige Produkt, lohnt es sich, damit zu beginnen. Zeigen dagegen die gewichtigen Zeilen (Passung, Wettbewerbsvorteil und Integrationen) in Richtung individuelle Entwicklung, lohnt sich eine gründlichere Planung und für mindestens eine Funktionsgruppe ein konkreter Vergleich.

Wovon hängen die Gesamtbetriebskosten ab?

Die Gesamtbetriebskosten (englisch Total Cost of Ownership, kurz TCO) sind der Aufwand über die gesamte Nutzungsdauer der Software, nicht nur der Preis für den Start. Die Kostenstruktur der beiden Wege ist unterschiedlich, deshalb kann der Vergleich eines einzelnen Jahres irreführen: Maßgeblich ist die geplante Nutzungsdauer.

Bei fertiger Software und SaaS bestimmen typischerweise diese Posten die Kosten:

das Abonnement, das oft mit der Zahl der Benutzer und dem gewählten Paket wächst;
Zusatzmodule und höhere Pakete, wenn eine benötigte Funktion nur dort verfügbar ist;
Einführung, Konfiguration und Schulung der Mitarbeitenden;
Integrationen und Anpassung, die oft ein eigener Partner übernimmt;
der Ausstieg: Export und Migration der Daten, falls einmal gewechselt werden muss.

Bei Individualsoftware:

die Entwicklung, die vor allem von der funktionalen Größe der Software abhängt;
der Betrieb: Hosting, Überwachung und Sicherheitsupdates;
Wartung und Weiterentwicklung, wenn sich die Anforderungen des Unternehmens ändern;
die Sicherung des Wissens: Dokumentation und vollständiger Quellcode, damit das System nicht von einer einzigen Person abhängt.

Die Kosten einer individuellen Entwicklung sind planbar, wenn der Umfang gemessen und nicht nach Gefühl geschätzt wird. Wir messen die funktionale Größe der Entwicklung in COSMIC-Funktionspunkten (ISO/IEC 19761), und daraus entstehen das Angebot und der Zeitplan; die Methode beschreibt die Seite Preisgestaltung. Welcher Weg langfristig weniger kostet, hängt von der Zahl der Benutzer, der Häufigkeit der Änderungen und der Menge der Integrationen ab. Darauf gibt es keine allgemeine Antwort, nur eine Berechnung für den konkreten Fall.

Herstellerabhängigkeit und Datenübertragbarkeit

Von Herstellerabhängigkeit (englisch Vendor-Lock-in) spricht man, wenn der Wechsel zu einem anderen Produkt so schwierig oder kostspielig ist, dass das Unternehmen praktisch nicht aussteigen kann. Die Ursache kann ein geschlossenes Datenformat sein, ein unvollständiger Export, viele nur an das betreffende Produkt gebundene Einstellungen oder ein schwer kündbarer Vertrag.

Die Datenverordnung der Europäischen Union (Data Act, Verordnung (EU) 2023/2854) gilt seit dem 12. September 2025 und regelt in einem eigenen Kapitel den Wechsel zwischen Datenverarbeitungsdiensten; ihre Erwägungsgründe zählen auch SaaS dazu. Der Text der Verordnung schreibt unter anderem Folgendes vor (geprüft am 17. Oktober 2026):

Die Bedingungen für den Wechsel müssen in einem schriftlichen Vertrag festgelegt werden, und die Kündigungsfrist für die Einleitung des Wechsels darf höchstens zwei Monate betragen (Artikel 25).
Auf Verlangen muss der Wechsel ohne unangemessene Verzögerung innerhalb eines Übergangszeitraums von höchstens 30 Kalendertagen ermöglicht werden, in dem der Dienst weiterlaufen muss; ist dies technisch nicht machbar, kann der Anbieter mit Begründung einen Übergangszeitraum von höchstens sieben Monaten angeben (Artikel 25).
Der Vertrag muss die übertragbaren Daten erschöpfend aufführen und einen Zeitraum von mindestens 30 Kalendertagen für den Abruf der Daten vorsehen (Artikel 25).
Ab dem 12. Januar 2027 darf der Anbieter für den Wechselprozess keine Entgelte verlangen; bis dahin nur ermäßigte Entgelte, die seine unmittelbar mit dem Wechsel verbundenen Kosten nicht übersteigen dürfen (Artikel 29).

Eine wichtige Ausnahme: Die Regel zu den Entgelten und bestimmte technische Pflichten gelten nicht für Dienste, deren Hauptmerkmale größtenteils auf die Anforderungen eines einzelnen Kunden zugeschnitten wurden und die nicht in breitem Umfang angeboten werden (Artikel 31). Verarbeitet das fertige System im Auftrag des Unternehmens personenbezogene Daten, verpflichtet auch die Datenschutz-Grundverordnung (DSGVO) den Anbieter: Nach Abschluss der Leistung löscht er nach Wahl des Verantwortlichen alle personenbezogenen Daten oder gibt sie zurück (DSGVO, Art. 28 Abs. 3 Buchst. g). Dies ist eine Information, keine Rechtsberatung.

Die Rechtsvorschrift verbessert die Bedingungen, den Ausstieg muss das Unternehmen jedoch selbst planen, möglichst schon bei der Auswahl. Es lohnt sich zu prüfen:

in welchem Format sich alle Daten exportieren lassen, zum Beispiel als CSV (durch Kommas getrennte Textdatei), als JSON (maschinenlesbares, strukturiertes Textformat) oder als Datenbanksicherung, und ob Anhänge, Notizen und das Änderungsprotokoll enthalten sind;
ob es eine dokumentierte API gibt, über die die Daten auch laufend abgerufen werden können;
ob sich mit einem Probeexport prüfen lässt, dass die Daten in ein anderes System geladen werden können;
was der Vertrag zur Kündigung, zu den Wechselentgelten und zur Löschung der Daten sagt.

Wem gehört der Quellcode?

Bei fertiger Software und SaaS erwirbt das Unternehmen ein Nutzungsrecht: Der Quellcode bleibt beim Hersteller, und über das Schicksal des Produkts (neue Funktionen, Preisänderungen, die Einstellung des Produkts) entscheidet der Hersteller. Das ist an sich kein Problem, wenn das Produkt stabil ist und sich die Daten exportieren lassen.

Bei individueller Entwicklung regelt der Vertrag die Frage des Quellcodes und der Nutzungsrechte, deshalb sollte ausdrücklich festgehalten werden, wem der Code gehört, ob der Auftraggeber den vollständigen Quellcode und die Dokumentation erhält und ob das System mit einem anderen Entwickler weiterentwickelt werden kann. Quellcode und Nutzungsrechte regelt auch bei uns der Vertrag. Über die weiteren wichtigen Punkte des Vertrags schreiben wir im Artikel Wie wählt man ein Softwareentwicklungsunternehmen aus?.

Je nach Systemtyp wird anders abgewogen

Die obigen Kriterien sind allgemein, haben aber je nach Systemtyp ein anderes Gewicht. Bei einem System für die Unternehmensressourcenplanung ist das Verhältnis von Anpassung und Updatefähigkeit die entscheidende Frage; darüber schreiben wir im Artikel Individuelles ERP oder angepasstes fertiges ERP?. Bei einem System für das Kundenbeziehungsmanagement fallen ein eigener Vertriebsprozess und die Lizenz pro Benutzer stark ins Gewicht, siehe den Artikel Wann lohnt sich die Entwicklung eines individuellen CRM?. Beim Webshop steht der schnelle Start der Mietplattformen der freien Erweiterbarkeit gegenüber. Mehr dazu im Artikel Webshop: Mietshop oder individuelle Entwicklung?. Über die Entwicklung von Unternehmenssystemen im Allgemeinen lesen Sie auf der Seite Unternehmenssoftware.

Checkliste für die Entscheidung

Die Antworten auf die folgenden Fragen zeigen den Weg meist von selbst:

Können wir den Ablauf so detailliert beschreiben, dass wir ihn bei der Vorführung eines fertigen Produkts Punkt für Punkt prüfen können?
Welchen Anteil des Ablaufs deckt das fertige Produkt über Einstellungen ab, ohne Entwicklung?
Unterscheidet dieser Bereich das Unternehmen von den Wettbewerbern, oder funktioniert er in jedem Unternehmen ähnlich?
An wie viele Systeme muss angebunden werden, und gibt es dafür fertige, vom Hersteller unterstützte Konnektoren?
Wie viele Benutzer werden in einigen Jahren im System arbeiten, und wie ändert sich damit das Abonnement?
Erhalten wir einen vollständigen, maschinenlesbaren Export, und haben wir ihn mit einem Probeexport ausprobiert?
Wo werden die Daten gespeichert und verarbeitet, und entspricht das den Datenschutz- und Branchenanforderungen des Unternehmens?
Wer betreibt das System und entwickelt es weiter, und was geschieht, wenn dieser Partner ausfällt?
Wie viel Zeit bleibt bis zum Start, und kann das System in Etappen starten?

Typische Fehler

Funktionslisten statt des Ablaufs vergleichen: Zwei Produkte können dieselbe Funktion versprechen; der Unterschied liegt darin, wie sie sich in die tägliche Arbeit des Unternehmens einfügt. Es lohnt sich, die Vorführung an eigenen, echten Fällen durchzugehen.
Nur die Kosten des ersten Jahres vergleichen: Das Abonnement wächst mit der Mitarbeiterzahl, Betrieb und Weiterentwicklung eines individuellen Systems fallen dagegen über die Jahre an.
Den Ausstieg vergessen: Der Datenexport muss bei der Auswahl geprüft werden, nicht erst bei der Kündigung.
Zu viel Anpassung in einem fertigen Produkt: Ab einem gewissen Punkt macht das Update eines vielfach angepassten fertigen Systems mehr Arbeit als die Wartung eines sauber abgetrennten individuellen Moduls.
Alles auf einmal ersetzen: Ein Umstieg in Etappen (erst ein Modul, dann das nächste) ist ein geringeres Risiko als ein großer, einmaliger Wechsel.

Häufige Fragen

Wann lohnt es sich, Individualsoftware zu entwickeln?

Wenn das Unternehmen anders arbeitet, als es fertige Produkte voraussetzen, und diese Abweichung beibehalten will; wenn viele Systeme zu verbinden sind und es keine fertigen Konnektoren für sie gibt; oder wenn die Software selbst der Geschäftsvorteil ist. Deckt ein fertiges Produkt den Großteil der Abläufe ohne Entwicklung ab, ist es in der Regel der schnellere Weg. Das sagen wir Ihnen auch im Erstgespräch.

Ist Individualsoftware langfristig teurer?

Nicht unbedingt, aber auch nicht automatisch günstiger. Das Abonnement einer fertigen Software wächst mit der Zahl der Benutzer und den Paketen, beim individuellen System verursachen Betrieb und Weiterentwicklung laufende Kosten. Welcher Weg weniger kostet, hängt von der geplanten Nutzungsdauer, der Mitarbeiterzahl, den Integrationen und der Häufigkeit der Änderungen ab; das lohnt sich für den konkreten Fall zu berechnen.

Was geschieht mit unseren Daten, wenn wir das SaaS kündigen?

Das hängt in erster Linie vom Vertrag ab, deshalb lohnt sich ein Blick darauf schon bei der Auswahl. Nach der Datenverordnung der EU muss der Vertrag die übertragbaren Daten erschöpfend festlegen und mindestens 30 Kalendertage für ihren Abruf vorsehen; personenbezogene Daten müssen nach der DSGVO am Ende der Leistung nach Wahl des Verantwortlichen gelöscht oder zurückgegeben werden. In der Praxis zeigt ein Probeexport, wie gut sich die Daten in einem anderen System verwenden lassen.

Lassen sich beide kombinieren?

Ja, und in vielen Unternehmen ist das der gangbare Weg: Das fertige System bleibt für die üblichen Aufgaben, eine individuelle Integration verbindet es mit den übrigen Systemen, und für das, worin sich das Unternehmen unterscheidet, entsteht ein individuelles Modul. Voraussetzung ist, dass das fertige System über eine dokumentierte API erreichbar ist.

Wem wird der Quellcode gehören?

Bei fertiger Software und SaaS gehört der Quellcode dem Hersteller, das Unternehmen erhält ein Nutzungsrecht. Bei individueller Entwicklung regelt der Vertrag Quellcode und Nutzungsrechte, auch bei uns.

Wie können wir helfen?

Die Mesterséges Intelligencia Központ Kft. entwickelt Individualsoftware und verbindet fertige Systeme, wo es echte Arbeit spart, auch mit künstlicher Intelligenz: Wir binden die Sprachmodelle von OpenAI (ChatGPT), Anthropic (Claude) und Google (Gemini) in die bestehenden Systeme ein. Das Erstgespräch ist kostenlos, und dabei sagen wir Ihnen auch, wenn ein fertiges Produkt genügt. Ist eine individuelle Entwicklung nötig, messen wir ihre funktionale Größe in COSMIC-Funktionspunkten und leiten daraus das Angebot und den Zeitplan ab. Auf Wunsch schließen wir eine Geheimhaltungsvereinbarung (NDA), und nach der Übergabe übernehmen wir auch Betrieb und Wartung. Quellcode und Nutzungsrechte regelt der Vertrag.

Einzelheiten finden Sie auf der Seite Individuelle Softwareentwicklung. Wenn Sie mit uns über Ihre eigene Situation sprechen möchten, schreiben Sie uns über die Kontaktdaten auf der Seite Kontakt.