What was Fead? The haziness of this story in my mind makes me happy that I'm telling it now. I don't recall how exactly I conceptualized Fead, except that I was in a disposition similar to that described in The History Of Runwae. I wanted to make something meritorious and better prepare for the future. I remember the idea being simple and common sense.
Fead was the first "real" project that I set out to create. It was the first that would potentially serve people, have some value, structure, etc. To be clear, it wasn't anything close to a startup. It was a training course that I had set up for myself.
So, what was it? Fead was a platform for small businesses to sell their data to each other. Still today, I have no doubt that it's a great idea. I do think that it was premature and would require some real influence to get going.
The concept sounds simple: local restaurants sharing customer foot traffic patterns with nearby retailers, boutique hotels exchanging booking trends with event planners. Hyperlocal data sharing that could help small businesses compete with the analytics sophistication of large corporations. But Fead lasted exactly 18 months before I shut it down.
The Timing Lesson
What I learned from Fead wasn't just about the technical challenges of data platforms or the complexities of small business sales cycles. The deeper lesson was about timing in innovation. I was building for the world of 2025 from my position in 2021. The small businesses I approached weren't digitally mature enough to generate useful data consistently. They lacked comfort with cloud-based tools. Most fundamentally, they hadn't yet developed trust in data as a business asset—a mindset shift that wouldn't happen for several more years.
The Fead experiment taught me to distinguish between two types of innovation failure: execution failure (you can't build the thing well enough) and timing failure (the world isn't ready for the thing yet). Most postmortems focus on execution. But timing failures are often more instructive because they reveal assumptions about how change happens.
The Solo Founder Fallacy
I was operating under what I now call the "solo founder fallacy"—the belief that individual brilliance combined with technical skill could overcome structural resistance. The businesses I was trying to serve had existing relationships, established workflows, competing priorities. They didn't need a clever platform as much as they needed someone they trusted to guide them through an emerging landscape of digital tools and data practices.
What I should have built wasn't a platform. It was a consultancy that helped businesses understand what data they had, what they could do with it, and how to start sharing it safely. The technology could have come later, after the behavioral and cultural groundwork was established.
Behavior Change Doesn't Follow Logic
There's a particular kind of frustration that comes from seeing a solution clearly while watching people continue with obviously inferior practices. The temptation was to build faster, market harder, explain more clearly. But behavior change doesn't follow the logic of rational choice theory. It follows the logic of social proof, risk assessment, and cognitive load management.
Today, many of the businesses I originally pitched are now ready for exactly what I was offering in 2021. They've digitized their operations. They understand data as a competitive asset. The legal and cultural infrastructure for small business data sharing has matured. Someone will build what I tried to build, probably in the next 2-3 years. They'll likely succeed because they'll be building into an environment that's prepared to receive innovation rather than resist it.
The early builders map the territory for the people who arrive when the conditions are right.