Was kostet App-Entwicklung 2026?

Kosten nach Projekttyp

Die meisten Vorhaben lassen sich einer von drei Größenordnungen zuordnen. Die Werte sind Erfahrungswerte aus vergleichbaren Projekten, netto und unverbindlich, Stand September 2026. Den verbindlichen Festpreis nennen wir nach einem Scope-Workshop, abgerechnet in Etappen, die an sichtbare Zwischenstände gekoppelt sind.

Warum das Backend die Hälfte des Budgets beansprucht

Der teuerste Irrtum in App-Projekten ist die Annahme, eine App sei das, was man auf dem Bildschirm sieht. Sobald Inhalte gepflegt, Nutzer angemeldet, Daten zwischen Geräten geteilt oder Push-Nachrichten ausgelöst werden, existiert ein zweites System: Datenmodell, REST- oder GraphQL-Schnittstelle, Authentifizierung, Rechteprüfung, Protokollierung, Monitoring. Dieser Teil ist unsichtbar, aber nicht kleiner als die App selbst.

In unseren Projekten liegt der serverseitige Anteil regelmäßig zwischen 30 und 50 % des Gesamtbudgets. Das ist kein Aufschlag, sondern die Hälfte des Produkts. Wenn ein Angebot für eine App mit Anmeldung, geteilten Daten und Benachrichtigungen keine eigene Backend-Position enthält, fehlt entweder die Hälfte der Architektur oder die Hälfte des Preises – beides fällt erst auf, wenn die App bereits gebaut wird.

Push-Nachrichten sind dabei der am stärksten unterschätzte Einzelposten. Nötig sind Schlüssel und Zertifikate je Plattform, eine Verwaltung der Gerätetoken samt abgelaufener Einträge, eine Einwilligungslogik, Segmentierung der Empfänger und die Trennung zwischen stillen Hintergrundmeldungen und sichtbaren Hinweisen. Ohne diese Arbeit kommt entweder nichts an, oder es kommt zu viel an – und dann schalten Nutzer die Benachrichtigungen dauerhaft ab.

Es gibt Apps, die ohne Server auskommen, aber sie sind die Ausnahme. Unser Eigenprodukt Travl Tracker ist so ein Fall: Die App liest die Fotobibliothek aus, bestimmt über EXIF-Datum und GPS-Koordinate die besuchten Länder und Städte und speichert alles lokal in SwiftData. Die Umkehr-Geokodierung läuft vollständig offline – Länder über den Natural-Earth-Datensatz per Point-in-Polygon-Test, Städte über GeoNames. Kein Konto, kein Server, keine Abfragekosten pro Nutzer.

Kostentreiber und was sie im Budget bewegen

Zwischen der unteren und der oberen Grenze einer Spanne liegen selten geheimnisvolle Faktoren, sondern sechs gut benennbare. Die Auswirkungen unten sind Erfahrungswerte aus vergleichbaren Vorhaben und keine feste Preisliste – sie zeigen, an welchen Stellschrauben ein Budget überhaupt bewegt werden kann.

Die wichtigste Erkenntnis aus dieser Tabelle ist nicht die einzelne Zahl, sondern die Reihenfolge: Wer Budget sparen will, schneidet zuerst den Funktionsumfang und verschiebt die zweite Plattform, statt an Design, Tests oder Wartung zu kürzen. Die ersten beiden Entscheidungen verkleinern das Produkt kontrolliert, die letzten drei verschlechtern es unkontrolliert.

Native, Cross-Platform oder Web-App – was die Entscheidung finanziell bedeutet

Die Technologiewahl ist die zweitgrößte Budgetentscheidung nach dem Funktionsumfang. Sie ist aber keine Glaubensfrage, sondern eine Ableitung aus drei Punkten: Welche Gerätefunktionen braucht die App, wie viele Plattformen sollen bedient werden, und wer pflegt sie in drei Jahren. Wer diese Fragen im Discovery beantwortet, entscheidet damit zugleich über den Wartungsaufwand der kommenden Jahre – nachträgliche Wechsel sind in aller Regel eine Neuentwicklung.

Zwei getrennte native Codebasen sind die teuerste Variante, weil jedes Feature zweimal spezifiziert, zweimal gebaut und zweimal getestet wird – und weil die beiden Versionen im Betrieb auseinanderdriften. Das lohnt sich nur, wenn ohnehin nur eine Plattform bedient werden soll oder die App tief in Systemframeworks greift. Travl Tracker ist genau so ein Fall: Der Scan der kompletten Fotobibliothek mit Speicherung in SwiftData ist nativ in SwiftUI gebaut, weil ein Zwischenlayer hier Aufwand erzeugt statt gespart hätte.

Am anderen Ende steht die Web-App oder PWA. Sie ist in der Erstentwicklung am günstigsten, spart den kompletten Store-Prozess und lässt sich jederzeit ohne Prüfung aktualisieren. Sie scheidet aus, sobald Hintergrund-Standort, tiefer Gerätezugriff oder verlässliche Benachrichtigungen zur Kernfunktion gehören. Wer das vorher klärt, spart im besten Fall das gesamte App-Budget.

Die laufenden Kosten, die in keinem Erstangebot stehen

Eine App ist kein Projekt mit Abschlussdatum, sondern ein Produkt mit Betriebskosten. Die Plattformgebühren selbst sind dabei der kleinste Teil: Das Apple Developer Program kostet 99 USD pro Jahr, die Registrierung für die Google Play Console einmalig 25 USD. Relevanter sind die Posten, die sich nicht in einer Gebührenordnung nachlesen lassen, sondern Arbeitszeit sind.

Wer über die App Erlöse erzielt, sollte vor dem ersten Verkauf das App Store Small Business Program anmelden. Es senkt die Provision auf Käufe unterhalb der Umsatzschwelle auf 15 % statt 30 %. Die Anmeldung gilt nicht rückwirkend, gehört also vor den Launch und nicht in die erste Abrechnung danach.

Was passiert, wenn die Wartung nicht eingeplant wird

An keiner Position wird häufiger gespart als an der Wartung, und keine rächt sich verlässlicher. Der Mechanismus ist unspektakulär: Jedes Jahr ändern sich Build-Werkzeuge, geforderte Ziel-Versionen, Berechtigungsregeln und Abhängigkeiten. Wer diese Änderungen laufend einspielt, hat pro Quartal wenige Stunden Aufwand. Wer drei Jahre wartet, steht vor einem Stapel gleichzeitiger Versionssprünge, bei dem sich Ursache und Wirkung kaum noch trennen lassen.

Dazu kommt der Store selbst. Apple und Google verlangen, dass veröffentlichte Apps aktuell gehalten werden; Apps, die über längere Zeit keine Aktualisierung erhalten und die Plattformvorgaben nicht mehr erfüllen, können in der Sichtbarkeit eingeschränkt oder aus dem Store entfernt werden. Für ein Unternehmen heißt das: Das Produkt verschwindet aus dem Katalog, während die Erwartung der Nutzer bestehen bleibt.

Wirtschaftlich ist der Punkt einfach zu rechnen. Ein Wartungsbudget von einigen hundert Euro im Monat hält eine App über Jahre lauffähig. Die Alternative ist nicht null, sondern eine Neuentwicklung nach zwei bis drei Jahren – also erneut der volle Projektpreis, nur ohne den Nutzen der zwischenzeitlichen Weiterentwicklung.

Förderung: Digitalbonus Bayern

Für bayerische Unternehmen kann der Digitalbonus einen erheblichen Teil der Kosten tragen. Antragsberechtigt sind Unternehmen mit weniger als 50 Beschäftigten und höchstens 10 Mio. € Jahresumsatz oder Bilanzsumme. Gefördert werden bis zu 50 % der Kosten, im Standard bis 7.500 €, in der Plus-Variante bis 30.000 €. Das Programm läuft bis zum 31.12.2027.

Entscheidend ist die Reihenfolge, und daran scheitern die meisten Anträge. Der Antrag muss vor der Auftragserteilung gestellt sein – ein bereits beauftragtes oder gar laufendes Projekt ist nicht mehr förderfähig, unabhängig davon, wie gut es inhaltlich passt. Wer also ohnehin ein App-Vorhaben plant, klärt die Förderfähigkeit vor dem Scope-Workshop, nicht danach.

Wie Sie ein App-Budget sinnvoll aufteilen

Die häufigste Budgetfalle ist nicht ein zu kleines Budget, sondern ein falsch verteiltes. Wer die gesamte Summe in eine erste Version steckt, die alle Wünsche abdeckt, hat nach dem Launch kein Geld mehr für das, was sich erst im Betrieb zeigt – und genau dort entscheidet sich, ob eine App benutzt wird. Sinnvoller ist eine Aufteilung, die den Ausbau bewusst offen lässt.

Praktisch heißt das: zuerst ein MVP mit den zwei bis drei Funktionen, die die zentrale Annahme überprüfbar machen. Das ist keine reduzierte App, sondern eine vollständige Antwort auf eine einzige Frage. Danach wird ausgebaut, was die Nutzungsdaten hergeben – nicht, was in der ursprünglichen Wunschliste ganz oben stand. Erweiterungen rechnen wir wahlweise als Festpreis je Paket oder ab 120 €/h ab.

Ein Rahmen, der sich bewährt hat: etwa die Hälfte des verfügbaren Budgets in die erste veröffentlichte Version, ein Viertel als Reserve für den Ausbau in den ersten zwölf Monaten, ein Viertel für Betrieb und Wartung über drei Jahre. Die konkrete Verteilung verschiebt sich je nach Vorhaben, aber die Reihenfolge bleibt: erst veröffentlichen, dann messen, dann ausbauen.

Vom Richtwert zum verbindlichen Preis

Die Zahlen in diesem Artikel sind Richtwerte, keine Angebote. Verbindlich wird ein Preis erst, wenn Funktionsumfang, Backend, Plattformen und Offline-Anforderungen geklärt sind – bei uns im Scope-Workshop, an dessen Ende ein Scope-Dokument mit User Stories, Plattformentscheidung und Festpreis steht. Danach wird in Etappen abgerechnet, die an sichtbare Zwischenstände gekoppelt sind; jeder Sprint endet mit einem installierbaren Build in TestFlight oder Google Play Internal Testing.

Für die Terminplanung ist der Store-Schritt der einzige, der nicht vollständig in unserer Hand liegt. Apple gibt an, dass die Mehrheit der Einreichungen innerhalb von 24 Stunden geprüft wird. Wir kalkulieren trotzdem ein bis zwei Wochen für den Release, weil eine Ablehnung den Prüfzyklus neu startet und Rückfragen realistisch sind. Vor der ersten Einreichung inventarisieren wir deshalb Datenflüsse und eingebundene SDKs, weil falsche Angaben unter App Privacy Details oder Data Safety ein Ablehnungsgrund sind.

Hinter den Projekten steht eine Person: David De Matteo, Hirnworx, Ziegelstraße 2 in 90579 Langenzenn bei Nürnberg, Entwickler seit 2011 mit über 350 Projekten. Sie sprechen von der ersten Anfrage bis zum Betrieb mit demselben Ansprechpartner. Wie das in der Praxis aussieht, zeigen die beiden Apps in diesem Artikel: Travl Tracker mit vollständig geräteseitiger Auswertung und StoreKit-2-Einmalkauf, und die Silk Road Rally App mit Live-Etappenkarte, Geofence-Quests und Offline-Roadbook für eine Rallye über rund 15.000 Kilometer.