CROPIA - Harvest Operations Dashboard

A fruit farm makes one decision every morning: how much to pick today. Pick too much and the fruit is unsold and gone within two days. Pick too little and you cannot supply the buyer negotiating price and volume at six in the morning.

That decision depends on three things: what is already in the cold store, what is committed to sell today, and what each plot is likely to give. Around 60 plots, 20 varieties, 440 tonnes a year, 50+ seasonal pickers at peak. Yield varies from plot to plot, and even between the top and the bottom of the same plot, depending on soil, planting density and the age of the plants.

Two systems that did not talk to each other. Picking was entered into a program written in Pascal twenty years ago. Everything else lived in a Google Sheets I had set up four years earlier, which the team used every day.

In practice that meant a physical loop. To check the day's figures you drove to the cold store, printed the picking sheets, came back to the house, opened the spreadsheet and checked the two matched. My father did it. I did it. Every day, and again at midday to check sales.

The second friction was smaller and constant. To price a sale, the salesperson opened the current week's sheet, then opened last week's in a second tab, to see what that client had paid and where prices were going.

The users. Four people who are not comfortable with software and who had been using the same spreadsheet daily for four years. Anything that asked them to relearn how they work would not get used, whatever it did.

One developer. Me. No team, no design phase, no budget.

The history. Ten years of production records, all extracted from the same Pascal program but in two different shapes, before and after an update I had asked the original developer for. Neither shape was clean. Before any of it could support a forecast, it had to be reconciled into one consistent history.

Built: picking, planting, sales, invoicing, stock, and plot-level forecasting.

Left out: plant protection records, and per-plot tracking of what each employee did. Plant protection would not have been difficult, which is precisely why I had to be deliberate about it. The tool needed to do the core of the business properly, and be trusted doing it, before it did anything else. When I moved abroad we agreed to drop it rather than build it remotely.

Taken further than the immediate need: team invitations and permissions, and the beginnings of a multi-entity structure that would let a cooperative manage several farms. That part is not finished. I built it because the problem is not specific to one farm, and I did not want the data model to rule that out later.

Two things, both pointed out by someone else. My uncle works in IT and I asked him to look at what I had built.

I had modelled access as broad roles: salesperson, crop manager, picker, data entry. That maps to how the farm is organised, which is why it felt right. It is also wrong, because a role describes a person and what you actually need to control is an action. As soon as one person wears two hats, or another farm organises itself differently, roles break. Access is now set per item, with read, write and edit separated, and the same granularity applied to the admin section.

I had also built the navigation hierarchy around data entry, fruit down to variety down to plot, and then found I could not query in the other direction. Weight by variety, weight by plot, and the cascade got in the way. A hierarchy optimised for entering data is not a hierarchy for analysing it, and the tool needed both. Filters now work in both directions.

Both are implemented and in production.

Cropia is used daily by four people covering four jobs: the farm manager, the salesperson, the crop manager and invoicing, plus a separate entry account in the cold store. The Pascal program has been retired.

It is in its first full harvest season, and it has run for two months without a change. The yield data is starting to feed planting decisions for next season: which plots and varieties performed, and what gets replanted.

Both corrections above are things I would now design in from the start: permissions modelled as actions rather than roles, and an analysis hierarchy sitting alongside the entry hierarchy. Neither is a hard idea. I just did not see them until the tool was in real use and someone from outside asked the right question.

The wider lesson is the one that moved me out of operations. Most of the problems I had spent four years solving by hand were data problems. Once the data was in one place and could be queried, the operational decisions got easier on their own.