Designing Reliable Plant-Level Field Workflows for El Cateo

Agricultural teams work across large physical areas where an individual plant or tree can need its own record of observations and treatments over time, and where network availability changes constantly as a worker moves between fields. El Cateo needed a platform that could follow field workers down to the level of an individual plant, without assuming the reliable connection that most business software takes for granted. iEncode Tech built a React Native mobile application with an offline-first architecture at its core, so that field capture kept working exactly where and when connectivity could not be guaranteed. What makes this case study worth reading is less the feature list than the sequencing: offline reliability had to be solved before plant-level detail could matter at all.

Within iEncode Tech's agriculture and farm management work, a farm is not a uniform environment. Signal strength varies by field, by weather, by how far a worker has walked from the nearest structure, and any tool that assumes a stable connection will simply stop being useful the moment that assumption breaks. Before this project, field observations, plant health issues, treatments applied, general inspection notes, had nowhere structured to live once a worker left an office or a well-connected area, which meant they either went unrecorded in the field or were reconstructed from memory later, at a real cost to accuracy.

Field-level agricultural record-keeping introduces constraints that a conventional web or mobile CRUD application does not face:

• Farm, zone, field, and plant records needed distinct data models rather than one flat list of locations, since a plant-level observation is meaningless without its farm and zone context
• Identifying a specific plant among many visually similar ones had to be fast and reliable in the field, not just accurate when demonstrated on a screen
• Connectivity could not be assumed, so record entry needed to work fully offline and reconcile cleanly once a connection returned, without silently losing data in the process
• Health-issue and treatment data had to be captured as observations, without the platform implying an automated diagnosis it was never built to make
• GPS and QR-based identification needed to stay fast enough for repeated use across a full working day, not just usable once in a controlled demonstration

Early technical discovery focused on one question before any interface was designed: what happens on a device with no signal, and does the answer hold up under real field conditions rather than a best-case assumption. That question ruled out any architecture that treated offline behaviour as a fallback state layered onto an otherwise online-first application. The goals that followed were correspondingly specific: field workers needed to capture an observation in the same number of steps whether or not they had a connection, farms and zones needed to behave as genuine structural entities rather than descriptive labels, and no feature could be allowed to suggest medical or diagnostic authority the platform had not been built to provide.

iEncode Tech modelled farms, zones, fields, and plants as distinct, connected entities, so a plant-level record always carries its farm and zone context rather than existing in isolation. GPS location support and QR-code scanning were combined deliberately: a worker could either browse to a location the conventional way or scan directly to a specific plant record, cutting the number of steps needed to log an observation while standing in a field with limited patience for a slow interface.

Health issues and treatment or medicine prescriptions were built as structured records attached to that plant-level context, giving teams a consistent way to log what was observed and what was applied, without the platform ever presenting those entries as an automated diagnosis. Realm's offline-first architecture let field capture continue regardless of connectivity, with a synchronisation layer that reconciled locally captured data once a device reconnected, so a field visit in a dead zone was never simply lost.

The interface was designed around a worker standing in a field, often in bright sunlight, sometimes wearing gloves, rarely in a position to read dense text or navigate a deep menu structure. Screens were kept focused on the task directly in front of the worker, log an observation, scan a plant, record a treatment, rather than surfacing the full breadth of farm-management functionality on every screen. QR scanning and GPS-based navigation exist specifically to reduce how much manual searching a worker has to do, since every extra tap in a field is a real cost in a way it is not at a desk.

Farm, zone, and plant structure

Farms, zones, fields, and individual plants are modelled as distinct but connected entities, giving field observations a structured home instead of forcing them into a flat, generic location list.

Offline data capture

A Realm-backed local data layer lets field workers record observations, health issues, and treatments with no connection at all, then synchronises automatically and reconciles cleanly once a signal returns.

GPS and QR identification

GPS-based location support and QR-code scanning give workers two fast paths to the correct plant record, either browsing by location or scanning directly to skip the search entirely.

Health and treatment records

Plant-health issues and treatment or medicine prescriptions are captured as structured, plant-linked records, deliberately presented as observations rather than automated diagnoses.

Backend and API layer

Node.js and Express.js run the backend, with GraphQL giving the mobile app precise, efficient queries for exactly the farm, zone, or plant data a screen needs, which matters over limited field connections.

• Mobile: React Native builds the field application from a single codebase, keeping GPS, QR scanning, and record entry consistent across iOS and Android devices used in the field.
• Backend: Node.js and Express.js run the API layer, a lightweight, event-driven combination suited to frequent small updates arriving from many field devices.
• Database: MongoDB stores farm, zone, field, and plant records in a flexible document model that adapts naturally to varied observation and treatment data across crop types.
• Offline layer: Realm powers offline-first data capture directly on the device, the technical foundation behind El Cateo's ability to keep working without a connection.
• APIs: GraphQL gives the mobile app precise, efficient queries, reducing unnecessary data transfer over limited field connections.
• Location and identification: GPS and location services, together with QR-code scanning, give workers fast, reliable ways to reach the correct plant record.
• Infrastructure: AWS (EC2, Lambda, S3, Route 53) hosts the backend and manages the infrastructure that reconciles offline data once devices reconnect, while Google APIs and Firebase handle authentication, analytics, and push notifications, and an SMS gateway delivers time-sensitive field alerts.

Offline-first architecture is straightforward to describe and genuinely difficult to get right, because the hard part is not capturing data offline, it is reconciling it correctly once several field devices reconnect after working independently for hours. The synchronisation layer had to handle records arriving out of order, from different devices, without corrupting the plant-level context each observation depended on. Getting that reconciliation logic right, rather than simply overwriting whichever record synced last, was the single most important engineering decision in the project.

The second real difficulty was resisting scope creep toward diagnostic functionality. Once health-issue and treatment records exist, it becomes tempting to add features that interpret them, flagging a plant as diseased, for instance. iEncode Tech deliberately kept the platform at the level of structured observation and treatment logging, since the engagement never included the agronomic or botanical verification that a diagnostic claim would require.

El Cateo centralised field information at the level where the work actually happens, connecting farm and zone structure down to individual plant records instead of leaving that detail scattered across paper notes or disconnected spreadsheets. Offline-first capture meant field teams were never blocked by a connectivity gap, and QR-based identification reduced the friction of finding the right record among many visually similar plants.

The supplied information does not establish medical, botanical, or diagnostic accuracy, so the platform is not presented as making agricultural diagnoses. It is presented as what it verifiably is: a reliable, offline-capable field-record system built around real farm conditions rather than an idealised, always-connected use case.

Offline-first design only works when it is the starting architecture, not a feature added once the online version is finished. That lesson shapes how iEncode Tech now approaches any offline-first application or field-based tool, and it pairs naturally with the location and QR-based workflows used across other operationally grounded projects such as the 2Legit Volleyball platform.

Running field operations where connectivity can't be guaranteed? Speak with iEncode Tech about an offline-first mobile platform built around your team's actual working conditions, or see the El Cateo project overview for a portfolio-style summary of what was delivered.