On Building Things Nobody Asked For
The most consequential technology was never planned. It showed up because someone hit a wall the institution could not see.
The most consequential technology of the last forty years was never planned. It was not roadmapped, not approved by committee, not the output of a strategy offsite. It showed up sideways, usually because someone hit a wall and built through it. The pattern holds so consistently that it should concern anyone whose job is to plan what gets built next.
Linux. Git. SQLite. The web. These are not edge cases. They are the substrate. Nearly everything we build today sits on top of something that began as a side project, a workaround, or an accident. The infrastructure of the modern world was not designed. It accumulated.
The Gap, Not the Vision
Linus Torvalds was a student in Helsinki who wanted to run a Unix-like system on his personal hardware and could not afford one. That was the entire scope. There was no manifesto about open source. No plan to replace commercial Unix. There was a 21-year-old with a 386 and a problem that the existing market had no interest in solving.
The market had no interest because the market was structured around selling Unix licenses. The gap Torvalds filled was not technical. It was economic. The technology to build a free operating system existed. The incentive did not. So the gap persisted until someone outside the incentive structure stumbled into it.
Richard Hipp built SQLite because a database server kept failing on a Navy destroyer. He needed something that worked without a network connection. This was not an exotic requirement. Millions of deployed systems had the same constraint. But the database industry was organized around the server model. Licensing, support contracts, feature development, all of it optimized for networked deployments. The idea that a database could be a single file linked into an application did not register as a market opportunity. It registered as a limitation.
SQLite is now the most widely deployed database engine in history. It is in your phone, your browser, your car, your television. It got there not because someone identified a market but because someone identified a wall.
Git exists because a licensing dispute forced the Linux kernel project off its previous version control tool. Torvalds needed a replacement in weeks, not months. He built one. The design decisions that make Git unusual, its distributed model, its focus on speed over ease of use, its willingness to expose complexity, all followed directly from the constraints of that moment. They were not product decisions. They were survival decisions.
The web itself was a document-sharing system for physicists at CERN. Tim Berners-Lee was solving a filing problem. Not commerce. Not social networking. Not the reorganization of global media. A filing problem.
The pattern is not that brilliant individuals had brilliant ideas. The pattern is that structural gaps in existing systems created pressure, and the people closest to the pressure built what the system could not.
Institutional Blindness
There is a reason these things came from the margins and not from the center. The center cannot see the gaps it creates.
Commercial Unix vendors could not see that their pricing model was generating demand for a free alternative. They saw their pricing model as the business. The gap it produced was invisible from inside the business because acknowledging it would mean questioning the business itself.
Database companies could not see that their server architecture was excluding an enormous class of use cases. The server model was the product. Embedded, serverless, zero-administration deployment was not a feature request because the people who needed it were not database customers. They were not in the feedback loop at all.
This is not a failure of intelligence. It is a failure of position. Institutions optimize for what they can measure and what they can imagine. What they can measure is defined by their existing operations. What they can imagine is bounded by their existing model. Anything that falls outside both of those boundaries does not exist, as far as the institution is concerned.
Market research compounds this. It surveys the existing population of users within the existing framework. It asks what people want, and people answer in terms of what they already have. Faster horses. Better Unix. More features in the database server. Nobody asks for the thing that makes the question irrelevant, because the question itself defines the space of possible answers.
The things nobody asked for are precisely the things that fall outside the institution’s field of vision. They are diagnostic. They reveal where the system has calcified. Where it is serving its own preservation rather than the people who depend on it.
The Accumulation Problem
These technologies did not arrive with announcements. They accumulated. Linux spread through universities and hobbyist communities for years before any enterprise took it seriously. The web was a curiosity for academics before it became the foundation of global commerce. SQLite was embedded in so many devices before anyone thought to count that by the time they did, it was everywhere.
This is uncomfortable for the planning model. We expect consequential things to look consequential from the start. We expect launches, press coverage, adoption curves that slope upward from a visible origin. We expect the important things to be legible.
They almost never are. They look like toys. Like someone’s weekend hack. Like something that obviously will not scale and obviously cannot compete with the serious, well-funded, properly managed alternative. They look that way right up until they do not, and by then the serious alternative is already irrelevant.
The accumulation happens because usefulness compounds in ways that visibility does not. A tool that solves a real problem gets adopted by the next person with the same problem. Then the next. No marketing required. No strategy deck. Just repeated contact between a genuine solution and a genuine need.
The institutions watching from above see none of this. Their metrics track market share, revenue, competitive positioning. The thing accumulating beneath them does not register on any of those instruments. It is growing in a dimension they are not measuring.
What This Means
The implication is not that planning is useless. Planning works well for incremental improvement within a known framework. If you understand the problem space and the solution space, planning will get you there efficiently.
But planning cannot produce the thing that reveals the framework itself was wrong. That requires someone outside the framework, bumping into a wall the framework created, building through it because they had no other option. It requires exactly the conditions that institutional planning is designed to prevent: uncoordinated, unauthorized, unscoped work by people who were not asked.
The things nobody asked for are the system’s way of telling you what it cannot see. They do not come from vision. They come from friction. And the institutions that learn to pay attention to friction, rather than smoothing it over with roadmaps, are the ones that occasionally notice the next substrate forming beneath them.
Most do not notice. Most are still optimizing the old model when the new one has already become the foundation. That is not a failure of strategy. It is a property of how institutions work. They are built to execute, not to perceive. And perception, it turns out, is where the consequential things begin.