DEV Community: Mathieu Poli

We formalized a real design system inside an app builder. Here's the architecture

Mathieu Poli — Tue, 04 Aug 2026 10:17:56 +0000

A good-looking app builder isn't a pile of themes. It's a formalized design system, and that's an architecture decision, not a cosmetic one. Here's ours, layer by layer.

Why an app builder needs a design system at all

Start with the scale problem. An app builder doesn't design one app. It designs the possibility space of every app its users will ever create: thousands of them, built mostly by people who aren't designers, about subjects the platform never anticipated. Each of those apps needs to look intentional, stay coherent as it grows, and still look current years later.

A pile of themes can't deliver that. A theme is a frozen set of aesthetic outcomes. It looks right until the user's project deviates from what the theme anticipated: a longer title, a deeper menu, a section combination the designer never tried. Then it degrades, and the user has no principled way to recover, because a theme encodes results, not rules.

A design system encodes the rules. Spacing, typography, color relationships, component behavior, decided once, formally, then applied to every combination of content and configuration, including the ones nobody foresaw. That's why I call it an architecture decision. Like any architecture, it determines what stays true about the output no matter what inputs arrive.

At GoodBarber we were the first app builder to formalize a true design system. The same discipline Material Design brought to Google, or the Human Interface Guidelines to Apple, inside a no-code platform. And I should say it up front: the design system is only the lower half of what we formalized. We had to name the entire app. I'll get to that. First, here's how it's built.

The architecture: three layers, eighteen levels of type

Three layers, each one consuming the one below.

Layer one, Foundations. The invariants, in eight categories: Grid, Spacing, Breakpoints, Layers, Color, Typography, Image Aspect Ratios, Icons. One example of how deep "formalized" goes: gutter spacing isn't a value, it's a behavior. A base gutter that shifts per device, 16px on mobile, 20 on tablet and desktop, with half and double tiers derived from it, all from a single configuration.

Layer two, the Atoms. The smallest reusable design decisions: Color, Font, Image, Gradient, Shape, Shadow, Size, Border, Blur, Overlay, immersive feedback, and the list keeps growing. An atom is a named, constrained choice. A shadow isn't free-form CSS, it's a token picked from a curated range.

Layer three, UI Components, assembled exclusively from atoms: Background, Text Field, Dropdown, Date & Time Picker, Checkboxes & Radio Buttons, Button, Thumbnail, Form. Because components can only speak in atoms, they can't drift apart stylistically.

Typography gets its own paragraph, because it's where most tools are weakest. The system defines 18 semantic levels: Display Headings, Headings, Navbar Headings, Body, Sub-body, Buttons, Badges. A size scale calibrated per device, from mobile to desktop. And hard rules attached: 1.2 line-height, two font families per view maximum. That last rule alone quietly prevents one of the most common ways non-designers hurt their own apps. It's the difference between a font picker and a typographic system: the picker gives you a choice, the system makes your choice work.

Color follows the same philosophy. Four semantic roles per theme, applied across the whole app. The user doesn't color screens one by one. They define what their brand's colors mean, and the system propagates the meaning. Readability constraints live at this level too, structurally rather than by audit.

Beyond the design system: naming the whole app

If that vocabulary rings a bell, it should: the "atoms" and the layered composition come from Atomic Design, the methodology Brad Frost laid out in 2013. The difference lives in the word "formalized". Atomic Design is a discipline that design teams impose on themselves, by hand, project after project. Here, the engine imposes it: the rules are code, applied to thousands of apps built by people who aren't designers. Frost described a method. We compiled it.

And compiling forced us to go further than he did. Atomic Design stops at pages, because beyond that, in a design team, humans take over. An engine doesn't have that luxury: you can't derive what you haven't named. So we extended the hierarchy all the way up, into a true ontology of the app: an App made of Sections, made of Pages, made of Widgets, made of Components, which speak in atoms. A "News" section is a list page and a detail page. The list page is assembled from widgets. Each widget speaks in components and atoms. That complete anatomy is what the rendering engines read when they derive an app.

Here's the detail that matters, though: the back-office doesn't show any of this. Deliberately. An article list page contains exactly one widget, the list, so the editing tool never mentions that widget. You edit the page, period. The ontology is for the machine, not for you. It's a choice we've defended from the start: a strict, structured architecture underneath, and an editing tool that stays simple to understand, instead of turning into a maze just to mirror its own model. (A choice that happens to age well: now that AI agents need to understand the tools they operate, an app that is entirely named and typed is exactly what a machine can read.)

What the architecture guarantees

Three guarantees, and they hold no matter who is building. A designer, a shop owner, or an AI.

Coherence at any scale. Screen forty obeys the same grammar as screen one, because both derive from the same tokens. Apps stay coherent through years of edits by different hands. The failure mode that kills most long-lived interfaces has no mechanism to occur here.

Speed without penalty. In most tools, going fast means accumulating visual debt. Here, every available choice is already systemically valid, so the fast path and the correct path are the same path. That's also the honest answer to AI-speed generation. That's also the honest answer to AI-speed generation. I've written about why AI output converges on the same generic look, and a formalized system is the way out.

Reproducible quality. Good design stops being a lottery that depends on the user's taste and becomes a floor the architecture holds up. The system embodies the judgment, the user supplies the intent. Whose taste got encoded in the system, and why that question matters more than ever, is a separate essay.

One more thing, because "formalized" can sound like "frozen". The system is alive. Our design teams evolve it continuously: trends enter it digested into rules, never copied as-is; components grow variants; old configurations keep working because the engine migrates past formats. That might be its most underrated property: an app built three years ago still looks current, because the system underneath moved for it. (To see these rules at work in actual code, I've opened the engine's hood elsewhere.

How it stays open

The objection every strong system meets: "so everyone's app looks like yours." The answer is graduated escape hatches rather than an all-or-nothing wall.

Customization has three levels. Pick a theme: four semantic colors, done. Override individual colors: deviate where it matters to your brand, inherit everywhere else. Or remap the full design, item by item. Beyond the parameters, custom CSS opens the last mile for the projects that need it.

What makes this different from freeform styling is that every level operates through the system, not around it. Your custom color still lands in a semantic role. Your adjusted spacing still rides the multi-device scaling. You can go remarkably far from the defaults, and you can't, structurally, produce an incoherent app on the way.

In a design system, constraints are what make freedom safe to use.

Mathieu Poli — Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI — and everything that happens when the three meet. · X: @hellomathieup

The rendering engine: how a no-code project becomes a smooth native app

Mathieu Poli — Thu, 30 Jul 2026 07:51:20 +0000

People picture no-code as snapping frozen blocks together. Let me open the hood on the part that actually matters: the rendering engine that turns a data model and a config into polished, native Swift and Kotlin.

I've spent fifteen years building these engines. It's what my teams at GoodBarber do all day. This piece is the tour I'd give you if you visited: what a rendering engine is, what happens between the user clicking Publish and a native app running on a phone, and the engineering problems that live in between.

What a rendering engine actually is

A rendering engine, in a no-code platform, is the layer that transforms a project's description, a data model plus a configuration, into a running application. Everything the user decided in the back-office (content structure, sections, navigation, design choices) exists as structured data. The engine is what makes that data become software.

The common misconception is that this layer is a theme: a fixed shell with slots where your content and colors get poured in. A theme customizes an app that already exists. An engine derives the app from the description. The difference shows up at the edges. A theme degrades as soon as your project deviates from what the shell anticipated. An engine re-derives: different data model, different sections, different navigation depth, and the output is still coherent, because the coherence is computed.

Here's the pipeline that does it.

From a data model to polished native code

Stage one is the input: a data model (the shapes of the user's content: articles, products, events, custom types) and a configuration (which sections exist, how they're arranged, every design decision expressed as parameters of a formalized design system).

Stage two, the engine resolves that description against its component catalog. The components have been designed, built and hardened once, then instantiated in every app the platform produces. The design system acts as the engine's grammar here: spacing, typography and color roles resolve from tokens, not from per-app hardcoding.

Stage three is the output: compiled Swift for iOS, compiled Kotlin for Android. Real projects, real binaries, submitted to real stores.

Why insist on that last stage? Because "it renders on a phone" and "it's a native app" are two different engineering standards. Native output means the app speaks the platform's own language. Scrolling with the system's exact physics. Transitions and motion that match the OS. Haptics where the platform expects them. Text that behaves like platform text. Users can't name these properties, but their thumbs find every one of them within seconds. And this polish is the part a plausible generated codebase skips, because it lives below the level a demo exercises.

One more thing about economics, because it's what makes the whole model work. This native-quality bar is paid for once, by my team, and amortized across every app the engine renders. One example from our own codebase. Our Home section is lists inside lists: a vertical list of widgets, where each widget is itself a scrolling list of content. Any iOS developer who has built that pattern knows the trap. Nested lists defeat the system's cell recycling, cells multiply, memory climbs, and the classic fix, cache more, is also the classic way to blow up. Our engine recycles cells across the nesting, from the inner lists up to the containing one, with widgets of very different natures drawing from the same pool. We shipped that Home page in 2017. Apple introduced a system tool for the pattern two years later (compositional layout), and it helps, but it doesn't end the work: we've been re-tuning that part of the engine continuously ever since, and we're not done. And that's one example. The engine is full of them. No individual project could afford that. None needs to.

What the engine deduces on your behalf

Here's what "derive" means concretely, because it's exactly what a theme can't do. A widget's description carries only what the user decided. Everything else is deduced.

The number of columns doesn't need to be in the description: one on a phone, two on an iPad, three in landscape, resolved at render time. Text direction is inherited from the app's global settings, unless this widget says otherwise. Configs written years ago still render, because the engine migrates old description formats on the fly.

Part of those deductions comes from the design system and its formalized rules. My favorite example is one line of code carrying a whole design opinion. When a small element inside a card, a play button, a date badge, has no shape of its own, the engine gives it the app's global shape token, with the corner radius capped at 8 points. Your brand's rounded corners propagate down to the tiniest badge, but never so far that the radius swallows the element. Nobody configures that. Someone decided it once, and the engine enforces it in every app.

The output isn't static, either. A rendered page ships with its behaviors: the header that retracts as you scroll, the transitions between screens, the gestures the platform expects. None of that sits in the description. It's code, written once, derived everywhere.

And when a configuration stops making sense, the engine doesn't obey it. It transforms it. The description of a detail page's header carries the list of buttons the user wants up there. Ask for more than three and the engine won't cram them in: it switches to a deployable toolbar, automatically, so the top of the screen stays breathable. That philosophy, prevent the mistake instead of rendering it, is one we've documented on our blog.
A caveat, because all my examples come from iOS: that's the engine I know line by line. Its Android and web siblings have their own versions of every one of these mechanisms.

Multiply all of that, the deductions, the behaviors, the transformations, by the sixty-or-so widgets in the catalog, and that's the difference between deriving and decorating.

The problems you never see in a demo

The pipeline is the architecture. The engineering, the part that consumes my teams' actual years, is a list of problems that never show up in a demo and always show up in production.

Lists that stay smooth at scale. Demos show twelve items, real apps have thousands. Cell recycling, image loading and downsampling off the main thread, pagination that doesn't stutter, prefetching that doesn't flood the network. Classic mobile engineering, unforgiving, and in an engine it has to hold for any data model a user defines, not for one hand-tuned screen.

Offline that tells the truth. Real usage happens in parking garages and airplanes. The engine caches content so the app opens and navigates without network. That drags in the hard questions: what's cached, for how long, how staleness is shown, what happens to actions taken offline. Solving this generically, for every content type the platform supports, is engine work in its purest form.

Consistency across the whole app. Ten sections built by different hands over months still have to feel like one product: same rhythm, same type scale, same behaviors. In hand-built projects this dies by a thousand small divergences. In an engine it can't, because every screen derives from the same tokens and the same components.

And the OS wave, every year. New OS versions, new device formats, new store requirements. Apps that aren't maintained don't stay the same, they age, visibly. Behind an engine, the adaptation happens once, centrally, and apps regenerate into the new world. A user who described their project three years ago has a current app today without having touched anything.

None of these problems is exotic. Any senior mobile developer will recognize all four. Which is the point. The engine doesn't make the engineering disappear. It moves it, from every individual project into one layer built by people who do nothing else.

Three engines, one description

One last thing the frozen-blocks picture misses completely. The same project description is consumed by three independent engines: Swift for iOS, Kotlin for Android, and a TypeScript/Angular engine that produces a Progressive Web App.

Architecturally, that means the user's project is genuinely abstract. Pure description, owned by no runtime. Each engine interprets it idiomatically for its world: the iOS app is fully an iOS app, the Android app fully an Android app, the PWA a real web citizen with URLs and SEO.

Take sharing. The description says: this content can be shared. On iOS, the action opens Apple's share sheet. On Android, the platform's own dialog. On the web, the browser's share API. Even the share buttons differ: we draw the icons ourselves, one per engine, each close to the codes of its platform, because an iOS user and an Android user don't picture the same symbol when they think "share". Same key, three renderings, each one correct in its world. Or take blur: the frosted effect behind an element doesn't blur the same way on iOS, on Android and in a browser, so each engine implements its platform's version of it rather than imitating another's. Three different renderings, and no divergence. It's the same sentence, spoken in three languages.

And the three engines never drift apart on what the app is, because none of them owns that information: they all read the same description. Teams that maintain an iOS app, an Android app and a web app by hand have to rebuild every feature three times, then keep checking that the three versions still match. Here, that matching isn't a discipline. It's a consequence of the structure.

So, is no-code real engineering? I'd flip the question. The point of the category is that the serious engineering happens once, below a surface simple enough that it doesn't have to be everyone's job.

AI didn't kill the framework. It made it more valuable

Mathieu Poli — Tue, 28 Jul 2026 07:27:57 +0000

If AI can generate an app, what's an app builder even for? Here's the honest answer from inside one: AI is brilliant at the blank page, and useless at year two. Unless it sits inside a framework that carries everything the demo skips.

The question deserves a straight answer

The question isn't silly. From the outside, the logic looks airtight. Frameworks and app builders existed because writing software was slow and required rare skills. AI now writes software in seconds, from a sentence. So the middle layer is dead weight. If you build app-building software for a living, as I do, you've heard a version of this every week for two years. Sometimes as a question. Sometimes as a eulogy.

The people asking aren't wrong about what they've seen. A model produces in thirty seconds what used to take a sprint. Any answer that starts by minimizing that will be dismissed, and should be. So let's start from the other end.

What AI does excellently

AI has solved the blank page. Ideation, first drafts, scaffolding, boilerplate: the whole from-nothing-to-something phase of building has gone from days to minutes, and the something is often good. Exploring five variants of a flow used to be a budget question. Now it's a coffee break. The tedious transcription work that filled the middle of every project, the code that is neither hard nor interesting, is exactly what these models produce best.

I mean this concession fully, not tactically. It's a real, permanent gain, and it lands where our industry's costs were dumbest. Nobody's professional pride should be invested in hand-typing boilerplate.

But look at where the gain lands: at the beginning. Everything I just listed happens in the first week of a project's life.

What still requires the framework

Now run the tape forward. The generated app works, it ships, time passes. And time is where the demo's assumptions die.

Software that lasts needs an architecture that stays coherent as it grows. Screen thirty has to obey the same conventions as screen three, or every change becomes archaeology. It needs output quality that holds on real devices, with real data volumes, under real OS updates, at the level app stores and users actually demand. It needs maintenance as a process: someone watching the deprecations, the API changes, the security patches, for years, without being asked. And it needs consistency, visual and functional, which is a property of the whole product, not of any single generation.

That maintenance load isn't an abstraction, by the way. It has a calendar. Apple: since April 28, 2026, every submission or update must be built with the latest SDK, a bar that moves up every year. Google Play: from August 31, 2026, no update ships unless it targets Android 16, and an app that targets an older level stops being offered to new users on more recent devices. Meta: each Graph API version becomes unusable two years after the next one ships, and calls to it are silently redirected to a newer version, which is worse than an error because nothing breaks loudly. Add the payment, ads and analytics SDKs riding their own cycles, and you land on the industry's standard estimate: maintaining an app costs 15 to 20% of its initial development budget, every year. None of that work shows up in a demo. All of it is mandatory.

Generation is an event. Those four things are processes. A model, however capable, fires at time T and moves on. That's the asymmetry the framework question misses: AI is brilliant at the blank page and useless at year two. Not because it writes bad code. Because year two isn't a code-writing problem, it's an ownership problem. And a framework is, structurally, the thing that stays. Opinions encoded, invariants enforced, an engineering team amortized across every app it carries.

I'm not the only one landing here, by the way. From the code-framework side, Ayobami Ogundiran has argued that AI made frameworks more important, not less, because agent state, asynchronous UIs and browser-native agents are exactly the kind of new problems that demand new abstractions. His argument is about the new problems AI adds. Mine is about what time does to any app. The two point the same way: the layer that carries structure doesn't lose value when generation gets cheap.

So the conclusion we reached, building an app platform in the middle of this wave, was almost geometric. Don't put AI in place of the framework. Put it inside.

AI wired into the framework

"Inside" means each AI capability plugs into the platform's guarantees instead of bypassing them. The clearest illustration is the furthest we've pushed it: the AI Extension Builder. The customer describes a custom section in natural language. The assistant generates its code, renders it live, and what comes out plugs into the platform's own APIs: geolocation, content, push, commerce data. You can keep prompting, or open the code and edit it directly.

Now look at the economics of that, because it's the same arithmetic I defend elsewhere about the real cost of freedom. Whatever app you're building, most of it already exists in formalized form: lists, accounts, search, push, payments. Features that have been studied, optimized and debugged against years of production. Asking a model to regenerate them is asking it to re-create, quickly, problems that were already solved slowly. So the split writes itself. The platform carries the 90% that isn't specific to you. The AI builds the one part that is genuinely yours, the part no roadmap could have anticipated, in a dedicated section.

Picture a gym app. Class schedules, memberships, push notifications, the coach's content, payments: all of it comes with the platform, studied and debugged years ago. What doesn't come with it is the feature this particular gym lives by, say a real-time occupancy gauge, updated by the staff from the front desk, with a push when the floor frees up. No backlog anywhere contains that. The owner describes it, the AI builds it, and the section calls the same push and member APIs as everything else in the app. Generation gets spent exactly where it produces something nobody else could have shipped, and nowhere else.

And because the generated section lives inside the frame, it inherits everything the frame guarantees. The hosting, the design system, the deployment path, the API surface. That's the ownership layer a standalone generator leaves you without. It also bounds the risk: if your custom section turns out to be a bad idea, the blast radius is one section, not the app. The frame doesn't just make AI output safer. It makes being wrong cheap, and being wrong cheaply is the condition for experimenting at all.

When a customer needs a feature the platform doesn't have, the answer used to be "wait for the roadmap". It isn't anymore, and it isn't "here's a raw code generator, good luck" either. The genesis of that feature is a story of its own, and my colleague Dominique tells it. (The same wiring runs through the smaller assistants in our back-office, a palette generator whose output lands in the design system's semantic color roles, drafting tools whose output lands in the content model. The Extension Builder is just where the pattern is easiest to see.)

My colleague Muriel takes the public form of the question, will AI kill app builders, from the user's side. Two years into the "AI killed the framework" era, our conclusion is the opposite of the eulogy. Generation got cheap. So everything generation doesn't do, architecture, guarantees, maintenance, coherence, got relatively more valuable. The framework was never the slow part we tolerated. It's the part that stays.

When generation is free, taste is everything

Mathieu Poli — Thu, 23 Jul 2026 08:45:20 +0000

When the machine produces execution for free, and infinitely, value moves to the one thing it can't do: knowing what's worth making. Taste stops being a nice-to-have. It becomes the job.

Execution just became free

For the whole history of making things, execution was the bottleneck. Producing a working screen, a decent illustration, a functional feature took skill, skill took years, and years cost money. The economy of creative and technical work was priced on that scarcity. We paid for the making.

That pricing just collapsed. Code, layouts, images, copy: a model now produces competent versions of each in seconds, at near-zero marginal cost, in unlimited quantity. Whatever you think of the quality, the economic fact is settled. Execution went from scarce to abundant.

And abundance does a predictable thing to value: it pushes it up the stack, toward whatever is still scarce. So the useful question, for anyone who builds, is what's still scarce.

The value moves to taste

Watch what the machine produces when nobody exercises judgment: the average. Fluent, plausible, infinite average. I've written about why this happens mechanically with AI-generated apps. The model can execute anything. It can't want anything. It has no opinion about what should exist.

Now look at what's left standing when execution costs nothing. Knowing what's worth making, and what isn't, which is harder. Recognizing, among a hundred generated options, the one that's right, and being able to say why. Holding an intention steady across a thousand micro-decisions so the result feels like one mind made it.

There's an old word for that cluster: taste.

We used to treat taste as the decoration on top of competence, the extra that distinguished the very good from the great. That hierarchy has inverted. When anyone can generate the executions, what differentiates products is no longer who could build it but who could choose.

I'm far from alone in seeing this. Investors now call taste the new moat. And the sharpest version of the argument I've read is Ali Albakri's essay on taste in the AI era: AI, he writes, "democratizes execution without democratizing judgment". Everyone gains the ability to produce. Almost nobody gains the discernment to choose. It's the right diagnosis, and it usually stops there, at the flattering conclusion that the tasteful few will inherit the earth. I want to push on the half nobody addresses: can judgment be democratized too?

Taste sounds like an innate gift, which would mean no. It isn't one. Taste is trained judgment: exposure, repetition, attention, thousands of small verdicts with feedback. Which means it can be developed. And, less obviously, it can be engineered.

A design system is an act of taste

The other day, on the French podcast Continue tu m'intéresses, hosted by Patrick Baud (an excellent show, by the way, for those who understand French), I heard the philosopher Charles Robin draw a line that stuck with me: an AI that produces thought bothers him less than an AI that produces art, because art expresses an affect, something of the heart, while thought is judged only on the pertinence of what it states.
I fully agree with him. And his line helped me place my own trade: we don't make art, an app is judged on its pertinence, the head side. But our work is about bringing apps as close to that border as they can get. Our design system is the means we found for it: we put into it our taste, our affects, what the years have taught us, in a form that thousands of app creators can receive, and that a machine can apply. The goal was never to flatten that taste by writing it down. The goal is to share it.

Taste held in one person's head is a bottleneck. It dies at the edge of that person's availability. But taste can be written down as rules. This is how type scales. This is how spacing breathes. These are the four things a color is allowed to mean. This never goes with that. Do it rigorously enough and you get a system that applies judgment automatically, at scale, on behalf of people who don't have it, and against machines that don't either.

That's what a design system is: taste, formalized until it becomes reproducible. Ours fits in three layers and eighteen typographic levels. But the engineering is the smaller half of the story. The bigger half is that every rule in those layers is a crystallized aesthetic verdict. Someone decided what "right" looks like. The architecture just makes that decision tireless.

Seen this way, the division of labor in the machine age gets clear. The machine executes, infinitely. The system holds the judgment, structurally. The human does the one thing left that neither can do: deciding what the judgment should be, and what deserves to exist at all. What makes your product distinct sits upstream of all execution. My colleague Jérôme has written on exactly that.

The augmented curator

So the anxious question, does the machine replace the designer, the developer, the maker, gets an answer I find genuinely optimistic.

The maker's role shifts from executor to curator. The person with the intention, directing infinite cheap execution, selecting, rejecting, refining. Less time transcribing, more time deciding. That's not a demotion. Deciding was always the noble part of the work. Execution was just where the hours went.

For fifteen years I've built tools whose premise is that execution shouldn't be the barrier between someone's intention and a real product. AI radicalizes that premise beyond anything we imagined. It also sharpens the split this essay has been circling: a system can democratize the floor of judgment, so that nothing ships broken or incoherent. The ceiling, knowing what's worth making, no system can hand you. The people who thrive next won't be the ones who execute fastest, the machine won that contest. They'll be the ones who build that ceiling for themselves. It can be learned, and the time to start is now, while everyone else is still racing the machine at its own game.

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

Mathieu Poli — Tue, 21 Jul 2026 13:08:44 +0000

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.

The hard part was never writing the code

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, either. 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

Here's that view. 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.

Why every AI-generated app looks the same: the architecture that gets you out

Mathieu Poli — Thu, 16 Jul 2026 07:24:10 +0000

Scroll through the apps built with AI this year and you'll notice something: they all kind of look the same. That's not a failure of taste, it's a property of how these models work. And the way out isn't a better prompt. It's architecture.

Once you see it, you can't unsee it

Put a dozen AI-generated apps side by side.

A hero section with a centered headline. Card grids with rounded corners. A blue-to-purple gradient somewhere. Inter, or something close to it. Soft shadows, generous spacing, the same style of empty-state illustration. Different products, different companies, different prompts. One aesthetic.

None of it is ugly. Most of it is competent. The problem is elsewhere: your app is supposed to be yours, and it looks like everyone else's. On a store listing, the design was your one chance to say "this is us" before anyone reads a word.

People call this AI slop. The name is harsher than the output deserves, most of these screens are fine. But the convergence is real, and it has a technical cause. The cause is worth understanding, because it tells you which fixes can work and which can't.

Why it happens

A generative model is trained on a large corpus. Roughly: the visible web, plus the popular design systems and component libraries of the last decade. When you ask it for a screen, it produces the most probable one given that training. The most probable screen is the average of what it has seen.

The model doesn't have a style. It has a center of gravity.

You can prompt your way out of the average, locally. Ask for "brutalist, monochrome, dense" and screen one will comply. The problem shows up over time. A prompt is a one-shot correction applied to a system that keeps pulling back toward its mean, and by screen twelve the corners are round again and the gradient is back. I've watched people fight this screen by screen. It works, and it doesn't scale.

Surface tweaks don't do much either. Changing the primary color or swapping the font produces variation, not identity. A visual identity is a few hundred decisions that hold together across the whole product: how type scales, how spacing breathes, how components relate, what happens at the edges. Randomize three of those decisions and you get the average with a different coat of paint.

So how do you get out? It helps that this isn't the first time the industry has faced the problem.

We've been here before

AI didn't invent the sameness problem. I've been building app platforms since 2011, and in the early years the accusation aimed at no-code was, word for word, the one aimed at AI today: all these apps look the same. The cause was different, a finite set of templates instead of a statistical average, but the effect on screen was identical. Pick template 4, get app 4.

At GoodBarber we decided early on not to treat templates as molds. Our templates are recipes: combinations of parameters that our designers have prepared, so you start from something coherent. From there, everything is parameters: thousands of them, down to the shadow on a list cell or the background of a login field. Combined, the possibilities exceed one billion, a number I've had to compute and defend. But the freedom was only half the job. The other half, the invisible one, was making sure that among that billion combinations, the ugly ones simply weren't possible: every parameter is bounded, framed, designed so that any choice lands on its feet. Two apps that leave from the same starting point can end up with nothing visible in common, and neither of them is broken. That's how we set ourselves apart from the template platforms that all looked alike.

The lesson from that era transfers directly to this one. You don't escape sameness by adding more templates, and you don't escape it by prompting harder, which is the same move with new words. You escape it by turning design into a parameterized system, so that identity comes from the combination a product chooses, not from the mold it started in.

The fix is a design system, not a better prompt

That 2010s work left us with more than parameters. It forced us to define an art direction: a signature, a taste, something that makes an app built on our platform recognizable. And it isn't a monument. Our design teams keep it evolving, absorbing the trends of the moment without ever being a copy of them. Formalized, all of that has a name: a design system. Not a theme gallery, not a style-guide PDF: a grammar the platform enforces on every screen it produces.

Ours has three layers: Foundations (grid, spacing, breakpoints, color, typography), ten Atoms (color, font, shape, shadow, border, and so on, the smallest reusable decisions), and UI Components assembled from those atoms. Typography alone is a system of 18 semantic levels, from display headings down to badges, with fixed rules for scale, line height and line length.
Every one of the thousands of parameters from the previous section resolves against those layers.

With AI, the system's job has shifted. A model doesn't produce incoherent screens; coherent-but-average is exactly what it produces. So the design system is no longer mainly there to keep choices from clashing. It's there to carry that signature and impose it on whatever is doing the generating. In the 2010s it guided our users' hands away from the template look. Today it guides the machine away from the average of the web.

And that's the part I want to insist on, because it inverts how most people frame this: a design system isn't a defense against AI. It's what makes AI usable without regressing to the mean.

Speed and identity

The current debate assumes a trade-off. Either you generate fast and look generic, or you design slowly and look distinct. With a formalized system in place, the trade-off mostly disappears. The system holds the identity. The AI fills in content, assembles flows, handles the tedious middle of the work. Everything it produces comes out wearing your grammar, because the grammar is enforced underneath it.

What the system can't do is decide what the rules should be. Choosing which decisions to lock down, and what "right" looks like for your product, is human judgment. That's a question of taste, and I've written about it separately..
Upstream of taste there's an even more basic question, what actually distinguishes your app, which my colleague Jérôme covers.

So when the next batch of AI-built apps ships and they all look the same again, you'll know what you're looking at. Not bad taste. Missing architecture. Visual quality at scale was engineering work before AI, and it still is.