Project 01 / 2025 — 2026
SwiftLead.
An IoT platform, from field to cloud.
Swiftlet farmers need to understand what is happening inside their buildings and respond when conditions change. SwiftLead connects environmental sensing, actuator control, and farm operations in one system.
01 / The context
At the project site in Indramayu, humidity and temperature varied between floors. Audio was operated manually, and farmers had no integrated view of environmental readings or their history. Our student research team built a platform to connect the devices in the building with a web dashboard.
02 / My contribution
- Led technical direction and stack selection, and defined interfaces between the embedded, backend, AI, and web components.
- Built the Go + Chi backend, including REST APIs, MQTT telemetry ingestion, authentication, and role-based access for farmers, technicians, and administrators.
- Integrated PostgreSQL and TimescaleDB for relational records and environmental time-series data.
- Implemented WebSocket updates, device-control workflows, and AI service integration with fallback handling.
- Worked on container deployment, Prometheus and Grafana monitoring, and integration testing with field hardware.
03 / Engineering decisions
One backend, different workloads
Go handles HTTP requests, MQTT subscribers, and concurrent telemetry ingestion. Clear service boundaries keep the data and device-control paths understandable.
Time-series beside operational data
PostgreSQL and TimescaleDB support environmental history alongside farm, harvest, financial, and maintenance records.
Plan for the connection to fail
Cloud recommendations are part of the control path, but essential actuator behavior also has a local fallback. A lost cloud connection should not stop basic environmental control.
04 / What came out of it
The team integrated the field devices, backend, AI service, and dashboard, then tested the system in the laboratory and at RBW Swiftlead in Indramayu. My work covered the interfaces between these layers as well as the implementation of the backend itself.
The most useful architecture decisions came from field constraints: intermittent connectivity, multiple device types, and the need to trace a command all the way from the dashboard to a physical relay.