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.
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.
Does a managed IoT service connect devices but leave provisioning and operations fragmented?
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.
The managed service does not support required lifecycle, tenancy, API, or operating rules.
The device interface and one representative fleet can be tested during discovery.
The organisation can own support, credential operations, and platform policy after launch.
A vendor console already covers onboarding, monitoring, alerts, and user access.
Firmware and payloads are changing without a versioned contract.
The immediate need is one dashboard with no reusable fleet or tenant requirement.
Managed IoT service vs custom platform
| Managed service | Custom platform | |
|---|---|---|
| Best fit | Standard registry, broker, rules, and console | Specific lifecycle, tenancy, workflow, and API model |
| Operations | Vendor conventions and supported paths | Product-specific fleet roles, state, and recovery |
| Responsibility | Less infrastructure ownership | More control with explicit support ownership |
| First decision | Can 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
- Phase 101
Define the platform contract
Map device types, identities, tenants, telemetry, state, commands, retention, users, and the first product workflow.
- Phase 202
Prove connectivity and security
Test representative firmware, authentication, payload versions, offline behavior, revocation, and staged update paths.
- Phase 303
Build the shared services
Implement registry, ingestion, state, permissions, fleet operations, APIs, monitoring, and one application interface.
- Phase 404
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
Operations included
Related IoT services
- 01
IoT Development
The broader device-to-decision application and integration capability.
- 02
Asset Tracking Software
Location, custody, and movement exceptions across a physical fleet.
- 03
Industrial IoT
Plant equipment data in safe monitoring and maintenance workflows.
- 04
Smart Building Software
Installed building systems in facilities and tenant workflows.
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.
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.