There’s this idea that’s rapidly gaining popularity as AI continues to evolve that all SaaS products are dead—that if someone wants a ToDo app then they can just vibe code their own app in minutes. And yeah, maybe your grandma isn’t going to build her own recipe app, but there’s something fundamentally true about this idea. Most of the software we use is bloated. We use it because it exists and we use maybe 10% of its features and pay for 100%.
As Maggie Appleton puts it:
we’re in the industrial, high-modernism age of software, where these standardized, one-size-fits-all apps are made for us by people who don’t know much about us.
Source: Maggie Appleton, “Home-Cooked Software”
Even as I write this in Obsidian, software that’s praised for being minimalistic, I use exactly zero of these features nor do I even know what they do.
The idea of users building their own software isn’t new. Going back all the way to 1987, Kent Beck and Ward Cunningham wrote:
We propose a radical shift in the burden of design and implementation, using concepts adapted from the work of Christopher Alexander…[who] proposes homes and offices be designed and built by their eventual occupants. These people, he reasons, know best their requirements for a particular structure. We agree, and make the same argument for computer programs. Computer users should write their own programs. The idea sounds foolish when one considers the size and complexity of both buildings and programs, and the years of training for the design professions. Yet Alexander offers a convincing scenario. It revolves around a concept called a “pattern language.”
Source: Kent Beck and Ward Cunningham, OOPSLA ‘87
So what happened? Ordinary computer users never got around to building their own software. At best, we have the Power Users who could orchestrate their own complex workflows but the spirit of the idea, that the street seller in Turkey, or the doctor in Tunisia, would write their own user interfaces never quite took off. Instead, we pay people to architect for us and usually it’s pretty good or good enough. We can adapt our workflow. We can constrain our business into a set of predefined form fields in someone else’s database because ultimately, the cost of paying for 10% of the features outweighs the time to learn Smalltalk. We smooth down all the edges of our products so that they can fit inside the shipping container.
How does this change when that cost to learn X becomes zero? When AI can build whatever you need on demand? Without another “radical shift” in design, we’re stuck with just building faster horses. That street seller in Turkey can build their own software today, but they can only build what fits inside the shipping container. The constraint is no longer code, but the legacy of “patterns” that we’ve adopted and are now shackled to.
The old PlayPlace era before everything looked standardized.
Decades of “atomic” design and “modular” components preached constraints that no longer need apply.
We used to have 4 browsers that rendered text inputs different and they all were ugly. So we built components. We moved our native apps to electron. It was all easier to maintain one and have it work consistently. Eventually the world evolved. Browsers got better. IDE tooling got better. But we’ve invested too much in our libraries and frameworks that it’s difficult to throw it all away. 10k lines of code can now be reduced to “make all the buttons and text fields line up”.
The architects and planners and bankers have pattern languages which tell them to build gigantic steel and concrete buildings. The users have a few shattered patterns left in their vocabulary: a sheet of plastic to make a kitchen counter; huge plate glass windows for the living room; wall-to-wall carpet in the bathroom—and they enthusiastically piece these patches together, whenever they have a free weekend.
But the remnants of our former languages are dead and empty.
They are based mainly on the by-products of industry. People use plate glass windows, formica counters, wall-to-wall carpet, because industry makes them available, not because these patterns contain anything essential about life, or how to live it.
The time when a pattern language was a song, in which people could sing the whole of life, is gone. The pattern languages in society are dead. They are ashes and fragments in the people’s hands.
Source: Christopher Alexander, The Timeless Way of Building
In the war between Components and Patterns, components won because they were easy to digest and the legacy of that war has been papercuts all the way down, whether that’s your design system team needing to add a fourth variant for product, or the 1001st GitHub issue on your open-source shitty coding agent. Solutions that were designed by anyone other than you will rarely be as good as what you could design yourself. If only you had the time to learn Smalltalk.