Individualsoftware für das Unternehmen – wann lohnt sich ein eigenes System statt SaaS?

Jedes wachsende Unternehmen stößt früher oder später auf dieselbe Frage: das nächste Abonnement für ein fertiges Werkzeug bezahlen oder Individualsoftware für das Unternehmen bauen, die genau auf die eigenen Prozesse zugeschnitten ist? Wir bei Web Systems beschäftigen uns seit 2006 mit Softwareentwicklung – Webanwendungen, B2B-Systemen und Integrationen. Wir betrachten dieses Dilemma also mit den Augen eines Dienstleisters und nicht eines Verkäufers, der nur eine richtige Option kennt. Und ich sage es klar: Die Entscheidung “build oder buy” ist selten ideologisch. Sie ist eine ganz normale Rechnung – über Kosten, über die Kontrolle über die Daten und über das Risiko, das ein Unternehmen für die nächsten Jahre auf sich nehmen will.

Individualsoftware oder SaaS – worum es bei dieser Entscheidung wirklich geht

Die Frage lautet nicht “was ist besser”. Sie lautet “was lohnt sich ausgerechnet für uns mehr”. Ein fertiges Abonnement lockt mit schnellem Start und einer vorhersehbaren Rechnung. Ein maßgeschneidertes System verspricht die volle Anpassung an die Art, wie Sie tatsächlich arbeiten. Beide Wege kosten Geld, nur verteilt sich dieses Geld anders über die Zeit und landet in anderen Töpfen.

Aus Sicht des Dienstleisters behandeln wir diese Wahl als Entscheidung über drei Dinge zugleich. Das erste sind die Kosten – aber verstanden als Summe der Ausgaben über Jahre, nicht als reine Einführungsgebühr. Das zweite ist die Kontrolle über den Prozess und die Daten. Genau darum geht es: Passt sich das Unternehmen dem Werkzeug an oder das Werkzeug dem Unternehmen? Das dritte ist das Risiko. Das Risiko der Abhängigkeit vom Anbieter, des Datenverlusts oder dessen, dass die Weiterentwicklung stehen bleibt, weil das fertige Produkt nicht mehr mithält.

Wo sieht man am häufigsten das Signal, dass eine Organisation den Standardlösungen entwachsen ist? In Tabellenkalkulationen. Überall dort, wo Menschen Exporte aus mehreren Systemen von Hand zusammenkleben, sich Umwege in Excel basteln und Prozesse auf Zetteln nachhalten, unterstützt das Werkzeug die Arbeit nicht mehr. Es erschwert sie. Und diese Umwege kosten Zeit, erzeugen Fehler und verschwinden zusammen mit der Person, die sie sich ausgedacht hat.

In den folgenden Abschnitten zeige ich konkret, wann build gegen buy gewinnt und wann ein eigenes System ein teurer Irrtum wäre. Ohne neutralen Vergleich des gesamten Marktes. Ich konzentriere mich darauf, was über den Erfolg eines Projekts wirklich entscheidet: Gesamtkosten, Architektur, Integrationen und Betrieb.

Wann SaaS völlig ausreicht (und wann build ein Fehler wäre)

Ich beginne mit einem ehrlichen Eingeständnis. In vielen Situationen ist fertiges SaaS schlicht die vernünftige Entscheidung, und wir als software house raten dann von einer Eigenentwicklung ab. Standardprozesse, die in Hunderten von Firmen ähnlich aussehen, haben längst ausgereifte Lösungen. Buchhaltung, Rechnungsstellung, Mailversand, ein einfaches CRM ohne Extrawünsche – hier hat der Markt Jahre an Arbeit hinter sich, und das mit eigenem Code zu übertreffen ist schwer.

Der Vorteil eines Abonnements ist greifbar. Start in Tagen statt in Monaten, monatliche Kosten, die sich leicht ins Budget schreiben lassen, kein eigenes Betriebsteam im Unternehmen. Aktualisierungen, Sicherungskopien, das Schließen von Sicherheitslücken und die Einhaltung von Vorschriften – all das übernimmt der Anbieter. Für ein kleines Unternehmen ohne IT-Abteilung ist das eine echte Entlastung und kein Marketingspruch.

Der typische Fehler? Ein eigenes System dort zu bauen, wo es einen bewährten Standard gibt. Wir haben Firmen gesehen, die “ihr eigenes” Urlaubsprogramm oder “ihre eigene” Mailing-Plattform wollten, obwohl fertige Produkte einen Bruchteil davon kosteten und sofort einsatzbereit waren. Eine Funktion von Grund auf zu schreiben, die man für ein paar Dutzend Złoty im Monat kaufen kann, verbrennt Budget und Zeit. Zeit, die besser in das fließt, was das Unternehmen tatsächlich auszeichnet.

Man sollte allerdings die wahren Kosten von “billigem” oder “kostenlosem” SaaS verstehen. Einstiegstarife haben Grenzen bei Nutzern, Datensätzen und API-Aufrufen, die die Rechnung beim Wachstum kräftig nach oben treiben können. Dazu kommt der Vendor-Lock-in, also die Abhängigkeit von den Formaten und dem Ökosystem des Anbieters.

• Limits – die Zahl der Kontakte, die Teamplätze oder das Transaktionsvolumen drängen Sie oft schneller in einen teureren Tarif, als es das Budget vorgesehen hat.
• Vendor-Lock-in – je tiefer die Prozesse in ein einziges System hineinwachsen, desto schwieriger und teurer wird der Ausstieg.
• Datenexport – prüfen Sie rechtzeitig, ob Sie Ihre Daten in einem brauchbaren Format zurückbekommen oder nur in einer abgespeckten Datei, aus der sich kaum etwas herausholen lässt.

Anzeichen, dass es Zeit für ein dediziertes System ist

Es gibt einen Moment, in dem fertige Werkzeuge das Wachstum bremsen, statt es anzutreiben. Wir erkennen ihn an wiederkehrenden Symptomen – Kunden beschreiben sie uns mit nahezu identischen Worten. Wenn mehrere der folgenden Punkte bekannt klingen, ist das Gespräch über ein eigenes System keine Marotte mehr. Es wird zu einer wirtschaftlichen Rechnung.

• Zentrale Prozesse werden von keinem fertigen Werkzeug abgedeckt, und die Leute flicken sie mit Handarbeit zusammen.
• Integrationen zwischen Systemen kleben Sie zu Fuß zusammen, über den Export und Import von Dateien.
• Die Gebühren pro Nutzer wachsen schneller als der Umsatz des Unternehmens.
• Die Daten sind über mehrere Anwendungen verstreut, und es gibt keine einzige Quelle der Wahrheit.
• Der wichtigste Prozess ist so untypisch, dass ihn kein Anbieter vorgesehen hat.

Am meisten schmerzt das Fehlen einer einzigen Quelle der Wahrheit. Wenn derselbe Kunde im CRM, im Lagersystem und in einer Verkaufstabelle steckt und sich jede Kopie in Details unterscheidet, verliert das Unternehmen das Vertrauen in die eigenen Zahlen. Berichte stimmen nicht überein. Entscheidungen beruhen auf Bauchgefühl. Und der Abgleich der Daten frisst Stunden, die in die Entwicklung fließen sollten.

Das stärkste Argument für den Eigenbau? Ein Wettbewerbsvorteil, der in einem untypischen Prozess steckt. Wenn ein Unternehmen Kunden betreut, Produkte kalkuliert oder die Produktion so plant, wie es die Konkurrenz nicht kopieren kann, dann ist genau diese Logik nichts, was man im Abonnement kaufen kann. Einen einzigartigen Prozess in das starre Korsett einer Standardlösung zu pressen bedeutet, freiwillig das aufzugeben, was die Stärke des Geschäfts ausmacht.

Tipp: Wenn der größte Teil Ihrer Arbeit mit einem Werkzeug darin besteht, dessen Grenzen zu umgehen, kostet Sie das Abonnement bereits mehr, als auf der Rechnung steht. Dieser versteckte Kostenblock besteht aus Arbeitszeit der Mitarbeiter, Datenfehlern und verpassten Chancen, die keine Preisliste jemals ausweist.

Die wahren Kosten: TCO statt Einführungspreis

Der schwerwiegendste Budgetfehler bei der Entscheidung für den Eigenbau ist, nur die erste Umsetzung zu rechnen. Individualsoftware ist kein einmaliges Projekt. Sie ist ein Produkt, das lebt und Pflege braucht. Ein realistisches Bild ergibt erst der TCO, also die Gesamtbetriebskosten verteilt über die nächsten drei bis fünf Betriebsjahre.

Auf der Build-Seite ist der Preis der Umsetzung erst der Anfang. Dazu kommen Hosting und Infrastruktur, die Aktualisierung von Abhängigkeiten, das Schließen von Sicherheitslücken, Monitoring und die Weiterentwicklung, denn die Anforderungen ändern sich. Ein System, das niemand pflegt, wird nach ein oder zwei Jahren zum Risiko statt zum Vermögenswert. Deshalb zeigen wir Kunden schon bei der Kalkulation nicht nur den Preis für den Bau, sondern auch die ungefähren jährlichen Betriebskosten.

SaaS hat ein anderes Kostenprofil. Es verlangt kein eigenes Betriebsteam, aber die Rechnung wächst mit der Zahl der Nutzer, dem Datenvolumen und dem Bedarf an höheren Tarifen. Was bei fünf Personen wie eine kleine Ausgabe aussieht, kann bei fünfzig die Abschreibung eines eigenen Systems übersteigen. Es lohnt sich, diese Wachstumskurve zu berechnen, bevor Sie einen Vertrag über Jahre unterschreiben.

Der Punkt, an dem sich build gegen buy rechnet, liegt genau dort, wo sich diese beiden Kurven treffen. Je mehr Nutzer, je untypischer der Prozess und je länger der Horizont, desto schneller amortisiert sich ein eigenes System. Je standardisierter der Bedarf und je kürzer die Perspektive, desto länger gewinnt das Abonnement.

1. Rechnen Sie den vollen TCO beider Optionen über mindestens drei Jahre, nicht über einen Monat.
2. Rechnen Sie beim SaaS das realistische Wachstum der Nutzerzahl und der Datenmenge in diesem Zeitraum hinzu.
3. Rechnen Sie beim Eigenbau Hosting, Betrieb, Sicherheit und Weiterentwicklung hinzu, nicht nur die Umsetzung.

Architekturentscheidungen, die über den Projekterfolg bestimmen

Über den Erfolg eines dedizierten Systems entscheidet die Architektur, nicht die Zahl der sichtbaren Funktionen. Gute Fundamente erlauben es, das Produkt jahrelang günstig weiterzuentwickeln. Schlechte machen aus jeder Änderung einen teuren Kampf mit dem eigenen Code. Deshalb treffen wir die wichtigsten Entscheidungen ganz am Anfang, bevor der erste Bildschirm entsteht.

Der Ausgangspunkt ist eine einzige Quelle der Wahrheit für die Daten. Statt mehrerer auseinanderdriftender Kopien eines Kunden oder einer Bestellung entwerfen wir einen einzigen, maßgeblichen Datenbestand, den alle übrigen Teile des Systems nutzen. Daten werden an einer Stelle geändert, widersprüchliche Versionen verschwinden, und Fehler lassen sich leichter finden und beheben. Es ist dasselbe Prinzip, das die Entwickler großer Anwendungsplattformen als Muster beschreiben.

Die zweite Entscheidung ist die klare Trennung der Zuständigkeiten in Schichten: Daten, Geschäftslogik und Benutzeroberfläche. Wenn die Geschäftsregeln nicht im Code der Bildschirme stecken, lässt sich das Aussehen der Anwendung ändern, ohne das Herz des Systems anzufassen. Und umgekehrt. Diese Trennung verringert das Risiko, dass eine Korrektur an einer Stelle unerwartet etwas völlig anderes kaputt macht.

Skalierbarkeit und Sicherheit entwerfen wir von Anfang an und kleben sie nicht in Panik an, wenn ein Problem auftaucht. Es geht um die Art der Datenspeicherung, die Zugriffskontrolle, die Verschlüsselung und die Widerstandsfähigkeit gegenüber wachsender Last. Sicherheitsmaßnahmen an ein fertiges System anzuflanschen ist immer teurer und weniger wirksam, als sie im Entwurf zu berücksichtigen.

Die letzte Säule ist Modularität und Testbarkeit. Ein System aus gut getrennten, von Tests abgedeckten Modulen lässt sich weiterentwickeln, ohne Angst, dass jede Änderung eine Lawine von Ausfällen auslöst. Genau die Testbarkeit und klare Grenzen zwischen den Komponenten machen eine günstige Weiterentwicklung in der Zukunft überhaupt erst möglich, und neue Entwickler finden sich schnell im Projekt zurecht.

Integrationen, Daten und Betrieb – hier scheitern Projekte am häufigsten

Nach unserer Erfahrung scheitern Projekte selten am reinen Programmieren der Funktionen. Die meisten Schwierigkeiten entstehen an der Schnittstelle zum Rest der Welt: bei Integrationen, der Datenmigration und dem langfristigen Betrieb. Diese Phasen werden chronisch unterschätzt, weil sie in einer Präsentation unscheinbar wirken, in der Praxis aber darüber entscheiden, ob das System im Unternehmen überhaupt funktioniert.

API-Integrationen mit bestehenden Systemen sind ein harter Bestandteil fast jeder B2B-Einführung. Individualsoftware muss mit der Buchhaltung, dem Lager, den Zahlungs-Gateways und den BI-Werkzeugen sprechen. Jede dieser Integrationen hat eigene Beschränkungen, Anfragelimits und Inkonsistenzen, die erst im echten Betrieb sichtbar werden. Eine gute Planung dieser Schicht kann über den Zeitplan des gesamten Projekts entscheiden.

Die Migration von Daten aus alten Werkzeugen und SaaS-Diensten ist eine eigene, selbstständige Phase und keine Tätigkeit “nebenbei”. Daten sind oft unvollständig, doppelt vorhanden und in Formaten gespeichert, die man bereinigen und neu zuordnen muss. Je früher wir in einen echten Export schauen, desto weniger Überraschungen tauchen kurz vor dem Produktivstart auf.

Tipp: Behandeln Sie die Migration als Miniprojekt mit eigenem Budget und eigenen Tests und nicht als letzten Punkt der Aufgabenliste kurz vor dem Start.

Genauso wichtig ist ein Betriebsplan. Man muss von vornherein festlegen, wer Fehler behebt, wer Abhängigkeiten aktualisiert und auf Sicherheitsvorfälle reagiert – und in welcher Zeit. Der häufigste Fehler ist, die Einführung als Ende des Projekts zu betrachten. Die Wahrheit ist, dass der Start erst der Beginn im Leben eines Systems ist, das sich weiter zusammen mit dem Unternehmen verändern wird. Deshalb führen wir das Gespräch über den Betrieb mit dem Kunden ganz am Anfang und nicht nach der ersten Störung.

Der vernünftige Weg: MVP und hybrider Ansatz

Man muss nicht das ganze System auf einmal bauen, um es zu nutzen. Der vernünftigste Weg ist meist ein MVP, also eine minimale Version des Produkts, die einen wirklich schmerzhaften Prozess löst. Das Unternehmen bekommt schnell ein funktionierendes Werkzeug, und weitere Funktionen entstehen auf Basis von Daten aus der echten Nutzung statt aus Vorstellungen in Projektbesprechungen.

Dieses Vorgehen senkt das Risiko deutlich. Statt sich in ein großes Projekt zu stürzen, das sich erst nach einem Jahr als Treffer oder Fehlschlag erweist, prüfen wir die Annahmen an einem kleinen Ausschnitt innerhalb weniger Wochen. Es funktioniert und bringt Einsparungen? Dann bauen wir bewusst aus. Die Realität widerlegt die Pläne? Dann korrigieren wir die Richtung, bevor ein großes Budget verschlungen ist.

Sinnvoll ist oft auch eine Mischform: ein dedizierter Kern dort, wo der Wettbewerbsvorteil steckt, und fertiges SaaS dort, wo der Standard völlig ausreicht. Es lohnt sich nicht, ein eigenes Mail- oder Buchhaltungssystem zu schreiben, wenn man sie über ein API anbinden kann. Eigenen Code reservieren wir für das, was das Unternehmen auszeichnet, und den Rest decken wir mit bewährten Bausteinen ab.

Immer häufiger ist die Schicht, die alles zusammenhält, aus Automatisierungen und KI-Anwendungen aufgebaut, die auf bestehenden Systemen aufsetzen. Statt alles neu zu schreiben, legen wir eine intelligente Schicht darüber, die Daten verbindet, Handarbeit beseitigt und Entscheidungen vorschlägt. Schneller, günstiger und weniger riskant als eine Revolution auf voller Breite.

Tipp: Beginnen Sie mit dem Prozess, der die höchsten Kosten an menschlicher Arbeit verursacht, und nicht mit der eindrucksvollsten Funktion. Die Automatisierung einer langweiligen, sich wiederholenden Aufgabe zahlt sich in der Regel schneller aus als ein glänzendes Extra, das in der Demo gut aussieht, aber niemandem Stunden spart.

Fazit und FAQ

Die Entscheidung build gegen buy hat keine einzige Antwort, aber sie hat eine klare Logik. Individualsoftware für das Unternehmen gewinnt bei einem untypischen Prozess, einem realen Wettbewerbsvorteil und einem langen Horizont, wenn die Gesamtbetriebskosten für die eigene Lösung sprechen. SaaS bleibt dort vernünftig, wo der Prozess standardisiert ist und ein schneller Start sowie planbare Ausgaben zählen. Am besten bewährt sich meistens ein hybrider Ansatz auf Basis eines gut entworfenen MVP.

Lohnt sich ein dediziertes System immer?

Nein. Bei standardisierten Prozessen und kurzem Horizont ist fertiges SaaS oft günstiger und schneller. Ein eigenes System lohnt sich dann, wenn der Prozess untypisch ist, die Skalierung wächst und die Kosten für Abonnements und manuelle Umwege die über mehrere Jahre gerechneten Kosten für Bau und Betrieb übersteigen.

Wie lange dauert der Bau eines MVP?

Das hängt von der Komplexität des Prozesses und der Integrationen ab, aber ein gut eingegrenztes MVP entsteht meist in einigen bis mehreren Wochen. Entscheidend ist, den Umfang auf ein einziges reales Problem zu begrenzen, statt gleich zu Beginn ein komplettes System bauen zu wollen.

Kann man ein eigenes System mit fertigem SaaS verbinden?

Ja, und oft ist das der vernünftigste Weg. Der dedizierte Kern übernimmt das, was das Unternehmen auszeichnet, und bewährte SaaS-Werkzeuge binden wir über API-Integrationen dort an, wo der Standard genügt. Diese Architektur verbindet Flexibilität mit niedrigeren Kosten und einer kürzeren Einführungszeit.

Wenn Sie über den Bau eines Systems, die Modernisierung einer bestehenden Lösung oder die Verbindung Ihrer Firmenwerkzeuge zu einem Ganzen nachdenken, helfen wir Ihnen gerne bei der Einschätzung, ob sich build oder buy mehr lohnt. Bei Web Systems entwerfen wir MVPs, Web- und mobile Anwendungen, API-Integrationen, Automatisierungen sowie KI-Lösungen – schreiben Sie uns und lassen Sie uns über Ihren Prozess sprechen.