An IoT Fertigation Platform Built for an Agritech Startup
A startup selling fertigation systems to farms had hardware and no software. We built the web app and AWS infrastructure — 100+ devices now report in cleanly.
- Client
- Agritech startup, Malaysia
- Services
- Custom Software Development, Web Development
- 100+ devices communicating with the platform, without errors
- Live in 3 months, from no software at all
- Web app and AWS infrastructure built from scratch
The challenge
A startup selling fertigation systems to farms had the hardware. What it didn't have was the other half of the product.
Fertigation — delivering fertiliser through the irrigation system — is precise work, and the equipment doing it sits out in the field. Hardware alone means a farm can only manage it by walking to it. For a company selling those systems, that's not a missing feature; it's a missing product. Buyers were being asked to purchase equipment with no way to see or control it.
There was nothing to build on. No platform, no infrastructure, no vendor system to migrate from. A startup, hardware, and a blank page.
What we built
The software half of their product, and the infrastructure it runs on.
- The web application — the interface their customers actually use: live state of every device in the field, and the controls to change what those devices are doing, from a browser instead of from a field.
- The MQTT device layer — a lightweight publish/subscribe protocol built for constrained hardware on unreliable connections, sending small messages frequently. Exactly the shape of agricultural telemetry, where coverage is intermittent and the traffic is constant and small.
- AWS infrastructure — the deployment, environments, and cloud foundation the platform runs on, set up from scratch alongside the application.
Why this is harder than a dashboard
The interesting problems in a system like this are never in the UI. They are what happens when a network drops mid-instruction, when a device reports state that disagrees with what the database believes, and when a command needs to be guaranteed rather than hoped for.
MQTT provides delivery semantics you can reason about. The application still has to decide what "this device is unreachable" should mean to the person looking at the screen — and for a product a company is selling, getting that wrong isn't an internal annoyance. It's a support ticket from their customer.
The results
The platform went live 3 months from a standing start, and now has 100+ devices communicating with it without communication errors.
That device count matters more than a launch date. A system talking reliably to one piece of hardware proves very little; a system talking reliably to a hundred, in the field, is the thing a startup can actually sell against.
Building a product, not just software?
Startups building hardware often underestimate the software half — and it is usually the half a customer touches. We build both the application and the cloud infrastructure underneath it, so there is one team accountable when a device stops reporting.
This is our second platform driving physical equipment over MQTT; the other controls car-park barriers on an EV charging platform. Hardware-connected systems are a real share of the custom software we build.
If you have hardware and need the software half, get a free consultation.
Want results like these?
Tell us about your project and we'll show you what's possible.
Get a free consultation