„Was kostet es, diese Funktion noch einzubauen?“ klingt nach einer einfachen Frage. Bei bestehender Software ist sie häufig erst dann seriös zu beantworten, wenn klar ist, wie die Anwendung aufgebaut ist und wie gut sie sich verändern lässt.
Zwei äußerlich ähnliche Änderungswünsche können technisch völlig unterschiedlich sein. In einer gut strukturierten Anwendung ist eine neue Exportfunktion vielleicht klar abgegrenzt. In einem anderen System hängt dieselbe Funktion an mehreren Tabellen, einer veralteten Bibliothek und einem Deployment-Prozess, den nur noch eine Person kennt.
Bei bestehender Software kostet nicht nur die neue Funktion Geld. Auch die Unsicherheit der vorhandenen Codebasis hat einen Preis.
Warum ein Feature allein wenig über die Kosten verrät
Bei einer Neuentwicklung werden Anforderungen, Architektur und technische Basis gemeinsam geplant. Bei bestehender Software übernimmt ein Entwickler dagegen Entscheidungen, die bereits getroffen wurden.
- Programmiersprache und Framework
- Architektur
- Datenmodell
- Abhängigkeiten
- Deployment und Hosting
- Tests
- Sicherheitskonzept
- Schnittstellen
- Dokumentation und bekannte Sonderfälle
Diese Ausgangslage entscheidet darüber, ob eine Änderung direkt umgesetzt werden kann oder zunächst technische Vorarbeit nötig ist.
Die wichtigsten Kostentreiber bei bestehender Software
1. Verständlichkeit der Codebasis
Ein neuer Entwickler muss zunächst nachvollziehen können, wie die betroffene Funktion heute arbeitet. Klare Modulgrenzen, aussagekräftige Namen und nachvollziehbare Strukturen reduzieren diese Einarbeitungszeit.
2. Tests
Automatisierte Tests reduzieren nicht jede Form von Risiko, sie erleichtern aber die Prüfung, ob bestehende Funktionen nach einer Änderung weiterhin korrekt arbeiten.
Mit belastbaren Tests: Änderung umsetzen → Tests ausführen → gezielt nacharbeiten.
Ohne Tests: Änderung verstehen → Auswirkungen suchen → Testfälle rekonstruieren → manuell prüfen → Unsicherheit bewerten.
3. Technische Schulden
Technische Schulden entstehen unter anderem durch kurzfristige Workarounds, schlechte Dokumentation oder veraltete Abhängigkeiten. IBM beschreibt sie als zukünftige Kosten, die aus solchen technischen Kompromissen entstehen.
Für eine Weiterentwicklung bedeutet das: Ein neues Feature kann zusätzliche Arbeit auslösen, weil zunächst Altlasten stabilisiert oder refaktoriert werden müssen.
4. Abhängigkeiten und Framework-Versionen
Viele Anwendungen bestehen nicht nur aus eigenem Code. Sie nutzen Frameworks, Bibliotheken, Packages und externe Dienste.
Wenn zentrale Komponenten veraltet oder nicht mehr unterstützt sind, kann eine scheinbar kleine Änderung ein Update mehrerer technischer Ebenen erforderlich machen.
GitHub stellt beispielsweise Dependency-Graphen und Dependabot-Funktionen bereit, um verwendete Abhängigkeiten und bekannte Schwachstellen besser sichtbar zu machen. Das zeigt, wie relevant die Abhängigkeitsstruktur für Wartbarkeit und Sicherheit ist.
5. Datenbank und Datenmigration
Ändert ein Feature nur die Darstellung, bleibt die Datenbank möglicherweise unberührt. Werden jedoch neue Entitäten, Statuswerte oder Beziehungen benötigt, muss das bestehende Datenmodell berücksichtigt werden.
- alte Daten sind uneinheitlich,
- Migrationen fehlen,
- historische Daten müssen weiter verfügbar bleiben,
- mehrere Systeme verwenden dieselben Daten.
6. Schnittstellen
Eine neue Funktion wirkt selten nur innerhalb der Anwendung, wenn ERP, CRM, Zahlungsanbieter, E-Mail-Dienste oder andere Systeme angebunden sind. Dann müssen Datenformate, Fehlerfälle, Authentifizierung und mögliche Änderungen auf beiden Seiten geprüft werden.
7. Deployment und Infrastruktur
Auch fertig programmierter Code muss sicher in Produktion kommen. Ein dokumentierter Deployment-Prozess mit Staging, Versionierung und Rückfallmöglichkeit reduziert das Risiko.
8. Sicherheitsanforderungen
Bei einer Übernahme oder Modernisierung sollte nicht nur geprüft werden, ob eine Anwendung funktioniert. Zugriffe, Secrets, Dependencies und externe Komponenten gehören ebenfalls zur technischen Ausgangslage.
OWASP empfiehlt unter anderem Transparenz über verwendete Softwarekomponenten sowie ein kontrolliertes Secrets Management. Beides kann bei älteren Anwendungen zusätzliche Aufwände sichtbar machen, die für einen sicheren Weiterbetrieb relevant sind.
Warum ein seriöser Anbieter nicht sofort einen Festpreis nennt
Bei einer unbekannten Bestandssoftware wäre ein sofortiger Festpreis oft eine Wette auf den Zustand der Codebasis.
- Der Anbieter kalkuliert einen großen Risikopuffer ein.
- Oder der Preis wirkt zunächst günstig und wächst später über Nachträge.
Eine bessere Grundlage ist eine begrenzte technische Analyse.
Was in einer technischen Erstprüfung betrachtet werden sollte
- Zugriff auf Repository und Quellcode
- Projektstruktur und Architektur
- Framework- und Laufzeitversionen
- Dependencies
- Datenbank
- Tests
- Build und Deployment
- Hosting
- Authentifizierung und Rollen
- Schnittstellen
- Dokumentation
- bekannte Bugs und technische Schulden
Aus welchen Arbeitsblöcken sich die Kosten zusammensetzen
1. Analyse: vorhandene Lösung und Auswirkungen verstehen.
2. Stabilisierung: notwendige technische Voraussetzungen schaffen.
3. Entwicklung: gewünschte Funktion umsetzen.
4. Tests: neue und bestehende Abläufe prüfen.
5. Deployment: Änderung sicher ausrollen und überwachen.
6. Dokumentation: neue technische und fachliche Entscheidungen festhalten.
Bei einer gut gepflegten Anwendung kann der zweite Block sehr klein sein. Bei einem technisch schwierigen System kann er dagegen einen erheblichen Teil des Projekts ausmachen.
Wie Unternehmen die Kosten langfristig reduzieren können
- Repository und Zugänge gehören organisatorisch zum Unternehmen.
- Deployments werden dokumentiert.
- Kritische Geschäftslogik wird beschrieben.
- Abhängigkeiten werden regelmäßig aktualisiert.
- Tests werden für wichtige Abläufe ergänzt.
- Technische Schulden werden sichtbar priorisiert statt nur gesammelt.
- Änderungen werden schrittweise statt in seltenen Großreleases durchgeführt.
Die Kostenfrage besser stellen
Statt nur zu fragen:
Was kostet Feature X?
ist bei Bestandssoftware oft hilfreicher:
Was müssen wir über das bestehende System wissen, damit Feature X sicher und wirtschaftlich umgesetzt werden kann?
Die zweite Frage führt deutlich schneller zu einer belastbaren Kalkulation.
Fazit
Die Kosten einer Softwareweiterentwicklung entstehen nicht nur durch neue Funktionen. Entscheidend ist, wie gut sich die bestehende Anwendung verstehen, testen, verändern und ausrollen lässt.
Eine saubere technische Erstprüfung ist deshalb kein unnötiger Zusatzaufwand. Sie reduziert Unsicherheit und hilft, Entwicklungsbudget dort einzusetzen, wo es tatsächlich Nutzen erzeugt.
Häufige Fragen
Was kostet die Weiterentwicklung bestehender Software?
Die Kosten hängen stark vom technischen Zustand der Anwendung, dem gewünschten Umfang, Tests, Abhängigkeiten, Datenbank, Schnittstellen und Deployment ab. Eine belastbare Schätzung ist meist erst nach einer technischen Erstprüfung möglich.
Warum kann ein kleines Feature teuer werden?
Wenn die betroffene Funktion stark mit anderen Bereichen gekoppelt ist, Tests fehlen oder veraltete Abhängigkeiten zunächst aktualisiert werden müssen, entsteht zusätzlicher Analyse- und Stabilisierungsaufwand.
Was sind technische Schulden?
Technische Schulden bezeichnen zukünftigen Mehraufwand, der durch kurzfristige technische Kompromisse, schlechte Dokumentation, veralteten Code oder ähnliche Entscheidungen entsteht.
Braucht man vor einer Weiterentwicklung ein Audit?
Nicht für jede Kleinigkeit. Bei einer unbekannten oder länger nicht gepflegten Anwendung ist eine begrenzte technische Analyse jedoch oft sinnvoll, um Risiken und Aufwand belastbar einzuschätzen.