The freedom you don't want: why infinite customization is a tax, not a feature

The hard part was never writing the code

In 2023, at the No Code Summit in Paris, I gave a talk that our blog later turned into a deep dive. Its central claim sounds wrong: the hardest part of building a feature is not writing its code. Fifteen years of building an app platform taught me that. It’s also the reason the total freedom everyone sells right now - raw code, vibe-coding, build anything - arrives with a bill nobody itemizes. Let me itemize it.

Take any feature you consider simple. A list of items, say. Now formalize it: name the states:

• the loading
• the empty
• the error
• the stale

Decide what happens when the network dies halfway through a fetch. Decide what two options do when someone combines them in a way nobody asked about. That work - naming states and finding edges - is where the effort lives. The code that comes after is the transcription.

I didn’t learn this from a book. I learned it feature after feature, for fifteen years, building the platform where that formalization is my team’s actual job. And once you’ve seen it, you can’t unsee what the current tooling debate is really about. It isn’t about who types the code, you or an AI. It’s about who does the formalizing.

What “total freedom” actually invoices

Raw code and vibe-coding sell total freedom: nothing decided for you, no ceilings. Mechanically, that means every formalization is yours. Authentication strategy, state management, caching policy, error conventions, navigation architecture, build pipeline. None of it is your product, and all of it is now your problem. Not once, continuously. A decision in software isn’t an event, it’s a subscription. It has to be remembered, documented, defended in code review, revisited at every OS release, re-explained to everyone who joins. And the invoice is dated year two.

Day one feels free: you move fast, everything is possible, nothing has broken yet. The bill arrives when the framework you hand-rolled needs an update nobody budgeted, when the clever caching layer outlives the person who understood it. Vibe-coding sharpens this, it doesn’t soften it. AI collapsed the cost of producing decisions and left the cost of owning them intact. You can now generate architecture debt faster than at any point in the history of this industry.

None of this is new. The canonical version is ten years old: in Choose Boring Technology, Dan McKinley argued that every team gets about three “innovation tokens” to spend on non-standard choices, because every exotic decision is a long-term maintenance commitment. The industry keeps rediscovering his invoice, most recently in the wave of posts on vibe-coding’s technical debt. The diagnosis isn’t what’s missing. What’s missing is the view from the other side of the fence: what it looks like when a framework does the formalizing for you, at scale, for years. From that side, McKinley’s freedom budget isn’t a metaphor. It has a number.

The engineered middle

First, a word on “framework”, because I use it broadly, on purpose: any tool that made decisions before you arrived. That covers two very different families: code frameworks - Rails for example (Devopedia describes that philosophy well) - and full app platforms like the one I work on. Different technologies, zero shared code, same economics.

On our platform, the patterns that repeat across thousands of apps have been formalized once, by us. The parameters combine into more than a billion possibilities. And for the genuinely custom remainder, we apply what I call the 10% rule: about 90% of a real project is patterns the framework has already formalized. The last 10% is yours, and the framework’s job is to hand you escape hatches for it, rather than pretending the 10% doesn’t exist.

That’s the design position the usual binary hides. The dominant story says code and AI equal freedom, no-code equals limits. The real spectrum is: who formalizes what. Opinionated defaults for everything that is not your product, reversible trapdoors for everything that is. You enter complexity when your project requires it, by choice, with a map. Fast where you’re ordinary, open where you’re special.

AI has made this position stronger, not weaker. Whatever you’re building, most of it already exists somewhere in formalized form: lists, accounts, search, push, payments. Features that have been studied, optimized and debugged against years of production. Rebuilding them is the worst possible use of a freedom budget. The rational split is to inherit that 90% as-is and spend your tokens on the one part that is genuinely yours - the part no platform could have anticipated - and that part you can now vibe-code in a dedicated section, inside the frame. That’s what escape hatches become in the AI era. And the frame keeps the bill bounded: if your custom part turns out to be a bad idea, the blast radius is one section, not the app.

Seen that way, adopting a framework isn’t renouncing freedom. It’s acquiring a decade of formalization you won’t have to do yourself.

A line held for fifteen years

One last thing, because “the middle” can sound like the position you hold when you don’t have one. The platform I build has defended this line since 2011: opinionated where projects are alike, open where they aren’t. Fifteen years, through every wave that was supposed to invalidate it. The most persistent one is hybrid frameworks - they’ve been announced as our replacement for as long as the company has existed, under a new name every few years, and each time we made the same call: native. And now AI generation, the strongest freedom narrative so far.

Each wave moved the how. The economics never moved: someone pays for every formalization. The only real choice is whether you pay for the ones that make your product yours, or for all of them.