The cheapest smart-home architecture is not necessarily the one with the fewest boxes.

A product team can remove a dedicated hub and still increase total cost if that decision shifts complexity into radios, firmware, mobile apps, cloud services, certification, support, or interoperability testing. A homeowner can buy a low-cost device and still pay more over time if the chosen architecture requires subscriptions, replacement gateways, or repeated ecosystem changes.

That is why the economics of hubs and protocols should be measured as a system cost, not as the retail price of a hub.

The landscape is also moving. The Connectivity Standards Alliance released Matter 1.6 on June 17, 2026. Matter is an application-layer interoperability standard; Thread is an IP-based low-power mesh networking technology. A Thread Border Router connects a Thread mesh to other IP networks such as Wi‑Fi or Ethernet. A bridge, hub, controller, border router, cloud service, and app can overlap in one physical product, but they are not the same job.

The economic question is therefore not “Do we need a hub?”

It is:

Which functions must exist somewhere, what does each function cost to build and support, and who pays when the architecture changes?

Cost bucket 1: hardware that may disappear from the shelf but reappear inside other products

Traditional smart-home systems often used a dedicated hub because devices spoke protocols that phones and home networks did not understand directly.

A Matter-over-Wi‑Fi device can often use the home Wi‑Fi network and a Matter controller already present in the ecosystem. A Matter-over-Thread device needs access to a Thread network and, for communication with other IP networks, a Thread Border Router. Thread Group explains that the Border Router function can be integrated into other mains-powered products such as routers, speakers, displays, or set-top boxes, and multiple border routers can provide redundancy.

That can reduce the need for a separate branded box.

But “no separate box” does not mean “no cost.”

The cost can move into:

  • an 802.15.4 radio and associated components;
  • memory and compute for protocol stacks;
  • secure storage and credentials;
  • power-supply design;
  • antennas and RF tuning;
  • certification testing;
  • manufacturing test fixtures;
  • software maintenance.

For a device maker, the right comparison is not “hub BOM versus zero.” It is dedicated infrastructure versus distributed infrastructure.

When a dedicated hub can still be economically rational

A dedicated hub may make sense when it provides several expensive functions in one controlled environment:

  • local automation;
  • protocol translation for an installed base;
  • deterministic device discovery;
  • local storage;
  • security monitoring;
  • fleet management;
  • backup connectivity;
  • integration with professional services.

The box is visible, but the engineering can be easier to govern.

Cost bucket 2: protocol support is a portfolio decision, not a single-SKU decision

Supporting one more protocol sounds like a feature checkbox. In a product portfolio, it creates a new matrix.

Suppose a company supports:

  • Wi‑Fi;
  • Thread;
  • Bluetooth for commissioning;
  • an older proprietary or Zigbee installed base;
  • Matter at the application layer.

Now test combinations across:

  • phone operating systems;
  • major ecosystems;
  • routers;
  • border routers;
  • firmware versions;
  • account states;
  • multi-admin configurations;
  • migration and factory-reset paths.

Matter reduces some interoperability burden by creating common application semantics, but it does not erase network, device-category, implementation, and lifecycle differences.

Matter 1.6 is a useful reminder. The specification continues to evolve, adding setup and multi-ecosystem improvements. That is good for the ecosystem, but every new release creates a product-management choice: when to adopt, what to backport, which certification path to use, and how long to maintain previous versions.

Economic rule: protocol support should be budgeted across the product family and support lifetime, not charged only to the launch project.

Cost bucket 3: certification and compliance are recurring operations

A standards logo is not created by adding a library and shipping.

Certification can require:

  • conformance work;
  • test events or authorized labs;
  • product documentation;
  • identity and attestation management;
  • regression testing;
  • version-specific changes;
  • re-certification or extension work when hardware/software changes.

The exact fees vary by program, membership status, laboratory, region, and product, so this article does not present a universal certification price.

The important economic point is that certification has a cadence.

If a company ships ten device families and updates firmware frequently, the cost is not one certificate. It is the people and process required to keep releases inside certified boundaries.

That can justify shared platform engineering even when a single product manager thinks the common layer is “overhead.”

Cost bucket 4: cloud costs do not disappear when local control improves

Matter and Thread can enable more local communication, which is valuable for latency, resilience, and privacy.

But many commercial products still use cloud services for:

  • remote access;
  • account identity;
  • notifications;
  • device telemetry;
  • firmware delivery;
  • analytics;
  • voice-assistant integrations;
  • backup and restore;
  • customer support diagnostics;
  • subscriptions.

Local control can reduce dependency on cloud round trips for routine commands. It does not automatically remove the cloud business.

This matters because cloud cost has two dimensions.

Variable infrastructure cost

Examples include data transfer, databases, message brokers, logs, media storage, push infrastructure, and compute.

Permanent organizational cost

Examples include on-call engineering, security response, privacy/compliance work, account recovery, observability, and incident management.

The second category is often underestimated because it appears in payroll rather than a cloud invoice.

A device maker should model cloud cost per active device-year, not just per monthly active user, because connected products can remain deployed long after acquisition campaigns end.

Cost bucket 5: support is where architecture complexity sends its invoice

The household sees “device offline.”

Support has to determine whether the cause is:

  • weak Wi‑Fi;
  • Thread mesh coverage;
  • missing Border Router;
  • ecosystem controller unavailable;
  • app account state;
  • device firmware;
  • router multicast behavior;
  • bridge failure;
  • cloud outage;
  • expired token;
  • incorrect commissioning fabric;
  • factory-reset mismatch.

A more interoperable architecture can reduce vendor lock-in, but it can also create multi-party diagnosis.

Who owns the problem when the device is made by Company A, the border router by Company B, the controller platform by Company C, and the home router by Company D?

This is an economics issue because every ambiguous failure can create:

  • longer call time;
  • more returns;
  • replacement shipments;
  • field visits;
  • negative reviews;
  • engineering escalations.

Support cost can justify telemetry—but telemetry has a cost too

Better diagnostics can lower support time. However, telemetry requires data collection, storage, privacy review, dashboards, alerting, and retention rules.

The goal is not maximum telemetry.

It is the smallest diagnostic dataset that can answer common failure questions without collecting unnecessary household data.

Cost bucket 6: installed-base bridges can be cheaper than forcing replacement

A company with millions of older devices faces a different decision from a new entrant.

If the installed base uses Zigbee, Z-Wave, a proprietary radio, or another application model, supporting Matter may not mean replacing every device.

A bridge can expose existing devices into a Matter ecosystem while the underlying network remains unchanged.

That bridge has development and support cost, but it may protect:

  • customer hardware investment;
  • accessory revenue;
  • brand loyalty;
  • installer workflows;
  • warranty assumptions.

The alternative—telling customers to replace functioning devices—can create a much larger commercial cost.

Economic rule: a bridge should be compared with customer replacement cost and churn risk, not only with the cost of new hardware.

Cost bucket 7: ecosystem dependence creates switching costs on both sides

A consumer can often use Matter devices across multiple ecosystems, and Matter 1.6 continues to improve multi-ecosystem experiences.

But product companies still make strategic choices around:

  • which ecosystem features receive first-class support;
  • which app is the primary setup path;
  • whether advanced functions exist outside Matter’s standard clusters;
  • whether cloud accounts are mandatory;
  • whether automation logic lives locally or in a vendor service.

Every proprietary extension can differentiate the product and also create switching cost.

That is not automatically bad. A specialized energy-management feature may legitimately require vendor-specific logic. The problem begins when the business model assumes ecosystem lock-in but the customer believes they are buying portable interoperability.

Clear architecture reduces both support disputes and future migration cost.

Three business models, three different hub economics

1. Hardware-margin model

The company earns mainly when it sells the device.

It should care about:

  • BOM;
  • certification;
  • returns;
  • support calls;
  • channel margin;
  • long support life without recurring revenue.

A dedicated hub may be difficult to subsidize unless it increases basket size or reduces support.

2. Subscription/service model

The device supports recurring monitoring, storage, analytics, or automation services.

The company can justify more infrastructure if recurring revenue supports:

  • cloud operations;
  • security;
  • customer support;
  • ongoing development.

Here, the hub may function as a service anchor or local resilience layer.

3. Ecosystem/platform model

The company benefits when more devices live inside its broader platform.

A speaker, router, display, or set-top box may economically absorb controller or Border Router functionality because the value is not measured by that function alone. It improves the ecosystem’s usefulness.

That explains why “free” infrastructure can exist from the consumer’s perspective: the cost is being justified elsewhere in the platform economics.

A simple five-year cost model

For a product business, estimate:

Year-zero product costs

  • additional radio/components;
  • engineering;
  • certification;
  • manufacturing test;
  • launch documentation.

Annual deployed-base costs

  • cloud;
  • security updates;
  • support;
  • warranty replacements;
  • certification maintenance;
  • ecosystem regression testing.

Change costs

  • protocol version updates;
  • ecosystem API changes;
  • new phone OS behavior;
  • migration tooling;
  • end-of-support communication.

Then compare architectures with the same supported lifetime.

A design that saves $8 of hardware but adds years of avoidable support and cloud complexity may not be cheaper.

Conversely, a separate $50 hub may be hard to justify if functionality already exists in common household devices and the hub adds no unique resilience or service value.

The numbers are company-specific. The framework is not.

What Matter and Thread actually change economically

Matter can reduce the need to maintain completely separate application integrations for every ecosystem.

Thread can provide an IP-based low-power mesh and allow the Border Router function to exist in multiple products rather than a single proprietary gateway.

Those are real architectural advantages.

They do not remove the need for:

  • product security;
  • firmware maintenance;
  • compatibility testing;
  • customer education;
  • lifecycle support;
  • diagnostic tooling;
  • business decisions about cloud and proprietary features.

The cheapest architecture is therefore the one that minimizes lifetime cost per successfully supported household, not the one that minimizes the number of boxes shown in the product photo.

That distinction is the center of the business case.

Sources

Related Reading