The one-giant-farm-system pitch fits nobody. Build the layer, not the monolith.

A mixed ag business runs on several versions of the truth, and everyone in it knows the feeling. Livestock records in one program. Cropping in another. Finance keeps its own version. Compliance evidence lives in folders named things like “NLIS stuff FINAL.” And the working truth of the day lives in a notebook in someone’s ute and a couple of chat threads nobody else can read.

Somewhere along the way a vendor turns up with the answer: one giant platform that runs the whole operation from a single screen. Livestock, cropping, finance, compliance, weather, the lot. It demos beautifully. It also, almost always, fits nobody. The platform that tries to be everything to every enterprise ends up mediocre at each one, priced like a tractor, and abandoned within two seasons because it never matched how any single part of the business actually works.

The monolith is the wrong instinct. One view of the operation is a good goal. One tool that swallows everything is how you get an expensive project that fits no one.

One view is not the same as one tool

The useful move is smaller and far less glamorous. Leave the specialised systems that already work where they are, and build a thin layer that sits above them and connects the records that actually change a decision.

Your livestock program is probably good at livestock. Your agronomy tool is probably good at agronomy. Xero is good at the books. The problem was never that those tools are bad. It’s that none of them talk to each other, so nobody can see margin by enterprise, or which paddocks are carrying the season, or what records are missing for the audit, without an afternoon of copy-paste. A connecting integration layer fixes exactly that without asking anyone to abandon the tool they already know. You keep the specialists and add the view. That’s a project you can afford and staff won’t fight.

Two seasons in, the giant system is a login nobody uses

Here’s how the monolith actually fails, because the pattern barely varies. A mixed operation west of Toowoomba, cattle and grain, signs up for the do-everything platform in winter when there’s time to think about it. The livestock module is decent, because that’s the one the vendor built first. The cropping module assumes a single crop and can’t hold the rotation properly. The finance integration everyone was promised turns out to be a CSV export someone has to run and re-import by hand. So the old systems keep running in parallel, just until the migration settles, and now the operations manager is entering everything twice.

Double entry is where these projects die. The person doing it is usually the busiest person in the business, and the moment harvest tightens or a mob needs moving, one of the two systems quietly stops being updated. Nobody holds a meeting and decides to abandon the platform. It just stops being the truth, one skipped entry at a time, until eighteen months in it’s a login nobody opens and a direct debit nobody’s cancelled.

By then the bill is well into five figures, plus the training days, plus the goodwill spent asking staff to learn a system that fought them. And the original problem, that nobody could see the whole operation in one place, is exactly where it started.

Start from a question, or don’t start

The platforms that get built and then ignored almost always started as a data collection exercise: gather everything, connect everything, and surely value will fall out the end. It doesn’t. You get a warehouse of tidy data and no reason to open it.

The ones that work start from a question someone actually needs answered. What’s my real margin by enterprise this year? Which mobs are due for treatment? Which paddocks need attention before the next window? What records are missing for the audit that’s coming? Which commitments fall over if the season turns dry? The question tells you which two or three sources matter and lets you ignore the rest for now. Build the thing that answers one real question, prove it, then ask the next question. Skip this and the project drifts, the budget bloats, and you end up with a dashboard nobody asked for.

Take margin by enterprise, since it’s the question mixed operations ask most and answer least. It doesn’t need weather feeds, sensors or a paddock map. It needs the production records for each enterprise and the cost and income lines from the accounting file, matched so the allocation isn’t guesswork. Two sources and some matching rules. That’s a project measured in weeks, and when the number finally lands, the arguments that used to run on gut feel, the sheep pay for themselves, the hay’s barely worth cutting, suddenly have something to stand on. Some of those arguments end fast once the number’s on the table.

The boring data work is the actual work

Farm data is a mess, and pretending otherwise is how these projects fail quietly. Names are spelt three ways. Dates go missing. One system measures in one unit and another in something else. Staff use shorthand only they understand. Vendors export in formats that look like they were designed to be unreadable. None of that cleans itself.

A small example of how deep this goes: a paddock gets split in 2021, and now half the history refers to a paddock that no longer exists under that name. Any layer that can’t handle that will report on a farm that isn’t yours.

So the matching, cleaning and correcting rules are not a side quest before the fun part. They are the part that decides whether a report is something you’d act on or something you’d second-guess. A number you don’t trust is worse than no number, because you’ll waste time reconciling it every time it surprises you. Budget for this work honestly. It’s unglamorous, it’s most of the effort, and it’s the difference between a platform that changes decisions and one that just displays them.

Where AI actually helps, and where it can’t

AI is good at the messy edges of farm data. It can read the scanned chemical record, summarise a season of notes, flag the anomaly where a treatment date doesn’t line up, sort the photos, and let someone ask “which paddocks haven’t been sprayed this month?” in plain words instead of building a query. It can even help reconcile records that disagree, with a person confirming the result before it sticks.

But the clever layer needs something solid underneath. If the system can’t reliably tell which paddock, mob, asset or invoice a record belongs to, the AI has nothing to stand on and will confidently connect the wrong things. Get the data model right first, then the AI on top is useful. Reach for the AI to paper over a data model that doesn’t exist, and you’ve built a machine that produces plausible nonsense faster.

If you’re being pitched the monolith anyway

Sometimes the all-in-one deal lands on the table regardless, priced keenly and demoed well, and it’s worth knowing how to test it before anyone signs. Ask which module was built first, because that’s the one that will be any good; the others usually exist to round out the brochure. Ask the salesperson to run your actual structure through it live, your rotation, your mob setup, your agistment arrangements, not their tidy sample farm, because the demo always works right up until it meets a real operation. Ask how ten years of history gets in, who does that work, and what it costs, since easy migration tends to mean a spreadsheet template and your own weekends.

Then ask what leaving looks like. What can you export, in what format, and do your records come out in a shape the next system can read? Lock-in does a lot of quiet work in these contracts, and it’s cheapest to price before you’re a customer. A vendor with straight answers to all four is rare. If you meet one, the platform might even be worth running for the enterprise it’s honestly good at, alongside the tools you keep, which lands you back at the layer anyway.

Build it in layers you can afford

A sensible first layer might just connect finance and production for one enterprise, so you finally see margin by mob or by crop without an afternoon of exporting and cross-checking. The next layer folds in compliance documents so the audit stops being a scramble. The one after brings in weather or sensor data where timing matters. Each layer answers a real question before you add the next source.

For Darling Downs producers and agribusinesses, that staged approach is what keeps the cost sane and the thing actually used. You get a clearer view of the operation, season by season, without betting the farm on a single system replacement that history says won’t fit. If you’re tired of reconciling three versions of the truth, tell us the one question you most need answered and we’ll work out the first layer. Or start with the AI readiness assessment.