Most of what I write about here is new: apps I started this year, tools that did not exist a decade ago. This one is different. I am back inside a company I helped start in 2008.
It is called SeedMatrix, and I am rebuilding its engine now through Senternet. Returning to an eighteen-year-old product has taught me more about what is worth building than any greenfield project has.
The problem that would not go away
SeedMatrix exists to answer one deceptively simple question a farmer asks every year: will this variety actually perform on my field? A seed brand can say its variety yields well. Proving it in that grower's county, on that soil, under that irrigation, against the variety they planted last season is a completely different problem.
The data that would settle it exists, but it is scattered across dozens of independent trial networks, each with its own format and its own corner of the country. SeedMatrix pulls that official variety trial data together with a company's own plot results and lets a sales team slice it down to the conditions of the field in front of them.
When I look at what that has grown into, the numbers say something about how real the problem is: more than 1.8 million trial data points, twelve crops, forty states and provinces. That is not a problem I invented. It is one that was here before me and will outlast me, because a grower makes this bet once a season with a whole year riding on it.
Why I came back to it
I could have left SeedMatrix in the past and pointed only forward at the newer things. Plenty of founders treat old work that way, as a closed chapter. I do not see it like that anymore.
A problem that is still unsolved eighteen years later is not a stale problem. It is a durable one. The consumer apps I build now, like StockCar, solve real annoyances, but the annoyance and the fix can both shift quickly. Agriculture moves on a slower, deeper clock. The question of which seed to plant where has been asked every spring for as long as there have been farms, and it will keep being asked.
So coming back was not nostalgia. It was recognizing that some problems are worth a second pass precisely because they never expired. The first version proved the problem was real. The rebuild is a chance to solve it the way I would if I were starting today.
What eighteen years changes about a rebuild
The problem is the same. Almost everything around it is not. When SeedMatrix started, building a platform that could ingest scattered trial data, normalize it, and turn it into head-to-head comparisons took a team and a long runway.
Doing that rebuild now, with AI accelerating the parts that used to eat months, is a different exercise. One builder can move through the boring, structural work at a pace that used to require several. The engine that turns 1.8 million raw data points into a comparison a grower trusts is exactly the kind of unglamorous, high-leverage machinery that AI-assisted development is genuinely good at helping one person carry.
That is the quiet story of this rebuild. The ambition did not change. The size of the team needed to reach it did. Returning to old work is one of the clearest ways I have found to feel how much the tools have shifted, because I am measuring the new version against a baseline I lived through.
Rebuilding is not the same as restarting
There is a temptation, coming back to something this old, to throw all of it away and begin from a blank page. I have learned to resist that. The valuable part of SeedMatrix was never the code. It was the understanding of the problem, earned the slow way.
Knowing, for example, that:
- every data point has to tie back to a named, dated, independent trial or a skeptical grower will not believe it
- the same variety can look great in one county and mediocre in the next, so filtering by region, soil, irrigation, and maturity is not a feature, it is the point
- a sales rep needs the answer fast enough to have the conversation in a truck cab, not back at a desk
- seed is a high-trust purchase, so the data has to be defensible, not just persuasive
None of that shows up in a code diff. It is the part that took years to learn and cannot be regenerated. A rebuild done right keeps the hard-won understanding and replaces only the machinery underneath it. Throwing everything out would have meant paying tuition on the same lessons twice.
The through line I did not expect
I build consumer tools that run on your own machine with no account, and I also work on a B2B agtech platform that aggregates data at scale. On the surface those could not be more different. Under the surface they rhyme.
Both are about trust. Comoji earns it by never letting your typing leave your Mac. SeedMatrix earns it by making every number traceable to an independent source a grower can check. In each case the product only works if the person on the other side believes it, and belief is built the same way everywhere: by being honest about where the data comes from and what happens to it.
I did not plan for a farm-data platform and an emoji autocomplete to teach the same lesson. But returning to SeedMatrix surfaced it. The domain changes. The reason people let your software into their day does not.
What I am taking from the round trip
Going back to a company I co-founded in 2008 has reshaped how I judge a new idea. A few questions I now ask before starting anything:
- Is this problem durable, or does it disappear the moment fashion moves?
- If I looked at this again in eighteen years, would it still be worth solving?
- What understanding, not code, is the real asset here?
- Could one person, with today's leverage, carry what once needed a team?
SeedMatrix answers yes to all of them, which is why the rebuild is worth my time. The problem endured, the understanding compounded, and the tools finally caught up to the ambition. Sometimes the most forward-looking thing you can do is go back and finish something the way it deserved to be built in the first place.