Ein Kostenvoranschlag für eine App ist nur dann hilfreich, wenn alle Anbieter dasselbe Ergebnis kalkulieren. „Eine App für iOS und Android“ bezeichnet Plattformen, aber keinen konkreten Umfang. Lege zuerst fest, was der erste Release belegen soll und welche Nutzerreise diesen Nachweis liefert.
Nutze den Kostenrechner für iOS- und Android-Apps als konkreten Ausgangspunkt für den Umfang. Ein Beispiel aus diesem Studio: Ein Flutter-MVP mit einer Funktion für beide Plattformen kostet 15.000 €. Mit Produktdesign und QA für die Hauptfunktion steigt der Projektpreis auf 18.000 €. Beide Beträge verstehen sich ohne Mehrwertsteuer. Das ist ein Angebot mit klar definiertem Umfang, kein Branchendurchschnitt.
Lege den Umfang fest, bevor du Preise vergleichst
Gib jedem Anbieter dasselbe Briefing. Beschreibe das Ergebnis, das Nutzer brauchen, die nötigen Arbeiten und die Kriterien, an denen du die Fertigstellung erkennst. Nimm Folgendes auf:
- Nutzer, Rollen und wichtigste Abläufe, dazu eine klare Liste der Punkte, die nicht zum ersten Release gehören.
- Anforderungen für iOS und Android, einschließlich Funktionen, die plattformspezifisches Verhalten erfordern.
- Backend, Datenmigration, Integrationen mit Drittanbietern und die Zuständigkeit für jede Abhängigkeit.
- Erwartungen an Design, Barrierefreiheit, Lokalisierung, Datenschutz und Sicherheit.
- Tests, Abnahmekriterien, Zuständigkeiten für die Veröffentlichung, Übergabe und offene Fragen.
Der Kostenvoranschlag ändert sich meist mit der Unsicherheit: etwa bei einer undokumentierten Integration, uneinheitlichen Bestandsdaten, späten Designentscheidungen, zusätzlichen Freigabeschritten oder Plattformanforderungen, die im Briefing fehlten. Bitte die Anbieter, ihre wichtigsten Annahmen zu nennen, zu erklären, wie sie diese prüfen und was passiert, falls eine Annahme nicht zutrifft. Weitere MVP-Preisspannen und die Faktoren dahinter findest du unter Was kostet die Entwicklung eines MVP im Jahr 2026?.
Vergleiche Angebote mit demselben Leistungsumfang
Prüfe jeden Vorschlag anhand desselben Umfangs. Lass dir schriftlich bestätigen, welche Ergebnisse und Ausschlüsse gelten, welche Annahmen und Abhängigkeiten bestehen, wer die Arbeit ausführt, wie Fortschritt und Abnahme geregelt sind und wie sich Änderungen auf Kosten oder Zeitplan auswirken. Prüfe auch, ob Tests, Release-Vorbereitung und Übergabe enthalten sind.
Ein niedrigerer Gesamtpreis kann bedeuten, dass mehr Umfang oder Lieferrisiko bei dir liegt. Vergleiche die Annahmen und das Verfahren für Änderungen, bevor du über den Preis verhandelst. Festpreis und Abrechnung nach Zeit und Aufwand verteilen das Risiko unterschiedlich; mehr dazu unter den Unterschieden dieser Vertragsmodelle.
Mach aus den Angeboten eine Entscheidung
Ordne alle Angebote nach denselben Punkten und mach jede Lücke sichtbar. Eine kurze Vergleichstabelle sollte Folgendes enthalten:
- Ergebnis und Abnahme. Nenne die enthaltenen Abläufe, Plattformen und Integrationen und halte fest, wie du ihre Funktion nachweist. Ein Begriff wie „Zahlungen“ ist zu ungenau, um die Abnahme daran festzumachen.
- Team und Verfügbarkeit. Halte fest, wer die Arbeit ausführt, wer technische Entscheidungen trifft, wie viel Zeit die technische Leitung für das Projekt aufwendet und wer bei der Übergabe oder während Urlaub einspringt.
- Lieferung und Abhängigkeiten. Zeige die Reihenfolge der Meilensteine, welche Beiträge dein Team liefern muss und wie Verzögerungen bei Store-Konten, APIs, Testgeräten oder Freigaben den Plan beeinflussen.
- Änderungen und Betreuung danach. Halte fest, was bei geänderten Annahmen passiert, welche Unterstützung nach dem Release enthalten ist und welche laufenden Leistungen oder neuen Funktionen extra kosten.
Fehlt ein Punkt in einem Angebot, bitte den Anbieter, ihn einzukalkulieren oder ausdrücklich auszuschließen. Beschreiben die Angebote danach weiterhin unterschiedliche Produkte, schick allen dasselbe überarbeitete Briefing und fordere neue Kostenvoranschläge an. Nicht vergleichbare Gesamtsummen zu mitteln, verschleiert genau das Risiko, das du einschätzen willst.
Entwicklungskosten von den Ausgaben nach dem Launch trennen
Die Entwicklung umfasst das vereinbarte Produkt: Design, Umsetzung, Tests und Übergabe. Nach der Veröffentlichung solltest du laufende Dienste wie Hosting, Speicher, externe APIs, Monitoring und Store-Konten sowie Wartungsarbeiten wie Fehlerbehebungen, Abhängigkeitsupdates und Kompatibilität mit neuen Betriebssystemversionen einplanen. Manche Dienstkosten richten sich nach der Nutzung. Neue Funktionen sind zusätzliche Entwicklungsarbeit, auch wenn dasselbe Team sie umsetzt.
Lege die Grenze zwischen Release und Support ausdrücklich fest. Das Release-Paket dieses Studios umfasst einen Monat Fehlerbehebungen, eine QA-Umgebung sowie das Projekt-Repository und die Dokumentation in deiner Hand. Vereinbare separat, wie der Support danach abläuft und welche Dienste dein Unternehmen direkt bezahlt.
Eigentum und Übergabe klar regeln
Dein Unternehmen sollte die Kontrolle über das Quellcode-Repository sowie Store- und Cloud-Konten haben. Im Vertrag sollte stehen, wem individuell erstellter Code und Design gehören. Außerdem sollte er Drittanbieter-Lizenzen aufführen und verständliche Anleitungen für Build, Tests und Release enthalten. Neue Entwickler sollten die Arbeit fortsetzen können, ohne auf private Zugänge angewiesen zu sein, die nur der Anbieter besitzt.
Wenn die App bereits existiert, prüfe sie vor einer Neuentwicklung
Prüfe Repository, aktuelle Builds, Abhängigkeiten, Tests, Release-Pipeline, Grenzen des Backends und bekannte Produktionsprobleme, bevor du über einen Ersatz entscheidest. Ein Produktaudit kann zeigen, was du behalten, reparieren oder neu entwickeln solltest, bevor du dich auf eine Migration festlegst.
Passe mit dem App-Kostenrechner einen klar definierten Ausgangsumfang an und vergleiche anschließend die Angebote anhand desselben Ergebnisses, derselben laufenden Zuständigkeiten und Eigentumsbedingungen.