The number you have probably read is "15–20% of build cost per year." It is repeated across every agency blog on the internet and there is no evidence behind it. It is a heuristic somebody wrote down once, and it produces absurd results in both directions: a $200,000 enterprise build does not need $40,000 of annual upkeep if it has no integrations, and a $15,000 fitness app with four wearable integrations and a backend will burn through $3,000 in the first three months of a bad Android release.
Maintenance cost is a function of surface area, not of what you paid to build the thing. This post breaks the surface area into its parts, tells you what each one adds, and names what a retainer does not buy.
Our own numbers, since we publish them: app maintenance from $1,000/mo, website care at $299/mo with a $599/mo priority tier, and ongoing QA and release management from $799/mo. Whether you need all three, one, or none depends entirely on what follows.
The six things that actually generate maintenance work
1. Platform releases
iOS and Android ship major versions annually, and each one breaks something. Layout changes, permission model changes, background execution changes, deprecated APIs, new privacy prompts. This is non-negotiable work with a calendar attached, and health apps are hit harder than most because they lean on the parts of the OS that change most: permissions, background execution, and health data frameworks.
Google Play also enforces a minimum target API level that advances each year — apps that fall behind stop being available to new users and eventually to existing ones. This is the single most common way a neglected app dies quietly. It is not a crash; it is a listing that stops appearing.
Cost shape: a predictable annual spike, roughly two of them per year if you support both platforms properly.
2. Health and wearable integrations
This is where health apps diverge sharply from other categories, and it is the reason a fitness app costs more to maintain than a booking app of the same size.
Each integration is an independent moving part with its own release cadence. HealthKit changes with iOS. Health Connect replaced Google Fit's APIs and Android teams are still absorbing that migration. Garmin, Whoop, Fitbit, and Oura are cloud APIs with their own versioning, OAuth token lifetimes, webhook contracts, and rate limits — and none of them coordinate with each other or with you.
The failure modes that generate support tickets are the ones we describe on our wearable integrations page: background delivery quietly stopping, duplicate data when a user adds a second device, permission states that half-fail after an OS upgrade, and timezone handling that breaks a streak at a DST transition. None of these show up as crashes. They show up as one-star reviews saying the numbers are wrong, which is why they are often discovered late.
Cost shape: roughly linear in the number of platforms you support. Each integration you add increases both the baseline monitoring load and the probability of an unplanned month.
3. Backend, infrastructure and dependencies
Servers, databases, queues, and every library in your dependency tree. Security advisories arrive on their own schedule and the serious ones are not optional. Managed services deprecate versions and force upgrades. Cloud costs grow with your data, and health apps accumulate time-series data faster than most.
Cost shape: a steady baseline plus occasional forced migrations, and a cloud bill that grows with usage independent of engineering time.
4. Certificates, credentials and store housekeeping
Signing certificates, provisioning profiles, push notification credentials, and API keys all expire. So do the OAuth registrations for your wearable partners. An expired push certificate means silent notification failure that nobody notices for a week.
There are fixed platform costs here too: the Apple Developer Program is an annual fee and Google Play charges a one-time registration fee.
Cost shape: small, predictable, and catastrophic when missed.
5. Store policy and privacy requirements
App stores keep raising the bar on data disclosure, particularly for health data. Privacy manifests, data-collection disclosures, declarations for sensitive permissions, and specific rules for health and fitness data all change on the platforms' schedules, not yours. Health apps are subject to more of these than any other category except finance.
If your app handles PHI, add the compliance operating cost: dependency CVE review, access reviews, log review, and an annual security assessment cadence that enterprise customers increasingly expect. We cover the full picture in what HIPAA compliance actually costs a startup. To be clear about our own boundary while we are on the subject: we build and maintain HIPAA-aware systems and map compliance boundaries during planning, we do not issue certifications — there is no such thing as HIPAA certification — we do not provide legal sign-off, and we do not determine whether a product is a regulated medical device. That is all published on our trust page.
Cost shape: irregular, occasionally urgent, and hard to defer because non-compliance means removal.
6. The long tail of real devices
Crash triage, device-specific bugs, and the reports from the phone nobody on your team owns. Health apps also inherit hardware variability that other apps do not: watches, rings, straps, and scales, each with their own firmware releases.
Cost shape: highest in the first three months after launch, then declining to a baseline that never reaches zero.
Putting it together: three honest profiles
These are shapes, not quotes. Your actual number comes from a look at your codebase.
| Profile | What it looks like | Realistic posture |
|---|---|---|
| Content app, no backend | Workout library, video, no accounts, no sync | You may genuinely need nothing for months. Budget for the annual OS work and a store-policy check. Do not buy a monthly retainer. |
| Consumer fitness app with sync | Accounts, backend, one to three wearable integrations, subscriptions | A retainer earns its cost. This is the [$1,000/mo](/pricing) band, and integration breakages are what you are insuring against. |
| Regulated or multi-role platform | PHI, clinician and patient surfaces, integrations, audit requirements | Maintenance plus [ongoing QA](/services/qa-release) at $799/mo, plus security operating cost. The compliance work is continuous, not annual. |
The middle row is where most of the fitness and wellness products we see actually sit. If you are not sure which row you are in, tell us what your app does and we will say so — including when the answer is "you do not need us yet."
What $1,000/mo does not buy
This is the part that matters more than the price, and most agency pages skip it.
A maintenance retainer buys monitoring, fixes, dependency updates, and releases for a live app. It does not buy:
- New features. A retainer that is quietly absorbing feature work is a retainer that is not doing maintenance, and you will discover this during the next OS release.
- A rebuild. If the app has fundamental architectural problems, monthly maintenance manages the symptoms at a cost that eventually exceeds a rescue. An App Rescue assessment at $2,500 over ten days will tell you which situation you are in.
- New platform integrations. Adding Whoop is a $3,500 integration, not a maintenance ticket.
- Unlimited scope in a bad month. A major OS release with breaking changes across four integrations is a project. An honest retainer says so rather than absorbing it badly.
- Marketing, ASO, or growth. Different work, different service.
Insist on knowing what happens when a month exceeds the retainer. A vendor with no answer to that question either eats it silently until they resent you, or bills a surprise. Both end badly.
The unprofitable advice
We sell maintenance retainers, so here is what we would tell you if you were a friend rather than a prospect.
If your app is simple and stable, do not buy a retainer. A content-only app with no backend, no integrations, and no accounts can go months with no work. Pay for the annual OS compatibility pass when it is needed and keep the rest of your money. We have told people this and lost the recurring revenue.
If you have an in-house developer, buy QA instead. Often the gap is not engineering capacity, it is the discipline of a real device matrix and a regression cycle before each release. QA cycles start at $499 and ongoing QA at $799/mo, and that is a better purchase than duplicating engineering you already have.
If it is a website, not an app, the answer is much cheaper. Website care is $299/mo. Do not let anyone sell you app-tier maintenance for a WordPress or Webflow site.
Watch the actual expensive failure, which is neglect. The costly outcome is not a month of maintenance you did not need. It is an app that fell three years behind on platform requirements, has a dependency tree nobody can upgrade, and now needs a rebuild — while the reviews accumulated in the meantime follow you into the new version. The rebuild is a five-figure decision. The maintenance was not.
How to work out your own number
- Count your platforms. iOS, Android, web. Each is its own annual cycle.
- Count your integrations. Every wearable platform, payment provider, auth provider, and third-party API. Each is an independent source of unplanned work.
- Do you have a backend? If yes, add continuous dependency and infrastructure work. If no, remove most of this post.
- Do you handle PHI or regulated data? If yes, add the continuous security and compliance operating cost, which does not scale down.
- How many active users? Support and crash triage volume scale with users, not with code size.
- How old is the codebase and how current are its dependencies? This is the biggest single unknown, and the honest way to resolve it is an assessment rather than an estimate.
If you want the real number rather than the shape, an App Rescue assessment at $2,500 over ten days produces a technical assessment, a fix plan, and a quote. If the app turns out to be healthy, that is a useful thing to know before you commit to a retainer.
For products that are still being planned, the cheapest maintenance decision is made during the build: fewer integrations, fewer dependencies, less stored data, and a deliberate choice about which platforms you actually support. That is part of what an MVP Planning Sprint at $1,500 over five days is for.
Tell us what your app does, how old it is, and what breaks most often, and we will tell you honestly whether you need a retainer. Get in touch.
Frequently asked questions
How much does it cost to maintain a fitness app?
It depends on surface area, not build cost. A content-only app with no backend may need nothing for months. A consumer fitness app with accounts, a backend, and two or three wearable integrations sits in our $1,000/mo band. A regulated multi-role platform adds ongoing QA and security operating cost on top.
Is app maintenance really 15–20% of the build cost per year?
That rule of thumb is widely repeated and has no real basis. It ignores the variables that actually drive cost — number of platforms, number of integrations, whether there is a backend, and regulatory scope — and it produces bad answers at both ends of the range. Count the moving parts instead.
What happens if we do not maintain the app at all?
The first thing to break is usually availability rather than function: Google Play advances its minimum target API level annually, and apps that fall behind stop reaching new users. After that, wearable sync degrades as APIs and tokens change, dependencies accumulate unpatched vulnerabilities, and eventually the upgrade path is a rebuild.
Does maintenance include new features?
No, and a vendor who blurs that line is doing you harm. Maintenance is monitoring, fixes, dependency updates, and releases. Features are scoped and quoted separately. If your retainer is quietly absorbing feature work, the maintenance is not happening.
Why do health and fitness apps cost more to maintain than other apps?
Wearable and health-platform integrations, which are independent moving parts with their own release cadences, plus a heavier load of store policy and privacy requirements specific to health data. Both scale with how many platforms you support, which is why integration count is the first question we ask.
Can we just do maintenance in-house?
Often yes, particularly if you have a developer who knows the codebase. The gap is usually not engineering capacity but release discipline — a real device matrix and a regression cycle before each ship. In that case ongoing QA at $799/mo is a better buy than a full maintenance retainer.
How much does the backend infrastructure itself cost?
That is separate from engineering time and it grows with your data and traffic. Health apps accumulate time-series data quickly, so budget for growth rather than for your launch-week bill. If the number matters to your model, get it estimated during architecture rather than discovered in month eight.