Was kostet eine App 2026? Ein Leitfaden zur Umfangsplanung

Was kostet eine App im Jahr 2026? Das hängt von Umfang, Plattformen, Integrationen und Risiko ab, nicht von der Idee selbst. Beispielhafte Spannen reichen von einigen Tausend US-Dollar für einen validierten Prototyp bis zu sechsstelligen Beträgen für ein plattformübergreifendes Produkt mit Zahlungen und KI. Behandeln Sie jede Zahl als Schätzung auf Basis von Annahmen, niemals als Angebot.

Dieser Beitrag beschreibt die Methode marktübergreifend und rechnet in US-Dollar. Wenn Sie speziell für Deutschland planen, mit DSGVO, Barrierefreiheit und Budgets in Euro, ergänzt unser Leitfaden für den deutschen Markt die folgenden Abschnitte.

Warum Kostenschätzungen für Apps so stark schwanken

Zwei Apps, die in einem Satz beschrieben werden, können sich im Aufwand enorm unterscheiden. „Eine App wie ein Buchungsmarktplatz“ verbirgt die Zahl der Nutzerrollen, die Admin-Werkzeuge, das Offline-Verhalten, Zahlungsabläufe, Benachrichtigungen, Integrationen und Compliance-Anforderungen. Solange das nicht aufgeschrieben ist, ist jede Zahl eine Vermutung.

Anbieter bepreisen außerdem unterschiedliche Dinge. Manche Schätzungen decken nur die Entwicklung ab. Andere enthalten Produktdesign, Qualitätssicherung, Deployment, die Einreichung in den App Stores und eine Supportphase. Wer sie vergleicht, ohne den Umfang anzugleichen, vergleicht unterschiedliche Produkte.

Die Sätze unterscheiden sich nach Region und Erfahrung, und wie viel Nacharbeit anfällt, hängt davon ab, wie klar die Anforderungen vor Beginn sind. Ein erfahrenes Team mit klarem Briefing kann insgesamt weniger kosten als ein günstigeres Team, das Funktionen zweimal baut, weil sich der Umfang ständig verschoben hat.

Typische Fehler von Teams

• Nach einem Preis fragen, bevor der Umfang aufgeschrieben ist, und dann die erste genannte Zahl als Budget behandeln.
• Screens zählen statt Verhalten. Ein einfach wirkender Screen kann Berechtigungen, Berechnungen und Integrationen verbergen.
• Alles rund um die App vergessen: Admin-Werkzeuge, Backend, Benachrichtigungen, Analyse, Store-Prüfung, Datenschutzerklärung und Nutzungsbedingungen.
• Laufende Kosten ignorieren: Hosting, KI-Nutzung, Abonnements von Drittanbietern und Wartung.
• Einen Festpreis des einen Anbieters mit einer Stundenschätzung des anderen vergleichen, ohne zu prüfen, ob beide denselben Umfang beschreiben.
• Annehmen, dass KI-App-Builder die Entwicklung fast kostenlos machen. Sie senken die Kosten der Oberfläche; die Arbeit für den Produktivbetrieb wie Autorisierung, Zahlungen und Monitoring bleibt.

Die wichtigsten Kostentreiber

Jede glaubwürdige Schätzung setzt sich aus denselben wenigen Treibern zusammen. Wenn eine Schätzung sie nicht erwähnt, fragen Sie nach, wie sie berücksichtigt wurden.

• Plattformen: Web, iOS, Android oder alle drei. Plattformübergreifende Frameworks reduzieren doppelten Code, aber nicht Tests, Store-Einreichung oder plattformspezifische Funktionen.
• Rollen und Berechtigungen: Eine einzige Nutzerart ist viel einfacher als Kunden, Mitarbeitende, Admins und Organisationen mit eigenen Mitgliedern.
• Integrationen: Zahlungen, CRM, Karten, Kalender, Messaging und Identitätsanbieter. Jede bringt Konfiguration, Fehlerbehandlung und Tests mit sich.
• Daten und Backend: Echtzeit-Synchronisation, Offline-Unterstützung, Dateiverarbeitung, Suche und Berichte.
• KI-Funktionen: Ein einzelner Modellaufruf in einer bestehenden Funktion ist überschaubar. Retrieval über Ihre Dokumente, Evaluierung, Sprache und Agenten mit Werkzeugberechtigungen und Sicherheitskontrollen sind erhebliche Arbeit.
• Compliance und Sicherheit: Gesundheit, Finanzen, Daten von Kindern und regionale Datenschutzanforderungen erfordern zusätzliche Arbeit in Design, Prüfung und Dokumentation.
• Designtiefe: eine an Ihre Marke angepasste Vorlage oder ein eigenes Designsystem.
• Qualitätsanspruch: automatisierte Tests, Staging-Umgebungen, Monitoring und Barrierefreiheit.

Beispielhafte Spannen und ihre Annahmen

Die folgenden Spannen sind beispielhaft, keine Angebote oder Garantien. Sie zeigen, wie sich Umfang in Aufwand übersetzt. Annahmen: ein kleines erfahrenes Team oder ein gründergeführtes Studio, ein Mischsatz zwischen 60 und 120 US-Dollar pro Stunde, ein vor Beginn vereinbarter Umfang und Schätzungen, die Design, Entwicklung, Qualitätssicherung und das erste Deployment umfassen. Nicht enthalten sind Marketing, rechtliche Prüfung, Content-Erstellung, App-Store-Gebühren und laufendes Hosting.

• Klickbarer Prototyp oder validiertes Design: grob 40 bis 150 Stunden, also etwa 2.400 bis 18.000 US-Dollar. Screens und Ablauf, kein produktives Backend.
• Fokussiertes MVP auf einer Plattform: grob 250 bis 600 Stunden, also etwa 15.000 bis 72.000 US-Dollar. Authentifizierung, ein Kernablauf, einfache Administration, eine Zahlungs- oder Messaging-Integration, Deployment.
• Plattformübergreifendes Produkt (Web plus iOS und Android): grob 600 bis 1.400 Stunden, also etwa 36.000 bis 168.000 US-Dollar. Mehrere Rollen, Zahlungen, Benachrichtigungen, ein Admin-Dashboard und Analyse.
• KI-lastiges Produkt: grob 800 bis 2.000 oder mehr Stunden, also etwa 48.000 bis 240.000 US-Dollar und darüber. Retrieval, ein Evaluierungs-Harness, Sprache oder Agenten mit Werkzeugberechtigungen sowie Kostenkontrollen.

Die Rechnung ist bewusst sichtbar: Stunden mal Mischsatz. Wenn die Sätze in Ihrem Markt abweichen oder Ihr Umfang Posten enthält, die hier ausgeschlossen sind, verschiebt sich die Spanne entsprechend. Wer in Euro plant, setzt einfach die Sätze seines Marktes ein; die Methode bleibt gleich, nur die Zahlen ändern sich. Die Breite jeder Spanne spiegelt echte Unsicherheit im Ein-Satz-Stadium wider; ein schriftliches Briefing macht sie enger.

Ein durchgerechnetes Beispiel

Nehmen wir eine hypothetische Termin-App für eine einzelne Praxis: Patientinnen und Patienten buchen und stornieren auf iOS und Android, das Personal verwaltet einen Kalender im Web, Zahlungen werden bei der Buchung eingezogen, und Erinnerungen gehen per E-Mail und Push-Benachrichtigung hinaus. Zerlegen Sie das in Funktionen und schätzen Sie jede mit einem niedrigen und einem hohen Wert: Authentifizierung und Rollen, Buchungsablauf, Kalender für das Personal, Zahlungsintegration mit Webhook-Verarbeitung, Benachrichtigungen, Admin-Einstellungen, Analyse, Tests und Store-Einreichung. Angenommen, die Summe liegt zwischen 500 und 900 Stunden. Beim angenommenen Mischsatz von 60 bis 120 US-Dollar pro Stunde sind das grob 30.000 bis 108.000 US-Dollar. Die Zahl selbst ist weniger wichtig als die Liste: Jede Zeile lässt sich hinterfragen, streichen, verschieben oder präzisieren, und genau so wird die Spanne enger, bevor jemand einen Vertrag unterschreibt.

Laufende Kosten nach dem Launch

Budgetieren Sie getrennt, was der Betrieb der App kostet. Hosting und Datenbanken sind zum Launch oft überschaubar und wachsen mit der Nutzung. KI-Nutzung wird pro Aufruf abgerechnet, schätzen Sie sie deshalb aus den erwarteten Aufgaben pro Nutzer statt mit einer Pauschale. Hinzu kommen Abonnements von Drittanbietern, Entwicklerkonten in den App Stores, Monitoring und Wartung für Betriebssystem-Updates, Aktualisierungen von Abhängigkeiten und Sicherheitskorrekturen. Ein praktischer Ansatz ist, von Anfang an ein jährliches Wartungsbudget zu reservieren und es nach einigen Monaten mit echten Nutzungsdaten zu überprüfen.

Worauf es bei einer belastbaren Schätzung ankommt

Schreiben Sie ein einseitiges Briefing, bevor Sie nach Preisen fragen. Decken Sie Nutzer und Rollen ab, den einen Ablauf, der am ersten Tag funktionieren muss, die Integrationen, die Plattformen, wie sensibel die Daten sind, die Deadline und was ausdrücklich nicht zum Umfang gehört. Das Projektbriefing führt Sie in sechs Schritten durch diese Fragen.

Fordern Sie Schätzungen als Spannen pro Funktion an, mit aufgelisteten Annahmen und Ausschlüssen. Ein Anbieter, der eine einzige Zahl ohne Annahmen nennt, rechnet entweder einen Risikoaufschlag ein oder rät, und Sie können nicht erkennen, was davon zutrifft.

Bezahlen Sie für eine Discovery-Phase, wenn die Unsicherheit hoch ist. Eine kurze bezahlte Scoping-Phase, die Nutzerabläufe, ein Datenmodell und eine Risikoliste liefert, macht die Entwicklungsschätzung deutlich enger und gibt Ihnen etwas Brauchbares, selbst wenn Sie sich für ein anderes Team entscheiden.

Teilen Sie die Entwicklung in Phasen. Vereinbaren Sie einen MVP-Umfang, listen Sie verschobene Funktionen getrennt mit eigenen Spannen auf und legen Sie fest, welche Belege ihren Bau rechtfertigen würden. So bleibt das erste Budget ehrlich, und Sie haben einen Plan für das zweite.

Abwägungen

Ein Festpreis schafft Budgetsicherheit, verleitet Anbieter aber dazu, Reserven einzurechnen und sich gegen Änderungen zu sperren. Abrechnung nach Aufwand ist flexibel, braucht aber Vertrauen, Transparenz und regelmäßige Demos. Viele Teams nutzen einen Festpreis für die Discovery und eine klar definierte erste Phase und wechseln zur Abrechnung nach Aufwand, sobald das Produkt von echten Nutzern lernt.

Niedrigere Stundensätze können mehr Stunden, mehr Nacharbeit oder mehr eigenen Steuerungsaufwand bedeuten. Plattformübergreifende Frameworks sparen doppelte Arbeit, können aber bei plattformspezifischen Funktionen Mehraufwand erzeugen. KI-App-Builder senken die frühen Kosten der Oberfläche, doch die oben beschriebene Arbeit für den Produktivbetrieb muss trotzdem erledigt sein, bevor echte Kunden sich auf die App verlassen.

Erfahrungen aus der Arbeit von ImadDhin

Dies sind Beobachtungen auf Code- und Umfangsebene aus öffentlicher Arbeit, keine Kundenbudgets oder -ergebnisse.

Die öffentliche FoCoCo-Fallstudie nennt ihren Umfang: eine Flutter Phone App, eine Next.js WebApp, ein Firebase-Backend, Sprache in Echtzeit, Mitgliedschaften und eine öffentliche Website. Jeder dieser Punkte ist eine eigene Zeile in jeder ehrlichen Schätzung: zwei Clients, ein Backend mit Sicherheitsregeln, eine Sprach-Pipeline, eine Abrechnungsintegration mit Berechtigungen und eine Marketing-Website. Sie als „eine Golf-Coaching-App“ zu beschreiben, würde fast all diese Arbeit verbergen.

Das ImadDhin-Portal zeigt, wie sich Integrationen ansammeln: Terminbuchung, CRM, Transaktions-E-Mails, Newsletter, Analyse, Zahlungen und Fehlermonitoring. Jede ist schnell angebunden und langsamer zuverlässig gemacht, weil jede eine Konfiguration pro Umgebung braucht, eine Fehlerbehandlung, die den Nutzer nicht blockiert, und Dokumentation, damit jemand anderes sie pflegen kann. Aus genau diesem Grund liegen Einrichtungsnotizen für mehrere Integrationen im Repository.

Häufige Fehler, auf die Sie eine Schätzung prüfen sollten

• Listet sie auf, was ausgeschlossen ist, und nicht nur, was enthalten ist?
• Sind Backend, Admin-Werkzeuge und Deployment enthalten oder nur die Screens?
• Ist die Qualitätssicherung ein eigener Posten?
• Sind bei Mobile-Apps die Store-Einreichung und Prüfrunden enthalten?
• Werden die laufenden KI-Kosten getrennt geschätzt, mit offengelegten Nutzungsannahmen?
• Wem gehören am Ende Code, Cloud-Konten, Store-Konten und Daten?
• Wie werden Änderungen am Umfang bepreist, wenn die Arbeit bereits läuft?

Wann eine einfachere Lösung besser ist

Wenn eine Tabelle, ein Formular und ein Automatisierungswerkzeug den Prozess für Ihre ersten Kunden tragen können, beginnen Sie dort und lernen Sie, was die App tatsächlich leisten muss. Wenn ein Standardprodukt den größten Teil des Ablaufs abdeckt, ist seine Konfiguration meist günstiger als eine Eigenentwicklung. Und wenn Sie die Nachfrage noch testen, sind ein Prototyp mit einem KI-App-Builder oder eine Landingpage mit Warteliste ein günstigeres Experiment als ein MVP.

Entwickeln Sie individuell, wenn der Ablauf zentral für Ihr Geschäft ist, wenn bestehende Werkzeuge zu mühsamen Umwegen zwingen oder wenn Sie Kontrolle über Daten, Verhalten und Nutzererlebnis brauchen, die Standardprodukte nicht bieten.

Eine Schätzung, die Sie vertreten können

Eine gute App-Schätzung ist eine Liste von Treibern und Annahmen, keine einzelne Zahl. Wie Umfang, Phasen und Übergabe strukturiert sind, erfahren Sie auf unserer Seite zur KI-Produktentwicklung und bei den verfügbaren Formen der Zusammenarbeit. Wenn Sie einen Entwurf für Ihr Briefing haben, bringen Sie ihn in ein 30-minütiges Gespräch mit, und wir gehen die Treiber gemeinsam durch.