Web-App oder bestehende Software? Wie Sie die richtige Entscheidung treffen

Die teuerste Entscheidung fällt vor dem ersten Code

Die Idee kommt oft in einem Meeting: „Wir brauchen eine eigene Software dafür." Manchmal stimmt das. Häufig gibt es aber bereits eine Standardlösung, die den Großteil der Anforderungen abdeckt – mit fertiger Dokumentation, laufendem Support und einer aktiven Nutzercommunity. Die Frage, ob eine eigene Web-App wirklich die richtige Antwort ist, stellen sich viele Unternehmen gar nicht erst – und bereuen das später.

Wir beraten Mittelständler in dieser Entscheidung regelmäßig und empfehlen Eigenentwicklung nur dann, wenn ein konkreter, messbarer Wettbewerbsvorteil entsteht, den keine verfügbare Standardlösung liefern kann. Das klingt streng, ist aber die ehrlichste Grundlage für eine nachhaltige Software-Entscheidung. Eine selbst entwickelte Web-App bedeutet nicht nur einmalige Entwicklungskosten – sie bedeutet laufende Wartung, Updates, Sicherheits-Patches und Weiterentwicklung, für die dauerhaft Expertise vorhanden sein muss.

Website, Web-App, SaaS: Was ist was?

Die Begriffe werden häufig durcheinandergeworfen – was zu falschen Erwartungen und falschen Budgets führt.

Eine Website ist primär ein Kommunikationsinstrument. Sie präsentiert ein Unternehmen, seine Leistungen, seine Kontaktmöglichkeiten. Nutzer konsumieren Inhalte, sie interagieren kaum. Technisch ist eine Website oft relativ einfach: HTML, CSS, ein CMS. Für die meisten Unternehmen ist eine professionell gestaltete und gepflegte Website ausreichend – und deutlich günstiger als eine Web-App.

Eine Web-App dagegen ermöglicht Nutzerinteraktionen, verarbeitet Daten und bildet Geschäftsprozesse ab. Nutzer melden sich an, erfassen Daten, sehen personalisierte Ansichten, starten Prozesse – etwa ein Kundenportal, ein Bestellsystem, eine interne Projektverwaltung oder ein Konfigurator. Web-Apps brauchen eine Datenbankarchitektur, Nutzerverwaltung, Rollenkonzepte, Sicherheitsmechanismen und deutlich mehr Entwicklungsaufwand als eine Website.

SaaS (Software as a Service) ist eine Web-App, die als Dienst für viele Kunden gleichzeitig betrieben wird. Der Anbieter entwickelt und betreibt die Software, Kunden zahlen eine wiederkehrende Gebühr. Für viele Anforderungen gibt es bereits ausgereifte SaaS-Lösungen – CRM, Projektmanagement, Buchhaltung, HR. Vor einer Eigenentwicklung lohnt immer die Frage, ob eine SaaS-Lösung den Großteil der Anforderungen abdeckt.

Der Make-or-Buy-Entscheidungsrahmen

• Anforderungen klar und vollständig definieren: Was soll die Software leisten, welche Nutzergruppen gibt es, welche Prozesse sollen abgebildet werden? Ohne Anforderungsdokument ist jeder Vergleich zwischen Eigenentwicklung und Standardsoftware Spekulation.
• Markt auf Standardlösungen prüfen: Gibt es SaaS- oder Open-Source-Lösungen, die die Anforderungen zu einem relevanten Teil erfüllen? Selbst wenn keine Lösung zu 100 Prozent passt, lohnt der Vergleich der Total Cost of Ownership beider Optionen.
• Echten Differenzierungsbedarf identifizieren: Eigenentwicklung lohnt sich, wenn ein konkreter Prozess- oder Wettbewerbsvorteil entsteht, den keine Standardsoftware abbilden kann. Lässt sich der Vorteil nicht konkret benennen, fehlt die Grundlage für eine Eigenentwicklung.
• Gesamtkosten realistisch kalkulieren: Eigenentwicklungskosten bestehen nicht nur aus der initialen Entwicklung, sondern aus laufender Wartung, Sicherheits-Updates, Weiterentwicklung und Hosting über mindestens drei bis fünf Jahre.
• Testaufwand und Rollout einplanen: Systematisches Testing, Schulungsaufwand, Datenmigration und Parallelbetrieb während der Umstellung können leicht 30 bis 50 Prozent der Entwicklungskosten ausmachen.
• Entscheidung dokumentieren und kommunizieren: Die Entscheidung für oder gegen Eigenentwicklung gehört schriftlich festgehalten, inklusive Begründung und geprüfter Alternativen.

Typische Stolperfallen bei der Web-App-Entwicklung

• Kein vollständiges Anforderungsdokument: Nachträgliche Anforderungen sind der häufigste Grund für Budgetüberschreitungen.
• Kein Staging-System: Wer Änderungen direkt auf dem Live-System testet, riskiert Ausfälle und Datenverlust.
• Unterschätzter Testaufwand: Funktionstests, Usability-Tests, Lasttests und Browser-Kompatibilitätsprüfung brauchen Zeit und Budget.
• Fehlende Rollenverwaltung: Wird nicht von Anfang an geplant, wer was sehen, bearbeiten oder löschen darf, wird das nachträglich zum komplexen Umbau.
• Keine Datenschutz-Konzeption: DSGVO-Anforderungen müssen in die Architektur einfließen, nicht als Nachgedanke.
• Kein Übergabe-Konzept: Ohne Dokumentation, Quellcode-Übergabe und verständliche Architektur bleibt die Software eine Blackbox.
• Zu ambitionierter Erststart: Version 1.0 sollte die Kernfunktionen abdecken, nicht alle Wünsche.
• Kein klarer Abnahme-Prozess: Ohne definierten Prozess gibt es am Ende Diskussionen statt Ergebnisse.

Ein häufiges Muster: Ein Unternehmen plant ein internes Verwaltungstool, die Anforderungsliste wächst im Projektlauf kontinuierlich, jede Abteilung ergänzt Wünsche. Version 1.0 soll am Ende alles können. Neun Monate Entwicklung später ist das Budget aufgebraucht, das Tool noch nicht fertig, und die eigentlichen Kernprozesse sind unter Zusatzfeatures vergraben. Der Ausweg ist ein MVP-Ansatz: Die absoluten Kernfunktionen werden in Version 1.0 umgesetzt, mit echten Nutzern getestet und iterativ erweitert. Das kostet initial weniger, liefert früher echten Nutzen und verhindert, an den Bedürfnissen vorbeizuentwickeln.

Wann Eigenentwicklung wirklich sinnvoll ist

Es gibt klare Fälle, in denen Eigenentwicklung die richtige Entscheidung ist: wenn ein Prozess so spezifisch für das Geschäftsmodell ist, dass keine Standardlösung annähernd passt; wenn durch die Software ein messbarer Wettbewerbsvorteil entsteht – schnellere Prozesse, besserer Kundenservice, geringere Fehlerquoten; wenn eine SaaS-Lösung langfristig teurer wäre als eine Eigenentwicklung; oder wenn Datenschutz- oder Compliance-Anforderungen keine Cloud-Lösung erlauben.

Die Faustregel: Kann ein Unternehmen im Gespräch nicht in zwei Sätzen erklären, welchen konkreten Vorteil die Eigenentwicklung gegenüber Standardsoftware bringt, ist Eigenentwicklung wahrscheinlich nicht die richtige Antwort. Das ist keine Absage an die Zusammenarbeit – es ist Ehrlichkeit im Interesse des Kunden.