„Was kostet es, eine App zu entwickeln?“
Das ist die häufigste Frage, die wir bekommen, und die ehrliche Antwort — „das kommt darauf an“ — ist gleichzeitig die am wenigsten hilfreiche.
Also machen wir sie hilfreich. Hier erfahren Sie, was Softwarekosten tatsächlich treibt, warum Schätzungen zwischen Anbietern so stark variieren und wie Sie realistisch budgetieren.
Warum Software teuer ist
Software ist nicht teuer, weil Code schwer zu schreiben ist. Moderne Tools, Frameworks und KI machen das Schreiben von Code schneller als je zuvor. Software ist teuer wegen allem rund um den Code:
Entscheidungen
Jedes Feature beinhaltet Dutzende von Entscheidungen:
- Was passiert, wenn der Benutzer ungültige Daten eingibt?
- Wie sieht der Ladezustand aus?
- Wie funktioniert das auf Mobilgeräten?
- Was passiert, wenn zwei Benutzer gleichzeitig denselben Datensatz bearbeiten?
- Wie gehen wir mit einem Sitzungsablauf mitten in einer Aktion um?
Ein Login-Formular scheint einfach. Aber die Entscheidung über Passwort-Anforderungen, Fehlermeldungen, Rate Limiting, Sitzungsdauer, „Angemeldet bleiben“-Verhalten, Passwort-Zurücksetzung, Kontosperrungs-Richtlinien und Barrierefreiheit macht aus einem „einfachen Formular“ eine Woche Arbeit.
Sonderfälle
Der Happy Path — wenn alles richtig läuft — ist vielleicht 20 % der Arbeit. Die anderen 80 % sind die Behandlung dessen, was passiert, wenn etwas schiefgeht:
- Netzwerkausfälle
- Gleichzeitige Benutzer
- Ungültige Daten
- Browser-Inkompatibilitäten
- Änderungen an Drittanbieter-APIs
- Zeitzonen
- Zeichenkodierung
- Barrierefreiheitsanforderungen
Das sind keine Bugs. Das ist Engineering. Und das ist der Unterschied zwischen Software, die in einer Demo funktioniert, und Software, die in Produktion funktioniert.
Laut der Forschung von Capers Jones[1], einem Pionier der Software-Messung, erfordert das durchschnittliche Softwareprojekt etwa 5x mehr Aufwand für Tests, Debugging und Nacharbeit als für die initiale Programmierung. Der Code selbst ist die Spitze des Eisbergs; die eigentlichen Kosten liegen darin, ihn zuverlässig zu machen.
Die Lücke zwischen Beschreibung und Realität
„Bauen Sie ein Dashboard“ ist ein Satz. Ein Dashboard zu bauen, das mit 100.000 Datensätzen schnell lädt, auf Mobilgeräten korrekt dargestellt wird, Benutzerberechtigungen berücksichtigt, Echtzeit-Updates verarbeitet und für Screenreader zugänglich ist — das ist ein Projekt.
Die Lücke zwischen dem, was Menschen beschreiben, und dem, was sie tatsächlich brauchen, ist der Ort, an dem die meisten Kostenüberschreitungen entstehen. Nicht weil Stakeholder unklar sind — sondern weil Software eine inhärente Komplexität hat, die erst sichtbar wird, wenn man mit dem Bau beginnt.
Wie sich Preismodelle vergleichen
Festpreis
So funktioniert es: Der Anbieter gibt einen Festpreis für einen definierten Scope ab.
Das Versprechen: Sie zahlen genau das, was angeboten wurde.
Die Realität: Der Scope ist vorab nie vollständig definiert. Wenn sich Anforderungen ändern (und das tun sie immer), gibt es eines von drei Ergebnissen:
- Der Anbieter absorbiert die Kosten und spart an der Qualität, um profitabel zu bleiben
- Der Anbieter berechnet Änderungsgebühren, die den Gesamtpreis aufblähen
- Der Anbieter liefert exakt das, was spezifiziert wurde, auch wenn beide Seiten wissen, dass es nicht das ist, was gebraucht wird
Festpreise funktionieren für sehr kleine, sehr klar definierte Projekte. Für alles Größere schaffen sie kontraproduktive Anreize.
Zeit und Material (Stundenbasiert)
So funktioniert es: Der Anbieter rechnet nach Stunden ab.
Das Versprechen: Sie zahlen nur für tatsächliche Arbeit.
Die Realität: Zwei Probleme:
- Keine Vorhersehbarkeit: Sie kennen die Endkosten erst, wenn das Projekt abgeschlossen ist
- Kontraproduktiver Anreiz: Der Anbieter wird finanziell dafür belohnt, länger zu brauchen
Stundenabrechnung kann mit hohem Vertrauen und erfahrenen Projektmanagern funktionieren, erfordert aber ständige Überwachung.
aufwandseinheitenbasierte Preisgestaltung
So funktioniert es: Arbeit wird in Aufwandseinheiten (ein Maß für Komplexität) geschätzt. Sie kaufen ein monatliches Aufwandseinheiten-Kontingent. Jedes Feature wird geschätzt, bevor Sie sich festlegen.
Warum es funktioniert:
- Vorhersehbar: Sie kennen Ihre monatlichen Kosten im Voraus
- Transparent: Sie sehen genau, was jedes Feature in Aufwandseinheiten kostet, bevor es gebaut wird
- Flexibel: Prioritäten können sich von Entwicklungszyklus zu Entwicklungszyklus ändern, ohne Verträge neu zu verhandeln
- Abgestimmte Anreize: Der Anbieter profitiert von effizienter Lieferung, nicht davon, länger zu brauchen
So funktioniert die Preisgestaltung bei Toolwiz. Sie wählen einen Plan mit einem Aufwandseinheiten-Kontingent, und jeder Entwicklungszyklus liefert Features innerhalb dieses Budgets.
Was kostet Software tatsächlich?
Anstatt konkrete Projektzahlen zu nennen, hier eine Orientierung in Bezug auf Komplexität:
Einfache Features (1–3 Aufwandseinheiten)
- Statische Inhaltsseiten
- Einfaches Formular mit Validierung
- Grundlegende CRUD-Operationen
- Stiländerungen und UI-Anpassungen
Mittlere Features (5–8 Aufwandseinheiten)
- Benutzer-Authentifizierungsablauf
- Suche mit Filtern
- Datei-Upload und -Verarbeitung
- E-Mail-Benachrichtigungssystem
- Dashboard mit Diagrammen
Komplexe Features (13–21 Aufwandseinheiten)
- Zahlungsintegration
- Echtzeit-Zusammenarbeit
- Drittanbieter-API-Integrationen
- Komplexe Geschäftslogik mit Regelwerk
- Mehrfachrollen-Berechtigungssystem
Sehr komplexe Features (34+ Aufwandseinheiten)
- Vollständiger E-Commerce-Checkout-Flow
- KI/ML-Feature-Implementierung
- Migration von Altsystemen
- Multi-Tenant-Architektur
Bei Toolwiz reichen unsere Pläne von 40 Aufwandseinheiten/Monat (Starter) bis 150 Aufwandseinheiten/Monat (Enterprise). Ein typisches MVP umfasst etwa 40–80 Aufwandseinheiten insgesamt. Ein ausgereiftes Produkt verbraucht möglicherweise 80–150 Punkte pro Monat in der laufenden Entwicklung.
Unsere vollständige Preisübersicht ansehen →
Versteckte Kosten, die die meisten Anbieter nicht erwähnen
Hosting und Infrastruktur
Ihre Software muss irgendwo laufen. Cloud-Hosting-Kosten hängen von Traffic, Speicher und Rechenleistung ab. Kalkulieren Sie für die meisten Projekte mit einigen hundert Euro pro Monat, mehr für Anwendungen mit hohem Traffic.
Wartung
Software ist nicht „fertig“, wenn sie live geht. Abhängigkeiten müssen aktualisiert, Sicherheitspatches eingespielt und Bugs behoben werden. Kalkulieren Sie jährlich 15–20 % der anfänglichen Entwicklungskosten für Wartung.
Gartner-Forschung[2] zeigt durchgehend, dass der Großteil der IT-Ausgaben in Unternehmen in die Wartung und den Betrieb bestehender Systeme fließt — nicht in den Aufbau neuer Fähigkeiten. Bei individueller Software ist laufende Wartung keine Überraschungsausgabe — sie ist die primäre Ausgabe.
Iteration
Ihre erste Version wird nicht Ihre letzte sein. Planen Sie mindestens 2–3 Iterationen nach dem Launch auf Basis echten Nutzerfeedbacks. Die erste Version testet Annahmen; nachfolgende Versionen verfeinern sie.
Drittanbieter-Services
Authentifizierungsanbieter, E-Mail-Dienste, Zahlungsabwickler, Analytics, Fehler-Tracking — das summiert sich. Kalkulieren Sie für eine typische SaaS-Anwendung mit einigen hundert Euro pro Monat.
Wie Sie realistisch budgetieren
Schritt 1: Definieren Sie Ihr MVP ehrlich
Listen Sie nur die Features auf, die wesentlich sind, um Ihre Kernhypothese zu testen. Nicht „nett zu haben“ — wesentlich.
Schritt 2: Schätzen Sie in Aufwandseinheiten
Arbeiten Sie mit Ihrem Entwicklungspartner zusammen, um jedes Feature zu schätzen. Das gibt Ihnen eine Gesamtprojektgröße.
Schritt 3: Planen Sie einen Puffer ein
Software-Schätzungen sind von Natur aus optimistisch. Fügen Sie 25–30 % für Unbekanntes hinzu.
Schritt 4: Planen Sie für die Zeit nach dem Launch
Budgetieren Sie 3–6 Monate Entwicklung nach dem Launch für Iteration und Verfeinerung. Hier wird das Produkt tatsächlich gut.
Schritt 5: Berücksichtigen Sie laufende Kosten
Hosting, Drittanbieter-Services und Wartung sind fortlaufend. Berücksichtigen Sie diese von Tag eins in Ihrem monatlichen Budget.
Der teuerste Fehler
Das Teuerste in der Softwareentwicklung ist nicht, das falsche Feature zu bauen. Es ist, das falsche Feature zu bauen und es erst am Ende herauszufinden.
Kurze Entwicklungszyklen, regelmäßige Reviews und transparentes Fortschritts-Tracking existieren genau dafür, Fehler früh zu erkennen. Eine missverstandene Anforderung, die in Woche 2 erkannt wird, kostet ein Gespräch. Derselbe Fehler in Woche 12 kostet einen Neubau.
Deshalb arbeiten wir in 1–2-Wochen-Entwicklungszyklen mit Stakeholder-Review am Ende jedes Zyklus. Nicht weil es ein schöner Prozess ist — sondern weil es der günstigste Weg ist, Software zu bauen, die tatsächlich funktioniert.
Möchten Sie eine realistische Schätzung für Ihr Projekt? Kostenlose Schätzung erhalten →
