Was kostet eine App? Ehrliche Zahlen nach 20+ eigenen Apps

„Was kostet eine App?“ ist die meistgestellte Frage in unseren Erstgesprächen — und das Netz beantwortet sie mit Spannen von 5.000 bis 500.000 €. Das ist so nützlich wie „ein Fahrzeug kostet zwischen 500 und 500.000 €“. Wir bauen seit 2018 Apps und betreiben über zwanzig davon selbst. Hier ist die Antwort, die wir uns damals gewünscht hätten.

Warum sind die Spannen im Netz nutzlos? Weil „App“ alles bezeichnet — vom Nachschlagewerk mit drei Screens bis zum Marktplatz mit Bezahlsystem und zehntausenden Nutzern. Eine Spanne über all das zu legen sagt nichts. Eine ehrliche Auskunft besteht aus zwei Teilen: was den Preis wirklich treibt — und in welcher Größenklasse das eigene Vorhaben landet.

Die sechs Preistreiber, die wirklich zählen

Die Frage „Wie viele Screens hat die App?“ hören wir oft. Sie ist der schwächste Kostenindikator überhaupt — ein zusätzlicher Screen ist ein Nachmittag. Diese sechs Dinge sind es nicht:

• Plattformen. iOS, Android oder beides? Zwei getrennte native Apps bedeuten doppelte Frontend-Entwicklung — bei jedem Feature, bei jedem Bugfix, bei jedem Update. Dazu gleich mehr.
• Backend. Eine App, die für sich alleine läuft, ist eine andere Baustelle als eine mit Konten, Synchronisation und Push-Nachrichten. Letztere braucht Server, Datenbank, Schnittstellen — und jemanden, der das betreibt.
• Login und Rollen. Registrierung, Passwort-Reset, Rollen und Rechte, DSGVO-konforme Löschung: im Mockup unsichtbar, im Code einer der teuersten Posten.
• Offline-Fähigkeit. Muss die App im Funkloch funktionieren? Bei RoadReview ja — Fahrstunden finden auf Landstraßen statt, nicht im WLAN. Offline heißt lokale Datenhaltung plus Synchronisation plus Konfliktlösung, und das verdoppelt gern den Aufwand der Datenschicht.
• Schnittstellen. DATEV, ERP, Kalender, Bezahldienst — nicht ob die Anbindung geht, entscheidet über den Preis, sondern wie gut die jeweilige API dokumentiert ist.
• Store-Review und Compliance. Apple und Google prüfen jede App: Datenschutz-Angaben, Berechtigungen, In-App-Kauf-Regeln, Testzugänge für den Reviewer. Wer den Prozess kennt, plant ihn ein; wer nicht, verliert Wochen kurz vor dem Launch.

Und was den Preis selten treibt: das, worüber am längsten diskutiert wird. Farben, das App-Icon, der zehnte Screen. Ein aufwendiger Bildschirm mehr verschiebt ein Projekt nie in die nächste Klasse — eine vergessene Schnittstelle oder ein nachträgliches „muss auch offline gehen“ tut es zuverlässig. Die teuren Meter liegen unter der Oberfläche.

Drei Größenklassen mit ehrlichen Spannen

Wir kalkulieren Apps in denselben drei Schuhgrößen wie alle unsere Projekte. Die Spannen sind bewusst breit, weil sie ehrlich sind — wo ein Projekt landet, entscheiden die sechs Treiber von oben:

1. Werkzeug-App: 8.000–25.000 € netto. Ein fokussiertes Werkzeug ohne großes eigenes Backend: eine Erfassungs-App für den Außendienst, ein digitales Handbuch, ein Begleiter zu einem bestehenden System. Ein Zweck, wenige Rollen, überschaubare Datenhaltung.
2. Schlanker MVP: 25.000–80.000 € netto. Ein echtes Produkt in seiner ersten ehrlichen Version: Konten, Backend, Push, beide Stores. Die Kernfunktion vollständig, die Wunschliste bewusst gestrichen. Das ist die häufigste Größe auf unserem Tisch.
3. Ausgewachsenes Produkt: ab 80.000 € netto. Mehrere Nutzerrollen, Bezahlung, Admin-Konsole, laufende Weiterentwicklung. Was RoadReview heute ist, ist über vier Jahre gewachsen — niemand baut so etwas seriös in einem Wurf, und wer es als Erstprojekt anbietet, verkauft eine Wette.

Ein Beispiel, wie Treiber und Klassen zusammenspielen: Eine App, mit der Monteure Aufträge unterwegs erfassen — Fotos, Checkliste, Unterschrift, Übergabe ans Büro — klingt nach Werkzeug-App. Sie bleibt auch eine, solange sie online arbeitet und an ein System mit sauberer API andockt. Kommt Offline-Fähigkeit für die Tiefgarage dazu und ein zweites Bestandssystem ohne Dokumentation, wandert dasselbe Vorhaben in die MVP-Klasse. Nicht, weil jemand den Preis erhöht hat — sondern weil zwei Treiber umgelegt wurden.

Nach dem Erstgespräch ersetzt bei uns eine Festpreis-Skizze die Spanne durch eine konkrete Zahl — schriftlich, mit Annahmen. Wie dieser Zuschnitt läuft, steht auf unserer Seite zur App-Entwicklung.

Warum eine Codebasis die Rechnung fast halbiert

2021 haben wir ClickTestBuy gebaut — die Termin-App für Corona-Testzentren in Ostwestfalen-Lippe. Damals nativ: einmal Swift für iOS, einmal Kotlin für Android. Jedes Feature zweimal gebaut, jeder Bug zweimal gefixt, jedes Release zweimal getestet. Es ging, weil es schnell gehen musste — aber die Rechnung hat uns die Entscheidung fürs nächste Mal abgenommen.

Seitdem bauen wir Business-Apps mit Flutter aus einer Codebasis — RoadReview und LS-Athletics laufen so in beiden Stores. Halbiert das die Rechnung? Ehrlich gerechnet: Es halbiert den Frontend-Anteil. Backend, Design, Store-Release und Projektführung bleiben gleich. In Summe spart das je nach Projekt grob ein Drittel — genug, um aus „unbezahlbar“ ein „machbar“ zu machen. Wann Flutter nicht die richtige Wahl ist — Widgets, Watch, tiefe Plattform-Features — haben wir in einem eigenen Artikel aufgeschrieben: Flutter oder nativ?

Die laufenden Kosten nach dem Launch

Nach dem Launch ist eine App nicht fertig, sie ist im Betrieb. Vier Posten gehören von Anfang an ins Budget:

• Store-Gebühren. Apple Developer Program 99 $ pro Jahr, Google Play einmalig 25 $ — der kleinste Posten, aber ohne ihn ist die App weg.
• Pflicht-Updates. Jedes Jahr erscheinen neue iOS- und Android-Versionen. Wer zwei Jahre nichts tut, riskiert Abstürze auf neuen Geräten — und Apple entfernt lange nicht aktualisierte Apps aus dem Store.
• Betrieb. Hosting, Datenbank, Push-Dienste, Monitoring, Zertifikate. Unspektakulär, monatlich, unvermeidbar.
• Weiterentwicklung. Die Features, die echte Nutzer nach vier Wochen zu Recht verlangen. Wer dafür kein Budget hat, hat einen Launch, aber kein Produkt.

Als Faustregel planen wir 10–15 % der Bausumme pro Jahr für Pflege und Betrieb — bei Apps eher am oberen Rand, weil zwei Betriebssysteme pro Jahr nachziehen. Wichtiger als die genaue Prozentzahl ist, dass der Posten von Anfang an existiert, im Budget und im Kopf. Die teuersten Apps, die uns begegnen, sind die zwei Jahre nicht angefassten: Update-Stau, veraltete Bibliotheken und ein abgelaufenes Zertifikat werden dann auf einmal fällig — als großer, unangenehmer Batzen statt als planbare Monatsroutine.

Echte Spar-Hebel

• Den MVP radikal zuschneiden. Erst die Kernfunktion, schnell in echte Hände. Ausbauen geht immer — Zurückbauen nie.
• Eine Codebasis statt zwei. Der größte einzelne Hebel, wenn beide Stores gebraucht werden.
• Gelöste Probleme nicht neu lösen. Login, Push, Crash-Reporting sind Standardbausteine — wir nutzen etwa Firebase-Dienste, wo sie passen, statt Wochen in Eigenbauten zu stecken.
• Phase 2 nach echten Nutzern planen. Die zweite Ausbaustufe erst beauftragen, wenn die erste im Feld war. Die Prioritäten ändern sich garantiert.

Falsche Spar-Hebel

• Der 15.000-€-Anbieter für das 60.000-€-Projekt. Irgendwo fehlt das Geld — meistens bei Tests, Fehlerbehandlung und Wartbarkeit. Die Differenz zahlt man später, mit Zins.
• Baukasten für ein echtes Produkt. No-Code-Werkzeuge sind großartig für Prototypen. Für ein Produkt mit eigenen Anforderungen läuft man nach Monaten gegen eine Wand — und baut dann doch neu.
• Design streichen. Gemeint ist nicht Hochglanz, sondern Bedienbarkeit. Die App, die niemand versteht, ist die teuerste — egal, was sie gekostet hat.
• Testen und Review „später“. Eine abgelehnte Store-Einreichung kurz vor dem versprochenen Launch kostet mehr Nerven und Geld als jede Testwoche vorher.

Und die nützlichste Rechnung ist auch hier nicht „Was kostet die App?“, sondern „Was kostet es, sie nicht zu haben?“ — pro Woche, in Arbeitsstunden oder entgangenen Aufträgen. Wer diese Zahl kennt, kann die Spannen oben einordnen. Wer die konkrete Zahl für sein Vorhaben will: Ein Erstgespräch genügt, danach gibt es die Festpreis-Skizze schriftlich. Die Spannen aus diesem Artikel sind dabei der Anfang des Gesprächs — nicht das Kleingedruckte am Ende.