AppCare vs. Stundenbasis vs. interner Entwickler

Wenn eine App im Store steht, beginnt die eigentliche Arbeit. Drei Modelle dominieren in der Praxis: ein monatlicher Wartungs-Festpreis (AppCare), eine Stunden-/On-Demand-Vereinbarung mit einem externen Team und ein:e interne:r Entwickler:in. Alle drei können funktionieren — sie reißen nur an unterschiedlichen Stellen, und die Kosten lassen sich nicht so direkt vergleichen, wie es auf den ersten Blick wirkt.

Modell 1: AppCare-Festpreis

Wie es funktioniert: monatlicher Pauschalbetrag, definierte Reaktionsfenster, vereinbarter Leistungsumfang (Monitoring, Updates, Sicherheits-Patches, kleine Weiterentwicklungen). Was darüber hinausgeht, wird transparent on top abgerechnet oder fließt in einen Custom-Tarif ein.

Stärken:

• Planbarkeit. Festpreis, definierter Umfang. Kein Ticket-Schock am Monatsende.
• Proaktivität. Der Anbieter sieht CVE-Feeds, Store-Pflicht-Updates und OS-Major-Releases vor dir. Wartung passiert, bevor sie zum Notfall wird.
• Tooling im Preis. Crash-Reporting, Log-Aggregation, Backup-Verifikation und CVE-Monitoring sind Sache des Anbieters — keine Tool-Lizenzen on top.

Typische Bruchstellen: wenn dein Bedarf so weit jenseits der Tarif-Pauschale liegt, dass jeder Monat in Custom-Aufwand kippt, ist die Pauschale die falsche Mechanik. Bei sehr stabilen Low-Traffic-Apps kann der Tarif teurer wirken als der reine Reaktiv-Aufwand — stimmt rechnerisch, ignoriert aber die Bereitschaft, die du mitkaufst.

Sovion-AppCare-Spannen: ab 59 € · ab 149 € · ab 349 € netto/Monat. Was im jeweiligen Tarif drin ist, klären wir im Angebot — die Treiber dahinter stehen im Cost-Guide.

Modell 2: Stundenbasis / On-Demand

Wie es funktioniert: keine monatliche Pauschale, sondern ein Rahmenvertrag, in dem Stunden bei Bedarf abgerufen werden. Reaktion erfolgt, wenn ein Ticket aufgemacht wird. Häufig keine festen Reaktionsfenster, sondern „so schnell, wie der Dienstleister gerade kann”.

Stärken:

• Niedrige Fixkosten. Wer nichts braucht, zahlt nichts.
• Flexibel bei Einmal-Aufwänden. Eine isolierte Migration, ein Bugfix, ein Branding-Update — als Einzelauftrag funktioniert das.

Typische Bruchstellen:

• Reaktionszeit ist nicht definiert. Wenn am Sonntag-Abend dein Login-Flow bricht, bekommst du Montag-Vormittag Antwort — vielleicht. Ohne SLA gibt es keine Garantie.
• Kein proaktives Monitoring. Niemand sieht den Crash-Spike, bevor du ihn bemerkst. CVE-Patches passieren erst, wenn du sie beauftragst.
• Ramp-up-Kosten pro Ticket. Bei jeder Anfrage muss sich jemand wieder einlesen. Bei einer großen App heißt das oft: erste ein bis zwei Stunden gehen für Re-Onboarding drauf.
• Übergabe-Risiko. Wenn das Team den Code monatelang nicht angefasst hat, sinkt die Mannschaft-im-Kopf-Karte. Komplexe Fehler werden teurer und langsamer.

In unseren Angebots-Vergleichen 2025/2026 liegen DACH-Stundensätze für Senior-Mobile-Entwickler:innen typischerweise zwischen 110 und 180 € netto. Eine mittelgroße App, die in einem normalen Monat Routine-Updates und gelegentliche Inkompatibilitäten braucht, frisst auch in der Reaktiv-Variante vier bis zehn Stunden — ohne SLA, ohne Tooling.

Modell 3: Interner Entwickler / Inhouse-Team

Wie es funktioniert: jemand im eigenen Haus übernimmt Wartung neben (oder statt) Produktarbeit. Häufig die Person, die die App ursprünglich gebaut hat, oder ein internes Mobile-Team, das die App mitnimmt.

Stärken:

• Domänenwissen. Die App ist im Kontext des Geschäfts gebaut — niemand kennt die Sonderfälle besser als ein internes Team.
• Kein externer Vertrag. Direkter Zugriff, keine Abrechnungsdiskussion bei jeder Kleinigkeit.
• Skalierungs-Argument. Sobald drei oder mehr Apps im eigenen Haus laufen, lohnt sich Inhouse-Wartung wirtschaftlich.

Typische Bruchstellen:

• Wartung ist nicht das, was Entwickler:innen mögen. Sie wird gegen Feature-Arbeit verschoben, bis sie zum Notfall wird. Kein Charakterfehler, sondern eine berechenbare Konsequenz von Anreiz-Strukturen.
• Asynchrone Pflichten passen nicht in Sprints. OS-Major-Releases, Store-Pflicht-Updates und CVE-Patches kommen ohne Rücksicht auf Roadmap.
• Tooling-Kosten rechnen sich nicht für eine App. Crash-Reporting, Log-Aggregation und CVE-Monitoring sind teuer, wenn sie nur eine App tragen.
• Bus-Faktor 1. Wenn die einzige Person mit Mobile-Know-how kündigt, beginnt die Migrationsverhandlung mit dem Markt — meist genau dann, wenn ein Pflicht-Update ansteht.

Eine festangestellte Senior-Mobile-Position kostet inkl. Lohnnebenkosten in Deutschland im aktuellen Marktumfeld (BITKOM Bitkom Research / StepStone Gehaltsreport 2025) im niedrigen sechsstelligen Bereich pro Jahr. Solange Wartung den 100%-Job nicht füllt, läuft das Modell auf Bruchteils-Auslastung — bezahlt wird trotzdem die volle Stelle.

Entscheidungs-Matrix

Welches Modell passt, hängt nicht nur am Preis, sondern an drei Dimensionen:

1. Kritikalität der App. Hängt direkter Umsatz oder ein regulatorisches SLA dran? Dann ist „so schnell, wie der Dienstleister gerade kann” keine Option.
2. Anzahl der eigenen Apps. Bei einer App ist Inhouse fast immer Bruchteils-Auslastung. Ab drei Apps mit gemeinsamem Stack lohnt sich eigenes Tooling.
3. Änderungsfrequenz. Stabile Apps mit niedriger Änderung passen in günstige Pauschalen. Hochaktive Produktarbeit gehört in einen größeren Tarif oder in eine eigene Mannschaft.

Faustregel:

• Eine App, niedrige bis mittlere Kritikalität, kein eigenes Mobile-Team: AppCare-Festpreis. Kein Modell ist hier günstiger und stabiler.
• Eine App, hohe Kritikalität, kein eigenes Mobile-Team: AppCare im Premium-Bereich oder Custom-AppCare mit definiertem SLA.
• Mehrere Apps, eigenes Mobile-Team mit echter Kapazität: Inhouse mit klar zugewiesenen Wartungs-Slots im Sprint.
• Sehr stabile App, niedrige Kritikalität, technisch routinierter Auftraggeber: Stundenbasis mit klarem Notfall-Plan kann reichen.

Stundenbasis als alleiniges Modell für eine geschäftskritische App ist in der Praxis fast immer der teurere Pfad — der Schaden im Ernstfall übersteigt den vermeintlichen Festpreis-Aufschlag um Größenordnungen.

Kombi-Pfade, die in der Praxis funktionieren

• AppCare + Inhouse-Produktarbeit. Die häufigste Konstellation bei wachsenden B2B-Produkten: das interne Team baut Features, AppCare übernimmt die infrastrukturellen Pflichten (Updates, CVEs, Compliance, Monitoring). Das interne Team bleibt auf Produktarbeit fokussiert, die Wartungs-Schuld baut sich nicht auf.
• AppCare + Stundenbudget für Sondervorhaben. Kleine Weiterentwicklungen über das Tarif-Fenster hinaus laufen als zusätzliches Stundenbudget — kein Wechsel des Modells, nur ein Aufstocken.

Was selten funktioniert: reine Stundenbasis für eine kritische App in einem 2-Personen-Unternehmen ohne eigenes Mobile-Know-how. Genau diese Konstellation landet bei uns am häufigsten als Rescue — der Verfallsverlauf dahinter steht im Sub-Guide Was passiert ohne App-Wartung?.

Wenn du unsicher bist, welches Modell zu deiner App passt: schreib uns die Eckdaten (Größe, Nutzergruppe, kritisch oder nicht) über das Kontaktformular — Antwort in 24 Stunden, ohne Sales-Pipeline. Mehr Kontext zur Tarif-Logik im Detail steht im Cost-Guide.