Plan on roughly 15% to 25% of the original build cost every year just to keep a mobile app working — more if it controls hardware, and more again in the first months after launch. It never reaches zero. An app that receives no work for a year and a half will typically be broken, rejected at its next submission, or quietly removed from a store. This is the single most common budgeting mistake first-time hardware companies make with software.

Launch Is Not the End of Spending — It's the Start

Mechanical parts do not change after you ship them. Software sits on a platform that changes underneath it whether you touch it or not: new operating system versions each year, new devices with new screen shapes, deprecated APIs, tightened permission models, changed store policies, and a steady stream of security advisories in the libraries you depend on.

None of that generates a feature your users asked for. All of it is mandatory.

Where the Money Actually Goes

1. Operating System Releases You Cannot Postpone

Both major platforms ship an annual release plus regular point updates. Each cycle brings deprecated APIs, changes to background execution and permission prompts, and new UI conventions. Separately, the stores enforce minimum target-SDK levels — miss the deadline and you cannot submit an update at all, including a critical bug fix. Budget a testing-and-fixing pass per platform per year as a fixed, non-negotiable item.

2. Cloud and Backend: A Fixed Monthly Line

Compute, database, object storage, a message broker if devices publish telemetry, data egress, push notification services, logging, and monitoring. The bill scales with your installed fleet and with how chatty your firmware is, which makes it an engineering decision as much as a finance one. Typical ranges are broken down in IoT cloud costs.

3. Bug Fixes and Device Fragmentation

Crash reports arrive from device and OS combinations you never owned. Android in particular spans an enormous range of hardware, and Bluetooth stack behavior differs meaningfully between manufacturers. Expect a steady trickle of narrow, real bugs that only appear in the field.

4. Library, SDK, and Security Patches

Every third-party dependency is a maintenance obligation. Vulnerabilities get published, transitive dependencies need bumping, certificates and API keys need rotating, and platforms increasingly require privacy declarations for each SDK you embed. Skipping a year of dependency updates turns a routine upgrade into a rewrite. The broader security posture is covered in IoT security for connected products.

5. User Support and Small Changes

Onboarding copy, an extra language, a settings toggle support keeps requesting, an analytics event marketing needs. Individually trivial, collectively a recurring workstream — and each one still requires a build, a test pass, and a store submission.

6. The Hardware Extra: Firmware and App Move Together

This is what makes a connected-product app more expensive to maintain than a content app. Your app has to keep working with every firmware generation still in the field, deliver OTA firmware updates reliably, survive interrupted updates, and handle devices that have been offline for a year. Production and service tooling built on the same codebase needs maintaining too. Assume a compatibility matrix that grows with every hardware revision you release.

Plus the Small Fixed Costs

Developer program fees for both stores, code-signing certificates, crash and analytics tooling, and error-monitoring subscriptions. Small individually, but they recur and they cannot lapse — an expired certificate can block a release at the worst moment.

Three Ways to Budget It

  • Monthly retainer. A fixed block of hours covering platform upkeep and small changes. Predictable, keeps the team warm, and means someone is watching the crash dashboard. Best fit for a live product with real users.
  • Prepaid hour blocks. Draw down as needed. Cheaper when the app is stable, but response time depends on the vendor's availability, and a blocking store deadline does not wait.
  • Per-incident with an agreed response time. Lowest standing cost, highest risk. Reasonable for internal tools; risky for a consumer product where an outage means refund requests.

Whichever model you choose, agree in the development contract who owns the code and the accounts, and how handover works. Those terms belong in the discussion covered by fixed price vs time and materials.

How to Shrink the Bill Before You Write the Code

  • Support fewer platforms at launch. Every platform is a permanent maintenance obligation, not a one-time build.
  • Move logic out of the app. Anything that lives on the server or in a web view can be changed without a store release — the architecture argued for in mobile app vs web app.
  • Choose boring dependencies. Fewer libraries, well-maintained ones, no abandoned SDKs.
  • Use feature flags and remote configuration so behavior changes do not require a submission.
  • Pick a managed backend unless you have a reason to run infrastructure yourself.
  • Build OTA and remote logging from day one. Diagnosing a field failure blind costs more than the feature would have.
  • Automate the regression tests that cover pairing, provisioning, and update flows — the paths that break silently.
  • Retire unused features. Every screen is a maintenance liability; analytics will tell you which ones nobody opens.

For the build-side numbers, see mobile app development cost and native vs cross-platform development. The wider service is described on our app development pillar page.

If you want a total cost of ownership figure rather than a build quote, Projects House can price the app, the firmware, and the cloud together, including what keeping them alive will cost each year. Get in touch through the contact form and we will lay out both numbers.