Building an IoT Integrated Farm Management Platform for a MENA AgriTech Operator

Industry

Geography

MENA, Gulf and East Africa

Cooperation Period

Discovery to full rollout

About the Client

The client is a MENA headquartered AgriTech operator running controlled environment growing systems across the Gulf and East Africa. The operator combines hydroponic growing deployments with an operational software platform that unifies operator level administration, farm owner administration, farm manager execution, and season planning inside one product.

The operator reports that its hydroponic growing systems use 90% less water than conventional farming, and its public listing states 13 enterprise deployments across 6 countries. The operator’s public listing of enterprise clients includes Marathon Digital Holdings (NASDAQ: MARA), Regency Group, Khalid Juffali Holding, USAID, and Sharjah Asset Management.

The platform’s user hierarchy separates operator level administration from farm owner administration. Operator administrators manage the platform itself and the onboarding workflow for each deployment brought onto it. Each farm owner, a product role belonging to an enterprise client, manages their own farms, managers, assets, and operational visibility. Farm managers under each owner run daily operations at each farm, and field operators under each manager execute assigned tasks and record field activity.

Speed from a new deployment coming online to a running operational surface, and speed from a sensor reading to a task on a manager’s list, are primary economic drivers in this business. Every day a deployment sits without decision grade data carries a cost against the growing cycle and delays return on the underlying investment. Operational tooling sits on that critical path.

The operator’s team was rooted in agronomy and controlled environment operations, with a lean engineering setup. They engaged Clixlogix to take a defined product ambition through architecture, sprint delivery, and IoT integration while keeping the build phased to a manageable investment cadence across an evolving deployment footprint.

Regional Context

Water efficiency reads as an environmental credential in most markets. In MENA it is an operating constraint. The World Bank’s Economics of Water Scarcity in MENA, published 27 April 2023, finds that by the end of this decade the water available per capita annually will fall below the absolute scarcity threshold of 500 cubic metres per person per year. In that setting a growing system that uses materially less water stops being a sustainability line in a brochure and becomes the thing that makes the next deployment approvable. World Bank, April 2023.

Fig 1 – Before and After Transformation Matrix

Challenge

A fragmented operational stack had become a hard ceiling on how fast the operator could roll out new sites and how consistently existing sites could report against their growing plans. Several operational pressures made a unified platform initiative urgent.

Operator oversight scaled linearly with deployment count. Each new deployment added another set of spreadsheets, phone updates from the farm owner side, and month end reconciliations. As deployment count grew, the reconciliation load increased without a comparable gain in operational visibility.

Sensor telemetry was locked in vendor cloud portals. Milesight devices measured environmental conditions inside the growing systems where they were installed, but their readings lived inside the vendor’s cloud portal. Operators, farm owners, and managers each left the operational context, signed into a separate vendor portal, and correlated readings against activities by hand.

Multitenant access needed strict boundaries. Farm owners across multiple enterprise deployments needed access scoped strictly to their own farms, managers, assets, and growing cycles. A permissive model would have leaked data across enterprise tenants. A rigid model would have blocked legitimate manager workflows during common events like manager reassignment or handover.

Full scope build did not fit a single fixed cost cycle. The original ambition spanned 6 modules covering farm management, farm performance, sensor management, inventory management, incident management, and a planning tool. Estimated in one delivery cycle, the scope came back at a cost and timeline that were impractical for the operator’s phased investment approach, and would have delayed the platform past the point where it could earn its way into the deployments.

The initiative was scoped to build the operator and farm owner core platform first, integrate sensor telemetry through a controlled ingestion path, defer noncritical modules, and add them back in as monthly build cycles progressed.

Sequencing

Scope that does not fit one budget cycle is normally treated as a budgeting problem. It is usually a sequencing problem. Six modules priced together came back at a cost and a timeline that would have delayed the platform past the point where it could earn its way into the deployments it was built to serve. Shipping the role model, ingestion, planning and tasks first put a working operational surface in front of real users while inventory and incident management were still unbuilt, and the per module collection structure let those later modules compose in without reopening the schema of anything already live. The first release has to earn the second.

Engagement Model

Multicycle monthly SOW delivery from discovery through full rollout. Clixlogix owned the scope end to end and ran the daily design and delivery work, sharing closed decisions and milestone outcomes with the client at each planning and demo checkpoint. A fixed cost Planning Phase produced the architecture and Phase 1 backlog. Each subsequent build cycle ran on its own monthly SOW, and each cycle closed with internal validation followed by a client demo and workflow acceptance review. The senior delivery manager carried the client relationship, change control, and technical continuity across the full engagement. All 6 modules in the original ambition (farm management, farm performance, sensor management, inventory management, incident management, planning tool) were delivered by the end of the rollout.

Architecture Decisions

The Planning Phase produced the architecture and data model, the Phase 1 backlog, and the module sequencing plan. Clixlogix’s technology lead and solution architect ran the daily design work, and closed decisions and milestone outcomes were shared with the client at each planning checkpoint. Alternatives were considered on their merits and closed with documented rationale before Phase 1 code shipped.

Key decisions closed:

Decision	Options considered	What shipped
Data model structure	Farm first hierarchy versus owner rooted hierarchy	The operator at the root, farm owners beneath, and farms, managers, growing cycles, sensors, and tasks under each farm owner. A farm first model was simpler for single farm operations and weaker for owners running several.
Sensor ingestion pattern	Push and webhook ingestion versus scheduled pull based ingestion	Pull based ingestion, for control over cadence, retry behavior, cost, and farm specific polling rules. Push offered faster updates and leaned harder on vendor availability and webhook reliability.
Module rollout strategy	Full 6 module first release versus core platform first	The role driven operational core, sensor ingestion, planning, and task workflows first, with inventory and incident management in later cycles. Launching all 6 together carried too much cost and delivery risk for the first cycle.
Event architecture	Shared operational event log versus per module collections	Per module collections, keeping each module's write path independent and easier to evolve without cross module coupling. A shared log was considered for its cross module reporting simplicity.
Storage strategy	`PostgreSQL` with a dedicated time series database versus `MongoDB`	`MongoDB`, keeping the first release on a single database that fit the flexible sensor and event schema across modules. A relational plus time series pairing suits high telemetry volume and adds operational overhead early.
Task creation model	Manual task creation by managers versus plan generated and sensor triggered tasks	Tasks originate from growing cycle plans or monitoring rules, keeping daily execution tied to agronomy logic. Manual creation was flexible and risked recreating the fragmented to do behavior the platform was built to replace.
Access control model	Basic `RBAC` versus role plus ownership boundary checks	Role and object ownership checked together on every relevant request. `RBAC` alone names the caller as operator, farm owner, manager, or field operator, which leaves cross owner and cross farm data leakage open across 13 enterprise deployments.
Farm go live logic	Immediate live status on farm creation versus separate intake and live release gates	Farm creation separated from farm live publishing, so incomplete setup data stays off owner dashboards and generates no manager tasks until the farm has valid users, sensors, plans, and asset mappings.

Solution

Clixlogix delivered an IoT integrated farm management platform that carries a deployment from onboarding through daily operational execution, farm owner oversight, and operator wide visibility across the deployments in its footprint. The build was structured across functional subsystems, each with a distinct engineering discipline and a bounded interface to the subsystems around it. That separation kept the role model isolated from sensor integration work, let the storage and orchestration subsystems scale independently of the operational surface, and let each new module compose into the existing platform without a rebuild.

The subsystems move a deployment and its telemetry through role scoped onboarding and setup, pull based sensor ingestion and RFID capture, resilient orchestration and storage, and a planning driven task surface visible to the farm manager and the farm owner in near real time. Each subsystem is described below, followed by the two mechanisms that cut across all of them, farm live publishing and task generation from plans.

Fig 2 – System Architecture

Role Hierarchy Core

The platform rests on a four role hierarchy for administration and daily operations. Operator administrators sit at the top with rights to onboard new farm owners, configure global settings, and view every deployment across every tenant. Farm owners, a product role belonging to an enterprise client, sit under the operator with rights to create farms, appoint farm managers, and view performance across every farm they own. Farm managers sit under a farm owner, run daily operations, and supervise execution on their assigned farms. Field operators sit under a farm manager and complete assigned tasks, scan tagged assets, and record field activity. A farm manager cannot see or act on data belonging to another owner. A farm owner cannot see or act on data belonging to another farm owner. The operator administrator can see across owners in an administrative capacity but does not receive automatic write access to their operational data.

JWT sessions carry the caller’s identity and role. NestJS middleware evaluates every request against the caller’s role and the ownership boundary of the object being accessed, rejecting any traversal that would cross an owner tenancy line. The middleware is the single choke point for the multitenant access rule, so authorization logic did not scatter into each module.

Tenancy Risk

An operator platform carrying 13 enterprise customers is not one system with 13 logins. It is 13 blast radii sharing a database. IBM’s 2024 Cost of a Data Breach Report, published 30 July 2024, puts the global average breach at 4.88 million dollars, and finds that the 40 percent of breaches involving data spread across multiple environments cost more than 5 million and took the longest to identify and contain, at 283 days. Role alone does not stop a farm manager reading another owner’s yield data. Checking role and object ownership together on every request, at one choke point that every module inherits, is what keeps a tenancy line from becoming an incident. IBM, July 2024.

Fig 3 – Four Role Hierarchy

Farm Onboarding and Live Release

Farm setup runs as a two stage workflow inside the platform. The first stage is the onboarding record, where the farm owner side captures the farm’s identity, geographic location, growing cycle plan, assigned managers, sensor inventory, and RFID tagged asset registry. The farm exists in the system as a setup stage record during this period. It does not yet appear on owner dashboards, and it does not yet generate manager tasks.

The second stage is farm live publishing. A farm becomes eligible for live release only when 5 conditions hold on its onboarding record.

At least one farm manager is assigned to the farm and has accepted the invitation
Required sensor coverage is provisioned, with at least one valid reading from each required sensor type
The current growing cycle plan is saved with scheduled tasks and monitoring rules
Required RFID tagged assets are registered against the farm
Intake binding is validated, with sensor serials matching vendor inventory and no reconciliation cases left unresolved

Publishing the farm to live exposes it to the owner dashboard, activates monitoring rules against its telemetry, and populates the manager task list from the growing cycle plan.

Fig 4 – Farm Live Release Gates

The separation exists so incomplete setup data never surfaces on owner dashboards or as manager tasks before the farm is genuinely ready to operate. That mattered especially at rollout scale, where 13 enterprise deployments meant onboarding was a recurring workflow, not a one time event.

Backend, Queue, and Resilience

Clixlogix built the backend on NestJS, structured module by module to mirror the platform’s product modules (farm management, farm performance, sensor management, inventory management, incident management, planning tool). Each module owned its own routing, service code, and MongoDB collection set. That mirroring matched the per module data architecture and kept module boundaries clean in the code and in the data model.

Redis backed the platform’s asynchronous work through two separately configured deployments. The first instance served as the job queue. Scheduled ingestion jobs at per sensor cadence were dropped onto the queue and picked up by NestJS ingestion workers, along with other asynchronous work items such as follow on writes into MongoDB. The second instance served as a monitoring rule configuration cache, so ingestion workers did not need to reread rule definitions from MongoDB on every reading. Keeping the two separate let queue durability policy and cache eviction policy be tuned independently.

Fig 5 – Redis Deployment Split

The platform ran in a single AWS region with in region high availability. Multiregion hosting was outside scope. The React web application was delivered through a CDN for static assets and page delivery. Containerized NestJS APIs ran behind an AWS Application Load Balancer, while ingestion workers ran as background services inside the same region.

Storage and Data

MongoDB held the primary store that Clixlogix built. The database was organized into per module collections in place of a single shared event log. Each module (farm management, farm performance, sensor management, inventory management, incident management, planning tool) owned a set of collections covering its own entities, its own reads, and its own writes.

The per module structure meant Inventory Management and Incident Management, both introduced in later build cycles, could be added with their own collections without changing the schema of any existing module. It also kept each module’s write path independent, which reduced coupling risk across the multicycle rollout.

Environmental sensor readings, monitoring rules, and task states each sat inside the collections of the modules that owned them. Sensor Management owned environmental telemetry from the Milesight cloud. Planning owned the growing cycle plans and their generated tasks. Inventory Management owned RFID scan events and the assets they identified.

Sensor Ingestion and RFID Capture

Milesight sensors measured environmental conditions inside the growing systems where they were installed. Their readings originally lived inside the vendor’s cloud portal. The integration works on a pull model mediated by the Redis job queue. Scheduled ingestion jobs at a cadence configurable by sensor type and farm requirement are dropped onto the queue, and NestJS ingestion workers pick them up to pull the latest readings from the Milesight cloud, normalize them into the platform’s internal telemetry format, and write each reading into the Sensor Management module’s collection set.

Polling cadence is set per sensor type and per farm. Sensors with tight tolerances or high value crops poll frequently. Sensors on cycles with looser tolerances poll less often. Compute cost tracks operational value across the deployment footprint.

The same service checks each reading against monitoring rules attached to the farm’s active growing cycle plan. A reading that crosses a threshold spawns a scheduled task on the manager’s list through the task creation path described below.

Instrumentation Gap

The binding constraint in connected agriculture is rarely measurement. Sensors are inexpensive and the vendors ship capable clouds with them. The constraint is the distance between a reading and an assigned piece of work. A reading that lands in a vendor portal somebody has to log into separately gets checked when somebody remembers. The same reading, evaluated against the active growing cycle plan and written onto a named manager’s task list for that day, gets acted on. Most programmes of this kind buy the first half and assume the second, then conclude the sensors underdelivered.

Fig 6 – Sensor Ingestion Flow

Handheld RFID readers, tied to authenticated user sessions, captured asset activity through mobile workflows on the React Native app. When a farm manager or field operator scanned a tag against an activity in progress, the platform recorded the RFID identifier, the asset, the activity type, the farm and growing cycle context, and the user’s identity. Scan events were written into the Inventory Management module’s collections, alongside the assets they identified, forming the audit trail for what happened, where, and by whom.

Three design choices carried the integration.

Vendor readings stay authoritative. The platform never overwrites a raw Milesight reading. Every derived value on the dashboard traces back to a raw reading in the sensor management collections.
Cadence is configurable per sensor type and per farm. Compute cost tracks operational value.
Sensor triggered tasks and plan generated tasks share a task list. A manager sees sensor triggered actions on the same daily task list as plan generated actions from the growing cycle plan. Telemetry becomes decisions inside the product.

Task Generation from Plans

Every scheduled task the manager sees on their daily list originates from a growing cycle plan or from a monitoring rule triggered by sensor telemetry. Tasks are not entered ad hoc. This ensures the operational surface always reflects planned agronomy work plus platform detected sensor events, and never diverges into a parallel to do list on paper or in a messaging app.

A growing cycle plan defines phases and, for each phase, a set of task templates with a scheduled date range, an owner role (farm manager or field operator), the activity type, and any asset class the task binds to. At plan activation, the platform expands templates into concrete task instances scheduled against the current cycle’s calendar. The manager sees tasks appear on the React Native app on the day they come due. Task completion writes an event into the planning module’s task collection.

Sensor triggered tasks follow the same task schema. When a monitoring rule fires on an incoming reading, the ingestion service creates a task with the triggering reading attached as context. The manager sees a task on the list identical in shape to a planned task, with the sensor context visible on tap.

The single list surface is the mechanism that turns operator ambition into daily execution. It is why a manager working on a deployment in one country and a manager working on a deployment in another country see the same operational rhythm, today’s planned work plus today’s sensor triggered actions, in one place.

Fig 7 – Manager Task List Surface

Where Field Conditions Strained the Platform and How We Fixed It

Live operation surfaced conditions that no amount of design review finds, because they come from vendor clouds lagging, tags misreading, and cellular dropping out in remote regions. Each was closed inside the shipped platform during the build cycles, and each fix is listed against the condition that prompted it.

Fig 8 – Field Condition and Remediation Matrix

Field condition	Remediation
Sensor sync delay from vendor cloud	The `Milesight` cloud occasionally lagged updates by several minutes. The ingestion service backfills readings on the next pull cycle and preserves the actual reading timestamp in place of the pull timestamp, so monitoring rules and task creation evaluate each reading against its real occurrence.
Duplicate readings	Arrivals sharing a sensor identifier, timestamp, and value are deduplicated at the ingestion service before the write, avoiding double writes and repeated monitoring rule evaluations.
Mismatched sensor to farm assignment	Onboarding gained a verification step matching sensor serials against the farm's declared inventory before live release, plus a reassignment flow that reattaches readings to the correct farm and preserves the full reading history when a mismatch surfaces after go live.
`RFID` misreads or duplicate scans	Reconciled inside the Inventory Management module. A misread triggers a retry in the field workflow, with a manual visual confirmation prompt if the retry fails. Duplicate scans against one activity inside a short window fold into a single event.
Role access edge cases after manager reassignment	Manager reassignment initially left ambiguous access to in flight tasks. The role and ownership middleware now recognises a role transition event. Outstanding tasks reassign to the new manager, prior farm history stays under the outgoing manager for audit, and the outgoing manager's access closes on the transition timestamp.
Offline or poor connectivity during field use	Deployments in remote regions run on intermittent cellular. The `React Native` app holds an offline queue for task completions and `RFID` scans, then resyncs on reconnect. Timestamps preserve the completion time recorded in the field.
Task duplication from repeated threshold events	A sensor holding an above threshold reading could originally generate a task on every reading. Monitoring rule evaluation consolidates an ongoing threshold condition into a single active task per rule per farm, updating that task's context as readings continue.

Each was closed inside the service or workflow that owned the condition, which kept every fix local to one module at a time and left the data model untouched.

Results

The results below are the verified business outcomes the operator publishes on its own site.

13 Enterprise Deployments

The operator's public listing states 13 enterprise deployments. The platform supplies the operational template applied when each new deployment comes online.

6 Countries

Those deployments run across 6 countries on the same role hierarchy, the same growing cycle planning surface, and the same sensor ingestion path.

90% Less Water

The operator reports that its hydroponic growing systems use 90% less water than conventional farming.

5 Trust Anchors

The operator's public listing of enterprise clients includes Marathon Digital Holdings, Regency Group, Khalid Juffali Holding, USAID, and Sharjah Asset Management.

What the Client Does Differently Now

The operator runs new deployments onto a repeatable operational template. New farm owner onboarding, sensor provisioning, and growing cycle plan setup all follow the same two stage flow, and a deployment goes live on the platform only once its onboarding gates are satisfied.

Farm owners open per owner dashboards to see every farm they run in a single view. Farm managers work off task lists on the React Native app, generated from growing cycle plans and sensor telemetry, with sensor triggered and plan generated actions on the same list.

Inventory Management and Incident Management, both deferred out of the initial Phase 1 scope, run as first class modules on the same platform. They added their own collections in MongoDB without requiring changes to the schema of any existing module.

The operator continues to scale through the same platform template as they enter new markets, letting deployment count grow without a linear growth in oversight cost.

Technologies and Tools

Every row names the technologies Clixlogix built with or integrated to, with a stated role.

Subsystem	Technologies (with role)
Operational Surfaces (Web)	React web app for operator administration and per owner dashboards. Delivered through a CDN for static assets and page delivery. Built by Clixlogix.
Operational Surfaces (Mobile and Tablet)	React Native app for farm manager task lists, RFID scan workflows, and field operator use, with an offline queue for intermittent connectivity. Built by Clixlogix.
Backend Framework	NestJS, structured module by module to mirror the platform's product modules (farm management, farm performance, sensor management, inventory management, incident management, planning tool). Containerized API services ran behind an AWS Application Load Balancer, and ingestion workers ran as background services in the same region. Built by Clixlogix.
Job Queue	Redis, first of two separately configured deployments. Held scheduled ingestion jobs at per sensor cadence and other asynchronous work items for pickup by ingestion workers.
Monitoring Rule Cache	Redis, second deployment. Cached monitoring rule configuration so ingestion workers did not need to reread rule definitions from MongoDB on every reading. Tuned independently for eviction policy.
Primary Data Store	MongoDB, organized into per module collections in place of a shared event log. Each module owned its own reads and writes.
Cloud	Single AWS region with in region high availability. Multiregion hosting was outside scope.
Authentication and Authorization	JWT sessions plus NestJS role and ownership boundary middleware evaluating every request against the caller's role and the tenancy of the object being accessed.
IoT Vendor Integration	Milesight IoT cloud consumed as a pull based data source. Ingestion cadence configurable by sensor type and farm requirement.
RFID Capture	Handheld RFID readers tied to authenticated user sessions, capturing asset activity through mobile workflows on the React Native app. Scan events written into the Inventory Management module's collections.
Contract Signing	Zoho Sign for monthly SOW execution between the operator and Clixlogix.

Is This Relevant to Your Business?

The crop is specific. The mechanisms underneath it are not. This platform solved a shape of problem that recurs wherever one organisation administers many independent customers, each running physical sites full of vendor owned hardware, with staff who work away from a desk. The table below maps each mechanism to what it assumes about an operation, so you can judge the fit against the way your own operation runs.

Mechanism built here	What it assumes about your operation	Where it transfers
Role and ownership boundaries checked together	One operator administers many independent customers, each with their own sites, staff, and data, and no customer may ever see another.	Franchise and dealer networks, equipment rental fleets, facilities management contracts, and property portfolios.
Gated go live on a setup record	Bringing a new site online has prerequisites, and activating it early pollutes dashboards or generates work that should not exist yet.	Branch and clinic rollouts in healthcare, store openings in retail, and charging site commissioning in energy.
Pull based ingestion from a vendor cloud	The hardware vendor owns the cloud. You consume readings through their API and control neither their uptime nor their update cadence.	Cold chain monitoring, building management and HVAC, water and energy metering, and fleet telematics across manufacturing and mobility.
Polling cadence set per asset	Your sensor estate is large enough that a uniform polling frequency wastes money on assets nobody acts on quickly.	Any estate where API quota or compute is a real budget line, which is most deployments past a few hundred devices.
Monitoring rules that generate assigned work	A threshold crossing should become a tracked task owned by a named person, with the reading attached as context.	Preventive maintenance, field service scheduling, facilities operations, and food safety monitoring.
Handheld capture with an offline queue	The people doing the work are outdoors, in a warehouse, or on a site with unreliable connectivity, and they are scanning or tagging something.	Warehousing and logistics, utilities field crews, construction sites, and agriculture.
Per module collections with modules added later	The full scope does not fit one budget cycle, and you want a working core now with modules added across later cycles.	Any phased platform build where the first release has to earn the second.

Where it does not transfer is worth saying plainly. This architecture reads telemetry on a cadence measured in minutes and stores it in a document database alongside everything else. An operation running control loops at sub second frequency, or holding years of high frequency readings for analysis, needs a dedicated time series store and a streaming ingestion path, which the Architecture Decisions table above records as the option this project weighed and set aside. That is a different build, and a team who tells you otherwise is selling you this one twice.

Services Delivered

Digital Engineering, Emerging Technologies, IoT, Enterprise Software, Enterprise Application Dev, Mobile App, Web Development, DevOps

Team Composition

Delivery Manager, Technology Lead, Solution Architect, Backend Developer, Frontend Developer, Mobile App Developer, QA Engineer, DevOps Engineer

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

Zoho CRM and Jane integration for a multi service mental health practice

A Mental Health Practice Gains Reconciled Reporting and Ad to Session Attribution on Zoho

Digital Engineering Zoho Consulting Service Healthcare & Life Sciences Enterprise Software

Zoho One quote to cash buildout for a US custom awards manufacturer

Zoho One Cuts Quote Turnaround from 10 Days to Same Day at a US Custom Awards Manufacturer, Lifts Retainer Recovery 80%

Web Development Digital Engineering Zoho Marketing Automation Consulting Service Manufacturing Enterprise Software

View All Case Studies