Building one working IoT prototype is the easy part. The hard part is the 500th unit, running unattended in a market or on a station platform, on Indian mains power and a patchy mobile network, with nobody nearby to reset it. This is how we take a product from idea to a fleet in the field, drawn from the more than 500 IoT vending machines we have deployed for the West Bengal, Sikkim and Central Pollution Control Boards. Every one of them runs on a board we designed, and the first has been running at the same site, on the same board, for three years.
The stages of an IoT product
- Requirements and architecture: what the device must do, where it will live, how it connects and who will look after it.
- Circuit board design: the schematic, component choice and layout, built for the power and weather it will actually meet.
- Firmware: the code on the device, written for the network you will really have.
- Connectivity, cloud and dashboard: how the device reports, and the screens the people running it will use.
- Enclosure: the housing that keeps out water, dust, heat and curious hands.
- Production, deployment and support: building units in quantity, installing them, and keeping the fleet healthy with remote updates.
A good development partner can take all of these as one project or step in for a single stage, such as only the board or only the firmware.
Design the board for Indian power
Textbook mains is 230 V. In the field we have measured 178 V to 268 V on one line within a single hour, and consumer-grade power supplies die within months. Our boards use wide-input power supplies rated 90–305 V, at least 4 kV of surge protection, and a raised brownout threshold so the microcontroller resets cleanly instead of misbehaving when the voltage sags. If the hardware does not survive the power, nothing else matters.
We design boards of up to six layers and more in KiCad, Altium Designer, EasyEDA or Fusion 360. Five of our designs are in production today: ESP32-based controllers, Quectel 4G LTE communication modules, motor drivers with battery management, and custom display drivers. Where a standard module is the right choice, such as a cellular modem, we design the board around it.
Write firmware that expects the network to fail
Our deployment data shows 8–12 short connectivity drops a day on GSM in tier-2 cities. They are not full outages, just gaps long enough to fail a transaction if the firmware assumes a clean network. So every transaction is queued on the device, retried with backoff and reconciled with the server when the link returns.
Payments make this harder. Many of our sites fall back to 2G, while UPI expects reliable round-trips, so the payment flow needs local queuing, retries and an asynchronous reconciliation layer. We worked through three payment gateway partners before finding one whose timeout settings matched field reality.
Plan for over-the-air updates from day one. When a fix can reach the whole fleet without a site visit, a bug costs an afternoon instead of a tour of every installation.
Choose the radio for the site, not the spec sheet
- Wi-Fi where there is reliable infrastructure, such as offices and malls.
- GSM or 4G LTE where there is not; most of our public deployments run on cellular with a 2G fallback.
- BLE for links to phones and wearables.
- LoRa for long-range, low-power links.
Devices report to the cloud over MQTT, and the dashboard on top shows live machine health, stock, fault alerts and usage by location. That is what lets an operator run hundreds of units without visiting them.
Build the enclosure for humidity and tampering
We over-engineered our early units for 50°C heat. What actually killed them was humidity creeping through tiny seal gaps. Outdoor units now ship in IP65 housings, with conformal coating on every board and desiccant cartridges that the field team replaces during routine maintenance.
Hardware in public places also gets tampered with, usually within the first 60 to 90 days. Our cabinets carry tamper-evident screws, an accelerometer for shock detection and an SMS alert when a door is opened off-schedule.
From prototype to production
A board prototype typically takes three to four weeks. Bare boards come from our fabrication partner; assembly, reflow, bring-up and testing happen in our workshop at Boral, Kolkata. The engineers who designed a board write its firmware and are the ones who debug it if it ever fails in the field. Production runs carry a minimum order quantity, which we confirm in the quote together with the build and test plan.
Before committing to a full production run, deploy a small number of units at real sites and watch the dashboard. Field data on power, connectivity and usage will change the design more than any bench test.
What we have shipped
- IoT cloth bag, compostable bag and sanitary pad vending machines: 500+ units for three Pollution Control Boards and government schools
- Solar-powered IoT compactor bins with fill-level telemetry, including units in Gujarat supplied through resellers
- Smart e-waste bins with GSM fill-level alerts
- Health-monitoring wearables and patient-monitoring kiosks
Questions to ask an IoT development partner
- Have they run their own hardware in the field, and for how long?
- How do their boards handle voltage swings, surges and brownouts?
- What happens to a transaction when the network drops?
- Can they update the whole fleet over the air?
- Who builds the dashboard, and who supports the fleet after installation?
- Can they take on one stage, or the whole product?
Our IoT and embedded systems work →
PCB design and assembly in Kolkata →
Case study: 500+ IoT vending machines for three Pollution Control Boards →