Engineering problem
Build and validate the connected product while the physical controller and sensor integration were still evolving.
Habion
- Focus
- Product Engineering / IoT
- Year
- 2026
- Stack
- Next.js · TypeScript · Go · PostgreSQL · RTK Query · IoT Simulation
My role
Product / Full-stack Engineer. I worked across the Next.js frontend, Go backend foundation, telemetry model, simulator and device-facing interaction flows.
Architecture
Simulator / controller → Go services → PostgreSQL → API state → Next.js + RTK Query → dashboard, alerts and commands
Outcome
A working MVP whose frontend and backend could be exercised against realistic telemetry and failure scenarios without waiting for final hardware.
Habion is an early-stage connected irrigation product spanning a web dashboard, telemetry and command APIs, persistent measurements, alerts and a compact local controller interface. The key engineering problem was sequencing: the product software had to become testable before the final hardware integration was complete.
Developing against a simulated device
The dashboard needs more than nominal sensor values. Irrigation software has to represent pressure and flow, active zones, commands, alerts, connection state and failure conditions such as abnormal readings or possible leaks. Those states formed the contract between device-side behaviour, backend logic and the web application.
I built an ESP32-style telemetry simulator that produced realistic measurements and failure scenarios. This made it possible to develop and test UI states, alerts, historical data and command workflows before the final controller integration was available.
Backend and telemetry model
The supporting backend was structured around telemetry ingestion, historical measurements, alerts and command flows, with Go handling the service layer and PostgreSQL providing persistent state. The web client consumes this model rather than coupling itself to the details of a specific sensor or controller implementation.
This separation lets the system evolve on both sides: hardware integrations can change while the product keeps a stable representation of zones, measurements, connection state, tests and commands. It also makes simulated and physical devices usable through the same product flows.
Local interface built from the same system states
The controller needs to remain useful without opening the web dashboard, so the compact OLED interface exposes the same essential zone, telemetry and status concepts through a much smaller interaction surface.
The enclosure image is still a product-direction mockup; the local interface itself was implemented and tested on a microcontroller.
One system across web and device
The Next.js/React frontend uses reusable status, chart, zone and alert components backed by RTK Query. The same domain model drives quick remote monitoring in the web dashboard and the smaller set of states required by the local controller interface.
The project demonstrates a workflow I find especially useful in hardware-adjacent products: define the domain and interfaces early, simulate the missing physical layer, and let frontend, backend and device integration progress in parallel instead of serially.