Complexity Lock-In
Sept. 15th , 2026
I use a handful platforms to build websites and have, historically, used many more. Every time I have a new project or want to revisit and refine an older one I always take a moment to survey the state of the art in site building. When it was time to renew my personal site I undertook the customary exploration and found some highly recommended frameworks (Astro and Tailwind if you’re interested).
As with previous explorations I got excited for a while: there’s always an initial giddy rush of “this could be the thing” followed by an hour or two of wrangling with the documentation or just getting stuck in and trying to reverse engineer an implementation I like.
Experience has taught me that it’s a good idea to back off, even if temporarily; and this time I backed off by doing some deeper dives into the reviews. It quickly became apparent that building something on these frameworks would involve a steep learning curve in a proprietary jungle of idiosyncrasies and work-arounds that ultimately meant adapting to a complex abstraction layer inserted between me and the technologies that the web is actually built on.
The positives were things like never having to touch CSS (actually I like CSS), or being able to build reusable components. But the negatives seemed to far outweigh those.
I’m lucky that I learned basic HTML and CSS many years ago and however much things evolve, I can update my knowledge fairly easily and build again with those languages. But even if I hadn’t learned them I think it would still be easier to do that than learn a proprietary framework that obfuscated them.
But this post isn’t just about web technologies: it’s actually about anything that seeks to insert itself between us and the “real world”. Or, more to the point, anything that seeks to insert a high level of proprietary complexity between us and the real world.
“Complexity lock-in”, for want of a better name, is the process of making people dependent on things which have such a convoluted set of procedures, rules, functionalities and inner-worlds that the further we get into them the harder it is to extract ourselves. And these things tend to insert themselves between us and reality so that we begin operating in the inserted layer and lose our grip of that reality. Or, worse, we begin to see the insertion as reality.
The business case for creating these things is often obvious. But it doesn’t always come down to money. We might want to lock people into our thing because we want to attract followers, or we may want to lock people in because of an ideology. It could be any combination.
Open source web frameworks are potentially wonderful inventions and many of them solve genuine problems. On the other hand you might argue that they’re all about land grab, or ego. In practice they inevitably emerge from a web (ha!) of complex motivations. Other, more prevalent insertions into our realities might come from more simplistic intent.
In some of my previous work I helped out on projects that were designed to help people engage with nature through technology and at the heart of things like this is always a simple question: “does this enhance my engagement with something or does it separate me from it?”
I reminded myself of this when I was rebuilding my website and I realised that if I carried on down the path of a new framework I’d have done the latter.
It’s good to get back to the simple craft of something, even if takes more work. Because that extra work means engaging with something that has a deeper, lasting value. Friction is good.
We’re besieged by people wanting to provide that frictionless layer between us and a meaningful reality. And the more complex the seamlessness gets (a paradox)—the more we have to learn the language of the layer—the harder it becomes to escape. The cost of backing out gets too high.
When this happens the negative effect is twofold: we separate ourselves from the rich (rewarding) messiness of the thing we cared about in the first place and we become a customer of the layer. Of course, it’s possible to overthink this in the context of choosing a web framework, but even with that it’s possible to see how much we might invest when we could have invested much better elsewhere.