Aionic is a product engineering studio for connected hardware. We write the firmware that talks to your devices, the Node.js services that ingest and make sense of the data, and the React console your operators live in all day.
Most IoT projects stall in the seams between hardware, cloud and interface. We staff all three from day one, so nobody is waiting on a vendor to answer a question about a byte order.
Sensor drivers, power budgets, local buffering and store-and-forward for sites with bad connectivity. Signed over-the-air updates from the first prototype, not bolted on later.
An MQTT front door, a device registry, a rules engine and clean HTTP and WebSocket APIs. Written in TypeScript, sized to your message rate, and load tested with a simulated fleet before real hardware arrives.
The screen your team actually uses: live fleet map, per-device history, alarm rules, firmware rollouts and role-based access. Built for a shift supervisor on a ten-year-old browser, not for a demo.
Bluetooth provisioning flows an installer can finish in ninety seconds on a cold rooftop, plus the customer-facing app that comes after. One React Native codebase for both stores.
Infrastructure as code, one-command environments, and dashboards that page a human before a customer notices. We hand you the keys and the runbook, or keep running it for you.
Once the telemetry is clean, it becomes useful: anomaly detection on vibration, failure prediction from duty cycles, and small models that run on the gateway when the link drops.
Each one has its own failure modes, its own questions in week one, and its own reasons to build rather than buy.
Sampling, power and radio decisions you cannot revise from a laptop.
Local rules and a backlog for the days the uplink is down.
Accept fast, prove who sent it, never lose one under a spike.
Registry, rules, alerting and the APIs your other systems call.
The screen someone uses for eight hours under time pressure.
Client names are withheld where the contract requires it. We are happy to walk through architecture and code on a call.
Vaccine shipments were being written off because temperature breaches were only discovered on arrival. Paper loggers gave no way to intervene while a truck was still moving.
We built a battery-powered logger with a two-year life, a LoRa gateway per depot, and a Node.js ingest tier that scores every reading against the product's stability profile. Dispatchers see a breach forming in the React console and reroute before the load is lost.
The retailer inherited three meter vendors with three protocols, and a billing team reconciling exports by hand every month.
We normalised all three into one message schema at the edge, then rebuilt the ingest path in Node.js to absorb the 15-minute reporting spike without dropping a reading. Billing now pulls from a single API, and field engineers use the same console to commission new meters.
Spindle failures stopped lines without warning, and the maintenance window was booked around a calendar rather than the state of the machine.
Retrofit vibration and current sensors feed a gateway that runs a small anomaly model locally, so a machine can flag itself even when the plant network is down. Planners get a ranked worklist each morning instead of an alarm at 2am.
Connected products fail in ways a lab never shows you, so we get real hardware onto a real site early and let it argue with our assumptions.
We map the physical process first: what is being measured, how often, over what link, and who acts on it. You leave with an architecture sketch, a risk list and a fixed price for the next phase.
One device, one gateway, one screen, end to end. Ugly on purpose. It exists to prove the radio link, the power budget and the data model before anyone designs an enclosure.
Twenty to fifty units on a real site. We watch the failures that only appear in the field — thermal drift, dead zones, someone unplugging the gateway — and fix them while the fleet is small.
Manufacturing test jigs, provisioning at the factory, staged OTA rollouts, and load testing against a simulated fleet ten times your launch size.
We either operate the platform on an SLA, or spend a month pairing with your engineers until they are shipping without us. Documentation and runbooks come either way.
Written by the engineers who were there, mostly about the decisions that turned out to matter more than expected.
The single question that changes an IoT architecture more than any other, and why the answer is almost never the number you are first given.
Over-the-air update is treated as a launch feature and built last. That ordering is how fleets end up stranded on firmware nobody dares replace.
Most operator consoles are built for the demo rather than the shift. The gap between those two audiences explains almost every abandoned dashboard.
An engineer reads every message and replies within one working day. The first call is a conversation about your problem, not a sales script.
