The short answer

Buy commodity capabilities unless they constrain your product; build only where control or differentiation justifies permanent operational ownership.

What matters in practice

  • Integration cost exists in both choices.
  • Managed services shift rather than remove responsibility.
  • Exit paths have measurable value.
  1. List non-negotiable product capabilities.
  2. Price operations, compliance, and migration.
  3. Prototype the hardest integration before committing.

Boundaries and failure modes

  • Comparing license cost to developer salaries only.
  • Building a broker and calling it a platform.
  • Ignoring service retirement and regional availability.

Scope and decision boundary

Decompose connectivity, identity, registry, messaging, state, rules, storage, fleet operations, and product workflows. Do not choose one answer for a vague “platform.” Mark each capability as differentiating, necessary commodity, or experiment. Running open source creates operating ownership; integrating a managed component still requires architecture and governance.

Decision criteria

Build when a capability embodies proprietary domain behavior, changes with product learning, or requires control a provider cannot offer. Buy when standards and providers cover the need and internal ownership would not improve the user outcome.

Count permanent operations: upgrades, security patches, distributed state, capacity, observability, on-call response, backup, and recovery. Test protocol behavior, SDK footprint, network placement, tenant isolation, export, quotas, maintenance windows, and failure visibility rather than comparing feature checklists.

Model lifecycle economics across documented fleet scenarios. Include integration, migration, support, compliance, transfer, idle environments, incident labor, and delayed product work. Keep the assumptions visible; speculative totals are not precise forecasts.

Standard protocols reduce but do not eliminate lock-in. Device credentials, identifiers, schemas, rules, shadows, historical data, and operating tooling need an exercised exit.

Decision process

  1. Decompose capabilities and sources of truth.
  2. Classify differentiation and required control.
  3. Write pass/fail security, reliability, residency, and interoperability requirements.
  4. Prototype the highest-risk integration with production-shaped devices.
  5. Test outage, quota, upgrade, identity rotation, and export.
  6. Estimate lifecycle cost from explicit scenarios.
  7. Design and exercise the exit before adopting proprietary semantics.
  8. Record assumptions, rejected alternatives, owners, and review triggers.

A hybrid design should retain canonical device and tenant identity plus product schemas under direct governance. Provider adapters need explicit boundaries without erasing useful native features behind a lowest-common-denominator layer.

Failure modes

Building a broker or PKI because it looks small ignores years of operations. Buying an all-in-one suite can force domain semantics into proprietary models. Cost comparisons omit on-call labor or network fees. Hybrid systems can leave teams owning opaque glue while lacking visibility on both sides. A nominal export that has never restored credentials, configuration, and data is not an exit plan.

Implementation checklist

  • Scope is decomposed into owned capabilities.
  • Differentiation and commodity infrastructure are explicit.
  • Pass/fail requirements precede scoring.
  • Operations and security response have named owners.
  • Costs include labor, incidents, integration, and migration.
  • Identity and schemas remain governed.
  • Proprietary dependencies are inventoried.
  • Failure and exit paths are exercised.

Evidence and governance

The decision record should list capability boundaries, requirements, workload assumptions, trial architecture, failure results, cost inputs, security exceptions, rejected alternatives, and owners. Preserve what remains unverified. A polished weighted score can hide a failed hard requirement, so report pass/fail gates separately from preferences. Require architecture, security, operations, product, and finance reviewers to sign the assumptions they own.

For a provider trial, test device enrollment, credential rotation, tenant separation, reconnect storm, downstream outage, quota exhaustion, regional impairment, maintenance, support escalation, configuration export, and historical-data extraction. For an internal build, test node replacement, backup restoration, rolling upgrade, dependency failure, on-call diagnosis, and security patch delivery. Use the same product-shaped messages and devices so comparisons remain meaningful.

Define review triggers rather than an arbitrary annual ritual: material price or quota change, new residency requirement, acquisition or deprecation, fleet shape change, inability to meet recovery objectives, or a product capability becoming differentiating. Revisit the affected capability instead of reopening the entire platform by default. Migration work should have an explicit budget and customer impact. Avoid a permanent “temporary abstraction” that duplicates provider behavior without giving the team either portability or native operational visibility.

Assign one accountable owner after the decision. Procurement does not own service architecture, and the team that built a component cannot treat operations as somebody else’s problem. Publish service objectives, dependency maps, escalation, budget alarms, and deprecation plans. The selected option becomes production-ready only when ordinary engineers can diagnose it, restore it, and explain its failure boundary.

Keep experiments time-bounded. A pilot that becomes production through inertia can acquire sensitive data and availability obligations before security, support, cost, and exit were approved. Promotion from trial to production needs an explicit architecture and operating review.

Primary sources

Use NISTIR 8259A for device cybersecurity capabilities and the OASIS MQTT 5.0 specification for messaging interoperability. Verify current quotas, export, security, shared responsibility, and lifecycle claims in each provider’s official documentation.