„Was kostet eine Software?“ ist eine berechtigte Frage. Mit einer einzelnen Zahl lässt sie sich trotzdem nicht beantworten. Eine Urlaubsverwaltung für ein Team und ein Kundenportal mit Anbindung an Warenwirtschaft und Buchhaltung heißen beide „Software“. Im Aufwand liegen Welten dazwischen.
Deshalb findest du in diesem Ratgeber keine Preisliste. Du erfährst, welche Faktoren den Preis bestimmen, wie die Abrechnungsmodelle funktionieren, welche Kosten nach dem Go-live dazukommen und wie du Angebote vergleichbar machst. Wenn du Software entwickeln lassen willst, kannst du dein Vorhaben damit so beschreiben, dass eine Schätzung belastbar wird.
Die konkrete Zahl liefert der Projekt-Rechner: Du beantwortest bis zu acht kurze Fragen und bekommst per E-Mail eine Kostenspanne, die ungefähre Umsetzungsdauer und die Punkte, die den Aufwand bei dir am stärksten treiben.
Wie sich der Preis zusammensetzt
Softwareentwicklung wird fast immer über den Aufwand kalkuliert: Wie viele Personentage braucht das Team für Konzept, Design, Entwicklung, Tests, Projektmanagement und Inbetriebnahme? Der Preis ergibt sich aus diesem Aufwand und dem Tagessatz. Auch ein Festpreis ist im Kern eine Aufwandsschätzung, ergänzt um einen Aufschlag für das Risiko, das der Anbieter übernimmt.
Das Programmieren ist dabei nur ein Teil. Anforderungen klären, Oberflächen entwerfen, testen, abstimmen und ausrollen kosten Zeit, die in keiner Feature-Liste auftaucht. Wer nur die Programmierung im Blick hat, unterschätzt den Gesamtaufwand.
Die Kostentreiber im Überblick
Zehn Faktoren bestimmen, wie viel Aufwand in deiner Software steckt. Die ersten sieben fragt auch der Projekt-Rechner ab, weil sie den größten Unterschied machen.
1. Art der Anwendung
Eine interne Fachanwendung hat bekannte Nutzer im eigenen Unternehmen. Ein Kunden- oder Partnerportal öffnet sich für externe Nutzer, mit Login, Registrierung und Support-Fällen. Ein SaaS-Produkt muss für viele Kunden gleichzeitig funktionieren, mit getrennten Daten je Kunde, Abrechnung und eigenem Onboarding. Mit jedem Schritt steigt der Grundaufwand, noch bevor die erste Fachfunktion gebaut ist.
2. Prozessumfang und Funktionen
Der Umfang ist der größte Hebel. Jeder Ablauf, den die Software abbildet, braucht Eingabemasken, Geschäftsregeln, Fehlerfälle und Tests. Ein fokussiertes erstes Modul für einen Kernprozess ist etwas völlig anderes als eine Anwendung, die mehrere Abteilungen verbindet. Viele Projekte starten deshalb mit einem Kernprozess und bauen danach aus.
3. Schnittstellen
Buchhaltung, ERP, CRM, E-Mail-Versand, Zahlungsanbieter: Jede Anbindung braucht Abstimmung mit dem anderen System, Fehlerbehandlung und eigene Tests. Wie gut die Gegenseite dokumentiert ist, entscheidet viel. Eine saubere REST-API ist schnell angebunden, ein Altsystem, das nachts eine CSV-Datei exportiert, nicht. Mit der Zahl der Systeme wächst außerdem der Aufwand, alles zusammen zu prüfen. Wie wir Anbindungen umsetzen, steht auf der Seite zur API-Integration.
4. Rollen und Rechte
Sehen alle Nutzer dasselbe, ist das Rechtekonzept schnell gebaut. Mit Rollen wie Team, Leitung und Administration wächst die Zahl der Ansichten und Prüfungen. Richtig aufwendig wird es bei Rechten je Datensatz, Freigabeprozessen oder mehreren Mandanten, die strikt voneinander getrennt sein müssen. Das braucht ein eigenes Berechtigungskonzept, und jede Regel muss getestet werden.
5. Datenmigration
Sollen Daten aus einem Altsystem übernommen werden, heißt das: Felder zuordnen, Dubletten und Altlasten bereinigen, den Umzug mehrmals proben. Stammdaten wie Kunden und Artikel sind überschaubar. Wer auch Bewegungsdaten und die komplette Historie mitnehmen will, braucht deutlich mehr Probeläufe. Wie sauber die Daten im Altsystem sind, weiß vorher selten jemand genau. Deshalb gehört hier ein Puffer in jede Planung.
6. Oberfläche und Design
Bewährte UI-Komponenten, leicht an dein Erscheinungsbild angepasst, sind der günstigste Weg und für interne Werkzeuge oft völlig ausreichend. Liefert ihr ein fertiges Design, wird es umgesetzt. Ein eigenes Konzept mit Nutzerrecherche, Entwürfen und Abstimmungsrunden lohnt sich vor allem dort, wo externe Nutzer die Software freiwillig benutzen sollen.
7. Zusatzpakete: ERP, Abrechnung, Sprachen, KI
Manche Funktionen bringen so viele eigene Anforderungen mit, dass sie als eigene Pakete zählen: eine ERP-Anbindung, Abrechnung mit Abos und Rechnungen, eine mehrsprachige Oberfläche oder eine KI-Funktion wie ein Assistent oder eine Dokumentenanalyse. Plane nur ein, was sicher kommt. Was „vielleicht später“ kommt, sollte die Architektur zulassen, aber nicht im ersten Budget stehen.
8. Compliance: DSGVO, Barrierefreiheit, Branchenvorgaben
Verarbeitet die Software personenbezogene Daten, gehören Löschkonzept, Protokollierung, Zugriffsrechte und Verträge zur Auftragsverarbeitung dazu. Ob das Barrierefreiheitsstärkungsgesetz greift, hängt davon ab, ob du die Anwendung Verbrauchern anbietest und in welchem Bereich. Für viele interne Werkzeuge gilt es nicht. Wo es gilt, plane Barrierefreiheit von Anfang an ein, denn Nachrüsten ist teurer als Mitdenken. Branchen wie Versicherung, Gesundheit oder Finanzen bringen eigene Vorgaben mit, die Dokumentation und Tests erweitern.
9. Qualitätssicherung
Automatisierte Tests, Code-Reviews, Testumgebungen und Abnahmen kosten Zeit. Genau deshalb fallen sie in knappen Angeboten als Erstes weg. Das rächt sich später: Ohne Tests wird jede Änderung riskant und damit teuer. Frag in jedem Angebot nach, welche Tests enthalten sind und wer die Abnahme vorbereitet.
10. Team und Seniorität
Ein erfahrenes Team hat einen höheren Tagessatz, braucht für dieselbe Aufgabe aber oft weniger Tage und trifft Architekturentscheidungen, die später nicht teuer korrigiert werden müssen. Vergleiche deshalb nie nur Tagessätze, sondern immer den geschätzten Gesamtaufwand und wer konkret am Projekt arbeitet. Auch deine Seite zählt: Ein Ansprechpartner mit Entscheidungsbefugnis spart mehr Abstimmungsschleifen als jede Methode.
MVP, Fachanwendung, Plattform: drei Projekttypen im Vergleich
Die meisten Vorhaben lassen sich grob einem von drei Typen zuordnen. Die Tabelle zeigt, was jeweils typischerweise dazugehört und wie der Aufwand im Verhältnis zueinander liegt.
| Merkmal | MVP | Fachanwendung | Plattform |
|---|---|---|---|
| Ziel | Idee mit echten Nutzern testen | einen internen Ablauf digitalisieren | viele Nutzergruppen und Kunden bedienen |
| Funktionsumfang | ein Kernablauf, nur das Nötigste | mehrere zusammenhängende Abläufe | viele Module, oft mehrere Produktbereiche |
| Nutzer und Rechte | wenige Rollen | Rollen nach Abteilung und Funktion | Mandanten, feine Rechte, Selbstregistrierung |
| Schnittstellen | keine oder eine | einige, oft ERP oder Buchhaltung | viele, teils in beide Richtungen |
| Datenmigration | meist keine | häufig Stammdaten, oft auch Historie | je nach Herkunft umfangreich |
| Betrieb | einfache Infrastruktur | stabiler Betrieb mit Wartung | Skalierung, Monitoring, Bereitschaft |
| Relativer Aufwand | gering | mittel bis hoch | hoch bis sehr hoch |
MVP: Ein Minimum Viable Product beantwortet eine Frage: Nutzen Menschen das wirklich? Es ist bewusst klein, aber nicht schlampig gebaut. Funktioniert die Idee, ist es die Basis für den Ausbau und keine Wegwerfsoftware. Wie du den Umfang schneidest, zeigt unser Leitfaden zur MVP-Entwicklung.
Fachanwendung: Sie ersetzt Excel-Listen, E-Mail-Ketten oder ein Altsystem in einem klar umrissenen Bereich, etwa Disposition, Auftragsabwicklung oder Prüfprozesse. Der Aufwand steckt hier selten in der Oberfläche, sondern in Regeln, Ausnahmen und Schnittstellen.
Plattform: Portale und SaaS-Produkte bedienen viele Nutzergruppen, oft mit Selbstregistrierung, Abrechnung und hohen Anforderungen an Verfügbarkeit und Sicherheit. Hier wird der Betrieb zum eigenen Kostenblock. Bei der digitalen Versicherungsplattform für ENRA lag der Schwerpunkt zum Beispiel auf einer kurzen Abschlussstrecke, der Integration von Versicherungssystemen und einer performanten technischen Basis.
Planst du eine mobile App statt einer Web-Anwendung, kommen Store-Freigaben und Geräteunterschiede dazu. Die Besonderheiten stehen im Ratgeber App entwickeln lassen.
Festpreis, Aufwand oder agiler Festpreis?
Das Abrechnungsmodell ändert nicht, wie viel Arbeit in der Software steckt. Es legt fest, wer das Risiko trägt, wenn der Aufwand anders ausfällt als geschätzt.
| Modell | So funktioniert es | Passt, wenn | Darauf achten |
|---|---|---|---|
| Festpreis | fester Preis für einen fest beschriebenen Umfang | der Umfang im Lastenheft feststeht und sich wenig ändert | Risikoaufschlag im Preis; jede Änderung läuft über einen Change Request |
| Aufwand (Time & Material) | Abrechnung der tatsächlich geleisteten Stunden oder Tage | der Umfang noch offen ist oder sich laufend ändert | Budgetrisiko liegt bei dir; regelmäßige Aufwandsberichte und Schätzungen je Paket verlangen |
| Agiler Festpreis | fester Budgetrahmen, der Umfang wird innerhalb des Rahmens priorisiert | Ziel und Budget klar sind, Details aber im Projekt entstehen | klare Regeln, wie Funktionen getauscht werden; eine entscheidungsbefugte Person auf deiner Seite |
Ein Festpreis wirkt sicher, ist es aber nur, wenn der Umfang wirklich feststeht. Fehlt ein sauberes Lastenheft, preist der Anbieter die Unklarheit ein, oder jede Präzisierung wird zum Nachtrag. Abrechnung nach Aufwand ist ehrlicher, wenn noch vieles offen ist, verlangt aber Vertrauen und Transparenz. Der agile Festpreis verbindet beides: Das Budget steht, und ihr entscheidet laufend, welche Funktionen hineinpassen.
Bei nextlevels läuft es meist so: Du ermittelst im Projekt-Rechner eine erste Spanne. Im Erstgespräch schärfen wir gemeinsam den Umfang und benennen die Risiken. Nach einem Workshop oder einem Review deines Lastenhefts bekommst du ein Festpreisangebot.
Kosten nach dem Go-live: was in vielen Planungen fehlt
Die Entwicklung ist eine einmalige Investition, der Betrieb nicht. Diese Posten fehlen in vielen Kostenplanungen:
- Hosting und Infrastruktur: Server oder Cloud, Datenbanken, Backups, Monitoring sowie getrennte Test- und Produktivumgebungen.
- Wartung und Updates: Frameworks, Bibliotheken und Betriebssysteme bekommen laufend Sicherheitsupdates. Wer sie liegen lässt, sammelt technische Schulden, und das nächste große Update wird teuer.
- Lizenzen und Drittdienste: kostenpflichtige Bibliotheken, Kartendienste, E-Mail-Versand, Zahlungsanbieter und bei KI-Funktionen die Nutzungskosten der Modelle.
- Support und Weiterentwicklung: Fehlerbehebung, kleine Änderungen und neue Funktionen. Software, die gut ankommt, wird nach dem Go-live mehr genutzt und weiter ausgebaut.
- Interne Zeit: Abnahmen, Tests durch die Fachabteilung, Schulungen und Datenpflege kosten Arbeitszeit in deinem Team.
Rechne deshalb in Gesamtkosten über die Nutzungsdauer, nicht nur in Projektkosten. Der Fachbegriff dafür ist Total Cost of Ownership. Wie wir Betrieb und Wartung organisieren, beschreibt die Seite Integration, Deployment und Wartung.
Angebote vergleichbar machen: ohne Lastenheft geht es nicht
Wenn drei Anbieter für „dieselbe“ Software Angebote abgeben, liegen die Preise oft weit auseinander. Selten ist einer davon unseriös. Meist hat jeder etwas anderes verstanden: Der eine rechnet Tests und Projektmanagement ein, der andere nicht. Der eine plant eine Schnittstelle als einfachen Export, der andere als Abgleich in beide Richtungen.
Abhilfe schafft ein Lastenheft. Es beschreibt aus deiner Sicht, was die Software leisten soll: Ziele, Nutzergruppen, Abläufe, Schnittstellen, Datenmengen, Qualitätsanforderungen und was ausdrücklich nicht dazugehört. Alle Anbieter kalkulieren dann auf derselben Grundlage. Eine Vorlage und eine Anleitung findest du im Leitfaden Lastenheft und Pflichtenheft schreiben. Brauchst du dabei Unterstützung, erstellen wir das Lastenheft gemeinsam mit dir.
Prüfe in jedem Angebot zusätzlich diese Punkte:
- Welche Annahmen liegen der Schätzung zugrunde, und was ist ausdrücklich ausgeschlossen?
- Sind Konzeption, Design, Tests, Projektmanagement, Dokumentation und Inbetriebnahme enthalten?
- Wie laufen Änderungswünsche ab, und wie werden sie bewertet?
- Wer arbeitet am Projekt, und mit welcher Erfahrung?
- Wem gehören Quellcode und Nutzungsrechte nach Projektende?
- Was kosten Betrieb, Wartung und Support nach dem Go-live?
Sparen, ohne an Qualität zu verlieren
Es gibt gute und schlechte Wege, Kosten zu senken. Die guten verkleinern den Umfang, die schlechten die Sorgfalt.
Klein starten
Starte mit dem Kernprozess, der den größten Nutzen bringt, und baue danach aus. Eine erste Version im Echtbetrieb zeigt schneller als jedes Konzept, welche Funktionen wirklich gebraucht werden. Viele Wunschfunktionen erledigen sich dabei von selbst.
Standardkomponenten nutzen
Anmeldung, Benutzerverwaltung, Formulare, Tabellen, Dateiablage oder Benachrichtigungen muss niemand neu erfinden. Bewährte Bibliotheken und Dienste decken das ab. Individuell entwickelt wird, was dein Geschäft von anderen unterscheidet.
Bauen oder kaufen, je Baustein entscheiden
Nicht jede Anforderung braucht Individualsoftware. Für Buchhaltung, Lohn oder Ticketsysteme gibt es ausgereifte Standardsoftware. Oft ist die beste Lösung eine Kombination: Standard für das Übliche, eigene Entwicklung für die Abläufe, die dich ausmachen, verbunden über Schnittstellen. Wie du diese Entscheidung technisch triffst, steht in Build vs. Buy aus Engineering-Sicht, die betriebswirtschaftliche Seite in der Entscheidungsmatrix SaaS oder Individualsoftware.
Wo Sparen teuer wird
Wer bei Tests, Dokumentation oder Architektur spart, zahlt später drauf: bei jedem Update, jeder neuen Funktion und jedem Wechsel im Team. Auch das billigste Angebot ohne Lastenheft ist selten das günstigste. Die Differenz taucht später als Nachtrag wieder auf.
Checkliste: Das solltest du vor der Anfrage klären
- Welches Problem löst die Software, und woran misst du den Erfolg?
- Wer nutzt sie: nur dein Team, auch Kunden und Partner oder zahlende Kunden?
- Welche Abläufe müssen in der ersten Version laufen, welche können warten?
- Welche Rollen gibt es, und wer darf was sehen und ändern?
- Welche Systeme müssen angebunden werden, und gibt es dort eine dokumentierte Schnittstelle?
- Welche Daten ziehen aus Altsystemen um, und wie sauber sind sie?
- Welche Vorgaben gelten: DSGVO, Barrierefreiheit, Branchenregeln?
- Wer betreibt und wartet die Software nach dem Go-live?
- Wer entscheidet auf deiner Seite, und wie viel Zeit hat diese Person für das Projekt?
- Welches Budget ist realistisch, und gibt es einen festen Termin?
Mit diesen Antworten ist der Projekt-Rechner schnell ausgefüllt, und jedes Angebot, das du einholst, wird belastbarer.
Fazit
Was Softwareentwicklung kostet, hängt weniger von der Technik ab als davon, wie klar das Vorhaben beschrieben ist. Umfang, Schnittstellen, Rollen, Datenmigration und Vorgaben bestimmen den Aufwand. Betrieb und Wartung bestimmen, was die Software über die Jahre kostet. Wer diese Punkte vorher klärt, bekommt vergleichbare Angebote und erlebt im Projekt weniger Überraschungen.
Mein Rat: Starte klein, beschreibe den Kernprozess sauber und plane den Betrieb von Anfang an mit. Wie wir Projekte dieser Art umsetzen, zeigt die Seite zur individuellen Softwareentwicklung.
Häufige Fragen zu den Kosten von Softwareentwicklung
Was kostet individuelle Software?
Das hängt vom Umfang, den Schnittstellen, den Rollen und Rechten, der Datenmigration und dem Design ab. Eine kleine Fachanwendung für einen Ablauf und ein Portal für externe Nutzer liegen weit auseinander. Eine erste Spanne für dein Vorhaben rechnet der Projekt-Rechner aus deinen Antworten aus. Ein verbindlicher Preis entsteht nach einem Workshop oder einem Lastenheft-Review.
Warum unterscheiden sich Angebote für dieselbe Software so stark?
Weil jeder Anbieter etwas anderes kalkuliert. Der eine rechnet Tests, Projektmanagement und Inbetriebnahme ein, der andere nicht. Schnittstellen und Datenmigration werden unterschiedlich verstanden. Ein Lastenheft gibt allen Anbietern dieselbe Grundlage. Frag außerdem in jedem Angebot nach Annahmen und Ausschlüssen.
Ist ein Festpreis günstiger als Abrechnung nach Aufwand?
Nicht automatisch. Beim Festpreis trägt der Anbieter das Risiko, dass der Aufwand höher ausfällt, und preist es ein. Bei Abrechnung nach Aufwand zahlst du, was tatsächlich anfällt, trägst aber das Budgetrisiko. Steht der Umfang fest, passt ein Festpreis. Ist vieles offen, ist Aufwand oder ein agiler Festpreis mit festem Budgetrahmen meist fairer.
Welche Kosten kommen nach dem Go-live dazu?
Hosting und Infrastruktur, Wartung und Sicherheitsupdates, Lizenzen und Drittdienste wie E-Mail-Versand oder KI-Modelle sowie Support und Weiterentwicklung. Dazu kommt interne Zeit für Abnahmen, Schulungen und Datenpflege. Plane diese Posten über die gesamte Nutzungsdauer ein, nicht nur das Projektbudget.
Wie lange dauert es, Software entwickeln zu lassen?
Das hängt an denselben Faktoren wie die Kosten: Umfang, Schnittstellen, Datenmigration und wie schnell Entscheidungen fallen. Der Projekt-Rechner schätzt neben der Kostenspanne auch die ungefähre Umsetzungsdauer. Abstimmungen, Freigaben und Wartezeiten kommen im Kalender hinzu. Am schnellsten bist du mit einer fokussierten ersten Version im Echtbetrieb.
Wird Softwareentwicklung durch KI günstiger?
Teilweise. KI-Assistenten beschleunigen klar umrissene Aufgaben wie Grundgerüste, Tests und Umbauten. Anforderungen klären, Architektur entscheiden, Fachlogik prüfen und die Verantwortung für Sicherheit bleiben Arbeit von Menschen. Was das für Projekte bedeutet, steht im Beitrag KI in der Softwareentwicklung.
