FarmOS started as a client problem and became a product of our own. Building software for people who work in fields, cold stores and dairy sheds changed how we think about every project, including the ones that never leave an office.
The user is not at a desk
Most business software assumes a person sitting at a computer with a stable connection and time to think. On a farm, the person recording the work is usually the munshi: standing in a field, holding a phone, with sun on the screen and a queue of workers waiting. If a screen needs scrolling, typing or a second look, it will be skipped.
So we designed FarmOS around the phone first. Attendance for a whole crew fits on one screen, and marking it takes a tap per person. Waterings, sprays and harvests are logged against the field they happened on, with sensible defaults so most entries need only a number.
Speak the language of the farm
Early versions used acres, kilograms and generic labels. They were technically correct and practically confusing. Farmers in Pakistan think in acres and kanal, sell in maund and bags, and pay in rupees. Cold stores track lots by marka and rack. A tubewell is not the same as a canal turn.
Once FarmOS used those words and units, training time dropped and questions changed from "what does this mean?" to "can it also do this?". It is a small detail that does more for adoption than any feature.
The fastest way to make software feel simple is to use the words people already use.
Safety rules belong in the software
Some mistakes on a farm are expensive. Harvesting a field too soon after a spray is one of them. Releasing more bags from a cold store than a lot actually holds is another. These rules used to live in someone's head.
FarmOS now enforces them. Every spray records its pre-harvest interval, and the field shows a clear "do not harvest before" date. Gate passes can never release more than is in the lot. We have since applied the same thinking to client systems: if a rule matters, the system should make it impossible to break by accident.
Pick only what you need
A cold store, a crop farm and a dairy have very little in common. Trying to sell all of them one large system did not work. Splitting FarmOS into twenty modules did. Each module solves one job, says which other module it depends on, and can be added later as the business grows.
The package builder on the FarmOS site works the same way: tick the modules you need, and anything they depend on is added for you. Customers start small, see value in weeks, and grow into the rest.
Own your data, own your hosting
Many farm owners we spoke to were wary of monthly subscriptions and of their records living on someone else's server. FarmOS is sold as a one-time licence and installed on the customer's own hosting, under their own domain. That decision shaped the architecture, the update process and the support model, and it is a big part of why customers trust it.
What we took back to client work
- Watch the work happen. We now spend time where the software will be used before we design it, whether that is a clinic reception, a warehouse or a sales floor.
- Optimise the most frequent action. One screen used fifty times a day matters more than ten screens used once a month.
- Build modules, not monoliths. Smaller launches are easier to adopt and easier to fix.
- Encode the rules. If a mistake is costly, design it out.
Running our own product means we live with our decisions every day. That is the best training a software team can get, and it is why our products and our client work share the same standards.