- Was ist Individualsoftware? Software, die exakt für einen spezifischen Anwendungsfall entwickelt wird - zugeschnitten auf die eigenen Prozesse statt auf einen breiten Markt.
- Wann lohnt sie sich? Wenn Standardlösungen die Kernprozesse nicht abdecken, manuelle Überbrückungen täglich Stunden kosten oder die eigenen Abläufe ein Wettbewerbsvorteil sind.
- Was kostet sie? Mehr am Anfang, weniger im Verlauf. Der ehrliche Vergleich rechnet beide Seiten über denselben Zeitraum durch - die Anleitung dazu steht weiter unten.
- holzweg-Erfahrung: Individualsoftware-Entwicklung seit 1995 - vom Branchen-ERP über Fachplattformen im Gesundheitswesen bis zur B2B-Plattform mit SAP-Anbindung.
Was ist Individualsoftware?
Individualsoftware - auch Individual Software, Bespoke Software oder Custom Software genannt - ist Software, die exakt für einen spezifischen Anwendungsfall oder eine Organisation entwickelt wird. Sie entsteht auf Basis einer Anforderungsanalyse und wird von Grund auf neu gebaut, statt eine bestehende Produktlösung zu konfigurieren.
Standardsoftware wie SAP, Salesforce oder Shopify deckt typische Anwendungsfälle für einen breiten Markt ab. Sie ist schnell verfügbar, erprobt und wird vom Hersteller gewartet - bringt aber zwangsläufig Kompromisse mit: Features, die kein Unternehmen braucht, und fehlende Features, die manche Unternehmen dringend brauchen.
Dazwischen liegt die angepasste Standardsoftware: ein Standard-Produkt, das durch Customizing an spezifische Anforderungen angepasst wird. Das ist nicht dasselbe wie Individualsoftware - Customizing bleibt an die Grenzen der Plattform gebunden, erzeugt Abhängigkeit vom Hersteller und erhöht die Migrationskosten bei Versionsupgrades oft erheblich.
Vorteile von Individualsoftware - und ihre Bedingungen
Die Vorteile von Individualsoftware lassen sich auf vier Punkte verdichten. Jeder davon gilt allerdings nur unter einer Bedingung - die steht hier gleich dabei, statt im Kleingedruckten.
Passgenauigkeit
Die Software folgt Ihren Prozessen, nicht umgekehrt. Gilt, solange die Prozesse tatsächlich durchdacht sind - schlechte Abläufe werden durch Digitalisierung nur schneller schlecht.
Kein Vendor Lock-in
Der Quellcode gehört Ihnen, die Roadmap bestimmen Sie. Gilt nur bei dokumentiertem Code und verbreiteten Technologien - sonst tauschen Sie den Hersteller-Lock-in gegen einen Dienstleister-Lock-in.
Kosten, die nicht mit dem Team wachsen
Keine Lizenz pro Nutzer, keine Preiserhöhung bei jeder Einstellung. Dafür tragen Sie die Wartung selbst - die kommt nicht als Herstellerrechnung, aber sie verschwindet auch nicht.
Prozesse als Wettbewerbsvorteil
Was Sie besser können als der Mitbewerb, bleibt in Ihrer Software abgebildet statt in einem Produkt, das jeder kaufen kann. Relevant vor allem dort, wo der Prozess selbst das Geschäftsmodell ist.
Individualsoftware vs. Standardsoftware: Direktvergleich
Beide Ansätze haben ihre Berechtigung. Welcher passt, hängt von den konkreten Prozessen, dem Zeitrahmen und dem Budget ab. Die folgende Übersicht zeigt die wichtigsten Unterschiede ohne Beschönigung - die jeweils stärkere Seite ist hervorgehoben, und sie ist nicht immer dieselbe.
| Kriterium | Standardsoftware | Individualsoftware |
|---|---|---|
| Zeit bis zum Produktivstart | Tage bis Wochen | Monate - ein MVP typischerweise zwei bis vier |
| Initialer Aufwand | Niedrig (Lizenz und Konfiguration) | Mittel bis hoch (Entwicklungszeit) |
| Branchen-Fit | Generisch, viele ungenutzte Features | Auf die eigenen Kernprozesse zugeschnitten |
| Anpassbarkeit | Eingeschränkt, hohe Customizing-Kosten | Vollständig anpassbar |
| Laufende Kosten | Lizenz pro Nutzer - wächst mit dem Team | Wartung und Hosting - unabhängig von der Nutzerzahl |
| Vendor Lock-in | Hoch (Hersteller-Roadmap bestimmt) | Kein Lock-in, eigene Priorisierung |
| Wartung und Sicherheitsupdates | Hersteller, im Lizenzpreis enthalten | Eigenes Budget nötig |
| Regulatorische Anpassungen | Kommen in der Regel automatisch mit | Müssen beauftragt werden |
Tabelle seitlich scrollen, um alle Spalten zu sehen.
Der dritte Weg: Customizing, Low-Code und Hybrid-Lösungen
Die Frage wird meist binär gestellt: kaufen oder bauen. In der Praxis ist für viele Unternehmen ein dritter Weg der richtige - Standardsoftware für das, was standardisierbar ist, Eigenentwicklung für das, was den Unterschied macht.
Ein typisches Muster: Buchhaltung, Lohnverrechnung und E-Mail laufen auf Standard. Dort gibt es keinen Wettbewerbsvorteil zu holen, und regulatorische Updates kommen vom Hersteller. Die Auftragsabwicklung, die Disposition oder das Kundenportal dagegen werden individuell gebaut und per Schnittstelle angebunden. Genau so ist die EGLO-Plattform aufgebaut: individueller B2B-Shop und Produktdatenpflege, verzahnt mit den bestehenden SAP-nahen Prozessen.
Low-Code- und No-Code-Plattformen sind die vierte Option. Für abgegrenzte Aufgaben sind sie schnell und günstig. Ihre Grenze liegt bei komplexer Fachlogik, tiefen Schnittstellen und großem Datenvolumen - und sie tauschen den Software-Lock-in gegen einen Plattform-Lock-in samt nutzerbasiertem Preismodell. Als Einstieg sinnvoll, als Fundament für einen Kernprozess selten.
Eine fünfte Variante ist White-Label-Software: ein bestehendes Produkt, das unter eigenem Namen lizenziert und begrenzt angepasst wird. Sinnvoll für standardisierbare Geschäftsmodelle, aber kein Ersatz für echte Eigenentwicklung bei spezifischen Branchenprozessen.
Und was ist mit Vibe Coding? Bauen wir es einfach selbst mit KI
Diese Frage kommt inzwischen in fast jedem Erstgespräch, und sie ist berechtigt. Der Begriff stammt von KI-Forscher Andrej Karpathy, der im Februar 2025 einen Arbeitsstil beschrieb, bei dem man „vergisst, dass der Code überhaupt existiert" - Vorschläge werden übernommen, ohne die Änderungen zu lesen. Im November 2025 kürte Collins Dictionary „Vibe Coding" zum Wort des Jahres. Wichtig ist die Unterscheidung, die der Entwickler Simon Willison gezogen hat: Wer den generierten Code liest, versteht, testet und erklären kann, betreibt kein Vibe Coding, sondern Softwareentwicklung mit einem sehr guten Werkzeug.
Was kurzfristig wirklich funktioniert. Dass damit erstaunlich viel geht, lässt sich nicht wegdiskutieren - und wir reden hier nicht als Skeptiker: holzweg setzt KI in der eigenen Entwicklung täglich ein. Für eng umrissene Aufgaben ohne bestehenden Code-Kontext haben Microsoft-Forscher bereits 2023 eine um rund 56 Prozent schnellere Fertigstellung gemessen. Für einen Prototyp, ein internes Hilfstool oder einen Machbarkeitsnachweis ist das genau das richtige Vorgehen. Wer in zwei Tagen sehen will, ob eine Idee trägt, sollte nicht zwei Monate spezifizieren.
Warum wir davon abraten, wenn die Software bleiben soll. Sobald derselbe Code produktiv läuft und über Jahre gepflegt werden muss, dreht sich das Bild. Ein kontrolliertes Feldexperiment des Forschungsinstituts METR kam 2025 zu einem Ergebnis, das viele überrascht hat: Erfahrene Entwickler, die an einer ihnen vertrauten, bestehenden Codebasis arbeiteten, brauchten mit KI-Unterstützung 19 Prozent länger statt kürzer. Vorab hatten sie mit einer Beschleunigung um 24 Prozent gerechnet - und selbst nach getaner Arbeit glaubten sie noch, rund 20 Prozent schneller gewesen zu sein. Der Unterschied zum Prototyp-Szenario liegt genau dort, wo Ihre Software in fünf Jahren stehen wird: gewachsene Architektur, Altlasten, Abhängigkeiten. Die lassen sich nicht wegprompten.
Dazu kommen zwei messbare Effekte. Eine Auswertung von 211 Millionen geänderten Codezeilen aus Unternehmens-Repositories zeigt seit 2021 einen deutlich steigenden Anteil kopierter statt überarbeiteter Zeilen - das klassische Muster wachsender technischer Schulden. Und ein Sicherheitstest von über 100 KI-Modellen an 80 Programmieraufgaben fand 2025 in 45 Prozent der generierten Lösungen ausnutzbare Schwachstellen. Dass das kein Laborproblem ist, zeigte im Mai 2025 eine Lücke in einer verbreiteten Vibe-Coding-Plattform selbst: Über 170 produktiv laufende Anwendungen standen offen, weil grundlegende Zugriffsregeln fehlten - etwas, das ein Code-Review gefunden hätte.
Der eigentliche Knackpunkt ist aber keiner der genannten Werte, sondern das Know-how. Software, die niemand im Haus versteht, ist im Störfall nicht reparierbar - und der Störfall kommt immer sonntags. Wer den Code nie gelesen hat, kann ihn nicht debuggen, nicht sicher erweitern und einem neuen Dienstleister nicht übergeben. Für Unternehmen kommt ab Dezember 2026 ein rechtlicher Aspekt dazu: Die neue EU-Produkthaftungsrichtlinie zählt Software ausdrücklich als Produkt - unabhängig davon, wer oder was sie geschrieben hat. Wer sie in Verkehr bringt, kann als Hersteller verschuldensunabhängig haften, wenn sie Personenschäden, Schäden an privat genutztem Eigentum oder Datenverlust verursacht. Reine Vermögensschäden bleiben ausgenommen und weiterhin Sache des Vertragsrechts. Für ein rein internes Tool ändert das wenig, für Software, die Kunden oder deren Daten berührt, sehr wohl.
Unsere Empfehlung ist deshalb keine Absage an KI, sondern eine Trennlinie: Prototypen und Wegwerf-Werkzeuge gern mit KI in Tagen statt Wochen. Alles, was Kunden, Umsätze oder Personendaten trägt, gehört durch denselben Prozess wie jede andere Software - gelesener Code, Tests, Review, dokumentierte Architektur. Ob dabei eine KI mitgeschrieben hat, ist dann zweitrangig.
Was kostet Individualsoftware-Entwicklung wirklich?
Ein Vergleich, der nur die Anschaffung gegenüberstellt, führt fast immer in die Irre: Die Lizenz kostet im ersten Monat wenig, die Eigenentwicklung kostet am Anfang alles. Aussagekräftig wird die Rechnung erst über die gesamte Nutzungsdauer. Wir rechnen im Folgenden mit fünf Jahren - kurz genug, um planbar zu bleiben, lang genug, damit die laufenden Kosten sichtbar werden. Die folgende Aufstellung zeigt, welche Kostenblöcke auf beiden Seiten tatsächlich anfallen.
| Kostenblock | Standardsoftware | Individualsoftware |
|---|---|---|
| Anschaffung / Entwicklung | Gering bis mittel (Setup, Konfiguration) | Einmalig hoch (Entwicklungsstunden) |
| Laufende Grundkosten | Lizenz pro Nutzer und Monat | Hosting und Wartung, nutzerunabhängig |
| Anpassungen | Customizing-Projekte, oft zum Premium-Satz | Entwicklungsaufwand nach eigener Priorität |
| Upgrades | Major-Versionen erzwungen, Anpassungen brechen | Selbst terminiert, kein Zwang |
| Ausstieg / Wechsel | Migrationsprojekt, Daten oft proprietär | Quellcode und Daten liegen bei Ihnen |
| Größtes Risiko | Preiserhöhung oder eingestelltes Produkt | Falsch verstandene Anforderungen |
Tabelle seitlich scrollen, um alle Spalten zu sehen.
Die Lizenzseite lässt sich konkret beziffern. Ein Blick auf öffentliche Listenpreise gängiger Business-Software (Stand August 2026, jeweils pro Nutzer und Monat): SAP Business One Cloud liegt je nach Edition zwischen rund 38 und 91 Euro, Microsoft Dynamics 365 Business Central zwischen etwa 7 Euro für reine Leserechte und rund 95 Euro für die Premium-Lizenz, Salesforce Sales Cloud zwischen 25 und 350 Euro. Für ein Team von 20 Personen in einer mittleren Edition summiert sich das über fünf Jahre schnell auf einen sechsstelligen Betrag - allein an Lizenzgebühren, ohne Customizing und ohne Upgrade-Aufwände.
So rechnen Sie es für Ihren Fall durch - mit Ihren Zahlen, nicht mit Beispielwerten aus einem Blogartikel:
- Standardseite: Lizenzkosten pro Nutzer und Jahr, multipliziert mit der Nutzerzahl und fünf Jahren. Dazu die absehbaren Customizing-Projekte und den Aufwand für Major-Upgrades.
- Individualseite: angebotene Entwicklungsstunden mal Stundensatz, plus jährliche Wartung. Als Planungsgröße gilt in der Softwarebranche ein Richtwert von etwa 15 bis 20 Prozent der ursprünglichen Entwicklungskosten pro Jahr - lassen Sie sich diesen Anteil im Angebot ausweisen, statt ihn zu schätzen.
- Beide Seiten: die Kosten des Ist-Zustands. Wenn heute täglich Stunden in Excel-Listen, Doppelerfassung oder WhatsApp-Koordination fließen, ist das der eigentliche Vergleichswert - und er fehlt in fast jeder Kalkulation.
Wo genau innerhalb dieser fünf Jahre die beiden Kurven sich kreuzen, hängt nach unserer Erfahrung vor allem an der Nutzerzahl. Die Logik dahinter ist simpel: Lizenzkosten wachsen mit dem Team, Entwicklungskosten nicht. Je größer die Nutzerbasis, desto früher kippt die Rechnung Richtung Eigenentwicklung.
Sobald ein Unternehmen dauerhaft mehr für das Verbiegen einer Standardlösung ausgibt, als eine Eigenentwicklung gekostet hätte, ist die Entscheidung faktisch längst gefallen - nur eben unbemerkt.
Lohnt sich Individualsoftware für Sie? Der Selbsttest
Die ehrliche Antwort ist: nicht immer. Es gibt Konstellationen, in denen Standardsoftware klar die bessere Wahl ist. Prüfen Sie die folgenden Aussagen - je mehr auf Sie zutreffen, desto eindeutiger fällt die Entscheidung aus.
Signale für Eigenentwicklung
Für unsere Kernprozesse gibt es keine Standardlösung, die wirklich passt.
Ein erheblicher Teil der Features unserer aktuellen Software bleibt dauerhaft ungenutzt - wir zahlen für Ballast.
Manuelle Überbrückungen wie Excel, WhatsApp oder Papierformulare kosten uns täglich Stunden.
Unsere Abläufe sind ein Wettbewerbsvorteil, den wir nicht in ein Standardprodukt geben wollen.
Wir zahlen für jede neue Person im Team eine weitere Lizenz - und das Team wächst.
Wir brauchen Schnittstellen, die unser Anbieter nicht liefert und nicht liefern wird.
Eine Anbindung an ERP, SAP oder ein Legacy-System ist für uns geschäftskritisch.
Die Lösung soll mehrere Mandanten oder Standorte mit eigenem Branding bedienen.
Signale für eine Standardlösung
Es gibt ein markterprobtes Produkt, das den Großteil unserer Anforderungen abdeckt.
Wir müssen schnell live gehen - Zeit wiegt schwerer als Passgenauigkeit.
Unsere Prozesse sind noch im Fluss und nicht stabil beschrieben.
Der Bereich ist stark reguliert und der Anbieter liefert die Compliance-Updates mit.
Wir haben aktuell niemanden, der ein Projekt fachlich begleiten kann.
Das Thema ist für uns kein Differenzierungsfaktor, sondern reine Pflichtaufgabe.
Unsere Kauf- oder Redaktionsprozesse entsprechen dem Marktstandard.
Es geht um eine Microsite oder eine zeitlich begrenzte Kampagne.
Die vier häufigsten Risiken - und wie man sie entschärft
Individualsoftware scheitert selten an der Technik. Die Muster, die Projekte in der Praxis kippen lassen, sind fast immer dieselben vier - und alle vier sind vermeidbar.
1. Der Umfang wächst schneller als das Budget
Jede Woche eine neue Idee, und plötzlich ist das Projekt doppelt so groß. Gegenmittel: ein MVP, der zuerst nur den Prozess mit der größten Reibung abbildet und tatsächlich in Betrieb geht. Alles Weitere wird priorisiert, nicht dazugelegt.
2. Die Anforderungen wurden falsch verstanden
Was fachlich selbstverständlich ist, wird selten ausgesprochen - und landet dann nicht in der Software. Gegenmittel: die Anforderungsanalyse mit den Menschen führen, die den Prozess täglich ausführen, nicht nur mit der Leitungsebene. Und früh sichtbare Zwischenstände zeigen statt einer großen Abnahme am Schluss.
3. Abhängigkeit vom Dienstleister statt vom Hersteller
Kein Vendor Lock-in zu haben nützt wenig, wenn der Code undokumentiert ist und niemand anderes ihn übernehmen kann. Gegenmittel: Quellcode-Eigentum im Vertrag, verbreitete Open-Source-Technologien und eine Dokumentation, die einen Dienstleisterwechsel real möglich macht.
4. Nach dem Go-live passiert nichts mehr
Software, die nicht gepflegt wird, veraltet schneller als jede Lizenzlösung - Sicherheitsupdates inklusive. Gegenmittel: Wartung und Weiterentwicklung von Anfang an budgetieren, nicht als Restposten behandeln.
Drei Individualsoftware-Projekte aus der Praxis
holzweg entwickelt Individualsoftware seit 1995 - von internen Tools und Fachapplikationen bis zu vollständigen Branchen-ERP-Systemen. Alle drei folgenden Projekte entstanden, weil kein Standardprodukt die Anforderung abdecken konnte.
- MOMO - Branchen-ERP für die Karl Morf AG: die gesamte Auftragsabwicklung eines Schweizer Straßenmarkierungs- und Signalisationsbetriebs in einer Web-Applikation. Inklusive Felddisponierung, bei der Aufträge samt Bildern und GPS-Koordinaten direkt vor Ort erfasst werden. Eine passende Standardlösung war für diese Branche nicht zu finden - zu klein für ein eigenes Produkt, zu speziell für ein generisches ERP.
- Sprengelarzt - Plattform für den ärztlichen Bereitschaftsdienst: PLZ-basierte Anrufweiterleitung an den jeweils diensthabenden Arzt, digitale Dienstplanung und ein anonymes Rückrufsystem, technisch auf einer Asterisk-PBX mit IVR aufgesetzt. Die Anforderung entsteht direkt aus der österreichischen Sprengel-Organisation - es gibt dafür kein Produkt zu kaufen.
- EGLO - PIM und individueller B2B-Shop: ein PIM auf Akeneo-Basis, das mehr als 240.000 Produkte verwaltet und in 32 Länder und 29 Sprachen ausleitet, dazu ein individueller B2B-Shop für 29 Verkaufsorganisationen. Das vorherige Magento-System wird schrittweise abgelöst, nicht in einem Big Bang ersetzt.
Wer den Weg über ein eigenes ERP erwägt, findet die Details unter ERP-Eigenentwicklung. Einen Überblick über Leistungen und Ablauf gibt die Seite Individualsoftware & App-Entwicklung.
Beratungstermin vereinbaren
Häufige Fragen zur Individualsoftware-Entwicklung
Zwei Prüfsteine über die Vertragsfrage des Quellcode-Eigentums hinaus: Erstens beginnt ein guter Partner mit einer Anforderungsanalyse statt mit einem Pauschalangebot - wer Ihre Prozesse nicht kennt, kann sie auch nicht abbilden. Zweitens zeigt er Ihnen Referenzprojekte, die noch laufen und weiterentwickelt werden, nicht nur solche, die einmal live gegangen sind. Ein Warnsignal ist ein Festpreis für ein Projekt, dessen Anforderungen noch niemand aufgeschrieben hat: Entweder ist der Puffer üppig einkalkuliert, oder es wird später teuer nachverhandelt.
Ja, und das ist meist der bessere Weg. Der neue Baustein läuft dabei zunächst parallel zum Bestandssystem, statt es sofort abzulösen: Ein klar abgegrenzter Prozess wird zuerst umgesetzt und geht in den echten Betrieb, das alte System bleibt vorerst daneben bestehen. Das kostet kurzfristig etwas Doppelarbeit, nimmt dem Umstieg aber das Risiko - und Sie binden nicht das gesamte Budget, bevor die erste Zeile produktiv läuft.
Die Datenübernahme ist Teil des Projekts, kein Nachgedanke. Üblich ist ein Migrationsskript, das Stammdaten wie Kunden, Artikel und Projekte automatisiert überführt, plus eine Phase des Parallelbetriebs, in der beide Systeme laufen und die Ergebnisse verglichen werden. Kritisch sind erfahrungsgemäß nicht die Daten selbst, sondern historisch gewachsene Sonderfälle - deshalb gehört ein Datenqualitäts-Check an den Anfang der Migration, nicht ans Ende.
Für Prototypen, interne Hilfstools und Machbarkeitsnachweise: unbedingt, das geht heute in Tagen statt Wochen. Für Software, die produktiv läuft und Jahre halten soll, raten wir davon ab - nicht aus Prinzip, sondern aus drei praktischen Gründen. Erstens ist Code, den niemand im Haus gelesen hat, im Störfall nicht reparierbar. Zweitens zeigen Untersuchungen, dass KI-Unterstützung bei bestehenden, gewachsenen Codebasen die Arbeit eher verlangsamt als beschleunigt, und dass generierter Code überdurchschnittlich oft Sicherheitslücken enthält. Drittens zählt die EU-Produkthaftungsrichtlinie ab Dezember 2026 auch Software ausdrücklich als Produkt - unabhängig davon, wer oder was sie geschrieben hat. Wer sie in Verkehr bringt, kann bei Personen-, Sach- oder Datenschäden verschuldensunabhängig haften. Der pragmatische Weg: KI als Werkzeug im Entwicklungsprozess nutzen, aber Review, Tests und Architektur nicht überspringen.
Für abgegrenzte Aufgaben wie Formularworkflows oder einfache Automatisierungen sind Low-Code-Plattformen oft die bessere Wahl. Der Kipppunkt in der Praxis: Sobald Sie anfangen, Plattformgrenzen mit eigenem Code oder externen Diensten zu umgehen, zahlen Sie doppelt - Plattformgebühr plus Entwicklungsaufwand - und verlieren gleichzeitig die Wartungsfreundlichkeit, die der eigentliche Grund für Low-Code war. Wer diesen Punkt zweimal erreicht hat, sollte den Prozess grundsätzlich neu bewerten.
Keine Entwicklungskenntnisse, aber zwei Dinge: eine Person, die die Prozesse wirklich kennt und entscheidungsbefugt ist, sowie verbindliche Zeitfenster für Rückfragen und Abnahmen. Verzögerungen entstehen nach unserer Erfahrung seltener an der Technik als an einer unklaren Entscheidungslage auf Auftraggeberseite. Den laufenden Betrieb - Hosting, Updates, Support - übernimmt in der Regel der Dienstleister.
Das hängt vom Umfang ab. Ein internes Tool oder eine abgegrenzte Webapplikation ist typischerweise in zwei bis vier Monaten produktiv. Ein vollständiges Branchen-ERP wie MOMO wächst über deutlich längere Zeiträume - der erste nutzbare Stand steht aber lange vor dem vollen Funktionsumfang. Wichtig ist die Unterscheidung: „fertig" heißt bei Individualsoftware nicht „abgeschlossen", sondern „produktiv nutzbar und weiter ausbaufähig".
