Why a Hardware Product Ends Up With a Subscription

Hardware revenue arrives once. The software behind a connected product bills forever: cloud ingest, storage, push notifications, certificate rotation, and two mobile apps that need rebuilding whenever Apple or Google changes an SDK requirement. A device selling for $299 with a $9 monthly tier earns more across three years than the hardware ever did. That arithmetic is why licensing appears in the requirements document long before launch.

It also breaks things. A subscription converts a product the customer owned into one they rent, and buyers notice fast. The engineering question is not whether to charge recurring, but which capability sits behind the paywall and exactly what the device does when payment stops. Get that wrong and you generate one-star reviews and chargebacks; get it right and you fund the ongoing software maintenance the product needs anyway.

The Three Pieces of a Licensing System

Every workable implementation has the same three components, and confusing them is the most common architectural error.

  • The entitlement service. A server that answers exactly one question: what is this device or account allowed to do right now? It holds plan, expiry, seat count, and feature flags. It is not the billing system and should not know what a credit card is.
  • The billing system. Stripe, Chargebee, Recurly, or the app store's in-app purchase rails. It handles cards, dunning, sales tax, proration, and refunds, and it notifies the entitlement service by webhook when a subscription starts, renews, downgrades, or lapses.
  • Device-side enforcement. Firmware or app code that reads a signed entitlement token and gates behavior. Offline tolerance, clock skew, and grace periods are all decided here.

Keep the three separate. Teams that let firmware talk straight to a payment processor end up shipping a firmware update every time marketing changes a price, and they leak payment logic into a binary that ends up in a competitor's hands.

The Decision That Shapes Everything: Offline Behavior

Write down what a paid device does after seven days with no internet, and what an unpaid device does forever. Those two answers drive the whole design.

The usual pattern is a signed entitlement token with a short lifetime, typically 24 to 72 hours, cached on the device and refreshed opportunistically. If the refresh fails, the device keeps operating on the cached token until it expires, then falls back to a defined degraded state. Sign the token with an asymmetric key so the device only carries a public key, and include the device serial in the payload so a token lifted from one unit will not validate on another.

Pick the degraded state deliberately. Safety, local control, and anything the customer physically paid for should keep working: a lock that will not open because a card expired is a product recall waiting to happen. Cloud history, remote access, analytics, automation, and multi-user sharing are fair to gate. This is the same boundary you draw when designing offline mode in a companion app, and the two decisions should be made together rather than by two different engineers a month apart.

Also handle clock attacks. A device with a settable RTC can be rolled back to extend a token, so anchor expiry to a monotonic counter in flash as well as wall-clock time, and treat a clock that moves backward as a refresh trigger.

Tiers, Trials, and What the Store Takes

Three tiers is the practical maximum for a hardware product: a free tier that keeps the device useful, a consumer tier in the $5 to $15 monthly range, and a professional or fleet tier priced per seat or per device. More tiers means more entitlement combinations, and every combination is a test case in firmware, the app, and the web portal.

Where you take the money matters more than founders expect. In-app purchase through Apple or Google costs 15 to 30 percent and buys frictionless conversion. Billing on your own web checkout keeps nearly all the revenue but the app store rules restrict how much you can say about it inside the app. Most hardware companies end up selling subscriptions on the web and letting the app read entitlements, which also keeps B2B invoicing possible. Model both against your cloud infrastructure cost per device before setting a price, because a $4 plan on a device that costs $2.60 a month to run is not a business.

Free trials should start on device activation, not on account creation, or you will pay for months of cloud service for units sitting in a warehouse. Fourteen to thirty days is standard. Require a payment method up front if your goal is revenue; skip it if your goal is activation data.

How Much Enforcement Is Enough

Perfect enforcement is impossible on a device the customer physically owns, and chasing it wastes engineering budget. Calibrate to the threat.

For a consumer product, a signed token plus server-side validation of anything that touches your cloud is sufficient. The cost of bypassing exceeds what almost any consumer will spend. For a professional tool where a cracked unit saves a business thousands of dollars a year, add real hardware backing: keys in the microcontroller's secure element, entitlement checks inside authenticated code paths rather than one tidy "isLicensed" function, and firmware images protected as described in secure boot and firmware encryption. The strongest practical lever is putting real value on the server: a device cannot pirate a computation it never performs locally.

Business Models the Architecture Has to Support

Licensing code is easier to write once the commercial model is settled. A pure hardware-as-a-service arrangement where the device is bundled into the monthly fee needs remote disable and return logistics built in from day one. A razor-and-blade model selling consumables needs authentication on the cartridge, not the base unit. A one-time purchase with an optional cloud tier is the least risky, and it is the only model that survives a customer who cancels and still expects the thing on their counter to work.

The Numbers Worth Instrumenting

Track activation rate from unit shipped to account created, trial-to-paid conversion, monthly churn by cohort, involuntary churn from expired cards, and revenue per active device against cloud cost per active device. Involuntary churn is the one nobody plans for and it commonly runs 20 to 40 percent of total cancellations; a dunning sequence with card-update reminders recovers most of it for almost no engineering effort.

Getting the Model and the Code to Agree

Projects House designs licensing and subscription architecture for connected products, from entitlement schema and offline policy through billing integration and the firmware-side enforcement that has to survive certification. If you are deciding what to gate and how hard, send your product concept and target plan structure through our contact form.