Downloads Do Not Pay the Cloud Bill

A companion app for a physical product is not free to run. Even a modest fleet carries a monthly bill: cloud infrastructure, push notifications, crash reporting, map or voice APIs, two store developer accounts, and the engineering time to keep the app alive through annual iOS and Android releases. That lands between $1,500 and $8,000 a month and never goes to zero. The decision is not whether the app makes money but where the money comes from.

Six models cover almost every hardware companion app. Most products end up combining two.

Subscription

Recurring revenue is the strongest model when the app delivers ongoing value: cloud history, remote access, alerts, analytics, sharing with family or crew, or anything with a recurring cost behind it. Typical consumer pricing sits at $3 to $10 per month or $30 to $80 per year, with annual plans converting better and reducing churn.

The rule that decides whether it works: a subscription must be tied to a service you actually incur cost to provide. Charging monthly for a feature that runs entirely on the device generates cancellations and one-star reviews. Charging for 90 days of video history, off-site alerting, or a shared team dashboard is defensible because the value is visibly continuous.

Budget honestly for churn: consumer hardware subscriptions commonly lose 4 to 8 percent of subscribers monthly, so lifetime value is twelve to eighteen months of revenue, not indefinite. Note the store cut too. Apple and Google take 30 percent in year one and 15 percent thereafter on auto-renewing subscriptions, which is why many hardware companies sell the plan on their own web checkout and let the app read entitlement from the backend.

Freemium

Everything the device needs to function is free; advanced capability is paid. This is the default and usually the right default for hardware, because a paywall in front of basic device control breaks the product the customer already bought.

The hard part is the line. Consumer freemium conversion to paid typically runs 2 to 5 percent, so the free tier has to stand on its own. A workable split for connected products: local control, current status, and basic settings free; history beyond a week, multi-user access, automations, exports, and integrations paid.

In-App Purchases

One-time unlocks fit products where the extra capability is discrete rather than continuous: an advanced measurement mode, an additional workout program library, extra device slots, or a professional calibration tool. Price points of $5 to $30 work; buyers accept a one-time charge far more readily than a subscription of equivalent annual value.

Consumable purchases and virtual goods rarely translate to hardware. If your instinct is to sell consumables, look at whether the physical consumable is the better business, which is the logic behind the razor-and-blade model: filters, cartridges, test strips, and blades monetize better through commerce than through the app store.

Advertising

Almost always wrong for a companion app. Ad revenue depends on session volume, and companion apps are opened briefly and rarely. Realistic eCPMs against a few sessions a week produce cents per user per year, while ads cheapen a product someone paid $200 for and complicate privacy disclosures. The exception is a genuinely high-engagement app, such as a fitness or navigation product where users spend hours in the interface.

B2B and Licensing

The model founders overlook. If your device sells to businesses, the app and its backend are the product's management layer, and businesses pay per seat, per device, or per site without the friction consumers show. Pricing of $2 to $15 per device per month is normal for fleet visibility, and $20 to $100 per seat per month for a management console. Churn is lower, contracts are annual, and there is no app store commission on invoices you send directly.

The same platform can also be licensed. A white-label version of your app for a partner who sells the hardware under their own brand turns engineering you already paid for into a revenue line, along the lines of white-label manufacturing arrangements. This is also where hardware as a service becomes viable: the device is bundled into a monthly fee and the app is what justifies it.

The App as Part of the Product

The sixth model is no direct monetization at all. The app is included in the hardware price because it makes the product sellable at a higher price, reduces support calls, or is simply required for setup. Judge it on margin contribution rather than app revenue: if the connected version sells for $80 more than the unconnected one and app plus cloud cost $12 per unit over its life, the app is profitable even though it never charges anyone.

This is the honest answer for most first products, and it forces the earlier question of whether the product needs an app at all. It also sets a hard ceiling on scope, since every feature is now a cost with no offsetting revenue.

Choosing: Three Questions

  • Does the app deliver value when the device is idle? If yes, a subscription can be justified. If the app is only a remote control, it cannot.
  • Do you have a recurring cost per user? Cloud storage, cellular data, third-party APIs, and video processing all argue for recurring revenue. A Bluetooth-only app with no backend has almost no marginal cost and should not pretend otherwise.
  • Who is the buyer? Consumers resist subscriptions on hardware they own; businesses expect them. The same feature set can be free to consumers and $8 per device per month to a facilities manager.

Then check that the model survives the cost base. Development runs into real money before a dollar comes back, and the ranges in mobile app development cost plus the recurring load described in app maintenance costs after launch and IoT cloud infrastructure costs together set the revenue you need. A $4 per month subscription with 3 percent attach on 5,000 units yields $600 monthly, which does not fund a team.

Implementation Details That Bite

Store policy is not a formality. Apple requires digital features consumed inside the app to use in-app purchase, while goods and services consumed outside it, including physical products and real-world services, must not. Where your feature falls decides whether you pay commission, and getting it wrong surfaces at review time; plan for it as part of publishing to the app stores. Build entitlement checking on your backend rather than in the app, support restore-purchases and account transfer when a device is resold, and decide up front what a paid feature does when the subscription lapses. Turning off safety-relevant functionality on a device the customer owns is a support and reputational problem, so degrade rather than disable.

Work Out the Model Before the Architecture

Projects House builds connected products end to end, and the monetization model shapes the backend, the account system, and the firmware long before the app screens are drawn. Bring us your device concept and target customer through our contact form.