The Line Item Missing From Most Business Plans

Hardware founders budget development, tooling, certification, and inventory. Then the product ships and a bill arrives that nobody modeled: keeping the app, the firmware, and the cloud alive. Software is not a capital purchase that depreciates quietly. It decays on a schedule set by other companies, and the decay is not optional.

Apple and Google each push a major mobile OS release annually and periodically deprecate APIs your app depends on. Cloud providers retire runtime versions and managed service tiers. Security advisories land against libraries you shipped. Certificates expire. A connected product that gets zero software attention for eighteen months typically stops working, and the failure looks to customers like a hardware defect.

A useful planning rule: annual software maintenance runs 15 to 25 percent of the original software development cost, every year, for as long as the product is sold and supported. If the app plus firmware plus cloud cost $180,000 to build, expect $27,000 to $45,000 a year to keep it working, before any new features.

What the Annual Work Actually Consists Of

"Maintenance" is a bundle of six distinct workstreams, and quotes are impossible to compare unless you know which ones are inside the number.

  • Platform compatibility. Testing and fixing against each new iOS and Android release, updating build toolchains, meeting new store submission requirements, and re-signing. This alone is 40 to 120 engineering hours a year for a moderately complex app, and it is non-negotiable if you want to stay listed; the submission side is covered in publishing an app to the app stores.
  • Security patching. Monitoring advisories for your dependency tree, updating libraries, rotating credentials and certificates, and responding to disclosures. Ties directly into the ongoing obligations in IoT security for connected products.
  • Cloud operations. Uptime monitoring, alerting, log retention, backup verification, scaling adjustments, and incident response. Distinct from the infrastructure bill itself, which is separate and covered in IoT cloud infrastructure cost.
  • Bug fixes from the field. Reproducing, fixing, and shipping. Highest in the first six months after launch, then settling to a lower baseline.
  • Firmware releases. Each device-side update has to be built, regression tested on real hardware, staged, and rolled out with monitoring and rollback, per OTA firmware updates. A single firmware release for a modest fleet is realistically 40 to 80 hours end to end.
  • Third-party churn. A payment provider changes its API, a mapping SDK changes pricing, a BLE library drops a platform. This is unplannable individually and entirely predictable in aggregate.

Real Numbers by Product Complexity

Ranges below assume a competent outside team at US or blended offshore rates, and cover maintenance only, not new feature development.

Simple BLE product with one app. A sensor or accessory, phone-only, no cloud account, under 5,000 units. Expect $12,000 to $30,000 per year. That is roughly one part-time engineer's attention, concentrated into two or three release cycles.

Connected product with cloud accounts. App on both platforms, user accounts, device history, OTA, 5,000 to 50,000 units. Expect $40,000 to $90,000 per year, plus infrastructure. This is the most common category and the most commonly underbudgeted.

Fleet or B2B platform. Web dashboard, role-based access, integrations, SLAs, tens of thousands of devices. Expect $120,000 to $300,000 per year. At this scale an in-house team of two to four usually beats an agency retainer on both cost and response time, and the operational demands are laid out in IoT fleet management.

Regulated device. Add 30 to 60 percent on top of any tier. Every change requires documented verification, risk assessment, and traceability, and a two-hour code fix generates a day of paperwork.

Separately, the app-specific portion has its own cost structure worth reading in app maintenance costs after launch.

What Drives the Number Up

Two products with identical feature lists can differ threefold in upkeep. The drivers are architectural, and almost all of them are decided during initial development.

  • Two native codebases instead of one shared one. Separate Swift and Kotlin apps roughly double platform-compatibility work forever.
  • Many hardware variants and firmware versions in the field. Every combination is a test matrix cell. Five active firmware versions across three hardware revisions is fifteen configurations to regression test on every release.
  • No automated tests. Manual regression turns each release into a week of QA. Test coverage is the highest-leverage maintenance investment there is.
  • Heavy third-party dependency. Each external SDK is someone else's deprecation schedule imposed on you.
  • Unmanaged devices that never update. Products without reliable OTA force you to support old firmware indefinitely, and old firmware is the tail that wags the whole cost.

What lowers it: one cross-platform codebase, a small and stable dependency list, real CI with automated tests, a forced-upgrade policy with a defined minimum supported version, feature flags so behavior changes without a release, and aggressive sunsetting of old firmware once adoption passes 95 percent.

Structuring the Contract

Avoid the two common extremes. An hourly break-fix arrangement means nobody watches the system until it is already broken. An all-inclusive retainer with vague scope means you pay for availability and get whatever attention is left over.

A workable structure has three parts. A fixed monthly base covering monitoring, security patching, dependency updates, and platform compatibility, with a named response time for outages. A defined number of scheduled releases per year, typically two to four, each with agreed regression scope. And a separate hourly pool for new features, drawn against explicitly.

Insist on specifics in writing: response and resolution targets by severity, who holds the signing keys and cloud account root credentials, where source and build pipelines live, and a documented handover package so another team could take over in two weeks. Founders discover the cost of skipping that last item only when they want to switch vendors.

Where the Money Comes From

Maintenance is a recurring cost, so it wants a recurring revenue source. A one-time hardware sale funding indefinite software upkeep is a structurally losing position, and it is the main reason so many connected products go dark. Options include a subscription for cloud features, a premium tier for B2B customers, or a service contract, all of which are examined in hardware as a service. At minimum, price the hardware with a few years of expected maintenance amortized into the margin, and publish a support-lifetime commitment so customers know what they bought.

Get a Real Number Before You Ship

Projects House models multi-year software upkeep alongside development, so the number is in the plan before the first unit sells rather than after. Send your architecture, platform list, and expected fleet size through our contact form.