Eigenentwicklung ist stark, aber nicht immer vernünftig
Standardsoftware deckt 70 % ab. Die letzten 30 % wirken oft wie der Grund, warum eine Eigenentwicklung „nötig" ist. In Wahrheit liegt der Hebel meistens dort, wo man sich diese Frage zuerst stellt: Sind die 30 % wirklich Geschäftsdifferenzierung, oder nur ein Excel-Prozess, der nie hinterfragt wurde?
Gute Digitalisierung beginnt mit der Frage, was nicht gebaut werden muss. Custom Software ist ein starkes Werkzeug, aber sie bringt Verantwortung: Architektur, Tests, Dokumentation, Betrieb, Wartung, Übergabefähigkeit. Wer das nicht von Anfang an mitplant, hat in zwei Jahren ein Tool, das niemand mehr verstehen will.
Was oft falsch läuft
100 % neu bauen. Statt Standard zu konfigurieren, wird komplett von Null entwickelt. Das ist fast immer teurer als ein hybrides Vorgehen.
Keine Rechteklärung. Wem gehört der Code? Wer darf ihn weitergeben? Was passiert bei Anbieterwechsel?
Kein Exit. Ohne Übergabefähigkeit ist Custom Software eine teure Abhängigkeit.
Kein Budget für Betrieb. Entwicklung ist 30 % der Lebenszykluskosten. Betrieb, Wartung und Anpassung sind die anderen 70 %.
Die drei Wege
Standard konfigurieren
ERPNext, M365, WordPress, WooCommerce, Zammad, Amelia. Konfiguration, Templates, Workflows. Schnell, günstig, übergabefähig, und langweilig im positiven Sinn.
Standard plus Custom-Modul
Standard bleibt Standard, ein klar abgegrenztes Modul wird ergänzt. Beispiele: ERPNext mit Schweizer Lohn-Schnittstelle, WordPress mit Custom-Booking-Logik, M365 mit Microsoft-Graph-Integration. Hier liegt der Sweet Spot für viele KMU.
Kompletter Custom-Build
Nur dort, wo Standard wirklich aufhört: einzigartiger Geschäftsprozess, regulierte Domäne, echte Differenzierung. Mit dokumentierter Architektur, Tests und Übergabeplan von Tag eins.
Build-vs-Buy-Matrix
| Kriterium | Standard | Standard + Modul | Custom |
|---|---|---|---|
| Time-to-Value | Wochen | Monate | Monate bis Jahr |
| Initialkosten | tief | mittel | hoch |
| Betriebskosten | tief | mittel | mittel bis hoch |
| Anbieter-Risiko | tief (viele Optionen) | mittel | hoch (eigene Verantwortung) |
| Geschäftsdifferenzierung | gering | mittel | hoch |
| Übergabefähigkeit | hoch | hoch (bei sauberer Trennung) | nur mit Disziplin |
| Eignung KMU | sehr hoch | hoch | nur bei klarer Begründung |
Eigentum und Übergabefähigkeit
Bei jeder Custom-Entwicklung müssen drei Fragen schriftlich beantwortet sein, bevor Code geschrieben wird:
- Wem gehört der Code? Vollständige Übertragung, Lizenz, Co-Ownership.
- Wo liegt das Repository? Beim Kunden, beim Dienstleister, gemeinsam, und mit welchem Zugriff.
- Wie sieht der Exit aus? Übergabe-Dokumentation, Build-Anleitung, Deploy-Doku, Test-Suite, Lauffähigkeit ohne den ursprünglichen Entwickler.
Wenn ein Anbieter diese Fragen nicht beantworten will, ist nicht der Stundensatz das Problem.
Beispiel aus dem KMU-Alltag
Ein Handelsbetrieb prüft, ob das interne Excel-Lager-Tool durch Custom Software abgelöst werden soll. Die Anforderung wirkt komplex: Multi-Lager, Reservationen, Kommissionierung, Lieferantenintegration. In der Discovery-Phase stellt sich heraus: 80 % davon kann ERPNext Stock-Modul bereits, die restlichen 20 % sind ein klar abgegrenztes Custom-Modul für die Lieferantenanbindung. Statt eines neunmonatigen Eigenbau-Projekts entsteht eine ERPNext-Konfiguration plus ein 4-Wochen-Modul. Kosten: ein Bruchteil. Übergabefähigkeit: deutlich besser.
Konkrete Empfehlung
Vor jeder Custom-Entwicklung steht ein Discovery-Workshop von einem halben bis ganzen Tag:
- Realer Prozess, nicht der gewünschte
- Was ist Differenzierung, was Bequemlichkeit?
- Was leistet Standard heute?
- Wo sind die echten Lücken?
- Was kostet Build, was kostet Buy, was kostet Hybrid?
- Wie sieht der Exit-Plan aus?
Erst danach entsteht ein Angebot, oder eine Empfehlung gegen die Entwicklung.
Wann wir helfen
Wir führen den Discovery-Workshop durch und sind ehrlich mit dem Ergebnis: Standard-Empfehlung wenn Standard reicht, Hybrid wenn Hybrid passt, Custom wenn es wirklich nötig ist. Teil unserer Leistung Custom-Software-Entwicklung. Eigene Proof-Points (sys-esign, sys-graph-mail, ERPNext-Module) zeigen wir auch in Engineering. Wie ein realer Custom-Build aussehen kann, illustriert das Szenario ERPNext mit Hot-Standby.
Häufige Fragen
Wann lohnt Custom Software? Wenn Standard nicht das Geschäftsmodell trägt, nicht, wenn Standard nur „nicht ganz passt".
Wem gehört der Code? Schriftlich vor Projektstart klären. Standardlösung: vollständig dem Kunden, mit gemeinsamer Repository-Pflege.
Was kostet Discovery? Klar abgegrenzt als Projektarbeit. Discovery ohne Verkaufsdruck ist günstiger als Custom-Build aus falschen Gründen.
Wie wird Wartung geregelt? Vor Projektstart als Wartungsmandat oder Stunden-Kontingent. Nicht „wir sehen dann".
Was passiert bei Anbieterwechsel? Der Code muss ohne Originalentwickler buildbar, deploybar und lauffähig sein. Das ist eine Anforderung, kein Bonus.