App-Betriebskosten pro Jahr

Die Frage „Was kostet eine App?" wird in Angeboten beantwortet, in Vergleichen, in meinem eigenen Beitrag dazu. Die Frage „Was kostet die App danach, jedes Jahr?" wird fast nie beantwortet, und sie ist für einen Betrieb die wichtigere. Denn die Entwicklung zahlt man einmal. Den Betrieb zahlt man, solange die App im Store steht, und eine Business-App steht dort fünf bis zehn Jahre.

Dieser Beitrag ist die Jahresrechnung. Er ergänzt den Beitrag über Wartung und Support, der beschreibt, was zur Pflege gehört, um die Frage, was das in Tagen und Euro pro Jahr bedeutet. Die Zahlen sind Größenordnungen aus meinen Projekten für Apps mit ein paar hundert bis ein paar tausend Nutzern, keine Preisliste. Sie sollen einem Geschäftsführer erlauben, die Rechnung vor dem Projekt aufzustellen statt nach dem ersten Jahr.

Eine Abgrenzung vorweg, weil sie später jede Diskussion erspart: Betriebskosten sind nicht Weiterentwicklungskosten. Eine neue Funktion gehört nicht in diese Rechnung. Die Jahresrechnung beantwortet nur die Frage, was es kostet, die vorhandene App sicher, kompatibel und betreibbar zu halten. Wer das nicht trennt, führt im zweiten Jahr das Gespräch „Wir zahlen doch schon Wartung, warum kostet das neue Feature extra?"

Für Entscheider: Worum es geht

• Der Betrieb einer App besteht aus vier Blöcken: Infrastruktur (Server, Store, Dienste), Pflege (Betriebssysteme, Bibliotheken, SDKs), Support (Abstürze, Nutzerprobleme, ausgefallene Drittdienste) und einer Reserve für Anlässe von außen.
• Als Planungsgröße: etwa 15 bis 25 Entwicklertage pro Jahr, bevor eine einzige neue Funktion gebaut ist, plus Infrastruktur im niedrigen vierstelligen Bereich. Bei sehr schlanken Apps weniger, bei Hardware-Anbindung, komplexen Drittsystemen oder höherem Supportbedarf mehr.
• Die Pflichtposten sind weitgehend fix. Sie kosten bei einer kleinen App fast dasselbe wie bei einer großen. Deshalb ist der Betrieb bei einer 45.000-Euro-App anteilig deutlich teurer als bei einer für 150.000.
• Über fünf Jahre können sich Betrieb und Pflege auf einen erheblichen Teil der ursprünglichen Investition summieren; bei kleineren Apps können sie die Entwicklungskosten sogar übersteigen. Wer das vorher weiß, kann entscheiden, ob sie sich rechnet.
• Der größte Posten ist nicht der Server, sondern die Zuständigkeit: Jemand muss Konten, Termine, Meldungen und Updates im Blick haben.

Block 1: Infrastruktur, die jedes Jahr Geld kostet

Store-Konten, Signatur, Push

Das Apple Developer Program muss jährlich verlängert werden, 99 US-Dollar. Google Play verlangt einmalig 25 US-Dollar. Das ist der billigste Posten und gleichzeitig einer, der am häufigsten zum Stillstand führt: Läuft das Apple-Konto aus, weil die Kreditkarte abgelaufen ist oder die Mail an einen ehemaligen Mitarbeiter ging, kann die App nicht mehr regulär gepflegt und angeboten werden. Signaturzertifikate und Profile werden bei Apple heute teilweise automatisiert verwaltet, und eine bereits veröffentlichte App läuft weiter, auch wenn ein Zertifikat abläuft; für das nächste Update braucht es aber wieder eine gültige Signatur. Bei Push hängt der Pflegeaufwand davon ab, ob die App noch mit zertifikatsbasierten Push-Zertifikaten arbeitet, die jährlich ablaufen, oder mit einem APNs-Schlüssel, der nicht abläuft und nur widerrufen werden kann.

Entscheidend ist hier weniger das Geld als die Zuständigkeit: Store-Konto, Signatur und Push dürfen nicht an einem ehemaligen Mitarbeiter oder einer alten Agentur hängen. Was dazugehört, steht im Beitrag über die App-Übergabe.

Backend: Der Serverpreis ist nicht der Betrieb

Fast jede Business-App hat ein Backend: Schnittstelle, Datenbank, Nutzerverwaltung, Push-Versand. Der Server dafür kostet bei einem deutschen Hoster für eine App dieser Größe 30 bis 150 Euro im Monat. Das ist die kleinere Hälfte. Die größere ist der Betrieb, und der besteht aus Aufgaben, die jemand erledigen muss:

• Sicherheitsupdates für Betriebssystem, Datenbank und Laufzeit
• Backups, und einmal im Quartal ein Restore-Test, sonst sind es keine
• Monitoring des Servers mit Alarmweg, der auch gelesen wird
• TLS-Zertifikate, Speicherplatz, Logrotation
• Störungsbehebung, wenn nachts etwas stehen bleibt
• je nach App: Mailversand, Push-Relay, Warteschlangen, und bei Bedarf Ausfallsicherheit über einen zweiten Server

Ist das automatisiert und meldet sich das System selbst, kostet der Betrieb ein bis zwei Tage pro Quartal. Ist es das nicht, kostet er ein Vielfaches, nur unregelmäßig und immer zur falschen Zeit. Wie ein Backend so aufgesetzt wird, dass es sich meldet statt zu schweigen, steht im Beitrag über Backends für Mobile Apps.

Dienste und Testgeräte

Crash-Reporting, Kartendienste, Zahlungsanbieter, Scanner-SDKs: Jeder Dienst hat einen Preis, und die Preise ändern sich zu schnell, als dass sie in einen Beitrag gehören. Der Posten, der bleibt, ist Zeit: Jemand muss die Meldungen lesen, einordnen und die relevanten beheben, sonst ist das Monitoring Dekoration. Dazu Testgeräte: für jede Plattform mindestens ein aktuelles und ein älteres Gerät, bei Hardware-Anbindung die tatsächlich im Betrieb genutzten. Alle zwei bis drei Jahre wird eines ersetzt, 300 bis 800 Euro im Jahr, je nach Gerätepark.

Block 2: Pflege, die jedes Jahr Zeit kostet

Betriebssysteme und Store-Vorgaben

Jeden Herbst erscheinen ein neues iOS und ein neues Android. Bei Google ist der Druck konkret: Seit dem 31. August 2026 müssen Updates Android 16 als Ziel haben, bestehende Apps brauchen mindestens Android 15, um für neue Nutzer auf aktuellen Geräten verfügbar zu bleiben, und Google zieht diese Grenze regelmäßig weiter. Apple verlangt ein aktuelles SDK bei neuen Einreichungen; eine veröffentlichte App muss nicht jedes Frühjahr neu eingereicht werden, nur weil Apple ein neues SDK fordert.

Für eine aktiv gepflegte Business-App heißt das: Mindestens einmal im Jahr wird geprüft, ob sie mit den aktuellen Werkzeugen baut und auf den aktuellen Betriebssystemversionen sauber läuft. Spätestens beim nächsten Update müssen dann die aktuellen Store-Vorgaben erfüllt sein. Dabei bricht regelmäßig etwas: eine Berechtigung, die anders abgefragt werden muss, ein Verhalten im Hintergrund, das eingeschränkt wurde, eine Darstellung, die auf dem neuen Gerät verrutscht. Erfahrungswert für eine mittelgroße Business-App: zwei bis fünf Entwicklertage pro Jahr, bei Apps mit viel Hardware-Anbindung (Bluetooth, NFC, Hintergrund-Ortung) deutlich mehr, weil genau diese Schnittstellen sich am häufigsten ändern.

Bibliotheken, SDKs, Werkzeugketten

Eine App besteht zu einem großen Teil aus fremdem Code, und der hängt an einer Kette: das Framework (Flutter, React Native oder die nativen SDKs), darunter Gradle und das Android-Gradle-Plugin, Kotlin, CocoaPods oder Swift Package Manager, Xcode, und obendrauf die Bibliotheken für Kamera, Scanner, Karten, Netzwerk, Datenbank. Jedes Glied bekommt Updates, manche mit Sicherheitskorrekturen, manche mit Brüchen, und ein Sprung an einer Stelle zieht oft die nächste mit. Wer die Kette zwei Jahre liegen lässt, hat beim nächsten Pflicht-Update zwanzig Änderungen auf einmal, von denen fünf sich gegenseitig blockieren. Regelmäßige kleine Updates sind deshalb fast immer billiger als ein großer Versionssprung nach zwei oder drei Jahren. Für eine mittelgroße App sind ein bis drei Entwicklertage pro Jahr ein brauchbarer Planungswert; in einem Jahr mit einem großen Sprung, etwa einer neuen Flutter-Hauptversion oder einem Wechsel des Gradle-Plugins, wird es mehr.

Block 3: Support und Störungen

Abstürze, die im Crash-Reporting aufschlagen, Nutzer, die eine Funktion nicht finden, ein Kartendienst, der seine Schnittstelle ändert, ein Scanner-Hersteller, der sein SDK erneuert, neue Pflichtangaben im Store. Das ist der Block, dessen genauer Umfang nicht planbar ist und für den trotzdem jedes Jahr Budget vorgesehen werden sollte. Vielleicht bleibt eine interne App einmal zwölf Monate ohne Zwischenfall; mit null planen kann man trotzdem nicht. Erfahrungswert: drei bis sechs Tage pro Jahr für das Lesen und Bearbeiten von Meldungen und die kleinen Anpassungen, die daraus folgen. Warum das Crash-Reporting Pflicht ist, steht im Beitrag über Crash-Reporting.

Block 4: Die Reserve für Anlässe von außen

Neue Geräteformate, ein Falt-Gerät, ein neues Ruggedized-Tablet im Lager. Drittdienste, die Preise oder Schnittstellen ändern. Store-Regeln für Datenschutzangaben, Berechtigungen, Login. Personelle Wechsel beim Kunden oder bei der Entwicklerin. Das kommt nicht jedes Jahr, aber es kommt, und es gehört als Reserve ins Budget: drei bis sechs Tage pro Jahr, die in manchen Jahren nicht gebraucht werden und in anderen nicht reichen.

Die Rechnung, und warum kleine Apps anteilig teurer sind

Block	Zeit pro Jahr	Geld pro Jahr
Infrastruktur: Konten, Backend-Betrieb, Dienste, Testgeräte	4 bis 8 Tage	1.000 bis 3.000 Euro
Pflege: Betriebssysteme, Store-Vorgaben, Bibliotheken	3 bis 8 Tage	0
Support und Störungen	3 bis 6 Tage	0
Reserve	3 bis 6 Tage	0
Summe	13 bis 28 Tage	1.000 bis 3.000 Euro

Für die Beispiel-App, eine Inventur-App für drei Lager mit Scanner-Anbindung und Anbindung an die Warenwirtschaft, Entwicklung rund 45.000 Euro, kommen bei einem Tagessatz von 900 Euro und 20 Tagen gut 18.000 Euro Zeit plus etwa 2.000 Euro Infrastruktur zusammen: rund 20.000 Euro im Jahr, knapp die Hälfte der Entwicklung. Das ist kein Rechenfehler, sondern der Kern der Sache: Die Pflichtposten sind fix. Store-Konto, OS-Anpassung, Bibliotheken, Backend und Monitoring kosten bei einer 45.000-Euro-App fast dasselbe wie bei einer für 150.000 Euro. Die große App landet mit denselben 20.000 Euro bei rund 13 Prozent. Die kleine bei knapp 45. Wer eine kleine App plant, muss das wissen, denn hier entscheidet sich, ob sie sich rechnet.

Und die Zeitachse: Eine Business-App steht fünf bis zehn Jahre im Store. Die Inventur-App aus dem Beispiel hat sich nach gut zwei Jahren Betrieb ein zweites Mal bezahlt; die 150.000-Euro-App erst nach rund acht. Über fünf bis zehn Jahre summiert sich der technische Betrieb so zu einem erheblichen Teil der Gesamtinvestition, und bei kleinen Apps übersteigen die laufenden Kosten die Entwicklung innerhalb weniger Jahre, weil die Pflichtposten unabhängig von der Größe anfallen. Das ist die Rechnung, die in Kalkulationen fast immer fehlt, und die, die ein Geschäftsführer dem Kollegen weitererzählt.

Was Sie bewusst streichen können

Nicht alles, was in Angeboten steht, ist nötig. Drei Posten lassen sich bei einer internen Business-App oft streichen, ohne dass etwas fehlt:

• Store-Optimierung und Marketing. Eine App für die eigenen Außendienstler braucht keine Screenshot-Optimierung und keine Keyword-Pflege. Wenn die Nutzer die App per Link oder über das Firmen-MDM bekommen, entfällt das komplett.
• Analytics-Dienste. Für eine App mit bekannten Nutzern reicht, was das Backend ohnehin protokolliert. Ein externer Analytics-Dienst kostet Geld, Datenschutzaufwand und liefert Zahlen, die niemand liest.
• Bereitschaft rund um die Uhr. Wenn die App montags bis freitags im Lager genutzt wird, braucht sie keine Wochenend-Bereitschaft. Eine Reaktionszeit am nächsten Werktag ist für die meisten Business-Apps angemessen und deutlich günstiger.

Wo Sparen teuer wird

Die Versuchung ist, die Pflege zu strecken: die OS-Prüfung auslassen, die Bibliotheken liegen lassen, das Monitoring abbestellen. Das funktioniert genau so lange, bis es nicht mehr funktioniert. Dann kommt die Store-Aufforderung mit kurzer Frist, die Werkzeugkette muss von vor drei Jahren auf heute gehoben werden, und aus drei Tagen pro Jahr werden drei Wochen am Stück, mit Eilzuschlag und ohne Wahl des Zeitpunkts. Der Beitrag über das Ablösen alter Apps beschreibt, wo dieser Weg endet.

Die laufenden Kosten einer App sind keine Verhandlungsmasse. Sie sind der Preis dafür, dass die App im Store bleibt.

Checkliste: Ist Ihre Jahresrechnung vollständig?

• ☐ Sind Betrieb und Weiterentwicklung im Vertrag getrennt?
• ☐ Wer ist für Store-Konto, Signatur und Push zuständig, und stehen die Termine im Kalender?
• ☐ Ist die jährliche Prüfung gegen aktuelle Werkzeuge und Betriebssysteme eingeplant, mit Testgeräten?
• ☐ Werden Bibliotheken und Werkzeugkette regelmäßig nachgezogen oder gesammelt?
• ☐ Was kostet der Backend-Betrieb als Aufgabenliste, nicht als Serverpreis?
• ☐ Liest jemand die Monitoring-Meldungen?
• ☐ Gibt es eine Reserve für Anlässe von außen?
• ☐ Ist die Rechnung über fünf Jahre aufgestellt, nicht nur über eins?

Fazit: Die zweite Rechnung gehört ins erste Gespräch

Eine App kostet nach dem Launch jedes Jahr Zeit und Geld, und zwar berechenbar: etwa 15 bis 25 Entwicklertage für Pflicht und Reserve, plus Infrastruktur, und bei kleinen Apps anteilig mehr als bei großen, weil die Pflichtposten fix sind. Über fünf Jahre kann das einen erheblichen Teil der Investition ausmachen, bei kleinen Apps mehr als die Entwicklung selbst. Wer diese Zahl vor dem Projekt kennt, kann entscheiden, ob sich die App rechnet, und sie in Ruhe budgetieren. Wer sie erst im zweiten Jahr erfährt, hat entweder ein Budgetproblem oder eine App, die langsam aus dem Store fällt. Ich stelle diese Rechnung deshalb im ersten Gespräch auf, neben dem Angebot für die Entwicklung.