The Original Problem
The problem I set out to solve was farmers not being able to find a reliably consistent market for their produce. This led to massive waste from unsold food. Simultaneously, many markets went without produce. Demand was high; supply was low.
The Solution? I thought: what if we created a system with full visibility and traceability of what's in the garden? Then markets could align according to available supply. If farmers have a surplus and markets have scarcity, we could link them.
The Hidden Reality of "The Market"
What I discovered is that "Markets" (traders, restaurants, aggregators) don't just buy any produce. Each market has its own definition of quality and quantity. Farmers can have produce, but they need to find the specific type of market that will accept that exact produce at a profitable price.
Markets often lack produce because they can't find the specific quantity and quality they need to consume. They won't take "any" produce, even if it is available.
So, how do we link them? I decided to get farmers to keep records. If they recorded when they planted, markets would have visibility of who planted what, when, and where. If they recorded their spending, they could negotiate profitable prices at the selling season. Worst case, those records would help them get bank loans if they needed capital for the next season.
I built a record-keeping platform. It generated P&L reports and production records. It tracked planting, growing, and harvesting. From our admin panel, I could see exactly what stage every crop was at. I went to the market and gave it to users because, finally, I could link them to buyers and help them negotiate at a profit.
The Incentive Gap
The app was brilliant on paper, but the usage was zero. I had solved for record-keeping, but I discovered that for a farmer, a record is not a means to an end. The only "end" is the market, i.e money in the bank when I sell my produce. Because our records were a reality far removed from the immediate buying or selling decision, they were ignored.
If I have to keep records in January and won't see the value of those records until September when I harvest, I might skip those records. Worse, if those records are telling me that at the current market price I will be making a loss, I will skip very fast.
This created a massive incentive gap. Creating full transparency in the supply chain made sense for the buyers, but in a free market, sometimes the farmer was forced to accept the lowest possible price at their point of need.
This is where the psychology of the market hit us. For a farmer, a low price isn't just a bad deal; it's an insult to their effort. Many would rather not sell at all - letting the crop rot - than sell at a price that undermines their hard work. It was an emotional decision, and our software was only making it harder by highlighting the gap.
Realistically? If there is no one-to-one reward for entering a record - an immediate return like money - it's hard to maintain returning users. People don't keep records because it's a "good practice"; they keep them because they want a specific result.
Our app offered financial reports that showed them exactly how much they lost. That was an outcome farmers didn't want to pay for. In fact, many felt, "I'd rather not know." The solution was a great "paper" solution, but in a free market, "knowing your losses" wasn't enough of an incentive to change behavior.
The Pivot: Atomic Problem Solving
1.5 Years Later
I had spent 1.5 years building and trying to sell the record-keeping platform and what I wholeheartedly believed was the future of AgTech. After a presentation where I demoed the platform to another group of farmers, a farmer came up to me.
He said: "This is amazing, I love what you're doing. That said, can you please add weather for us too? This is how I want the weather, and we can pay for it."
Remote weather forecasting is a nightmare, and they needed it to ensure they didn't miss a planting season so they could actually have something to sell at the end of the season. I went home and built the weather forecasting system for remote regions. We got 20 paying customers the weekend of release. We got 3,000 by the next month.
What else can I build, I asked? They said: "Market prices. Give them to us like this, and that, because we are always negotiating with aggregators and traders." I implemented the market prices feature and we reached 7,000 farmers nationwide in the following months.
The difference? Atomic problem solving got us market coverage faster than a feature-rich solution. Building exactly what they asked for got farmers paying us real money. Sometimes a software bug caused alerts to go out late and I would get calls: "I didn't see my alerts. Put me back on!"
The Realization
It took me 1.5 years to learn what the farmers already knew on day one.
I was an outsider trying to architect a 10G "platform" for a world I didn't live in. I understood the problem on a conceptual level, but the expression of a solution that would work took me a long time to figure out. Meanwhile, the farmers - the insiders - already knew the exact small (1G) problems that were standing in their way. They didn't need a visionary; they needed a builder who would listen.
I realized that at the start of building new products, a feature is only useful if the reward for using it occurs in the same cycle as the effort required to use it. If a farmer has to keep records in January for a reward in September, they will skip it. But if they get a weather alert today that saves their crop tomorrow? They will pay for that. They were paying for Agency.
The Conclusion: Agency and the Stack
Markets can correct themselves if we stack solutions to atomic problems. Solve for weather, solve for market prices, solve for inputs, solve for tools, and eventually, you are solving for the entire value chain - as a cash-flow company where users are voting with their money.
Building one solution for one problem and verifying that they will pay for the solution you built - not just the problem you're solving, but the specific solution you built - is the single most distinct factor between success and failure for a new product.
Supply chain traceability in agriculture is still a problem that exists and is still severely painful for buyers like traders who buy produce in tons, restaurants who need consistent quality, aggregators who need to verify sources, but on the farmer's side, there's a stack of problems in between. Users will pay for solutions to "small stack" problems NOW faster than they will for a problem that doesn't have an immediate one-to-one reward.
Eventually, traceability could look like satellite detection where a farmer enters coordinates and it automatically pings buyers. That one-to-one reward - where my harvest automatically gets me pings from buyers - is something a farmer might pay for. But asking them to track records for six months, to validate quality, for a reward that might never come because a restaurant owner needs to know what GMO was used on day 15 of planting to ensure allergy compliance? That won't work if the stack of problems beneath it remains unsolved.
Why Zorentia?
The biggest waste of resources in tech is outsiders trying to "disrupt" markets they don't understand.
I started Zorentia because I realized that the real power happens when you give the insiders - the domain experts who actually live the problem - the tools and infrastructure they need to build their own solutions.
The farmers knew the problem was weather and prices and many other stacked problems baked into their day-to-day. They just didn't have the tech to manifest the solution.
At Zorentia, we don't try to be the "visionary" for your industry. We provide the technical infrastructure and the 1G methodology to help domain experts ship the solutions they already know their market needs.
Supply chain traceability is still a problem, but it's at the top of a stack. You can't solve the big problem until you've solved the stack of small problems beneath it.