App Entwicklung · 30. April 2026 · ~4 Min Lesezeit

Was kostet eine App wirklich?

Warum dieselbe App in zwei Angeboten 80.000 € auseinanderliegen kann — und woran du erkennst, welches der beiden vertrauenswürdig ist.

„Was kostet eine App?” ist die häufigste Frage am Anfang. Die ehrliche Antwort lautet es kommt darauf an — und das ist kein Ausweichmanöver, sondern ein erster Honesty-Test.

Wer dir auf diese Frage in 30 Sekunden eine konkrete Zahl liefert, hat entweder zu wenig hingehört oder zu viel Erfahrung darin, später nachzubessern. Die wirkliche Antwort hat zwei Teile: eine Größenordnung — und ein Gespräch über die Treiber, die diese Größenordnung verschieben.

Dieser Artikel ist die kurze Editorial-Version. Wenn du Zahlen, Day-Rates und sechs Treiber im Detail willst, liegt die ausführliche Aufschlüsselung im Guide Was kostet eine App-Entwicklung?.

Größenordnung in einem Absatz

Drei Klassen, drei Bandbreiten — keine Studienkonstante, sondern eine Praxis-Faustregel aus DACH-Angeboten 2025/2026: Schlanker MVP auf einer Plattform liegt bei 30.000–60.000 €. Vollwertige Produkt-App auf beiden Plattformen mit Backend, Auth und Payments bei 60.000–150.000 €. Komplexe Plattform mit Multi-Tenant, mehreren Integrationen oder Hardware-Schicht ab 150.000 € aufwärts.

Die Größe entscheidet sich nicht in der UI-Schicht, sondern im Datenmodell, in der Anzahl externer Systeme und in der Compliance-Last. Welche Treiber das im Detail sind, dröselt der Guide auf — hier geht es um die andere Hälfte der Antwort: wie du erkennst, ob ein Preis trägt.

Warum dieselbe App in zwei Angeboten 80.000 € auseinanderliegen kann

Du holst zwei Angebote für exakt denselben Scope ein. Eines liegt bei 90.000 €, das andere bei 170.000 €. Beide Studios sind seriös, beide haben Referenzen. Der Unterschied liegt fast nie an der Day-Rate — er liegt darin, was im Angebot eigentlich enthalten ist.

Drei Posten, die in günstigen Angeboten regelmäßig fehlen oder klein gerechnet werden:

  • Konzept-Phase und Spec-Aufwand. Wer den Build-Preis sieht und das Konzept als „besprechen wir nebenher” verkauft, schiebt den Aufwand in Phase 2 — wo er als „unerwartete Komplexität” wieder auftaucht.
  • Test-Pfade für die Kern-Flows. Eine App ohne automatisierte Tests ist ein Angebot, das im Build günstig wirkt und in der Wartung teuer wird. Faustregel: ein App-Stack ohne Test-Layer kostet pro Jahr 30–50 % mehr in der Pflege.
  • Submission, Store-Compliance, Privacy-Manifest. Apple lehnte laut Apple-Transparenzbericht 2024 rund 25 % aller Submissions ab — 1,93 von 7,77 Mio. Wer den Submission-Aufwand mit „ein Tag” einplant, hat den Mechanismus nicht verstanden.

Wer Angebote vergleicht, vergleicht zuerst die Zeilenstruktur, dann die Summe. Sonst vergleichst du Budgets, die ganz unterschiedliche Dinge umfassen.

Drei Fragen, an denen ein Angebot kippt

Bevor du Preise vergleichst, lohnt sich ein Reality-Check der eigenen Annahmen. Drei Fragen, deren Antwort den Build-Preis halbiert oder verdoppelt — bevor irgendein Studio eine Zeile Code schreibt:

  1. Welche Hypothese testet die V1? Wenn du sie nicht in einem Satz benennen kannst, ist der Scope zu breit. Mehr zur Scope-Disziplin im Sub-Guide MVP oder direkt komplett.
  2. Wer wartet die App in 18 Monaten? Die Antwort beeinflusst die Stack-Wahl mehr, als die Stack-Wahl selbst es tut. Externe Wartung verträgt Cross-Plattform und dokumentierte Architektur — interne Wartung verträgt Native, wenn das Team es kann.
  3. Was passiert, wenn ihr euch geirrt habt? Ein Studio, das Scope-Changes ohne Aufpreis durchwinkt, lügt entweder bei der Erst-Schätzung oder bei der späteren Rechnung. Sauber ist: Fixpreis für den definierten Scope, transparenter Change-Prozess für alles dahinter.

Wer diese drei Fragen vor dem ersten Angebot beantwortet, vergleicht nachher Äpfel mit Äpfeln — und hört, welches Studio mitdenkt.

Was teure Apps von billigen Apps unterscheidet — in 18 Monaten

Der Build-Preis ist der sichtbare Teil. Der unsichtbare ist das, was über drei Jahre dazukommt: Hosting, Updates, OS-Anpassungen, Security-Patches, Weiterentwicklung. Gartner führt unter „Software Maintenance” eine seit Jahrzehnten etablierte Beobachtung: über den Lebenszyklus übersteigt der Betrieb die initiale Entwicklung deutlich.

Konkret heißt das: eine App, die im Build 50.000 € spart, indem sie Tests weglässt und Architektur abkürzt, kostet im Betrieb pro Jahr regelmäßig 15–25 % mehr — eine Faustregel, die wir in eigenen Übernahme-Projekten in beide Richtungen sehen.

Apple veröffentlicht jährlich eine iOS-Major-Version, Google liefert Android-Hauptversionen über das AOSP-Programm. Das BSI verzeichnet im Lagebericht IT-Sicherheit 2025 durchschnittlich 119 neue CVE-Schwachstellen pro Tag. Eine App, die nicht aktiv mitwächst, fällt in 12–18 Monaten in Compliance- und Stabilitäts-Drift — unabhängig davon, wie clever sie initial gebaut wurde.

Wer Wartung im Erst-Angebot ignoriert, verschiebt das Problem nur. Was Wartung kostet und wie sie sich vom Stundenmodell unterscheidet, steht im AppCare-Guide.

Was du bei einem konkreten Angebot prüfen solltest

Ein gutes Angebot gibt dir nicht nur einen Preis, sondern eine Begründung für diesen Preis. Wenn du nachfragst, warum eine Position 5.000 € kostet, sollte die Antwort innerhalb von 30 Sekunden verständlich sein. Ist sie das nicht, ist das Angebot nicht durchgerechnet — sondern grob geschätzt.

Konkrete Punkte, die du prüfen kannst, bevor du unterschreibst:

  • Steht die Konzept-Phase als eigene Position? Oder ist sie im Build versteckt — und entsprechend dünn?
  • Ist der Test-Aufwand sichtbar ausgewiesen? Faustregel: 20–30 % der Build-Stunden sind Test-Pfade, weniger ist verdächtig.
  • Wie wird Scope-Change behandelt? Pauschale Toleranzen, getakteter Change-Prozess oder offen gelassen?
  • Welche Day-Rate liegt zugrunde? In DACH-Angebots-Vergleichen 2025/2026 liegen Senior-Mobile-Tagessätze typischerweise bei 880–1.440 € netto — Werte deutlich darunter sind erklärungsbedürftig.
  • Was passiert nach Launch? Wartungs-Optionen, Übergabe-Bedingungen, Code-Eigentum — alles im Angebot oder als Folge-Klärung markiert.

Bei Sovion machen wir das so: Konzept-Phase vor der Entwicklung als eigener Posten, klarer Scope, Fixpreis pro Modul, dokumentierter Change-Prozess. Wenn wir falsch geschätzt haben, tragen wir es. Das ist keine Großzügigkeit, sondern die einzige Position, die ein Studio einnehmen kann, das zwölf Monate später noch ohne Streit mit dir reden will.

Wenn du gerade ein Angebot vor dir hast und unsicher bist, ob die Zahlen tragen: schick uns den Scope in drei Sätzen — was die App tut, wer sie nutzt, ob Hardware oder Compliance Pflicht sind — über das Kontaktformular. Wir antworten in 24 Stunden mit einer Einschätzung der Größenordnung. Tieferer Kontext: Wie läuft eine App-Entwicklung ab? für die Phasen-Logik, Custom-Dev vs. No-Code/Low-Code, wenn ein günstigerer Validierungs-Pfad sinnvoll sein kann.