IoT Business Models: SaaS, DaaS, Platform-as-a-Service

Why the Business Model Is a Design Input

A connected product has two price tags: what the customer pays, and what it costs to keep the device working, secure, and useful for years. The business model decides who carries the second one, and engineers turn that decision into requirements whether anyone writes it down or not.

Who pays for the battery swap in year three? The SIM in year five? The security patch after the original firmware team has moved on? The answers change the BOM target, the power budget, the update strategy, and how much telemetry the device should send.

Four Models in One Table

The models stack. A thermostat can be sold outright, offer paid energy reports, and run on a third-party IoT platform that the manufacturer pays for. That is a product sale plus SaaS revenue plus a purchased PaaS, not DaaS. DaaS starts when the customer stops buying the device and starts paying for it to keep working.

One-Time Sale: Every Cloud Feature Is a Liability

The money arrives once; the costs don't stop. Every unit that depends on your backend consumes hosting, connectivity, support, and security-maintenance effort for as long as you support it, and all of that has to come out of the margin earned at the sale:

Required margin per unit  >=  (cloud + connectivity + support + security maintenance per device-year)
                              x supported years

At an illustrative USD 1.00 per device-year over a five-year support period, every unit sold carries USD 5.00 of future cost: trivial for a USD 300 appliance, decisive for a USD 15 smart plug. If the device can't function without that cloud, the liability is open-ended.

Design rules that follow:

• Make the core function local. The device should keep doing its main job when your servers are unreachable, or gone. Local-control standards such as Matter let a device keep working without its maker's cloud. Revolv's hubs in 2016 and Insteon's cloud in 2022 are the standard cautionary tales: when the backend shut down, devices that depended on it lost much of their functionality.
• Declare a support period and design for it. In the UK, the PSTI regime has required manufacturers of consumer connectable products to publish a minimum security-update period since April 2024. In the EU, the Cyber Resilience Act's vulnerability-reporting obligations have applied since 11 September 2026, and from 11 December 2027 manufacturers must provide security updates over a declared support period of at least five years, unless the product is expected to be in use for less time.
• Keep the update path cheap to run. Signed images, a rollback slot, and a build pipeline that someone can still operate in year five matter more than feature velocity.
• Spend cloud features where they earn money. If a feature generates no recurring revenue, implement it locally or don't implement it.

SaaS: Retention Is a Hardware Requirement

In a SaaS-led product the customer pays for an outcome (alerts, reports, fleet visibility) and the device is the delivery mechanism. Hardware may be sold at a profit, at cost, or below cost to lower the upfront price. Whatever the choice, the business only works if customers keep paying long enough.

Initial hardware subsidy   = delivered hardware cost - upfront hardware revenue
Monthly contribution       = subscription price - recurring variable cost
Subsidy payback (months)   = initial subsidy / monthly contribution

Worked example. An environmental sensor costs USD 75 delivered and sells for USD 60, so the vendor starts USD 15 down. The subscription is USD 4.00/month; connectivity, cloud, and support cost USD 1.20/month, leaving USD 2.80 of contribution. The subsidy pays back in about 5.4 months.

That is subsidy payback, not profitability: development, certification, customer acquisition, and fixed operations still have to be covered, and retention is what pays for them. Over a 60-month hardware life, monthly churn sets the expected number of paid months:

Expected paid months = (1 − (1 − churn)^60) ÷ churn; lifetime contribution = paid months × USD 2.80 − USD 15.

Cutting churn from 2.0% to 1.5% is worth about USD 13 per device. If a USD 2 change (better connector sealing, a brown-out-safe flash write path, a better-tuned antenna) removes enough failure-driven cancellations to get there, it pays back more than six times. That is why reliability belongs in the SaaS business case, not just the test plan.

Engineering priorities:

• Data quality is the product. Calibration drift, missing timestamps, silent sensor faults, and gaps in the record make the software worthless even while the device is online. Detect and flag them on the device.
• Make the fleet observable. A compact daily health record lets support solve most problems before the customer cancels:

/* Daily health record, also sent after any reset.
 * Encode field by field (fixed little-endian layout or CBOR):
 * 18 bytes on the wire. */
typedef struct {
    uint32_t fw_version;        /* packed as 0xMMmmpp00               */
    uint32_t uptime_s;
    uint16_t batt_mv;           /* measured under load                 */
    int8_t   rssi_dbm;
    uint8_t  reset_reason;      /* POR, BOR, WDT, HardFault, OTA...    */
    uint16_t tx_retries_24h;
    uint16_t sensor_faults_24h;
    uint8_t  ota_state;         /* idle, pending, applied, rolled back */
    uint8_t  config_rev;
} health_v1_t;

• Gate features in the cloud or with signed configuration, not with an unsigned flag in flash, and define what the device does when a subscription lapses: typically keep local safety and basic functions, stop the paid cloud features.
• Don't overbuild. Hardware headroom that no subscription tier uses only lengthens payback.

DaaS: You Pay for Every Truck Roll

With Device-as-a-Service, the customer pays a recurring fee for a working device. The provider typically owns the hardware and carries maintenance, replacement, and end-of-life costs as the contract defines. The metric that matters is cost per device-year at the agreed service level, not purchase price.

Worked example. A 2,000-unit tracker fleet on a 60-month contract, with an assumed USD 120 per site visit and USD 6 per replacement battery:

Design B saves about USD 241 per device, roughly USD 482,000 across the fleet. The word "validated" carries the result: a cell that sags at −20 °C, or a radio that keeps retrying in marginal coverage, turns a five-year design into a two-year one. Measure battery life on the real duty cycle, at temperature, in representative coverage.

Engineering priorities:

• Remote diagnostics before site visits. Reset reasons, battery trends, signal statistics, and firmware versions separate "send a technician" from "push a config fix".
• OTA with A/B slots and automatic rollback, plus staged rollouts. A bad update across a fleet you own is a fleet of truck rolls.
• Choose serviceability deliberately. Replaceable batteries and modular parts lower repair cost, but connectors, seals, and access panels add failure modes; for a sealed outdoor sensor, swapping the whole unit can be cheaper.
• Design for redeployment. Refurbishment needs a secure wipe of customer data, credential rotation, and fast re-provisioning. Reuse is also where the green IoT design case and the DaaS margin meet.
• Decommission from the server side. Revoke credentials and access in the backend; a remote-wipe command does nothing for a device that is dead or offline.

PaaS: Your Firmware Writes the Platform Bill

An IoT platform sells infrastructure: device registry and identity, message ingestion, state synchronization such as device shadows and digital twins, rules, storage, and integrations. Whether you buy one or sell one, its pricing meters behavior that firmware controls: registered devices, connection time, messages (often counted in fixed-size blocks of a few kilobytes), state updates, and stored data.

Worked example. 10,000 devices each take one reading per minute. Sent individually, that is 432 million messages a month. Batching ten readings per message cuts it to 43.2 million, so as long as each batch stays within one billing block you pay for a tenth of the messages and wake the radio a tenth as often. The cost is up to ten minutes of extra latency; alarms can still bypass the batch.

Firmware behaviors that drive cost:

• Reporting interval and batching, as above.
• Keepalive policy. On LTE-M or NB-IoT, a short MQTT keepalive spends data on pings and keeps the modem out of power-saving mode. For infrequent reporting, reconnecting with TLS session resumption is often cheaper in both energy and data.
• Reconnect storms. After an outage, a whole fleet retrying in lockstep can hit platform rate limits and multiply connection charges. Use exponential backoff with jitter:

#include <stdint.h>

extern uint32_t rng_u32(void);  /* hardware TRNG, or seeded per device */

/* Exponential backoff with full jitter. attempt = 0 on the first retry.
 * A fleet sharing one RNG seed reconnects in lockstep and the jitter
 * does nothing, so seed from a TRNG or the device's unique ID. */
uint32_t reconnect_delay_ms(uint32_t attempt)
{
    const uint32_t base_ms = 2000u;              /* 2 s first window */
    const uint32_t cap_ms  = 15u * 60u * 1000u;  /* 15 min ceiling   */
    uint32_t shift  = (attempt < 9u) ? attempt : 9u;
    uint32_t window = base_ms << shift;          /* up to 1024 s     */

    if (window > cap_ms) {
        window = cap_ms;
    }
    return rng_u32() % window;                   /* [0, window)      */
}

Platform requirements also reach the hardware. A TCP/TLS/MQTT stack with certificate authentication typically needs tens of kilobytes of RAM, which pushes a design toward the larger RFC 7228 constrained-device classes; CoAP/DTLS-based options such as LwM2M fit smaller parts. Where the logic runs (device, gateway, or cloud) is part of the same decision; see IoT device classification.

Before committing to a platform, answer these:

Keep platform-specific code behind a thin connectivity layer. Portability isn't free, but discovering the cost of lock-in after shipping 50,000 devices is more expensive.

Choosing a Model: The Engineering View

PaaS sits across all three: any of them can run on a purchased platform.

The financial test is the same in every case:

Expected lifetime contribution =
    expected collected revenue
  - hardware and deployment cost
  - connectivity and platform cost
  - support, maintenance, and replacement cost
  - customer acquisition cost
  - end-of-life cost

Run it with pessimistic inputs (shorter retention, higher failure and replacement rates, worse coverage, longer support obligations, platform price increases, batteries measured at temperature) and watch cash timing: hardware is paid for months before subscription revenue arrives. IoT ROI calculation covers the customer-side version of the same math.

Requirements That Apply to Every Model

• A defined supported lifetime, aligned across component availability, firmware maintenance, backend compatibility, and what the customer was promised. Qualify second sources early with alternative component cross-referencing so a single end-of-life notice can't end the product.
• A security baseline: protected credentials, authenticated updates, access control, and a vulnerability-handling process.
• Specified failure behavior for when connectivity, the cloud, a sensor, or an update fails.
• A budget for fleet operations: monitoring, incident response, credential management, and support tooling.
• Measurements under realistic conditions for power, radio performance, update reliability, and data quality.
• An end-of-service plan covering device behavior, data access, credential revocation, and customer communication if a subscription or backend ends.

Write each one as a product requirement with a measurable acceptance criterion.

Key Takeaways

• The business model decides who pays for batteries, connectivity, cloud, and patches; engineers turn that into requirements.
• One-time sale: fund the whole support period from the original margin and keep the core function local.
• SaaS: retention is the revenue, and reliability and data quality are what protect it.
• DaaS: optimize cost per device-year; an extra USD 11 of BOM can save USD 241 in site visits.
• PaaS: message rate, batching, keepalive, and reconnect behavior set the platform bill.
• Subsidy payback is not profitability; test the economics with pessimistic retention, failure, and coverage assumptions.