Die meisten Individualsoftware-Projekte werden nicht im Code entschieden. Sie werden in den Wochen davor entschieden, in denen drei Fragen entweder ehrlich beantwortet oder elegant übersprungen werden. Wer sie überspringt, merkt es erst achtzehn Monate später: an einem System, das es fertig zu kaufen gegeben hätte, an einem Budget, das nur bis zum Go-live gerechnet war, oder an einem Dienstleister, ohne den nichts mehr geht.
Frage 1: Individual- oder Standardsoftware — wann lohnt sich was?
Die erste Frage ist die brutalste, weil die ehrliche Antwort oft lautet: gar keine Individualsoftware. Für Buchhaltung, Lohnabrechnung oder E-Mail gibt es ausgereifte Standardprodukte. Wer dort selbst baut, bezahlt eine Eigenentwicklung für einen Prozess, der ihn von niemandem unterscheidet.
Die Entscheidungsachse ist nicht der Preis, sondern die Differenzierung. Stell dir für jeden Prozess eine Frage: Hebt er dich vom Wettbewerb ab, oder muss er einfach nur zuverlässig laufen? Hygiene-Prozesse kaufst du als Standard. Individuell baust du nur das, was dein Geschäft tatsächlich ausmacht: den Produktkonfigurator mit deiner Pricing-Logik, das Kundenportal, die Verzahnung von Produktion, Lager und Versand, die kein Standardprodukt sauber abbildet. Was du von der Stange kaufen kannst, kann dein Wettbewerber auch kaufen. Dann ist es per Definition kein Vorteil.
Die Grauzone dazwischen ist der Ort, an dem das Geld verdient oder verbrannt wird. Das klassische Muster sieht so aus: Das ERP deckt Stammdaten, Lager und Buchungslogik sauber ab, aber die Staffelpreis-Logik, mit der der Vertrieb tatsächlich verkauft, lebt in einer Excel-Datei neben dem System. Niemand traut sich, sie anzufassen, und jedes Angebot läuft über Copy-and-paste.
Die falsche Reaktion darauf ist ein neues ERP. Die richtige: das Standard-ERP behalten, die Preislogik als eigenes Modul danebenbauen, beides über eine Schnittstelle verbinden. Wie du diese Abwägung systematisch triffst, inklusive Entscheidungsmatrix, haben wir im Beitrag zu SaaS oder Individualsoftware ausführlich auseinandergenommen.
Frage 2: Was kostet Individualsoftware wirklich?
Die häufigste Antwort auf diese Frage ist eine Zahl, die nur die halbe Wahrheit enthält: das Projektbudget bis zum Go-live. Diese Zahl ist real, aber sie ist nicht der Preis der Software. Sie ist der Eintrittspreis.
Der größere Kostenblock kommt danach. Studien zur Softwarewartung beziffern den Anteil von Betrieb, Pflege und Weiterentwicklung über den gesamten Lebenszyklus auf 60 bis 80 Prozent der Gesamtkosten; die in der Softwaretechnik geläufige 60/60-Regel zeigt in dieselbe Richtung.
Als Faustregel für die Budgetplanung: Rechne mit laufenden Kosten von grob 15 bis 20 Prozent der ursprünglichen Entwicklungskosten pro Jahr. Ein System, das 200.000 Euro in der Entwicklung kostet, verursacht über fünf Jahre realistisch noch einmal einen ähnlichen Betrag für Wartung, Updates, Sicherheits-Patches und die Anpassungen, die dein Geschäft ohnehin verlangen wird.
Das ist kein Argument gegen Individualsoftware, sondern eines gegen falsche Vergleiche. Die SaaS-Alternative hat ihre eigene Kurve: niedriger Einstiegspreis, der mit jedem Nutzer, jedem Zusatzmodul und jeder Integration skaliert. Individualsoftware kostet vorne viel und läuft dann flacher. Meine Daumenregel: Bleibt der Prozess nah am Standard und wächst die Nutzerzahl moderat, bleibt SaaS dauerhaft vorn. Sobald du aber für deinen Kernprozess Enterprise-Tiers, Zusatzmodule und Workarounds zusammenbuchst, kippt die Rechnung typischerweise zwischen Jahr zwei und drei zugunsten des Eigenbaus.
Was das Budget am Ende wirklich treibt, ist selten der Stundensatz des Dienstleisters. Es ist der Scope-Schnitt: Ein Projekt, das mit einem fokussierten MVP startet und in Ausbaustufen wächst, kostet planbar. Ein Projekt, das alles auf einmal will, kostet, was es will.
Der zweithäufigste Kostentreiber versteckt sich in einer einzigen Angebotszeile. „Anbindung ERP: 3 Personentage" liest sich harmlos, bis sich herausstellt, dass das ERP keine API hat, sondern nur einen CSV-Export per Nachtjob. Dann werden aus drei Tagen drei Wochen, und zwar nach Vertragsunterschrift. Jede Integration in Bestandssysteme verdient im Angebot eine eigene, begründete Schätzung statt einer Pauschalzeile.
Und darunter liegt die Architekturqualität: Ein sauber geschnittenes System ist in fünf Jahren erweiterbar, ein verwachsenes wird zur Altlast.
Kurz gesagt: Die richtige Kostenfrage lautet nicht „Was kostet die Entwicklung?", sondern „Was kostet das System über seine Laufzeit, und was kostet die Alternative im selben Zeitraum?". Wer nur die erste Zahl vergleicht, entscheidet auf der falschen Grundlage.
Frage 3: Wie läuft ein Projekt ab — und woran erkennst du den richtigen Partner?
Ein seriöses Individualsoftware-Projekt beginnt nicht mit einem Angebot, sondern mit einer Discovery-Phase. Anforderungen werden geschärft, Prozesse angeschaut, technische Rahmenbedingungen geklärt. Erst danach lässt sich seriös schätzen.
Am Ende der Discovery sollten drei Dinge auf dem Tisch liegen: ein priorisiertes Backlog, das trennt, was ins MVP gehört und was warten kann, eine Architekturskizze mit den kritischen Integrationspunkten, und eine Schätzung, die pro Baustein begründet ist statt als Gesamtsumme vom Himmel zu fallen. Fehlt eines davon, war es keine Discovery, sondern ein verlängertes Verkaufsgespräch. Ein Dienstleister, der dir schon nach einem Erstgespräch einen Festpreis für ein komplexes System nennt, schätzt ohnehin nicht dein Projekt. Er schätzt seine Vertriebschance.
Danach gehört ein iterativer Ablauf hin: ein MVP, das den Kernprozess produktiv abbildet, dann Ausbaustufen in kurzen Zyklen mit echtem Nutzerfeedback. Der Vorteil ist nicht nur methodische Hygiene. Du siehst früh, ob das Team liefert, und kannst nachsteuern, bevor das Budget verbraucht ist. Eine tragfähige Systemarchitektur gehört an den Anfang dieses Prozesses, nicht ans Ende, denn sie entscheidet darüber, ob die Ausbaustufen später auf ein Fundament oder auf Treibsand bauen.
Beim Partner selbst sind zwei Forderungen nicht verhandelbar, und beide gehören in den Vertrag. Der Code gehört dir, vollständig, inklusive Repository-Zugang ab dem ersten Sprint. Und es gibt ein benanntes Wartungs- und Weiterentwicklungsmodell für die Zeit nach dem Go-live, mit Reaktionszeiten und Konditionen, nicht nur eine Absichtserklärung.
Der eigentliche Lackmustest ist unbequemer, weil er sich nicht in eine Vertragsklausel schreiben lässt: Baut der Partner so, dass du ihn wechseln könntest? Ein marktgängiger Tech-Stack wie Node.js oder TypeScript statt einer exotischen Speziallösung, nachvollziehbare Dokumentation, Entwickler, die du in fünf Jahren noch am Markt findest. Ein Partner, der auf Austauschbarkeit hin baut, bindet dich über Qualität statt über Abhängigkeit. Genau deshalb wirst du ihn wahrscheinlich nie wechseln müssen.
Was am Ende zählt
Die drei Fragen bauen aufeinander auf, und ihre Reihenfolge ist der eigentliche Punkt. Erst wenn klar ist, dass ein Prozess Individualsoftware verdient, lohnt die Kostenrechnung. Erst wenn die Gesamtkostenrechnung steht, lohnt die Partnersuche. Wer die Reihenfolge umdreht und mit der Dienstleisterauswahl beginnt, bekommt eine Antwort, bevor er die Frage gestellt hat.
Meine Empfehlung ist deshalb unbequem, aber einfach: Nimm dir für diese drei Fragen mehr Zeit als für den Vergleich von Angeboten. Ein mittelmäßiger Dienstleister mit einem sauber geschnittenen Auftrag liefert ein besseres Ergebnis als ein exzellenter mit einem falschen. Und wenn du bei einer der drei Fragen nicht weiterkommst, ist genau das der richtige Zeitpunkt für ein Gespräch über maßgeschneiderte Business-Software, nicht erst, wenn das Lastenheft schon geschrieben ist.
Individualsoftware ist kein Produkt, das man kauft. Sie ist eine Entscheidung, die man trifft. Triff sie in der richtigen Reihenfolge.