IoT Platform Development Services

IoT platforms for device lifecycle, fleet operations, and tenant access.

We build the shared software layer for device identity, provisioning, telemetry, state, commands, fleet operations, APIs, and tenant permissions. A custom platform makes sense when a managed IoT service cannot express the product model or operating lifecycle.

See our work

Bring the problem, the current workflow, or the existing code. We reply with a practical next step within one business day.

The brief

Start with what is not working.

Good software decisions begin with the constraint, not a list of features or a preferred technology.

01

Does a managed IoT service connect devices but leave provisioning and operations fragmented?

02

Do customer, site, or business-unit boundaries need stronger isolation than a shared vendor console provides?

Plain answer

IoT platform development creates shared software for device identity, provisioning, telemetry ingestion, state, commands, fleet operations, APIs, and tenant access. RaftLabs builds a custom platform when managed services cannot support the required device lifecycle or product model. A focused one-device-type release starts at $30,000 and usually takes 10 to 16 weeks.

The broker worked. Fleet operations still lived in support tickets.

Devices could publish. Onboarding still required database edits, revocation remained unclear, and each customer needed an engineer to diagnose state, so a real platform release must own the whole lifecycle from first registration through fleet support, incident recovery, ownership transfer, and eventual revocation.

Focused delivery baseline

starting first release
$30K
Priced after the device contract is verified
typical focused timeline
10-16 weeks
One device type and product workflow
initial expansion gate
One fleet
Prove onboarding and recovery before adding types

RaftLabs does not currently publish a named IoT-platform scale case. These are scope and delivery parameters, not promised fleet results. The first release should prove provisioning, telemetry, recovery, operator use, and support ownership on representative devices before expansion.

Build a custom IoT platform when device lifecycle and fleet operations are part of the product.

Start with a stable firmware contract, representative hardware, and one product workflow.

A fit
01

The managed service does not support required lifecycle, tenancy, API, or operating rules.

02

The device interface and one representative fleet can be tested during discovery.

03

The organisation can own support, credential operations, and platform policy after launch.

Not a fit
01

A vendor console already covers onboarding, monitoring, alerts, and user access.

02

Firmware and payloads are changing without a versioned contract.

03

The immediate need is one dashboard with no reusable fleet or tenant requirement.

Managed IoT service vs custom platform

Managed serviceCustom platform
Best fitStandard registry, broker, rules, and consoleSpecific lifecycle, tenancy, workflow, and API model
OperationsVendor conventions and supported pathsProduct-specific fleet roles, state, and recovery
ResponsibilityLess infrastructure ownershipMore control with explicit support ownership
First decisionCan configuration meet the product need?Which capability truly requires custom software?

Scope

What belongs in a focused IoT platform release

  • 01

    Device identity and registry

    Represent device type, ownership, firmware, credentials, status, and lifecycle without shared identities.
  • 02

    Telemetry and state

    Validate versioned payloads, process retries and duplicates, preserve time, and expose current and historical state.
  • 03

    Fleet operations

    Support onboarding, health, search, diagnostics, revocation, and controlled changes for a bounded fleet.
  • 04

    Tenant and role boundaries

    Separate customer, site, or business-unit access across broker, data, API, and application layers.
  • 05

    API and application path

    Expose stable platform capabilities to one product interface or downstream integration with monitoring and audit.

How it works

From device contract to operating platform

  1. Phase 1
    01

    Define the platform contract

    Map device types, identities, tenants, telemetry, state, commands, retention, users, and the first product workflow.

  2. Phase 2
    02

    Prove connectivity and security

    Test representative firmware, authentication, payload versions, offline behavior, revocation, and staged update paths.

  3. Phase 3
    03

    Build the shared services

    Implement registry, ingestion, state, permissions, fleet operations, APIs, monitoring, and one application interface.

  4. Phase 4
    04

    Pilot and establish operations

    Onboard a controlled fleet, rehearse failures and rollback, document support, and add device types only after proof.

Risk

What the platform specification must settle

Device contract
Version payloads, identity, time, commands, error states, and compatibility before shared services are fixed.
Authority and isolation
Define who can observe, configure, command, revoke, and export data across each tenant and role.
Failure and recovery
Specify offline state, buffering, reconnect load, duplicate handling, staged updates, and rollback.
Support ownership
Assign monitoring, credential operations, incident response, data retention, and device-lifecycle policy.

Scope and price

A focused IoT platform release starts at $30,000.

Begin with one device type, core lifecycle and telemetry, basic fleet operations, and one product workflow.

The first phase proves reusable platform behavior before the fleet or tenant model expands.

Starting investment

Starts at $30,000

A focused first release usually takes 10 to 16 weeks. Multi-tenancy, OTA operations, more device types, or regulated evidence extend the plan.

Device contract first

Shared services are built against representative firmware and a versioned interface, not a slide-deck assumption.

Operations included

Monitoring, recovery, credential ownership, and support responsibilities are part of the release definition.

Common questions

A focused platform includes device identity and provisioning, authenticated connectivity, telemetry validation, current and historical state, fleet health, alerts, API access, and one application workflow. Commands, OTA updates, billing, tenant self-service, and more device types are added only when the product needs them.

Use a managed service when its device registry, broker, rules, security model, and operating console fit the product with limited adaptation. Build a custom layer when lifecycle rules, tenant isolation, fleet operations, data model, or integrations are part of the product's differentiation.

We scope per-device identity, credential issuance and revocation, encrypted transport, broker permissions, API authorization, audit, and tenant isolation. The exact controls follow the device capability, threat model, customer commitments, and regulatory requirements rather than a generic checklist.

Yes. Filtering, aggregation, rules, buffering, or local workflows can run on an approved gateway when latency, bandwidth, privacy, or connectivity requires it. The design specifies which state is authoritative, how updates are deployed, and how edge and cloud recover after separation.

A focused release starts at $30,000 and usually takes 10 to 16 weeks. It covers one device type, core identity and telemetry, basic fleet operations, one user workflow, and an API or integration path. Multi-tenancy, OTA operations, more device types, or regulated evidence increase scope.

Work with us

Bring the device lifecycle your managed platform cannot express.

Share the device types, firmware interface, fleet size, tenants, data volume, operators, and product workflow. We will identify the smallest reusable platform release.

  • Scope and cost agreed before work starts. No surprises. No obligation.
  • Working prototype within 3 weeks of kickoff.
  • Pay by milestone. You see progress before each invoice.
  • 60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
  • All conversations are NDA-protected.