Case Study 05. AgBizApps, From Contractor to Owner
Industry: Agricultural Mobile Software. Timeline: Approximately 2010 to the mid-2010s.
The Problem.
Farmers run a constant stream of quantitative decisions that people outside agriculture rarely see: projecting harvest yield, adjusting grain prices for moisture and shrinkage, optimizing fertilizer inputs. These are practitioner calculations, made in the field, and at the time almost no one was building simple, purpose-built mobile tools for them. A small software venture set out to fill that gap, with direct access to the domain through a family farm. That access was the real asset. The underlying math was well understood by the people who lived it. What was missing was someone to turn it into working software.
The Solution.
I came in as a contractor and built the tools. I wrote the first app, for grain shrinkage, in Java on Android, because that was the language I knew at the time, then learned iOS development on the venture’s other projects and built a fertilizer optimizer natively for Apple. The suite was sold under the name AgBizApps and included four apps in total: I wrote two, repaired and took over a third, and the fourth came with the portfolio. One of them projected a season’s corn yield from a handful of field measurements, a kernel count across a few sample rows, rows per ear, rows planted, and row length.
The apps earned the venture real money for a while. When the original owner lost interest in the business, I bought the entire portfolio, all four apps along with the WordPress website I had also built for him, for five hundred dollars. I went from the contractor who had been paid by the hour to build the software to the owner of it.
As owner, I was spending my own capital, and the sharper decisions were the ones not to spend. The apps had each been priced at $0.99. I raised them to $2.99 apiece and bundled all four into a single suite at $8.99, turning four small separate purchases into one product. A short, targeted round of Facebook advertising made the portfolio comfortably profitable on very little spend.
Then adoption plateaued, and I stopped. I did not keep pouring money into marketing a product that had clearly found its ceiling, and I did not keep pouring engineering into it either. I chose not to port the remaining apps to Android, and not to chase every new release of iOS and Android as the platforms changed. The sales data had already shown that iPhone users were the ones paying, so covering a platform that was not converting, or chasing endless operating-system compliance on a product that had flattened, would have been spending good money after a return that was not there. I let the apps run as they were until the platforms eventually retired them.
The Outcome.
It was a small portfolio in dollar terms, and that is not the point. The point is the shape of the decisions. I acquired an undervalued asset cheaply, improved its economics with minimal targeted spend through repricing and bundling, and then stopped investing the moment the returns flattened, in both marketing and engineering. Most developers never cross from billing hours to owning the thing they built. I did, and I ran it like an owner, optimizing for return on capital rather than for the satisfaction of building more.
The reason the apps worked at all is worth stating plainly, because it still guides how I choose work. The code was never the hard part. Direct access to the domain, the real decisions farmers actually make, was the asset. Software is only ever as valuable as the real-world problem it is connected to, and knowing when further spending will not earn its keep is the same judgment I have brought to much larger decisions since.