Warum „individuell oder Standard“ die falsche Frage ist
Sie haben eine Excel-Tabelle für Bestellungen, ein ERP-Modul, das das Team bei der Hälfte der Schritte umgeht, oder ein SaaS, das genau den Teil außen vor lässt, der am meisten zählt. Irgendwann sagt jemand: „Lasst uns unsere eigene Software bauen.“ Die Frage, die daraufhin gestellt wird, ist meist falsch formuliert: Individualsoftware oder Standardsoftware, als eine einzige Entscheidung für den gesamten Prozess.
Tatsächlich wird die Entscheidung Stück für Stück getroffen: welcher Teil des Prozesses zu üblich ist, um eine Neuerfindung zu rechtfertigen, und welcher Teil so spezifisch für Ihr Unternehmen ist, dass ihn kein Standardpaket abdeckt. Der Artikel geht die relevanten Kriterien durch, zeigt die Hybridvariante, die die meisten Unternehmen verpassen, dann eine Entscheidungstabelle und die Warnsignale eines unseriösen Softwareentwicklungsangebots.
Erstes Kriterium: wie standardisiert der Prozess ist und wie sehr er Sie differenziert
Ein einfacher Test aus der Softwaretechnik hilft bei der Entscheidung: Wenn der Prozess, den Sie ändern möchten, etwas ist, das jedes Unternehmen in Ihrer Branche genauso macht — Buchhaltung, Onboarding, das Ausstellen einer Rechnung —, kaufen Sie ein Standardtool und passen Ihren Prozess daran an. Wenn der Prozess genau der Grund ist, warum Kunden Sie wählen, verdient dieser Teil speziell dafür geschriebenen Code. Martin Fowler sagt es direkt: Wenn der Prozess Teil Ihres Wettbewerbsvorteils ist, bauen Sie Individualsoftware; wenn nicht, kaufen Sie ein Paket und passen sich daran an.
Kontext: Auf EU-Ebene sind Standardtools bereits die Regel — der Anteil der Unternehmen mit ERP reicht von 41 % bei kleinen Unternehmen bis 89 % bei großen, und 53 % der Unternehmen in der EU nutzen mindestens ein ERP-, CRM- oder BI-System, laut Eurostat (2025). Der Standardkern ist fast immer der richtige Ausgangspunkt; die nützliche Frage ist, was für Sie darin fehlt.
Zweites Kriterium: was mit was sprechen muss
Nur wenige „von der Stange“ gekaufte Tools sprechen nativ mit allem, was Sie im Unternehmen bereits haben. Ein ERP wie SAGA oder SAP, ein Kurier mit täglichen AWB-Nummern, das RO e-Factura-System der ANAF — jedes hat sein eigenes Format, und ein generisches SaaS deckt selten alles davon von Haus aus ab, vor allem nicht für einen Ablauf, der speziell auf ein rumänisches Unternehmen zugeschnitten ist. Meistens wird diese Reibung nicht durch den Austausch des Kerns gelöst, sondern durch kleine, dedizierte Webanwendungen, die genau für die Brücke zwischen den Systemen gebaut werden.
Die Fristen sind nicht theoretisch: Die B2B-Meldung in RO e-Factura ist seit dem 1. Januar 2024 verpflichtend, die B2B-Rechnungsstellung über dasselbe System seit dem 1. Juli 2024, laut Finanzministerium. Egal ob die Rechnungsstellung beim gekauften Tool bleibt oder in einem individuell gebauten Teil landet, die Integration mit e-Factura ist nicht optional — es ist eine gesetzliche Anforderung, die ohnehin erfüllt werden muss.
Drittes Kriterium: wer Code, Infrastruktur und Daten besitzt
Wenn Sie ein Abonnement kaufen, liegen Ihre Daten meist im Format und auf der Infrastruktur des Anbieters. Solange die Beziehung gut läuft, spielt das keine Rolle. Es spielt eine Rolle an dem Tag, an dem der Anbieter seine Preise ändert, aufgekauft wird oder das Produkt einstellt — dem Moment, in dem Sie aus der Position eines Unternehmens verhandeln, das nichts von dem besitzt, was es aufgebaut hat.
Daher auch die Falle der aggressiven Anpassung eines gekauften Pakets. Thoughtworks weist darauf hin, dass die Anpassung einer gekauften Software dieselben Risiken birgt wie eine Entwicklung von Grund auf — Verzögerungen, unvorhergesehene Kosten, Kompetenzen, die nichts mit dem Kerngeschäft zu tun haben —, jedoch ohne den Vorteil, am Ende den Code zu besitzen. Fowler empfiehlt das Gegenteil: Statt den gekauften Kern anzupassen, bauen Sie separate, über API verbundene Teile, die Sie vollständig besitzen — genau das Prinzip hinter der Hybridvariante.
Viertes Kriterium: die Kosten über drei Jahre, nicht der Einstiegspreis
Ein Abonnement wirkt im ersten Monat günstig. Über drei Jahre steigen die Kosten mit der Zahl der Nutzer, mit dem Datenvolumen und fast immer mit den Gebühren für genau die Ausnahmen, die Sie brauchen — ein zusätzliches Modul, ein höherer Plan, ein Add-on nur für Ihren Ablauf. Ein individueller Build kostet anfangs mehr und erfordert danach Wartung, aber seine Kurve ist anders: Der große Aufwand konzentriert sich am Anfang und vervielfacht sich nicht mit jedem neuen Nutzer.
Es gibt kein universelles Urteil — weder „immer kaufen“ noch „immer bauen“. Forrester beschreibt das als Pendel: Unternehmen, die dauerhaft in ein einziges Extrem gehen, verlieren Kontrolle oder Geschwindigkeit, während die bewusste Kombination das stabilste Ergebnis bringt. Time to Value zählt genauso viel wie der Preis — ein gekauftes Tool ist fast immer schneller einsatzbereit als ein Build von Grund auf, ein weiterer Grund, den Kern nicht wegzuwerfen.
Die Variante, die die meisten Unternehmen verpassen: der Kern bleibt, die Teile werden individuell gebaut
Die Diskussion „individuell oder Standard“ blockiert sich, weil sie als einzige Entscheidung für das gesamte System gestellt wird. Die Hybridvariante — Sie behalten den Standardkern und bauen nur die fehlenden Teile individuell — ist die Variante, zu der Unternehmen häufig gelangen, die die langfristigen Kosten analysieren, nicht nur den Einstiegspreis. Die drumherum gebauten Teile sind meist drei: Integrationen, interne Administrationspanels und Automatisierungen.
AutosWorld ist ein konkretes Beispiel, noch in der Launch-Phase: ein auf WooCommerce aufgebauter Online-Shop, mit unangetasteter Standardplattform. Was individuell gebaut wird, ist das Administrationspanel dahinter — Dashboard, schnelle Produktbearbeitung, eigene Felder für Lieferant und automatisch berechnete Marge. Nach der Anmeldung gelangt das Team direkt in sein eigenes Panel, nicht in WordPress, damit der tägliche Betrieb des Bestands nicht von jemandem außerhalb abhängt.
Tchibo GAME ON zeigt die gegenteilige Situation — der Prozess ist tatsächlich das Produkt. Die Kampagne erforderte das Hochladen von Kassenbons vom Telefon, automatische Validierung und Regeln zur Betrugsprävention gegen doppelte Bons. Kein Standardtool deckte diese Kombination ab, also wurde die Plattform vollständig individuell von The Niche Society gebaut. Der Unterschied zu AutosWorld liegt nicht in der Qualität, sondern in der Art des Prozesses.
Die Entscheidungstabelle: was wir je nach Situation empfehlen
Die obigen Kriterien ergeben für jedes Unternehmen eine andere Antwort. Die Tabelle fasst die häufigen Situationen und die jeweils passende Empfehlung zusammen.
| Situation | Empfehlung | Warum |
|---|---|---|
| Identischer Prozess in jedem Unternehmen der Branche | Sie kaufen das Standardtool | Niemand gewinnt dadurch, einen standardisierten Prozess neu zu erfinden |
| Das Team verliert Zeit damit, Daten manuell in ein anderes System zu kopieren | Sie bauen eine individuelle Integration auf den Kern | Das Problem liegt an der Grenze zwischen den Systemen, nicht im Kern |
| Der Prozess ist der Grund, warum Kunden Sie wählen, nicht die Konkurrenz | Sie bauen Individualsoftware für dieses Teilstück | Ein Standardpaket bringt Sie auf Marktniveau |
| Sie brauchen ein einfaches Backoffice über einer Standardplattform (z. B. Online-Shop) | Sie behalten den Kern, fügen ein individuell gebautes Panel hinzu | Der Kern bleibt leicht aktualisierbar |
| Sie wissen noch nicht, welchen Prozess Sie automatisieren möchten | Sie beginnen mit einem schriftlichen Discovery, nicht mit einer Code-Bestellung | Ein falscher Scope kostet mehr als ein Monat Analyse |
Wie ein erster ernsthafter Build aussieht — und worauf Sie bei einem Angebot achten
Ein erster ernsthafter Build beginnt nicht mit Code, sondern mit einem kurzen Discovery, das in einem Dokument mündet: was gebaut wird, was nicht, wie die Integrationen aussehen und wer was macht. Der erste Launch ist bewusst klein — ein einziger Ablauf, bis zum Ende durchgezogen. Code und Infrastruktur liegen von Tag eins an auf dem Konto des Kundenunternehmens.
Die Wartung endet nicht mit dem Launch: Abhängigkeiten veralten, Integrationen können brechen, wenn sich das ERP oder die e-Factura-Spezifikation ändert, und Sicherheitspatches sind nicht optional. Eine zwei bis drei Jahre lang „vergessene“ Software wird still und leise zum Risiko — das Wartungsbudget sollte schon im ersten Angebot besprochen werden.
- 01Festpreis vor jeder Discovery Der Aufwand wurde geraten, nicht gesehen
- 02Scope nur in mündlichen Gesprächen, nicht schriftlich Missverständnisse kommen erst bei der Lieferung ans Licht
- 03Der Code bleibt auf dem Konto des Anbieters Ohne Zugriff sind Sie unbegrenzt an ihn gebunden
- 04Einmaliger Launch, alles auf einmal Probleme kommen zu spät ans Licht
- 05Keine Diskussion darüber, was nach dem Launch kommt Das erste Problem wird zum Notfall, keine geplante Aufgabe
Quellen und weiterführende Lektüre.
Häufige Fragen
Wann lohnt es sich, Individualsoftware zu bauen, statt ein Standardtool zu kaufen?
Wenn der Prozess der Grund ist, warum Kunden sich für Sie und nicht für einen Wettbewerber entscheiden, oder wenn keine Kombination von Tools auf dem Markt genau den Ablauf abdeckt, den Sie brauchen. Für alles, was in Ihrer Branche üblich ist, ist es meist günstiger, zu kaufen und Ihren Prozess anzupassen.
Was bedeutet die Hybridvariante, und warum verpassen die meisten Unternehmen sie?
Das Standardtool, das Sie bereits nutzen, zu behalten und nur die fehlenden Teile individuell zu bauen — Integrationen, interne Panels, Automatisierungen. Das wird oft verpasst, weil die Diskussion als einzige Entscheidung zwischen „alles gekauft“ und „alles gebaut“ beginnt, obwohl die Entscheidung getrennt, Stück für Stück, getroffen wird.
Wie erkenne ich ein seriöses Angebot für die Entwicklung von Individualsoftware?
Beginnen Sie mit einem Discovery und einem schriftlich festgehaltenen Scope, nicht mit einem Festpreis, der schon im ersten Gespräch genannt wird. Schlagen Sie einen kleinen ersten Launch vor, keinen „Big Bang“ mit allem, was je erdacht wurde, und lassen Sie den Code von Tag eins an auf dem Konto Ihres Unternehmens.
Wer sollte bei einem Individualsoftware-Projekt Code und Infrastruktur besitzen?
Das Kundenunternehmen, nicht die ausführende Agentur. Der Code liegt auf dem Konto Ihrer Organisation, die Infrastruktur auf Ihrem Cloud-Konto, auch wenn die Agentur die tägliche Verwaltung übernimmt. So können Sie den Anbieter jederzeit wechseln, ohne zu verlieren, was Sie aufgebaut haben.
Lassen Sie uns schauen, was sich bei Ihnen automatisieren lässt.
Eine kostenlose 30-Minuten-Sitzung: Wir sagen Ihnen, was sich automatisieren lässt, wie lange es dauert und was es kostet – mit Festpreis nach dem Discovery-Gespräch.