Two years ago we started building farm reporting software. We called it trev. We thought it would take six months to reach product-market fit. It took fourteen. Not because we built the wrong thing. Because we underestimated how different this domain is from everything else we'd worked on. The gap between enterprise software for urban offices and enterprise software for rural operations is wider than any tech stack decision we've ever made.
What You Need to Know
- Agriculture software has unique constraints that urban-centric developers consistently underestimate
- Connectivity, seasonal timing, and domain complexity make the development cycle different from typical SaaS
- Building trust with rural users requires a different approach than enterprise buyers in offices
- Niche vertical SaaS in NZ has genuine market opportunity, but patience and domain immersion are required
The Domain Gap
Our team builds enterprise software. We've worked with health organisations, government agencies, and corporate clients. We understand regulated environments, complex data models, and demanding stakeholders.
None of that prepared us for agriculture.
The first thing we learned: farmers are not the technophobic stereotypes that tech people imagine. They're running complex businesses with sophisticated operational models. Many use precision agriculture tools, GPS-guided equipment, and satellite imagery. They're not anti-technology. They're anti-technology-that-doesn't-understand-their-world.
$48.7B
total NZ primary sector export revenue in 2020
Source: MPI Situation and Outlook for Primary Industries, June 2020
Connectivity Is Not a Given
In urban enterprise software, you assume the internet works. In rural New Zealand, you can't. Large parts of the country have unreliable connectivity. Some areas have none at all during certain weather conditions.
This constraint changed our entire architecture. trev had to work offline. Not "graceful degradation" offline. Fully functional offline, with sync when connectivity returns. That's a fundamentally different technical challenge than building a web application that assumes a persistent connection.
The first time we demonstrated trev to a farmer and it couldn't load because we were in a shed with no cell coverage, that was our education. A farming tool that only works where there's internet is a city tool with a rural skin.
Isaac Rolfe
Managing Director
Seasonal Timing Is Everything
Enterprise software projects have deadlines driven by budgets, contracts, and strategic plans. Agriculture has deadlines driven by seasons. Miss the calving window with a feature release and you wait a year for the next one. The cycle of when software is used, and therefore when it needs to ship, is dictated by biology, not business planning.
We learned this the hard way. A reporting feature we shipped in July was perfectly functional but useless, because the data it reported on was collected from September to March. The farmers who needed it couldn't test it until the season started. Our feedback loop went from weeks to months.
What We Built
trev is a farm reporting platform. It collects operational data, farm activities, environmental metrics, compliance records, and turns it into reports that farmers, rural professionals, and regulatory bodies need. The data that sits in notebooks, spreadsheets, and people's heads gets captured once and used across every reporting requirement.
The value proposition is time. A farmer spending ten hours a month on compliance paperwork could spend two hours if the data is already captured in a system that generates the reports automatically. Multiply that across a year and you're returning meaningful time to people who'd rather be on the farm than at a desk.
Domain Language Matters
We rewrote the UI three times in the first year. Not because the functionality changed, but because the language was wrong. We used generic software terms. The users wanted their terms. "Paddock" not "zone." "Mob" not "group." "Drench" not "treatment."
This isn't cosmetic. When the interface uses unfamiliar language, users lose trust. They assume the software was built by people who don't understand their work. And they're right.
Lessons for Other Niche Builders
Immersion over research. We spent time on farms. Not visiting. Working. Riding in utes, standing in yards, watching the actual workflow we were trying to digitise. Research told us what farmers needed. Immersion told us why.
Patience is structural, not virtuous. A niche SaaS product in a seasonal industry cannot be rushed. The feedback loops are long. The adoption cycles are slow. The trust-building is relationship-based, not marketing-driven. If your business model requires hockey-stick growth, pick a different market.
Solve the reporting problem first. Farmers don't want another app. They want less paperwork. The reporting obligation, compliance, environmental, financial, is the pain point they'll pay to solve. Everything else is secondary until that's working.
Build for the worst case. Worst connectivity. Worst weather. Oldest device. Biggest hands on the smallest screen. If it works under those conditions, it works everywhere. If it only works under ideal conditions, it's not a farming tool.
51,000
farms operating in New Zealand
Source: Stats NZ, Agricultural Production Statistics, 2019
Where trev Is Now
Two years in, trev has paying customers and growing word-of-mouth. The product-market fit is there, validated by the farmers who use it daily and the rural professionals who recommend it. Growth is slow by SaaS standards. It's fast by agricultural adoption standards.
The technology is the least interesting part of the story. The real lesson is about building software for a domain you don't know, with users who don't think like you, in conditions you didn't plan for. Every assumption we brought from enterprise software had to be questioned. Most had to be discarded.
If you're thinking about building for a niche market, start with the domain. Not the technology. Not the business model. The domain. Everything else follows from understanding the world your users actually live in.