We wrote our own software for a dairy farm
Buying the system was the easy option. It was also the wrong one.
By Sovandarapor (James) Kong · · Ventures
Every consultant who walked through the farm gave the same advice. Buy the system. Pay the license. Let someone else carry the maintenance. It is sensible advice and I ignored it.
The reason is not that we are clever. It is that every off-the-shelf system we looked at assumed a business that did not exist here. They assumed the milk was already measured. They assumed the delivery driver had a phone plan. They assumed the person entering the sale and the person counting the stock were two different people who trusted each other. None of that was true on day one.
What a system actually has to survive
A dairy in Cambodia runs on a set of facts that no software vendor has ever met. Milk leaves the farm before anyone knows exactly how much left. A route driver returns with bottles, some full, some empty, some broken, and the difference between those three categories is money. Customers pay in two currencies, sometimes in the same week, at a rate somebody wrote on a whiteboard that morning. A supermarket rejects a delivery for a reason nobody records.
You can either bend the business until it fits the software, or bend the software until it fits the business. Most companies do the first and call it a digital transformation. What actually happens is that people keep a second set of records in a notebook, because the notebook still works and the system does not.
If your team maintains a shadow spreadsheet, the software has already lost. The spreadsheet is not the problem. It is the report.
The thing nobody warns you about
The hard part of building your own system is not the building. It is that the moment you turn it on, it starts telling you things you would rather not know.
Our first honest inventory count did not produce a number. It produced an argument. The system said one thing, the shelf said another, and both were confidently wrong in different directions. That gap had existed for years. It only became visible because something finally wrote it down.
People treat that moment as a failure of the software. It is the opposite. The software finally worked. What failed was everything the business had been quietly assuming since before the software existed.
Build the boring parts first
The temptation is to build the dashboard. Everyone wants the dashboard. The dashboard is the last thing you should build, because a dashboard on top of bad data is a machine for making confident mistakes at speed.
The order that worked for us:
One. Name things properly. An item code should tell you what the thing is without opening anything. If a person has to ask which of two similar codes is the 2 litre bottle, you have already lost an hour a week, forever.
Two. Make entry faster than the notebook. Not equally fast. Faster. If entering a sale takes longer than writing it down, the notebook wins and it deserves to.
Three. Show people their own work. The single biggest change in adoption came from a page that showed each person what they had entered that week. Not a management report. Their page. Turns out people care about their own record.
Four. Only then, the dashboard.
What it costs
It costs your evenings. That is the honest answer. There is no version of this where you own the system and someone else carries it. Every process you automate is a process you now maintain. Every report you build becomes a report someone depends on and will call you about.
The trade is that the business becomes legible. Not perfect. Legible. You can ask a question and get an answer the same day instead of the same quarter. In a market where nobody has good data, being the company that can actually see itself is not a small advantage. It might be the whole advantage.
The consultants were right that buying it is easier. They were costing the decision over three years, though, and the thing we actually needed was a system that matched a business still changing shape every quarter.