US | Operations | 2026-08-16

App Maintenance Costs After Launch

The build invoice is a one-time number; the app is a subscription you pay in engineering hours, and the annual bill is more predictable than most owners expect.

An app that shipped in March and was never touched again will usually still work in September. By the following March it may be rejected from an app store review queue, refusing to build on the current toolchain, or silently failing for the third of your users who upgraded their phones. Nothing broke on your end. The ground moved.

Most owners budget the build and stop there. The build is the smaller number over a three-year horizon. Here is what the second number is made of.

The fees are trivial. The forced work is not.

Apple charges $99 per year for the Developer Program. Google charges $25 once, forever. Together that is less than a single hour of developer time. Nobody has ever been surprised by those.

The surprise is the calendar. Apple ships a major iOS version every September and, within a few months, starts requiring apps to be built against the newest SDK for any submission — including a one-line bug fix. Google Play enforces a rolling target API level requirement, currently pushing apps to target a recent Android version to stay updatable and, eventually, discoverable. Neither of these cares whether you had a change planned.

So the sequence goes: you have no roadmap items, you have a typo to fix in a pricing label, and shipping that typo requires updating the Flutter SDK, updating twelve packages, resolving three breaking changes, re-testing every screen, and regenerating your release build. A one-line change becomes a two-week engagement. This is the single most common way maintenance budgets get blown — not by big projects, but by small ones with expensive prerequisites.

Where things actually break

In a typical Flutter app with a Firebase backend and Stripe payments, breakage clusters in a handful of predictable places:

• Dependency drift. A production Flutter app pulls 30 to 60 packages. Some are maintained by companies, some by one person who has moved on. When Flutter releases a new stable version, packages that have not been updated stop compiling. You either wait, fork the package, or replace it.
• Native permission and privacy changes. Apple's privacy manifest requirements and Android's shifting permission model for photos, location, and notifications have all forced code changes in apps that had no feature changes. Photo picker behavior in particular has broken uploads in apps that worked fine the prior year.
• Payments SDKs. Stripe deprecates API versions on a schedule and its mobile SDKs follow. Payment sheets and 3D Secure flows change. Nothing degrades gracefully when a checkout breaks.
• Push notifications. Google retired the legacy FCM HTTP API and apps relying on it stopped delivering notifications. That is a backend change, not an app change, and it is easy to miss until customers report silence.
• Certificates and provisioning. iOS distribution certificates expire on a three-year cycle; provisioning profiles expire annually; push notification keys and signing keys need custody. Losing an Android upload keystore used to be close to unrecoverable, and even with Play App Signing it is a support ticket and a delay.

Backend and third-party costs scale with success

Firebase's free tier carries a genuinely small app comfortably. The cost curve is not smooth, though, and it is driven by patterns rather than user counts.

Firestore bills per document read. An app whose home screen loads a 200-item list on every open, without pagination or caching, spends a hundred times more than one that loads 20 and caches. Two apps with identical user numbers can differ by an order of magnitude in bill. Cloud Storage egress for images behaves the same way when nobody resized the uploads. Cloud Functions invocations climb when you add background triggers.

Add the recurring line items that have nothing to do with your code: Stripe's per-transaction cut, a transactional email provider, a crash reporting tier, an SMS provider if you verify phone numbers, and — if you shipped an AI agent — per-token model costs that rise with usage rather than staying flat.

A realistic annual figure

For a custom Flutter build in the $2,500 to $7,000 range, plan on 15% to 25% of the original build cost per year for keeping the app current, with heavier apps toward the top of that range.

Those percentages assume no new features. Feature work is a separate budget, and conflating the two is why owners feel like maintenance is expensive — they are counting the roadmap inside it.

What deferring actually looks like

Skipping maintenance does not produce steady decay. It produces a cliff.

Year one of neglect is usually invisible. Year two is where an urgent fix becomes impossible on a short timeline, because the SDK jump you avoided is now three versions wide and the packages you depended on have had breaking rewrites. A change that would have cost 6 hours as part of routine upkeep costs 40 to 80 hours as an unplanned catch-up project, and it lands exactly when you have a real emergency — a broken checkout, a crash on the newest iPhone, a store compliance notice with a deadline.

The store-level consequences are the ones with hard dates. Apps that fall too far behind Play's target API requirements stop being available to new users on newer devices. Apps that ignore a compliance notice — a missing privacy declaration, an outdated data safety form, an account deletion requirement — can be removed from sale. Removal is recoverable, but recovery takes review cycles you do not control.

The quieter cost is knowledge. The developer who built it remembers why the auth flow has that odd retry. Eighteen months later, whoever picks it up is reading code cold. This is the strongest practical argument for owning your full source: continuity does not depend on any single shop staying interested, and a new team can be productive without a rewrite.

How to keep the number small

A few decisions at build time move the annual figure by a large multiple:

• Fewer dependencies. Every package is a future breaking change. Writing 80 lines yourself often beats importing a library for one function.
• Boring, well-maintained choices. Prefer packages with corporate backing or a real contributor base over the clever one with 200 stars.
• Pin versions, then upgrade deliberately. A committed lockfile means today's build matches last month's. Upgrade on a schedule, not by accident.
• Query design early. Pagination, caching, and resized images cost a day during the build and save recurring money every month afterward.
• Own the accounts. Store listings, signing keys, Firebase project, and domain should be in your company's name from day one, not a contractor's.
• Book two maintenance windows a year. One after the September iOS release, one in spring before Play's target API deadline. Scheduled work is cheaper than emergency work by roughly the same ratio in every industry.

Treat the annual figure as part of the purchase price and the math holds up. Treat the build as the whole cost and the app becomes an asset that quietly turns into a liability around month twenty.