Was kostet Softwareentwicklung wirklich? Eine Kalkulationsgrundlage für KMU
Softwarekosten lassen sich nicht pauschal beantworten - aber sie lassen sich nachvollziehbar herleiten. So kalkulieren Entwicklungspartner deinen Festpreis, und so erkennst du ein realistisches Angebot.
"Was kostet eine App?" ist eine der am häufigsten gestellten und am schlechtesten beantwortbaren Fragen im B2B-Softwaregeschäft. Die ehrliche Antwort lautet: Das hängt vollständig von deinen Anforderungen ab. Aber genau diese Anforderungen lassen sich in eine nachvollziehbare Kalkulation übersetzen. Wenn man weiß, wie.
Warum Pauschalpreise nicht funktionieren
Zwei Projekte, die sich auf den ersten Blick ähneln ("eine App für unsere Kunden"), können im Aufwand um Zehnerpotenzen auseinanderliegen, je nachdem, wie viele Funktionen, Integrationen, Nutzerrollen und Sonderfälle tatsächlich gebraucht werden. Jeder Anbieter, der ohne Anforderungsdokument einen Pauschalpreis nennt, rät entweder oder kalkuliert einen so hohen Risikoaufschlag ein, dass du am Ende drauflegst.
Die Bausteine einer seriösen Kalkulation
1. Anzahl und Komplexität der Anforderungen
Jede einzelne Funktion lässt sich in Entwicklertage übersetzen, von "einfach" (ein Formular, ca. 0,5-1 Tag) bis "komplex" (Berechnungslogik mit mehreren Abhängigkeiten, mehrere Tage). Je präziser das Anforderungsdokument, desto genauer diese Schätzung.
2. Integrationen und Schnittstellen
Anbindungen an bestehende Systeme (ERP, CRM, Zahlungsdienstleister) sind häufig der größte unterschätzte Kostenfaktor, weil ihr Aufwand stark von der Qualität der jeweiligen Drittanbieter-Dokumentation abhängt. Eine saubere REST-API mit gutem Sandbox-Zugang kostet oft nur wenige Tage, eine veraltete SOAP-Schnittstelle eines Alt-ERP-Systems kann leicht das Mehrfache verschlingen.
3. Nicht-funktionale Anforderungen
Konkrete Skalierungs- und Performanceanforderungen, Datenschutz-Compliance, Verfügbarkeitsgarantien - diese Anforderungen werden in Lastenheften oft vergessen, treiben den Aufwand aber erheblich. Eine Anwendung, die nachweislich DSGVO-konform mit Auftragsverarbeitung, Löschkonzept und Verschlüsselung im Ruhezustand arbeiten muss, kostet spürbar mehr als eine funktional identische Version ohne diese Anforderungen.
4. Team-Seniorität und Setup
Wer die Arbeit ausführt, wirkt sich direkt auf Tagessätze und Geschwindigkeit aus. Ein erfahrenes Senior-Team liefert oft schneller und mit weniger Nacharbeit, auch wenn der Tagessatz höher liegt - unter dem Strich kann das günstiger sein als ein niedriger Tagessatz mit mehr Iterationen und Bugfixing.
5. Risikopuffer für Unklarheiten
Jede Lücke oder jeder Widerspruch im Anforderungsdokument zwingt den Anbieter, einen Puffer einzukalkulieren. Oder das Risiko stillschweigend auf dich zu verlagern, in Form von Nachforderungen während des Projekts.
6. Testing, Abnahme und Dokumentation
Häufig unterschätzt: die Zeit für Testfälle, Bugfixing vor der Abnahme und eine Übergabedokumentation, die auch ein anderes Team später verstehen kann. Bei sauber definierten Abnahmekriterien lässt sich dieser Aufwand vorab realistisch einplanen, statt ihn als nachträglichen Streitpunkt zu erleben - ein weiterer Grund, warum Lastenheft und Pflichtenheft sich ergänzen müssen, siehe Lastenheft vs. Pflichtenheft.
Ein Rechenbeispiel: Vom Lastenheft zur Zahl
Angenommen, ein Lastenheft für ein einfaches Kundenportal enthält folgende Kernanforderungen: Login mit E-Mail und Passwort (1 Tag), eine Übersichtsseite mit Filterfunktion (2 Tage), ein Formular zum Hochladen von Dokumenten inklusive Validierung (2 Tage), eine Anbindung an eine bestehende REST-Schnittstelle des Buchhaltungssystems (3 Tage) sowie Testing und Übergabedokumentation (2 Tage). Macht in Summe 10 Entwicklertage.
Bei einem Tagessatz von 700 € ergibt das einen Grundpreis von 7.000 €. Ist das Anforderungsdokument lückenhaft, etwa weil unklar bleibt, was bei einem fehlgeschlagenen Upload passieren soll oder welche Berechtigungen verschiedene Nutzerrollen haben, kalkuliert ein seriöser Anbieter einen Risikoaufschlag von 20-40 % ein, um diese Unklarheiten abzufedern. Aus 7.000 € werden dann schnell 9.000-10.000 €, ohne dass sich am tatsächlichen Funktionsumfang etwas geändert hätte. Genau dieser Aufschlag verschwindet, sobald die offenen Punkte im Anforderungsdokument geklärt sind, bevor das Angebot eingeholt wird.
Kosten nach dem Launch nicht vergessen
Der Festpreis für die Erstentwicklung ist nur ein Teil der Gesamtkosten. Hosting, Sicherheitsupdates, Monitoring und kleinere Anpassungen laufen nach dem Go-Live weiter und werden bei der ersten Kalkulation oft komplett ausgeblendet. Als grobe Orientierung kalkulieren viele Anbieter 15-25 % der ursprünglichen Entwicklungskosten pro Jahr für Wartung und laufenden Betrieb ein - wie sich dieser Betrag im Detail zusammensetzt und worauf du in einem Wartungsvertrag achten solltest, erklärt der Artikel Wartung & Weiterentwicklung nach dem Launch.
Illustrative Preisspannen nach Projektgröße
Die folgenden Zahlen sind illustrative Richtwerte auf Basis typischer KMU-Projekte - keine verbindliche Kalkulation und kein Angebot. Dein tatsächlicher Preis hängt vollständig von deinem konkreten Anforderungsdokument ab.
| Projektgröße | Typischer Umfang | Illustrative Preisspanne | Typische Laufzeit |
|---|---|---|---|
| Klein | Einfaches internes Tool, ein bis zwei Nutzerrollen, keine externen Integrationen | ca. 8.000 - 25.000 € | 4-8 Wochen |
| Mittel | Kundenportal oder SaaS-MVP mit mehreren Rollen, 1-2 Integrationen (z. B. Zahlungsanbieter) | ca. 25.000 - 70.000 € | 2-4 Monate |
| Groß | Komplexe Plattform mit mehreren Integrationen, Compliance-Anforderungen, hoher Skalierungsbedarf | ca. 70.000 - 200.000+ € | 4-9 Monate |
Diese Bandbreiten dienen ausschließlich der Einordnung. Innerhalb jeder Kategorie können Integrationen, Compliance-Vorgaben oder Sonderanforderungen den Preis deutlich nach oben verschieben - genau deshalb ersetzt keine Tabelle ein individuelles Anforderungsdokument.
Wie sich der Preis grob zusammensetzt
Eine einfache Denkweise, um die Kalkulation eines Anbieters nachzuvollziehen: Der Grundpreis ergibt sich aus der Summe der geschätzten Entwicklertage mal Tagessatz. Auf diesen Grundpreis kommen dann Zuschläge, die sich aus den oben genannten Faktoren ergeben - grob gesagt: je mehr Integrationen, je strengere Compliance-Anforderungen und je größer die Lücken im Anforderungsdokument, desto höher der Aufschlag auf den reinen Entwicklungsaufwand. Bei einem gut dokumentierten Projekt liegt dieser Aufschlag oft im niedrigen zweistelligen Prozentbereich, bei einem vagen Briefing kann er 50 % und mehr des Grundpreises ausmachen - schlicht weil der Anbieter sich gegen das Unbekannte absichern muss.
Die Faustregel
Der wichtigste Hebel auf den Preis ist nicht Verhandlungsgeschick, sondern die Qualität deiner Anforderungen. Ein präzises, vollständiges Anforderungsdokument senkt den Risikopuffer jedes seriösen Anbieters spürbar, weil er nicht mehr für Unklarheiten kalkulieren muss, die er nicht selbst verschuldet hat. Mehr dazu, wie du dieses Dokument ohne IT-Hintergrund selbst erstellst, findest du im Leitfaden für Fachabteilungen.
Wie du ein realistisches Angebot erkennst
Ein seriöses Festpreisangebot:
- bezieht sich konkret auf dein Anforderungsdokument, nicht auf eine vage Beschreibung
- schlüsselt den Preis nach Funktionsblöcken auf, statt nur eine Gesamtsumme zu nennen
- benennt explizit, was nicht enthalten ist
- enthält einen definierten Prozess für nachträgliche Änderungen (Change-Request)
- nennt Zahlungstermine, die an überprüfbare Meilensteine gekoppelt sind, statt nur an Kalenderdaten
Fehlt eines dieser Elemente, ist das Angebot entweder zu unpräzise kalkuliert oder bewusst niedrig angesetzt, um später über Nachforderungen draufzusatteln. Welche Klauseln du konkret im Vertrag einfordern solltest, damit der genannte Preis auch wirklich hält, erklärt der Artikel Wie du einen Festpreis-Vertrag verhandelst.
Warum Festpreis-Angebote oft weiter auseinanderliegen als erwartet
Holst du drei Angebote für dasselbe grobe Vorhaben ein, wirst du regelmäßig Preisspannen erleben, die um den Faktor zwei oder drei auseinanderliegen. Das liegt selten an unterschiedlicher Unseriosität, sondern meist daran, dass jeder Anbieter die Lücken in deinem Anforderungsdokument unterschiedlich interpretiert und unterschiedlich hohe Risikopuffer dafür einkalkuliert. Je präziser das zugrunde liegende Dokument, desto enger liegen die Angebote beieinander - und desto besser lassen sie sich überhaupt fair vergleichen.
Fazit
Die Frage ist nicht "was kostet Software", sondern "was kostet die Umsetzung meiner spezifischen Anforderungen". Wer diese Anforderungen vor der Angebotseinholung klärt, bekommt nicht nur ein realistisches, sondern auch ein vergleichbares Angebot - die Grundlage für einen fairen Festpreis.
Häufig gestellte Fragen
Was kostet ein typisches Softwareprojekt für ein KMU?
Das hängt vollständig vom Funktionsumfang, den Integrationen und den Compliance-Anforderungen ab. Illustrative Richtwerte liegen zwischen ca. 8.000 € für ein einfaches internes Tool und über 200.000 € für eine komplexe Plattform mit mehreren Integrationen - eine verbindliche Aussage ist nur auf Basis eines konkreten Anforderungsdokuments möglich.
Warum unterscheiden sich Festpreisangebote verschiedener Anbieter oft stark?
Anbieter kalkulieren unterschiedlich hohe Risikopuffer für Lücken und Unklarheiten im Anforderungsdokument. Je vager die Anforderungen, desto größer die Preisspanne zwischen den Angeboten. Ein präzises, vollständiges Anforderungsdokument macht Angebote enger und besser vergleichbar.
Welcher Faktor treibt die Softwarekosten am stärksten?
Neben der reinen Funktionsanzahl sind es vor allem Integrationen zu bestehenden Systemen und nicht-funktionale Anforderungen wie Datenschutz-Compliance oder Skalierbarkeit, die in vielen Lastenheften vergessen werden, aber den Aufwand erheblich erhöhen können.
Woran erkenne ich, ob ein Festpreisangebot realistisch kalkuliert ist?
Ein realistisches Angebot bezieht sich konkret auf dein Anforderungsdokument, schlüsselt den Preis nach Funktionsblöcken auf, benennt explizit, was nicht enthalten ist, und enthält einen definierten Change-Request-Prozess für spätere Änderungen.
Verwandte Themen
- Wie du einen Festpreis-Vertrag verhandelst
- Festpreis vs. Time & Material - welches Modell passt zu deinem Projekt?
- Software-Anforderungen dokumentieren ohne IT-Hintergrund
- Wartung & Weiterentwicklung - was nach dem Launch niemand einplant
Lade dein Anforderungsdokument hoch - Pairlios KI prüft es kostenlos auf Vollständigkeit und gibt eine erste Aufwandseinschätzung. Jetzt kostenlos prüfen →