Das Angebot lautete auf achtzehn Lakh Rupien — gut 20'000 Dollar — und vier Monate. Niemand hat gelogen. Die App ging live, sie funktionierte, alle waren zufrieden.
Was im Angebot nicht stand: Dieselbe App kostet danach jedes Jahr Geld, ob je ein neues Feature dazukommt oder nicht — und diese Summe übersteigt über eine normale App-Lebensdauer das, was der Bau gekostet hat.
Die Kosten, die kommen, egal ob Sie etwas tun
Das ist die Kategorie, die überrascht — weil sie nicht optional ist und nichts produziert, was ein Nutzer je bemerken würde.
OS-Releases, zweimal im Jahr, für immer. iOS und Android liefern je eine Hauptversion pro Jahr, und jede ändert etwas. Ein Berechtigungsmodell wird strenger, eine API wird abgekündigt, eine Hintergrund-Regel ändert sich, eine UI-Konvention verschiebt sich. Ihre App muss gegen jedes Release getestet und meistens angepasst werden. Lassen Sie einen Zyklus aus, sammeln Sie Schulden an, die irgendwann ein grösseres Projekt erzwingen.
Store-Richtlinien. Beide Stores heben ihre Mindestanforderungen periodisch an — Ziel-SDK-Versionen, Datenschutz-Deklarationen, Offenlegungen. Verpassen Sie eine Frist, nimmt Ihre App keine Updates mehr an und fliegt irgendwann aus dem Store. Das ist nicht verhandelbar und kommt nach dem Kalender von jemand anderem.
Dependency-Verschleiss. Jede Bibliothek in Ihrem Build hat ihren eigenen Release-Zyklus und ihre eigenen Sicherheitswarnungen. Eine Major-Version eines Frameworks kann zwei Wochen Entwirren bedeuten — und je länger Sie es aufschieben, desto schlimmer wird es, denn der Abstand zwischen Ihrer Version und der aktuellen wächst nur.
Zertifikate und Konten. Entwicklerprogramm-Gebühren, Signatur-Zertifikate, Push-Zugangsdaten. Alles läuft irgendwann ab, und jedes Ablaufen macht laut etwas kaputt, wenn niemand es im Blick hatte.
Nichts davon liefert ein Feature. Alles davon ist Pflicht, um in den Stores zu bleiben.
Abb. — Nur das letzte Band ist optional. Der Rest kommt nach dem Kalender von jemand anderem.
Die laufenden Kosten
Backend-Infrastruktur ist der offensichtliche Posten — bei wenig Nutzung meist bescheiden, bei Wachstum nicht linear. Der Fehler ist, ab den Zahlen der Launch-Woche zu budgetieren statt ab der Last, auf die Sie hoffen.
Drittdienste summieren sich leise. Push-Benachrichtigungen, Analytics, Crash-Reporting, Karten, SMS- oder E-Mail-Versand, Authentifizierung, Bild-Hosting. Einzeln ist jeder günstig. Zusammen sind sie ein monatlicher Posten, den die meisten Teams nicht auswendig aufschlüsseln können — und er wächst mit der Nutzung, statt flach zu bleiben.
Monitoring ist der Posten, den Teams streichen und dann bereuen. Crash-Reporting und Performance-Überwachung kosten etwas; sie nicht zu haben heisst, von einem Absturz aus einer Ein-Stern-Bewertung zu erfahren — eine Woche nachdem er begonnen hat.
Die Arbeit, die niemand einplant
Crash-Triage. Auch eine gut gebaute App produziert Abstürze auf Geräte-OS-Kombinationen, die niemand getestet hat. Jemand muss wöchentlich draufschauen, entscheiden, welche zählen, und diese beheben. Ignorieren Sie es, erodiert Ihre Store-Bewertung — und das rückgängig zu machen ist teuer.
Support-Eskalationen. Nicht der First-Level-Support — die Fälle, die einen Entwickler erreichen, weil die Antwort Logs lesen erfordert. Geringes Volumen, hohe Unterbrechungskosten.
Store-Ablehnungen. Auch Routine-Updates werden gelegentlich abgelehnt, manchmal aus Gründen, die ein echtes Gespräch mit einem Prüfer verlangen. Unvorhersehbar und unvermeidlich.
Sicherheits-Patches. Eine Schwachstelle in einer Bibliothek, von der Sie abhängen, ist keine geplante Arbeit. Es ist Arbeit, die Sie in derselben Woche machen.
Wer die Arbeit macht, zählt mehr als was sie kostet
Die Kostenfrage wird meistens vor der schwierigeren gestellt: Wer soll das eigentlich tun?
Die Agentur, die die App gebaut hat, ist die Standardantwort — und das funktioniert, wenn die Konditionen vorher vereinbart sind. Ärger macht die Lücke: Das Projekt endet, der Wartungsvertrag wurde nie unterschrieben, und sechs Monate später macht ein OS-Release etwas kaputt. Jetzt verhandeln Sie einen Notfall-Einsatz mit einem Team, das längst bei anderen Kunden ist — zu dem Satz, den die Dringlichkeit eben rechtfertigt.
Intern einstellen lohnt sich ab einer gewissen Grösse, und die ist grösser, als die meisten Gründer annehmen. Ein einzelner Mobile-Entwickler, der eine App pflegt, ist pro Arbeitseinheit teuer und fragil — wenn er geht, kann niemand sonst ein Release ausliefern, und Sie stellen fest, dass das Signatur-Zertifikat auf seinem Laptop lag.
Der pragmatische Mittelweg für die meisten kleinen Produkte ist ein moderater laufender Vertrag mit dem Team, das gebaut hat — dimensioniert für die planbare Arbeit: OS-Releases, Store-Fristen, Dependency-Updates, Crash-Triage — und Feature-Arbeit separat offeriert. Das verwandelt unberechenbare Notfallkosten in langweilige Monatskosten, und genau das ist der Sinn.
Wofür auch immer Sie sich entscheiden: Die Konten müssen Ihnen gehören. Die Entwicklerprogramm-Mitgliedschaft, die Signatur-Zertifikate, die Backend-Infrastruktur, die Drittdienst-Konten. Teams, die das überspringen, entdecken bei einer Übergabe, dass ihre App rechtlich am Konto eines früheren Auftragnehmers hängt — und dieses Gespräch ist teuer.
Ehrlich dafür budgetieren
Die verbreitete Faustregel der Branche: fünfzehn bis zwanzig Prozent der ursprünglichen Baukosten pro Jahr, nur für Wartung, vor jedem neuen Feature. Die Zahl schwankt mit der Komplexität — aber sie ist eine weit bessere Planungsannahme als die Null, mit der die meisten Erstbudgets stillschweigend rechnen.
Nützlicher noch: Rechnen Sie mit drei bis fünf Jahren Lebensdauer und erwarten Sie Gesamtkosten von ungefähr dem Doppelten der Baukosten. Wenn das die Rechnung kippt, wissen Sie es besser vor dem Start als im zweiten Jahr.
Und budgetieren Sie den Neubau. Jede App erreicht den Punkt, an dem angesammelte OS-Änderungen, Dependency-Drift und Design-Schulden die Weiterarbeit langsamer machen als einen Neuanfang. Typischerweise nach vier bis sechs Jahren. Das ist kein Versagen des Engineerings — es ist der normale Lebenszyklus, und ihn zu leugnen heisst nur, dass der Neubau als Notfall passiert statt als Plan.
Was die Rechnung tatsächlich senkt
Weniger Abhängigkeiten. Jede Bibliothek ist eine dauerhafte Wartungspflicht im Tausch gegen eine vorübergehende Ersparnis. Ein Paket einzubauen, um vierzig Zeilen Code zu sparen, ist über fünf Jahre gerechnet meistens ein schlechter Handel.
Automatisierte Tests um die Teile, die leise kaputtgehen — Zahlungen, Authentifizierung, Sync, alles mit Geld oder Zustand. Sie testen weniger auf Korrektheit als auf das OS-Update, das darunter das Verhalten ändert.
Eine echte CI-Pipeline. Wenn ein Fix nur mit einer bestimmten Person und deren speziell eingerichtetem Laptop ausgeliefert werden kann, bemisst sich Ihre Reaktionszeit auf ein dringendes Problem an der Verfügbarkeit dieser Person.
Und weniger Features. Das will niemand hören. Jeder Screen, den Sie ausliefern, muss gegen jedes OS-Release getestet werden, solange die App existiert. Das billigste Feature im Unterhalt ist das, das Sie nicht gebaut haben — das zweitbilligste das, das Sie entfernt haben, als die Analytics zeigten, dass es niemand nutzt.
Eine App günstig zu besitzen beginnt vor der ersten Zeile — so scopen wir Projekte, und unser Kostenrechner zeigt die Zahlen dahinter.
