Die Wahren Kosten der Wartung Einer Mobile App Nach dem Launch

Gründer kalkulieren den Build sorgfältig. Sie verhandeln das Festpreisangebot, sitzen durch Wireframe-Reviews, diskutieren, ob die dritte Integration wirklich nötig ist. Dann geht die App live, alle feiern den Launch — und die Budgetplanung hört auf. Genau in dem Moment, in dem die Rechnungen anfangen.

Was fast niemand vorher sagt: Ihre Mobile App kostet jedes Jahr Geld, in dem sie live bleibt — egal, ob Sie eine einzige Codezeile anfassen oder nicht. Apple und Google erzwingen Betriebssystem-Updates bei Ihren Nutzern, ob Sie bereit sind oder nicht. Ihre Backend-APIs ändern sich, ohne dass jemand Sie fragt. Es tauchen Bugs auf, die kein noch so gründliches QA vor dem Launch hätte finden können, weil echte Nutzer sich nie so verhalten wie ein Testplan es vorsieht. Nichts davon ist optional, und nichts davon ist im ursprünglichen Build-Budget enthalten.

Dieser Artikel ist das Begleitstück zu unserer Aufschlüsselung der Entwicklungskosten einer Mobile App. Dieser Guide behandelt, was Sie bis zum Launch zahlen. Dieser hier behandelt, was Sie zahlen, um live zu bleiben.

Mobile-App-Wartungskosten: Die Kurze Antwort

Frage	Antwort
Typische jährliche Wartungskosten	15-20% der ursprünglichen Build-Kosten, jedes Jahr
Was sie treibt	Erzwungene OS-Updates, Bugfixes, API-/Backend-Änderungen, Sicherheitspatches, Hosting
Beispiel	Ein Build für 55.000 € → etwa 8.250 €-11.000 €/Jahr, um die App am Laufen und aktuell zu halten
Was passiert, wenn Sie es ignorieren	Die App bricht still, dann sichtbar — meist innerhalb von 12-18 Monaten

Wenn Sie sich nur eine Zahl aus diesem Artikel merken, dann diese: 15-20%. Das ist die branchenübliche Faustregel für jährliche Mobile-App-Wartungskosten, und sie gilt unabhängig davon, ob die App intern, von einem Freelancer oder von einer Agentur gebaut wurde.

Warum Wartung im Ersten Budget Vergessen Wird

Es liegt nicht daran, dass Gründer nachlässig sind. Es liegt daran, dass Wartung während des Builds unsichtbar ist. Niemand präsentiert ein Dependency-Update in einem Demo. Niemand schreibt „funktioniert nach dem iOS-20-Release noch" auf ein Pitch Deck. Der Build hat eine klare Ziellinie — den Launch-Tag — und bekommt deshalb eine klare Budgetzeile. Wartung hat keine Ziellinie und fällt deshalb still aus der Tabelle.

Das Problem taucht später wieder auf, meist 6-12 Monate nach dem Launch, wenn ein Gründer eine E-Mail bekommt, dass die App wegen eines Compliance-Problems aus dem App Store entfernt wurde, oder wenn die Support-Tickets sprunghaft steigen, weil die App auf dem neuesten Handymodell abstürzt. An diesem Punkt ist der Fix dringend und ungeplant — und das ist immer die teuerste Art, für irgendetwas zu bezahlen.

Was die „15-20% der Build-Kosten" Wirklich Abdecken

Die 15-20%-Zahl ist kein Aufschlag — sie entspricht echter, wiederkehrender Arbeit. Hier ist, was wirklich darin steckt.

1. Erzwungene OS-Updates — Die, der Niemand Entgehen Kann

Apple bringt jedes Jahr im September eine neue iOS-Hauptversion heraus. Google bringt eine neue Android-Version nach eigenem Zeitplan heraus. Keiner der beiden fragt vorher um Erlaubnis. Bei jedem Zyklus muss Ihre App gegen neues OS-Verhalten, neue Gerätegrößen, neue Berechtigungsabfragen und neue Store-Review-Anforderungen getestet — und oft angepasst — werden.

Das ist der Hauptgrund, warum „Wartung kümmern wir uns später drum" nach hinten losgeht. Es ist keine optionale, aufschiebbare Arbeit. Es ist eine Uhr, die am Tag des Launches zu laufen begann, und Apple und Google geben das Tempo vor — nicht Sie.

2. Bugfixes und Absturzbehebung

Kein noch so gründlicher QA-Prozess findet alles, was echte Nutzer finden werden. Unterschiedliche Geräte, unterschiedliche Netzwerkbedingungen, unterschiedliche Kombinationen aus OS-Version und Bildschirmgröße bringen Probleme zutage, die in der Testumgebung nie aufgetaucht sind. Das Wartungsbudget deckt eine ständige Kapazität für Triage und Fixes ab — keine einmalige Aufräumaktion, sondern einen laufenden Strom.

3. API-, Backend- und Drittanbieter-Änderungen

Ihre App kommuniziert fast sicher mit etwas außerhalb von sich selbst: einem Zahlungsdienstleister, einem Karten-SDK, einem Auth-Provider oder Ihrem eigenen Backend. Jeder davon hat seinen eigenen Release-Zyklus, und wenn sich einer ändert, muss sich Ihre App mitändern — sonst bricht die Integration still und leise. Ein Zahlungsanbieter setzt eine API-Version auf „deprecated". Ein Karten-SDK ändert seine Rate-Limits. Ihr eigenes Backend-Team deployt eine Änderung an einem Endpoint, von dem Ihre App abhängt. Nichts davon ist hypothetisch — es ist der normale Betriebsrhythmus jeder vernetzten App.

4. Sicherheitspatches

Apps, die Nutzerkonten, Zahlungen oder personenbezogene Daten verarbeiten, brauchen kontinuierliche Sicherheitsaufmerksamkeit, kein einmaliges Audit beim Launch. Bei Abhängigkeitsbibliotheken werden Sicherheitslücken bekannt. Auth-Bibliotheken werden abgekündigt und müssen ersetzt werden. Wenn Sie in einem regulierten Bereich tätig sind — Gesundheitsdaten, Zahlungen, DSGVO-relevante Nutzer —, wächst dieser Posten mit der Zeit, statt zu schrumpfen.

5. Hosting und Infrastruktur

Server, Datenbanken und Managed Services laufen nicht von selbst. Jemand muss die Verfügbarkeit überwachen, auf Incidents reagieren und verhindern, dass die Infrastrukturkosten mit wachsender Nutzerbasis davonlaufen. Das ist meist der kleinste Anteil der 15-20%, aber ein Fixkosten-Posten ab Tag eins — nicht erst, sobald Sie skalieren.

6. Store-Compliance und Neueinreichungen

App-Store- und Google-Play-Richtlinien ändern sich öfter, als die meisten nicht-technischen Gründer erwarten — neue Anforderungen an Datenschutzhinweise, neue Vorgaben zur Kontolöschung, neue Regeln zur Datenerhebung. Jede Richtlinienänderung kann einen Neueinreichungszyklus erzwingen, selbst wenn sich am eigentlichen Produkt nichts geändert hat.

Was Passiert, Wenn Sie Wartung Ignorieren

Wartung zu ignorieren spart die 15-20% nicht — es verschiebt sie, mit Zinsen.

Monat 1-6: Nichts Sichtbares passiert. Das ist die Falle. Die App funktioniert noch, also fühlt sich Wartung an wie ein unnötiger Budgetposten.

Monat 6-12: Kleine Risse tauchen auf. Ein Feature, das von einer Drittanbieter-API abhing, funktioniert nach einer stillen Änderung vorgelagert nicht mehr. Eine Handvoll Nutzer mit den neuesten Handys meldet Abstürze, die Ihr Team nicht leicht reproduzieren kann, weil niemand die OS-Betas verfolgt hat.

Monat 12-18: Der Schaden wird sichtbar. Apple oder Google markiert die App wegen eines veralteten SDKs oder eines fehlenden Datenschutzhinweises und blockiert neue Einreichungen bis zur Behebung. Ältere OS-Versionen können die App gar nicht mehr herunterladen. Nutzer, die auf einen Absturz stoßen, verschwinden einfach — mobile Nutzer haben nahezu keine Geduld mit einer defekten App, und ein schlechter Update-Zyklus zeigt sich direkt in Ihrer Store-Bewertung und den Retention-Zahlen.

Nach 18 Monaten: Ein komplettes Sanierungsprojekt, von Grund auf neu kalkuliert und gescoped, kostet meist mehr, als 18 Monate des 15-20%-Wartungsbudgets gekostet hätten. Sie zahlen die aufgeschobene Arbeit trotzdem — nur später, unter Druck, und oft zusätzlich zu echtem Nutzerschwund, den Sie nicht zurückholen.

Ein Realistisches Jährliches Wartungsbudget nach Build-Stufe

Basierend auf denselben Stufen wie in unserem Guide zu den Entwicklungskosten einer Mobile App, so sehen die 15-20% in der Praxis aus:

Build-Stufe	Ursprüngliche Build-Kosten	Jährliches Wartungsbudget
Einfach	16.500 € - 37.000 €	2.500 € - 7.400 €/Jahr
Mittlere Komplexität	37.000 € - 87.000 €	5.500 € - 17.500 €/Jahr
Komplex	87.000 € - 200.000 €+	13.000 € - 40.000 €+/Jahr

Betrachten Sie diese Zahlen als Untergrenze, nicht als Obergrenze. Apps mit starker Drittanbieter-Integration, regulierten Daten oder ambitionierten Roadmaps landen oft am oberen Ende — oder darüber, in einem Jahr mit einem großen OS-Umbau.

So Budgetieren Sie App-Wartung Klug

• Legen Sie die 15-20% ab dem Launch zur Seite — als feste Budgetzeile, nicht als etwas, das Sie nach der ersten Krise hektisch zusammensuchen.
• Fragen Sie Ihren Entwicklungspartner, was ein Wartungsvertrag tatsächlich abdeckt — OS-Kompatibilitätstests, Sicherheitspatches und Bug-Triage sollten Standard sein, keine überraschend abgerechneten Extras.
• Priorisieren Sie erzwungene Arbeit vor neuen Features. OS-Updates und Sicherheitspatches halten die App am Leben; neue Features lassen sie wachsen. Beides zählt, aber nur eins davon ist bei einer Frist, die Sie nicht kontrollieren, nicht verhandelbar.
• Prüfen Sie Absturzberichte und Store-Bewertungen vierteljährlich, nicht jährlich. Kleine Probleme sind früh günstig zu beheben und teuer, sobald sie sich aufsummiert haben.

Wie P2C Post-Launch-Wartung Handhabt

Wir bauen jede App von Woche eins an mit Blick auf die Wartungsphase — saubere Architektur, dokumentierte Integrationen und eine Codebasis, mit der der nächste Entwickler (ob das nun wir in einem Jahr sind oder jemand anderes) tatsächlich arbeiten kann. Nach dem Launch bieten wir Wartungsverträge an, die OS-Kompatibilitätstests, Sicherheitspatches, Bug-Triage und Infrastruktur-Monitoring abdecken — zugeschnitten auf die tatsächliche Komplexität Ihrer App, nicht auf eine pauschale Branchenzahl.

Wollen Sie eine echte Wartungszahl für Ihre App, keine Faustregel? Fordern Sie ein Wartungsangebot an und wir gehen gemeinsam durch, was Ihre spezifische App wirklich braucht, um live, sicher und aktuell zu bleiben — dieses Jahr und nächstes.