What is hardware and IoT development?
IoT development means building a connected device, the code inside it and the cloud service behind it as one system. A good device does a narrow job reliably, survives a messy workplace and can be updated without a visit.
Restrologic builds this for operations where a number must be measured and recorded: a scoop of ice cream, a parcel, a bin, a station. We work from the board to the dashboard.
What we build
A hardware project has four layers, and we cover each.
- Electronics. A custom ESP32 carrier board, designed in KiCad, with design-rule checks passed before anything is ordered.
- Enclosure. Parametric 3D-printed housings sized to the board and the job, with checks that spills cannot reach the electronics.
- Firmware. Code that reads sensors, shows state to the operator and keeps working when the network does not.
- Cloud. Services that receive results, manage devices and feed the POS or dashboards you already use.
What proof do you have?
ScoopScale is a weighing station we built for Natural Ice Cream, a chain with about 251 outlets on our POS. It is a unit in daily use at an outlet, and a pilot rollout is planned. It is not a fleet, and we do not claim one.
At the station, the operator does this.
- Scans the order QR code.
- Tares the cup.
- Scoops, and the display checks each scoop against its target weight.
- Scans pack barcodes, which the station checks against the order.
- Finishes, and the result uploads to the cloud.
If the internet drops, the station queues the results and sends them later. See the Natural Ice Cream case study for the wider platform.
The next-generation design is ready and not yet manufactured.
| Item | Status |
|---|---|
| Weighing station in daily use | One unit at an outlet |
| Custom ESP32 carrier board | Designed in KiCad, design-rule checks passed |
| Factory files | Ready for JLCPCB |
| 3D-printed enclosures | Parametric, with spill-proofing checks |
| Firmware updates | Signed, over-the-air, with automatic rollback |
| Transport | Encrypted MQTT |
| Pilot rollout | Planned |
We wrote a longer account in from prototype to outlet.
How does a connected device work end to end?
A device is only useful when its data reaches a person who can act on it. The path is short.
- A sensor produces a reading, such as weight.
- The firmware checks it against a rule, such as a target weight, and shows the operator a result.
- The result is sent over encrypted MQTT, or queued if the device is offline.
- The cloud stores it and links it to an order, an outlet and a time.
- A dashboard or the POS shows the outcome.
The diagram on this page shows the same route: device, cloud, POS.
How do updates and security work?
Devices in the field need updates, and a bad update can ruin a working unit. Our design signs every firmware image, so a device only installs code we released. After an update, the device checks that it starts correctly, and if it does not, it returns to the last good version without anyone travelling to the site. Traffic uses encrypted MQTT.
What goes wrong in hardware projects?
Hardware fails in different ways from software, and most failures are avoidable with early testing. These are the risks we plan for.
- Real use differs from the bench. People tilt the device, spill on it and press buttons in the wrong order. That is why the first unit goes to a working outlet before the design is finalised.
- Connectivity drops. Offline queuing is built in from the first firmware, not added after a complaint.
- Updates cannot be done by hand. A device installed in a store has to update itself, safely, or it stays out of date.
- Factory files have errors. Design-rule checks and a review of the files happen before an order, because a wrong board costs weeks.
- Operators skip steps. If the device is slower than the manual way, it will be bypassed, so we time the whole task and keep it short.
Who is this for?
- Food and retail chains that need to measure portions, weights or temperatures at the point of work.
- Operators with a manual check that is skipped on busy days.
- Product teams that have a prototype on a breadboard and need it to become a product.
- Companies that need hardware tied to an existing POS, ERP or dashboard.
It is a poor fit if you need millions of units from day one. We plan pilots first, then volumes.
How does an engagement run?
- Problem framing. We watch the real task, or ask for video of it, and write down what the device must measure and how an operator will use it.
- Prototype. We build a working unit with real sensors and a simple enclosure, so operators can try it.
- Pilot in the field. We install a unit at a real outlet, collect data and fix what the people using it find.
- Design for manufacture. We finish the board, enclosure and factory files, and plan the update system.
- Rollout support. We help with a pilot rollout and the cloud service that watches the devices.
Next step
If you have a manual check that you wish a machine did, describe it to us. Contact Deepak and we will set up an online call to talk through the task and the first prototype. We can also connect the device to custom software that you already run.