Die ehrliche Antwort auf die Kostenfrage ist eine Gegenfrage: Was soll die App können? Alles andere — Preisrechner, „Apps ab …“-Werbung — verschiebt die Überraschung nur nach hinten. Den Preis einer App bestimmt ihr Funktionsumfang, und der lässt sich vor einem Gespräch über Screens, Anbindungen und Nutzerrollen schlicht nicht kennen. Was sich sehr wohl vorab verstehen lässt: welche Faktoren den Aufwand treiben, wo sich seriös sparen lässt und an welchen Stellen Sparen später doppelt kostet.
Die fünf Treiber, an denen der Aufwand hängt
Screens und Nutzerrollen. Jede Ansicht will gestaltet, gebaut und getestet werden — und eine App mit Admin-, Mitarbeiter- und Kundenrolle ist keine App, sondern drei. Die Screenzahl ist der schnellste Näherungswert für die Projektgröße.
Das Backend. Eine App, die nur anzeigt, ist billig. Eine App, die Daten synchronisiert, Nutzer verwaltet, Push-Nachrichten schickt und mit eurer Warenwirtschaft spricht, besteht zum größeren Teil aus Server-Logik, die niemand sieht. Genau dieser Teil wird in Laienschätzungen am häufigsten vergessen.
Schnittstellen zu Bestandssystemen. „Die Daten kommen aus unserem ERP“ ist ein Satz, hinter dem sich alles verbergen kann — eine saubere REST-API oder ein zwanzig Jahre altes System, das nur CSV-Exporte kennt. Integrationen sind der Posten mit der größten Streuung.
Offline-Fähigkeit und Synchronisation. Soll die App auch ohne Netz funktionieren und sich später abgleichen, wächst die Komplexität sprunghaft: Konflikte, Versionsstände, Teilsynchronisation. Für Außendienst oft unverzichtbar; viele andere Fälle kommen ohne aus.
Plattformen. Cross-Platform mit Flutter oder React Native spart die zweite Codebasis — aber nicht die Hälfte des Budgets, denn Konzept, Design, Backend und Tests bleiben gleich groß. Zwei getrennte native Apps sind der teuerste Weg und lohnen nur mit gutem Grund.
Wo sparen klug ist — und wo es teuer wird
Klug sparen heißt Umfang sparen: Ein echtes MVP mit den zwei, drei Kernfunktionen liefert Lerneffekte, bevor das große Budget fließt. Standardbausteine für Login, Bezahlung oder Karten schlagen den Eigenbau fast immer. Und eine ehrliche Konzeptphase, die Funktionen streicht, ist die billigste Entwicklungsleistung überhaupt.
Teuer wird Sparen an drei Stellen. Erstens am Konzept: Was im Gespräch ungeklärt bleibt, wird beim Bauen dreimal umgebaut. Zweitens an den Tests: Fehler, die Kunden finden, kosten Ruf und Hotfix-Wochenenden. Drittens an der Zeit nach dem Launch — jährliche OS-Releases, Framework-Upgrades und Sicherheitsupdates fallen an, ob eingeplant oder nicht. Eine App ohne laufende Wartung ist nach zwei Jahren ein Sanierungsfall, und die Sanierung kostet mehr als die gesparten Wartungsmonate.
Woran ihr ein seriöses Angebot erkennt
Ein brauchbares Angebot nennt seine Annahmen: welche Funktionen drin sind, welche explizit nicht, was das Backend umfasst, wer Design und Inhalte liefert, wie Änderungen behandelt werden und was nach dem Launch passiert. Eine nackte Summe ohne Annahmen ist keine Schätzung, sondern ein Köder — die Differenz wird später als „Change Request“ nachberechnet. Vergleicht Angebote deshalb nie über die Endsumme, sondern über das, was für die Summe geliefert wird. Wie wir selbst Projekte aufsetzen, steht hier — inklusive der Etappen von Konzept bis Übergabe.
Ihr habt eine App-Idee und wollt eine ehrliche Aufwandsschätzung statt einer Katalogzahl? Schreib mir — das Erstgespräch kostet nichts, und danach wisst ihr, woran ihr seid.