„Was kostet die Entwicklung dieser Software?” ist die Frage, die wir bei Soamee am häufigsten beantworten. Und die ehrliche Antwort beginnt immer gleich: Es kommt darauf an. Aber „es kommt darauf an” darf nicht das Ende des Gesprächs sein. In diesem Artikel öffnen wir deshalb unsere Küche: die Schritt-für-Schritt-Methode, mit der wir ein Budget für Softwareentwicklung schätzen, die Variablen, die den Preis wirklich bewegen, und wie Sie Lockangebote erkennen.
Wenn Sie konkrete Zahlen nach Projekttyp suchen, haben wir einen ergänzenden Leitfaden mit Marktspannen: Was kostet App-Entwicklung 2026. Hier konzentrieren wir uns auf die Methode: wie diese Zahl entsteht.
Die Variablen, die den Preis wirklich bewegen
Ein Software-Budget wird nicht nach Screens oder „Seiten” berechnet. Dies sind die Variablen mit dem größten Einfluss, geordnet nach ihrem realen Gewicht in unserer Erfahrung:
| Variable | Preiswirkung | Warum |
|---|---|---|
| Externe Integrationen (ERP, CRM, Zahlungen, Dritt-APIs) | Sehr hoch | Jedes externe System bringt Überraschungen: schlechte Doku, Limits, Sandboxes, die die Produktion nicht abbilden |
| Komplexe Geschäftslogik | Sehr hoch | Regeln, Ausnahmen und Randfälle vervielfachen die unsichtbare Arbeit |
| Sicherheit und Compliance (DSGVO, Gesundheit, Fintech) | Hoch | Audits, Verschlüsselung, Nachvollziehbarkeit, Anonymisierung: Arbeit, die in der Demo nicht sichtbar ist |
| Anzahl der Rollen und Berechtigungen | Hoch | Jede Rolle vervielfacht die zu entwerfenden und zu testenden Abläufe |
| Individuelles Design vs. bestehendes Designsystem | Mittel-hoch | Design von Grund auf bedeutet Wochen iterativer Arbeit |
| Mehrsprachigkeit und Lokalisierung | Mittel | Es geht nicht nur ums Übersetzen: Formate, Währungen, Routen, SEO pro Sprache |
| Anzahl der Screens | Mittel | Zählt, aber viel weniger als angenommen |
| Native Apps vs. Web | Mittel | Zwei native Plattformen ≈ das 1,6-1,8-Fache einer einzigen |
Die praktische Schlussfolgerung: Zwei Projekte mit denselben Screens können sich im Preis um das Dreifache unterscheiden — wegen dem, was unter der Oberfläche passiert.
Unsere Schätzmethode, Schritt für Schritt
Schritt 1: Das Problem verstehen, nicht die Lösung
Das erste Meeting dreht sich nicht um Features, sondern ums Geschäft: Welches Problem löst die Software, wer wird sie nutzen, was passiert, wenn sie nicht gebaut wird? Viele Projekte werden genau hier günstiger, weil die Lösung im Kopf des Kunden größer war als sein tatsächliches Problem.
Schritt 2: Den Umfang in Stories definieren, nicht in Screens
Wir zerlegen das Produkt in User Stories („als Manager möchte ich Rechnungen vom Handy aus freigeben”), gruppiert in Epics. Dieses Inventar ist das Rückgrat des Budgets: Alles, was drinsteht, wird geschätzt; alles, was nicht drinsteht, ist explizit außerhalb des Umfangs.
Schritt 3: In Spannen schätzen — mit dem Team, das umsetzt
Jedes Epic wird vom technischen Team geschätzt, das es bauen wird (nicht von einem Vertriebler), in optimistisch-pessimistischen Spannen. Als Kalibrierung nutzen wir Daten aus ähnlichen früheren Projekten: Das historische Gedächtnis ist mehr wert als jede Formel.
Schritt 4: Die unsichtbare Arbeit hinzufügen
Hier schummeln die Billigangebote. Ein professionelles Projekt enthält Positionen, die keine „Features” sind:
- Management und Kommunikation: 10-15 % der Gesamtsumme
- QA und Testing: 15-25 % je nach Kritikalität
- DevOps und Deployment: CI/CD, Umgebungen, Monitoring
- Unsicherheitspuffer: 10-20 % je nachdem, wie fest der Umfang steht
Wenn ein Angebot diese Positionen nicht aufschlüsselt, sind sie entweder im Preis versteckt oder schlicht nicht vorhanden (und Sie zahlen später dafür — in Bugs und Verzögerungen).
Schritt 5: Eine Spanne mit expliziten Annahmen präsentieren
Das Ergebnis ist nie „42.500 €”. Es ist etwas wie: „Zwischen 35.000 und 48.000 €, unter der Annahme, dass das Payment-Gateway Stripe ist, das Design auf Ihrem aktuellen System aufbaut und die ERP-Integration eine dokumentierte REST-API bereitstellt.” Jede gebrochene Annahme bewegt die Zahl — und alle wissen im Voraus, welche das sind.
Warum eine breite Spanne ein Zeichen von Ehrlichkeit ist
Es wirkt kontraintuitiv: Sollte eine erfahrene Agentur nicht eine exakte Zahl nennen können? Nicht am Anfang — und wer es tut, erzählt Ihnen ein Märchen.
Die Unsicherheit zu Beginn eines Softwareprojekts ist ein messbarer Fakt, keine Ausrede. Der klassische „Cone of Uncertainty” des Software-Engineerings zeigt, dass frühe Schätzungen leicht zwischen dem 0,5- und 2-Fachen abweichen können, bis der Umfang feststeht. Darauf gibt es drei mögliche Antworten:
- Exakte, niedrige Zahl → Verkaufsköder; die Marge wird über „Extras” mitten im Projekt zurückgeholt
- Exakte, aufgeblähte Zahl → man hat ein riesiges Polster eingebaut, ohne es Ihnen zu sagen; Sie zahlen für die Unsicherheit, auch wenn sie nie eintritt
- Ehrliche Spanne mit Annahmen → man sagt Ihnen die Wahrheit und gibt Ihnen den Mechanismus, die Spanne zu verengen (Scope schließen, Discovery-Phase durchführen)
Die Spanne verengt sich durch Arbeit: Nach einer Discovery-Phase oder einem ersten Sprint wird die Schätzung des Rests erheblich präziser. Misstrauen Sie der verfrühten Präzision, nicht der Spanne.
Wie Sie Angebote mehrerer Agenturen vergleichen
Drei Angebote erhalten und nach Preis sortieren ist die schlechteste Art zu entscheiden. Vergleichen Sie anhand dieser Checkliste:
- Gleichwertiger Umfang: Wurde dasselbe geschätzt? Fordern Sie die Aufschlüsselung nach Epics/Modulen an und prüfen Sie, was jeweils enthalten ist
- Unsichtbare Positionen: Erscheinen QA, Management, Deployment und Dokumentation? Oder ist der Preis nur „Programmieren”?
- Schriftliche Annahmen: Was wurde vorausgesetzt? Dort wohnen die künftigen Streitigkeiten
- Konkretes Team: Wer arbeitet an Ihrem Projekt (Seniorität, Auslastung)? Ein niedriger Preis mit unbetreuten Junior-Profilen wird teuer
- Was bei Änderungen passiert: Wie werden Scope-Änderungen gemanagt und bepreist?
- Eigentum und Ausstieg: Gehört der Code vom ersten Tag an Ihnen? Repository unter Ihrem Account?
- Arbeitsmodell: Festpreis, Time & Materials oder dediziertes Team — jedes verteilt das Risiko anders
Zum letzten Punkt: Der Festpreis verlagert das Risiko auf die Agentur (die es als Polster einpreist), Time & Materials verlagert es auf den Kunden (der Vertrauen und Transparenz braucht). Bei Projekten mit Unsicherheit ist ein vernünftiger Hybrid: Discovery zum Festpreis + Entwicklung in Sprints.
Wenn Sie auch die Alternative interner Einstellungen abwägen, haben wir einen vollständigen Vergleich Agentur vs. internes Team.
Red Flags in einem Software-Angebot
- Preis weit unter den anderen ohne strukturelle Erklärung (Standort, kleinerer Umfang): endet meist in Extras oder schlechter Qualität
- Exakte Zahl ohne geschlossene Anforderungen: verfrühte Präzision = Marketing
- Keine Aufschlüsselung: eine einzige Gesamtzahl verhindert Vergleich und Verhandlung
- Keine Annahmen oder Ausschlüsse: alles Ungeschriebene endet im Streit
- QA und Management „kostenlos inklusive”: es gibt sie nicht kostenlos; entweder werden sie nicht gemacht oder sie sind versteckt
- Druck, sofort zu unterschreiben mit ablaufenden Rabatten: Entscheidungen über Zehntausende von Euro trifft man nicht unter künstlicher Dringlichkeit
- Alles ist „ja”: eine Agentur, die Ihren Umfang nie hinterfragt, schätzt nicht — sie verkauft
Und die Green Flags
- Sie stellen Ihnen viele Fragen, bevor sie eine Zahl nennen
- Sie schlagen vor, den Umfang zu kürzen, um das Budget einzuhalten (Ihnen weniger zu verkaufen ist das beste Zeichen von Ehrlichkeit)
- Eine Spanne mit expliziten Annahmen und einem Plan, sie zu verengen
- Eine transparente Aufschlüsselung inklusive QA, Management und Deployment
- Überprüfbare Referenzen von Projekten ähnlicher Größe
Häufig gestellte Fragen
Warum nennen Agenturen Spannen statt einer festen Zahl?
Weil am Anfang echte Unsicherheit besteht: offene Anforderungen, noch unbekannte Integrationen. Eine ehrliche Spanne spiegelt diese Unsicherheit wider; eine exakte Zahl vor der Scope-Definition ist Marketing, keine Schätzung.
Wie vergleiche ich Angebote mehrerer Agenturen?
Vergleichen Sie den Umfang, nicht nur den Preis: Aufschlüsselung nach Positionen, Annahmen, konkretes Team und Änderungsmanagement. Zwei Angebote mit derselben Zahl können radikal unterschiedliche Umfänge abdecken.
Was macht ein Projekt teurer?
Externe Integrationen, Sicherheit und Compliance, komplexe Geschäftslogik und Scope-Änderungen mitten im Projekt. Die Anzahl der Screens zählt weniger, als man denkt.
Ist ein deutlich billigeres Angebot ein schlechtes Zeichen?
Fast immer: missverstandener Umfang, Qualitätskürzungen oder künftige Extras. Fordern Sie Aufschlüsselung und Annahmen an, bevor Sie nach Preis entscheiden.
Fazit
Ein gutes Software-Budget ist keine Zahl: Es ist ein zerlegter Umfang, geschätzt von denen, die ihn umsetzen werden, mit der unsichtbaren Arbeit inklusive und den Annahmen schriftlich. Die breite Spanne am Anfang ist keine Schwäche, sondern Ehrlichkeit; die Präzision kommt mit dem Schließen des Umfangs, nicht vorher.
Wenn Sie ein Projekt vorhaben und diese Methode auf Ihren Fall angewendet sehen möchten, buchen Sie eine kostenlose Beratung: Sie gehen mit einer realistischen Spanne und den richtigen Fragen nach Hause, um jedes Angebot zu bewerten — unseres oder das anderer.