Wartungskosten für App und Website: was Software pro Jahr wirklich kostet

Launch-Tag ist der billigste Tag im Leben Ihres Produkts. Alles danach kostet für immer Geld: Server, Zertifikate, OS-Updates, Store-Reviews, Dependency-Patches, Backups und die langsame Ansammlung kleiner Fixes, die Software mit einer Welt synchron halten, die sich weiterdreht. Auftraggeber budgetieren den Build routinely bis auf den Euro und die Zeit danach mit null, und sind dann überrascht, wenn Jahr zwei mit Rechnungen kommt.

Dieser Guide bepreist das Danach ehrlich: was jede Kategorie laufender Kosten kostet, warum die 15-20%-Regel existiert und welche Produkte sie in welche Richtung brechen.

Die 15-20%-Regel und was sie abdeckt

Branchen-Guides konvergieren auf eine Budgetregel: Planen Sie 15-20% der anfänglichen Baukosten pro Jahr für Wartung. Eine EUR60.000-App braucht grob EUR9.000-12.000 im Jahr; eine EUR10.000-Website braucht EUR1.500-2.000. Die Regel überlebt, weil die Arbeit dahinter mit der Build-Komplexität skaliert: Größere Builds haben mehr Dependencies, mehr Anbindungen, mehr OS-Fläche und mehr Nutzer, die Edge Cases finden.

Was die Prozentzahl kauft, Kategorie für Kategorie:

Hosting und Infrastruktur, typischerweise EUR10-100 im Monat für Websites und EUR50-500 für Apps mit echtem Backend. EU-Hosting bei Anbietern wie Hetzner oder AWS Frankfurt kostet keinen nennenswerten Aufschlag gegenüber US-Äquivalenten; die Compliance-Position ist der Punkt, nicht der Preis. Kosten explodieren nur bei vernachlässigtem Engineering: unoptimierte Queries, fehlendes Caching, ausufernde API-Nutzung.

Updates und Compliance, der größte Anteil. Dependencies brauchen Patches, iOS und Android liefern jährlich OS-Versionen, die ungetestete Pfade brechen, und beide App-Stores verschärfen jeden Zyklus Vorgaben zu Privacy-Manifesten, SDK-Versionen und Target-APIs. Für deutsche Produkte kommt die bewegliche Regulierungsfläche dazu: E-Rechnungs-Pflichten mit Einführung bis 2028 laut Koordinierungsstelle XRechnung und BFSG-Barrierefreiheitspflichten für Verbraucherprodukte seit Juni 2025.

Monitoring, Backups und kleine Fixes. Uptime-Monitoring, automatisierte Backups mit getesteten Restores, Zertifikatserneuerungen und der stetige Tropfen kleiner Korrekturen: eine verwirrende Fehlermeldung, ein gebrochener Edge Case, eine Textänderung. Einzeln trivial, zusammen der Unterschied zwischen Software, die sich lebendig anfühlt, und Software, die sich verlassen anfühlt.

Welche Produkte die Regel brechen

Die Regel ist ein Median, und Mediane verstecken Spreizung. Drei Produktformen landen verlässlich über 20%.

Alles mit Geld dran: Shops, Marktplätze, Abo-Produkte. Payment-Provider-Updates, Betrugsmuster, Steuerregel-Änderungen und Dispute-Handling erzeugen Dauerarbeit, die nie im Build-Angebot steht. Budgetieren Sie 20-25% und behandeln Sie es als Umsatzkosten, nicht als Overhead.

Alles mit Drittanbindungen: ERP-Links, CRM-Syncs, DATEV-Pipelines. Jedes externe System ändert seine API nach eigenem Fahrplan, und jede Änderung wird Ihr Incident. Zählen Sie Anbindungen bei der Wartungsbudgetierung genauso wie beim Build; unser MVP-Kosten-Guide erklärt, warum jede über die ersten zwei hinaus echtes Geld addiert.

Alles Regulierte: Gesundheit, Finanzen, Kinderprodukte, Public Sector. Audit-Trails, Pentests, Dokupflichten und Re-Zertifizierungen sind per Gesetz wiederkehrend. Wartung ist hier eine Compliance-Funktion mit dranhängendem Engineering, und Unterbudgetierung ist erst ein Rechtsrisiko, bevor sie ein Technikrisiko ist.

Unter der Regel liegen statische Marketingseiten und simple Content-Apps: wenige Dependencies, keine Nutzerdatenflüsse, keine Store-Präsenz. Fünf bis zehn Prozent decken sie ab, meist Hosting und gelegentliche Updates. Wenn ein Anbieter 20% Wartung auf eine Broschürenseite quotiert, holen Sie ein zweites Angebot.

Retainer oder Pay-per-Fix

Für alles Geschäftskritische schlägt ein kleiner monatlicher Retainer Pay-per-Fix in jeder Dimension, die zählt. Er kauft Monitoring mit jemandem, der hinschaut, garantierte Reaktionszeiten und vor allem ein Team, das Ihre Codebasis schon kennt, wenn sie im schlechtestmöglichen Moment bricht. Der Retainer sind nicht hauptsächlich die Stunden; es ist die stehende Beziehung.

Pay-per-Fix gewinnt für Broschürenseiten und Nebenprojekte, wo ein Tag Downtime nichts kostet und die Codebasis simpel genug ist, dass sich jede kompetente Entwicklerin in einer Stunde orientiert. Die Scheiterart ist die Umkehrung: Ein komplexes Produkt auf Pay-per-Fix heißt, dass jeder Incident damit beginnt, dass ein Fremder Ihren Code zu Notfall-Sätzen liest.

So oder so: Bestehen Sie schriftlich auf den unglamourösen Grundlagen: Arbeit in Ihren Repositories, Staging spiegelt Produktion, Backups restoren nach getestetem Fahrplan, und die Doku wächst mit dem Code. Unsere Vertragscheckliste deckt die Klauseln ab; sie zählen für Wartung so viel wie für Builds.

Wartung budgetieren, bevor Sie bauen

Das billigste Wartungsgespräch findet vor der ersten Codezeile statt, denn Build-Entscheidungen setzen Wartungskosten für Jahre. Ein Standard-Stack mit langweiliger Technologie kostet weniger Wartung als ein exotischer. Weniger Anbindungen heißen weniger künftige Incidents. Ein sauberes Datenmodell und getestete Payments heißen Fixes in Stunden statt Tagen. Verlangen Sie beim Angebotsvergleich von jedem Anbieter die Jahr-zwei-Schätzung im selben Dokument; Anbieter, die keine liefern können, verraten, wie sie über das Danach denken.

Für die Build-Seite des Budgets starten Sie mit App-Kosten oder Website-Kosten in Deutschland und addieren den Jahresanteil aus dem Rechner oben. Und wenn Sie ein Produkt geerbt haben, dessen Wartung mit null budgetiert war: Schicken Sie die Codebasis, der Audit ist billiger als der Notfall: Sprechen Sie mit uns.