On a Saturday morning at a 50-acre coffee estate in Trans-Nzoia, payroll should take two hours. Instead it takes the whole day. Someone's attendance register is missing. A supervisor's WhatsApp voice note says Joseph was in the picking field on Tuesday, but the paper register doesn't show him. Was he there? Was he paid last week for days he didn't work? Nobody knows for certain. The cherries are in the pulping tanks, the yield numbers don't match what the field tallies said, and the casual workers are standing in a line waiting. This is where MkulimaOS started: not in a Nairobi co-working space, not from a research paper, but from a real Saturday that went wrong the same way it had gone wrong the Saturday before.
The exercise-book problem
With 200-plus casual workers across coffee, horticulture, and general estate labour, the management overhead at Mulinga Farm was staggering. Attendance lived in exercise books. Piece-rate calculations for cherry picking sat in a foreman's phone, tallied by memory and forwarded over WhatsApp. Saturday payroll meant reconciling those voice notes against the paper register, resolving disputes about who worked which days, catching double-entries, and spotting ghost workers before cash left the account.
The audit trail was essentially non-existent. When cherry-yield numbers failed to add up at the end of a picking cycle, there was no way to trace the discrepancy to a specific field, a specific day, or a specific supervisor's count. The estate was losing money in ways that were impossible to quantify, which is the most dangerous kind of loss.
Vertical SaaS that works in the field has to be designed in the field. You cannot paper-prototype your way to software that a farm supervisor will actually use at 6 a.m. in a Trans-Nzoia coffee block.
Why generic ERP failed us
We looked at off-the-shelf farm management software before writing a single line of code. The options that existed were built for Iowa and the Netherlands. They assumed stable broadband, English-literate users, and payment rails that don't exist in western Kenya. None of them had M-Pesa integration. None had piece-rate payroll logic. None had an offline mode that could survive a day in a coffee block where the nearest cell tower serves 1,200 people and routinely saturates during picking season.
Enterprise agricultural platforms aimed at Africa were worse in a different way: they assumed satellite-imagery dashboards and agronomist-facing interfaces. They did not know the difference between a stumping cycle and a pruning cycle, let alone how to structure the labour records that accompany each. We needed software with crop-cycle semantics baked into its data model, not bolted on as a configuration option. That software did not exist, so we built it.
Designing from the field, not the conference room
The first module we shipped was GPS-verified attendance. Every morning, supervisors open the app, scan or tap workers into the system, and the attendance record is timestamped and geolocated to the field block. The paper register did not disappear on day one; it ran in parallel for three weeks until supervisors trusted the app. That parallel run caught two discrepancies that cost real money when they were on paper. After week three, the exercise books went into a drawer.
Module two was piece-rate payroll, auto-disbursed via M-Pesa Business-to-Consumer from the same dashboard that holds the attendance records. A supervisor logs the cherry weight per picker at the weigh station. The system applies the rate, calculates the pay, and queues it for M-Pesa disbursement. Saturday payroll dropped from a full-day ordeal to under two hours. Our rule during development was simple: every module had to survive a Monday at Mulinga before we considered it ready. Conference-room demos don't count. Production counts.
What “farmer-first” actually means in code
Farmer-first is not a design philosophy you put on a slide deck. It has concrete technical consequences. Here are the ones that shaped the architecture:
- Offline-first React Native. Supervisors check workers in even when the cell tower is saturated or down. Records queue locally and sync on uplink. This is not a nice-to-have; it is a hard requirement for any farm more than 30 km from a town centre.
- Bilingual Swahili / English by default. Not translated-on-request, not a settings toggle buried in a profile screen. The interface speaks Swahili out of the box because most farm supervisors in western Kenya are more comfortable in Swahili than in English, and making a person switch languages in the middle of a working day is friction that kills adoption.
- Battery-conscious GPS polling. A supervisor's phone needs to last a 12-hour shift. Continuous high-accuracy GPS tracking drains a mid-range Android in four hours. We throttle location sampling to what the workflow actually needs: block-level accuracy at check-in, not constant tracking.
- M-Pesa as a first-class payment rail. Not a plugin, not a third-party redirect. The payroll engine was designed around M-Pesa B2C semantics from day one, including retry logic for failed disbursements and reconciliation against M-Pesa transaction IDs.
We are also building toward agentic scouting: an AI module that cross-references field observations with crop-health data to flag disease pressure before it becomes visible. We are drawing on Anthropic's guidance on building effective agents to keep the system behaviour predictable and auditable in a context where a wrong recommendation has real agronomic consequences.
From a personal fix to a product
After 18 months running in production at Mulinga, the requests started coming from neighbouring estates. A dairy operation 40 km away wanted the attendance module. A horticulture exporter needed piece-rate payroll for their packing-shed workers. The problem was clear: what we had built was tightly coupled to Mulinga's data model and operational rhythms.
Productizing required a genuine multi-tenancy rewrite, not a configuration layer on top of a single-tenant system. Tenants get isolated data schemas, configurable crop types and pay structures, and role-based access that maps to how individual farms actually organise their supervisory chain. None of that existed in the first version, because the first version didn't need it. That discipline, building exactly what today's problem requires and no more, is what kept the core solid enough to rewrite around.
We are currently rolling out to two additional East African estates. The Poultry package (flock management, mortality tracking, feed conversion ratios) is in active development. Horticulture and Herbs packages are queued. Each new vertical starts the same way the original did: a real operation with a real problem, not a market-research exercise.
If you run a farm, cooperative, or agritech operation in East Africa and recognise any of the problems above, talk to us. We are building MkulimaOS module by module, shaped by the operations that actually use it. Your operation could be the next design partner. You can also read more about the full platform at spideylabs.tech/mkulimaos.