(Internet of Things)

IoT development, from the sensor to the dashboard someone actually reads

IoT development goes wrong in the field, not the lab. We build firmware, gateways, connectivity and the management plane that lets you update a fleet, spot a failing unit and defend what the telemetry says.

Talk to an engineer What we deliver
Virtual world scene
Internet of Things

(The part that bites)

A prototype on a desk proves the idea. A hundred units on customer sites prove the engineering. Batteries drain faster than the datasheet suggested, a gateway sits behind a firewall nobody documented, and a signed update stalls halfway through on the units with the weakest signal. Design for that day and the rest follows.

Which is why device management, provisioning and rollback are scoped in the first phase rather than added once the hardware is already boxed and sitting on a customer site. Retrofitting them costs several times more.

(What we deliver)

What IoT development covers

Most clients need three or four of these. Each is scoped as its own phase, and hardware lead times are planned around rather than discovered late.

  1. Embedded C and C++ on ESP32, STM32 and Nordic parts, usually under Zephyr or FreeRTOS. Power budgets, watchdogs, persistent buffers for when the network is gone, and a bootloader that can always fall back to the previous image.

  2. MQTT with Sparkplug B for structured telemetry, BLE for short-range and commissioning, LoRaWAN where range matters more than bandwidth, Modbus and OPC UA for machinery that predates all of it. Protocol choice is a cost decision, so it gets written down.

  3. Deciding what is computed on the device and what ships upstream. Filtering at the edge cuts data bills and keeps a line running through an outage; central processing is easier to change. Most fleets end up with a deliberate split, and we document where the line sits.

  4. Per-device identity issued at manufacture, signed firmware images, staged rollouts to a canary group, and a rollback that has been rehearsed. Fleets you cannot update safely become fleets you never update, which is how field security decays.

  5. Time-series storage in TimescaleDB or InfluxDB, with Grafana for engineers and a plainer web view for operations. Alert rules tuned to the thresholds your maintenance team acts on, so the pager means something.

  6. Mutual TLS with per-device certificates, secure element or trusted storage for keys, a revocation path for a compromised unit, and least-privilege topic rules so one device cannot read another one’s data. Threat modelled against the OWASP IoT guidance.

(Usual stack)

(How we work)

How the work runs

Every engagement is scoped in phases, priced per phase, and reviewed with you at the end of each one.

  1. 01

    Discovery

    We map the problem, the systems around it and what a good outcome looks like, then scope the work in phases you can stop after.

  2. 02

    Design

    Flows, architecture and interfaces agreed before anyone writes production code.

  3. 03

    Build

    Two-week increments, a working environment you can open, and a demo at the end of each one.

  4. 04

    Testing

    Functional, performance, security and accessibility checks run through the build, not bolted on at the end.

  5. 05

    Launch

    Deployment, monitoring, documentation and the handover your team needs to run it.

  6. 06

    Support

    Fixes, updates and the next set of features, at an agreed monthly capacity.

(Why Team of Keys)

Why IoT projects stall after the pilot

The gap between ten devices and ten thousand is mostly operational. These are the habits that close it.

  1. 01

    Rollback before rollout

    No update ships until the path back has been tested on real hardware, including a unit that loses power mid-flash. A bricked field device is a lorry journey, not a bug ticket.

  2. 02

    Connectivity costed early

    Payload size, reporting interval and SIM or gateway charges are modelled in the first phase. A chatty device design can cost more per year in data than the hardware did to build.

  3. 03

    Built to be debugged remotely

    Structured device logs, a health heartbeat and a safe remote diagnostic mode. Without them, every field fault becomes a site visit and a guess.

  4. 04

    Hardware realism

    Certification windows, component lead times and enclosure decisions affect the software schedule. Plans account for them instead of treating the board as a given.

  5. 05

    Identity per device, not per fleet

    A shared credential across a product line means one extracted key compromises everything. Certificates are issued per unit and can be revoked individually.

(Related)

More in emerging tech

All emerging tech services

(FAQ)

Questions, answered

Firmware for a single well-defined device typically runs as a phase of its own, with cloud ingestion and dashboards as a second. Costs rise with the number of protocols, certification requirements and the size of the fleet you must manage. Discovery gives you a phase plan and a price before hardware is committed.

Yes, and it is the usual case. We review the board, the radio and the power design, then tell you plainly what it will and will not support. If a choice will hurt later — no secure storage, no room for two firmware images — you hear it early enough to change it.

It follows the data. Wi-Fi or Ethernet where mains power and a network already exist, BLE for a phone-adjacent product, LoRaWAN for battery devices reporting small payloads over kilometres, cellular where coverage must be somebody else’s problem. We model the yearly running cost of each before deciding.

Yes, and we treat it as a requirement rather than a feature. That means signed images, staged rollouts, version reporting per unit, and a console where support staff can see which devices are on which firmware. We use Mender, balena or the native tooling in AWS IoT and Azure IoT Hub.

We design for it and prepare the documentation, then work alongside an accredited test laboratory for CE, FCC or equivalent marks. The testing itself is done by the lab, not by us. Budget and calendar time for pre-compliance runs are included in the plan so the schedule stays honest.

(Global presence)

Nine countries, one studio behind them.

Every project is designed, built and shipped from one studio.
Turn the globe, or pick a country to see what we deliver there.

NoidaDrag to turn

Studio · Noida, India · --:--

(Next step)

Tell us what the devices have to do in the field

Send the sensor list, the environment and your expected fleet size. You get a protocol recommendation, a running-cost estimate and a phase plan.

START

Or write to info@teamofkeys.com · Noida, India