Remote irrigation monitoring and control platform with position-based scheduling
A cross-platform mobile app giving growers live map-based visibility of every irrigation machine on their property, push alerts the moment something changes, and remote control including commands scheduled against a machine's position on its arc rather than the clock.
Irrigation machines are large, slow and unattended, often doing their most important work overnight and far from the farm office. Knowing whether a machine was running, where it was on its circle, or whether it had stalled traditionally meant driving out to look, and changing what it was doing meant driving out again — while an unwatered wedge of crop kept losing water the whole time nobody noticed. Growers also don't think in terms of clock time; they think in terms of position on the field, so scheduling commands against a timestamp was consistently the wrong abstraction for a machine travelling at variable speed around an arc.
Modelled command scheduling around the machine's angular position rather than the clock: an operator nominates a position and an action, optionally repeating every revolution, and the platform holds the instruction until the machine arrives, with an arrival projection so the operator can see when a queued command is expected to fire. Rather than encoding control permissions in the app, the service supplies a per-site capability set and lock state, and the client renders controls only where it's been granted — so what an operator may do can change per machine or per property with no app release.
The estate summary loads as a stream rather than a single response, batched and rendered after the first group of machines arrives, so an operator opening the app because something stalled sees data within moments instead of waiting for the whole property. Three different transports are used deliberately — a streamed initial load, a live subscription while the app is open, and conventional request/response for everything else — because a single transport would have been wrong for at least two of those jobs.
Every command requires explicit confirmation and returns explicit acknowledgement, with an interlock that surfaces a conflict rather than acting on an instruction that doesn't match the machine's current state. Because the authoritative state of a machine lives in its own field controller and not in the app, locally edited sector programmes are tracked as unsent until they've actually reached the equipment, with the apply control visibly flagged until then. Alerts use separate day and night sounds per notification type on dedicated channels, so an operator woken at 3am can identify the alert by ear before picking up the phone.
Equipment status is now continuously visible from anywhere, replacing physical inspection rounds as the primary way of knowing what machines are doing, and the gap between a fault occurring and someone finding out has collapsed. Control no longer requires attendance — speed, direction, stopping and end gun changes are issued from a phone — and instructions can be expressed the way growers actually think about them, against a position on the arc rather than a time on a clock. The product also survived a full platform migration from a managed cross-platform toolchain to a native workflow, carrying years of accumulated domain logic forward onto a current, maintainable foundation.
Something holding you back?
New build, rebuild, or adding AI to what you already have — I'll take a look and give you an honest perspective.