Nach dem Go-live fängt es an: was eine App im zweiten und dritten Jahr kostet

Auf dem Tisch liegt ein Angebot. Es nennt einen Preis, einen Zeitraum und einen Funktionsumfang, und es endet an dem Tag, an dem die App im Store steht. Genau dort beginnt die Frage, die in keinem Angebot steht: Was kostet dieses Produkt im zweiten Jahr? Und im dritten?

Diese Frage kommt in unseren Gesprächen fast immer, nur meistens zu spät: dann, wenn die erste Rechnung eintrifft, mit der niemand gerechnet hat. Dieser Beitrag beantwortet sie von der Budgetseite: welche Posten wiederkehren, warum sie wiederkehren und wie Sie daraus vor Projektbeginn eine Zahl machen, die in Ihrem Business Case steht.

Eine Abgrenzung vorweg, damit klar ist, worum es hier nicht geht. In unserem Beitrag über technische Schulden beschreiben wir, wie schlechte Codequalität die Entwicklung mit der Zeit langsamer und teurer macht. Das ist ein Qualitätsthema. Hier geht es um den Haushalt: um die Posten, die auch bei einwandfrei gebauter Software jedes Jahr anfallen, unabhängig davon, wie sauber jemand gearbeitet hat.

Der Denkfehler steckt schon im Angebot

Ein Angebot für eine App liest sich wie ein Bauvertrag. Es beschreibt ein Werk, das zu einem Stichtag fertig ist. Das ist für die Bauphase auch richtig. Falsch wird es in dem Moment, in dem man daraus schließt, dass danach nichts mehr kommt.

Eine App ist kein Druckerzeugnis. Eine Broschüre ist fertig, wenn sie aus der Druckerei kommt, und bleibt es. Eine App ist näher an einem Fuhrpark: Der Kaufvertrag ist der kleinere Teil der Gesamtrechnung, danach kommen Inspektion, Reifen, Versicherung, Steuer, irgendwann ein Austausch. Beim Transporter würde niemand die Betriebskosten für unerheblich halten.

Bei Software passiert genau das, und es hat einen Grund, den Sie nicht beeinflussen können: Die Umgebung, in der Ihre App läuft, verändert sich ohne Ihr Zutun. Ihr Produkt steht still, die Welt darum herum nicht.

Sechs Posten, die jedes Jahr wiederkehren

Erstens: der Plattformzwang. Apple und Google veröffentlichen jährlich neue Betriebssystemversionen und ziehen die Mindestanforderungen für Einreichungen im Store regelmäßig nach. Für Sie heißt das: Auch wenn Ihre App inhaltlich unverändert bleibt, muss sie in Abständen auf neue Werkzeugstände gehoben und gegen neue Geräte und Systemversionen geprüft werden. Wer eine App zwei Jahre lang nicht anfasst, steht irgendwann vor einem Produkt, das sich nicht mehr einreichen lässt. Und man merkt es ausgerechnet dann, wenn es eilig ist, weil ein dringender Fehler behoben werden muss und genau dieser Weg blockiert ist. Das ist der Posten, den fast alle unterschätzen, weil er nichts mit dem eigenen Geschäft zu tun hat und trotzdem nicht verhandelbar ist.

Zweitens: Abhängigkeiten und Frameworks. Kaum eine App besteht nur aus eigenem Code. Kartendarstellung, Zahlungsanbindung, Fehlerüberwachung, Anmeldung: All das kommt aus Bibliotheken anderer. Diese Bibliotheken bekommen Sicherheitsaktualisierungen in aller Regel nur im aktuellen Versionsstrang. Wer über Jahre nicht mitzieht, sammelt keine Ersparnis an, sondern einen Rückstand, und der wird nicht linear teurer, sondern sprunghaft, weil irgendwann mehrere große Versionssprünge gleichzeitig fällig werden.

Drittens: der Betrieb. Hosting, Datenbank, Monitoring, Sicherungen, Zertifikate. Das ist meist die kleinste Position auf der Rechnung und die mit dem größten Schaden, wenn sie ausfällt. Ein abgelaufenes Zertifikat legt eine technisch einwandfreie App an einem Dienstagmorgen still, und niemand ist zuständig, weil die Position nie jemandem zugeordnet wurde.

Viertens: Support und zweite Ebene. Nutzer schreiben. Sie schreiben in die Store-Bewertungen, an Ihre Servicemailadresse und manchmal direkt an den Geschäftsführer. Die erste Ebene ist fachlich und gehört zu Ihnen, denn Ihre Leute kennen den Prozess. Die zweite Ebene ist technisch: Wer nimmt einen reproduzierbaren Fehler auf, ordnet ihn ein und entscheidet, ob er sofort behoben wird oder in die nächste Auslieferung geht? Diese Rolle kostet Geld, auch wenn sie in ruhigen Monaten wenig zu tun hat.

Fünftens: Store- und Rechtspflege. Datenschutzangaben und Angaben zur Datenverwendung im Store-Eintrag wollen gepflegt sein, Screenshots müssen nach neuen Gerätegenerationen nachgezogen werden, Texte und Alterseinstufungen ebenso. Dazu kommen Anforderungen aus dem Rechtsrahmen, die sich fortschreiben. Dieser Beitrag ordnet den Stand nur ein und ersetzt keine Rechtsberatung, aber budgetseitig gilt: Rechtspflege ist ein wiederkehrender Posten, kein einmaliger.

Sechstens: Weiterentwicklung. Das ist ausdrücklich ein eigener Topf und keine Wartung. Wartung hält den Stand, Weiterentwicklung verändert ihn. Wer beides in einen Vertrag wirft, erlebt regelmäßig denselben Verlauf: Das Kontingent wird von Änderungswünschen aufgebraucht, die Pflege wird verschoben, und zwei Jahre später steht der Plattformzwang aus Punkt eins als Sammelrechnung vor der Tür.

Wie Sie daraus ein Budget machen

Der übliche Fehler ist, diese Posten einzeln zu schätzen. Das führt zu einer Liste mit sechs Zahlen, von denen fünf geraten sind, und am Ende glaubt niemand der Summe.

Praktikabler ist der umgekehrte Weg: Denken Sie in einem Anteil an der Erstinvestition pro Jahr. Diese Sicht skaliert mit der Größe des Produkts, denn eine größere App hat mehr Oberfläche, mehr Abhängigkeiten und mehr Betrieb. Und sie ist verhandelbar, weil eine einzige Zahl im Raum steht statt sechs Unbekannter.

Wir nennen hier bewusst keinen Prozentwert. Kursierende Faustzahlen unterscheiden sich erheblich, und sie hängen an Faktoren, die von Produkt zu Produkt verschieden sind: Zahl der Schnittstellen, Nutzeraufkommen, regulatorisches Umfeld, wie viele Plattformen Sie bedienen. Lassen Sie sich die Zahl stattdessen von Ihrem Dienstleister ausrechnen und vor allem begründen. Welche der sechs Posten stecken darin? Von wie vielen Auslieferungen pro Jahr geht die Rechnung aus? Ist die jährliche Systemumstellung enthalten oder wird sie separat beauftragt? Eine begründete Zahl können Sie prüfen und verhandeln. Eine Faustzahl aus einem Blogbeitrag können Sie nur glauben.

Zwei Fragen holen die Zahl zuverlässig heraus. Erstens: Was kostet der Betrieb in einem Jahr, in dem wir keine einzige neue Funktion bestellen? Zweitens: Was passiert, wenn wir dieses Budget ein Jahr lang aussetzen? Die Antwort auf die zweite Frage ist die eigentlich interessante.

Was die laufenden Kosten senkt

Der größte Hebel liegt vor dem ersten Entwicklungstag, nicht nach dem Launch.

Die Technologiewahl entscheidet mit darüber, wie viele Stände Sie später gleichzeitig pflegen. Testabdeckung senkt nicht die Entwicklungskosten, aber die Kosten jeder späteren Änderung, weil eine Aktualisierung überprüfbar wird, statt in einem Handtest zu enden. Dokumentierte Übergaben und Zugänge, die im Unternehmen liegen und nicht im Postfach eines einzelnen Entwicklers, entscheiden darüber, ob ein Wechsel des Dienstleisters ein Vorgang ist oder ein Projekt. Und je gewöhnlicher die eingesetzten Bausteine sind, desto günstiger bleiben sie: Eine exotische Bibliothek, die ein einzelner Autor pflegt, ist beim Bau bequem und in Jahr drei ein Risiko.

Wie viel diese Punkte ausmachen, sehen wir am deutlichsten dann, wenn wir ein bestehendes Produkt übernehmen. Die Here2Build Apps GmbH betreut FindPenguins seit Ende 2023, eine App, die bei der Übernahme längst am Markt war und aktive Nutzer hatte. Die Codebasis stammte ursprünglich von einer einzelnen Person und war praktisch auch nur von dieser Person zu warten. Der erste Arbeitsblock waren deshalb keine neuen Funktionen, sondern ein Umbau der Struktur, damit ein Team parallel daran arbeiten kann. Diese Arbeit hätte im Bau günstiger stattgefunden als im Betrieb. Das gilt für nahezu jeden Posten in diesem Beitrag.

Der Wartungsvertrag: was drinstehen sollte

Damit der Betrieb planbar wird, muss er beschrieben sein. Ein Wartungsvertrag, der nur eine monatliche Summe und das Wort Wartung enthält, ist keine Planungsgrundlage. Fünf Punkte machen ihn zu einer:

• Reaktionszeiten nach Schweregrad. Ein Totalausfall und ein schiefer Button brauchen unterschiedliche Zusagen. Getrennt geregelt ist beides günstiger als eine pauschale Zusage für alles.
• Umfang, positiv beschrieben. Was gilt als Wartung? Systemaktualisierungen, Aktualisierung der Bibliotheken, Fehlerbehebung, Store-Einreichungen, Betrieb und Überwachung gehören ausdrücklich benannt.
• Was ausdrücklich nicht enthalten ist. Neue Funktionen, Umbauten der Oberfläche, neue Schnittstellen. Dieser Satz schützt beide Seiten und verhindert genau die Vermischung aus Punkt sechs oben.
• Kontingent und Umgang mit Resten. Wie viele Stunden sind enthalten, verfallen sie, sind sie übertragbar? Ohne diese Regel entsteht jedes Quartal dieselbe Diskussion.
• Zuständigkeit für Konten und Zugänge. Wem gehören Entwicklerkonten, Zertifikate und Quellcode, und wie läuft die Übergabe, falls Sie den Anbieter wechseln? Das steht am besten im Vertrag und nicht in der Erinnerung eines Projektleiters.

Fazit

Eine App ist ein Betriebsgegenstand. Der Bau ist der sichtbare Teil der Investition, der Betrieb der planbare, und planbar wird er nur, wenn man ihn vor dem Start beziffert statt nach dem ersten Ausfall.

Wenn Sie aus diesem Beitrag eine einzige Frage mitnehmen, dann diese, gestellt im Angebotsgespräch, bevor unterschrieben wird: Was kostet der Betrieb dieser App im zweiten Jahr, und was genau ist darin enthalten? Ein Anbieter, der darauf eine begründete Zahl und eine Liste liefert, hat schon einmal Software über Jahre betreut. Ein Anbieter, der ausweicht, plant nur bis zum Launch. Der Unterschied fällt Ihnen nicht im ersten Jahr auf, sondern im zweiten.

Wenn Sie ein konkretes Vorhaben auf dem Tisch haben, rechnen wir die Betriebskosten dafür gemeinsam durch: die sechs Posten auf Ihr Produkt bezogen, mit Annahmen, die Sie nachvollziehen und mit Ihrem Anbieter abgleichen können. Das dauert ein Gespräch und kostet Sie nichts.

Erreichbar sind wir unter +49 177 4644822, per E-Mail an contact@here2buildapps.de und über here2buildapps.de. Die Here2Build Apps GmbH sitzt in Penzberg und betreut Apps für den Mittelstand, weit über den Launch hinaus.