The Problem Isn't Flexibility

Published 3 days ago

Every few months someone asks me whether Mason is meant to compete with page builders.

It's a fair question. Mason lets editors assemble pages from reusable building blocks, rearrange content, and create landing pages without writing code. From a distance, it appears to belong in exactly the same category as the visual builders that have become common across modern CMSs. That is usually where the conversation begins.

It is rarely where the interesting part begins.

After building marketing sites for years, I have found myself in the same meeting over and over again. Marketing wants a new landing page for a campaign. The request is not especially complicated. They are not asking to redesign the site. They simply want to tell a different story than the one the current templates were designed to tell.

The room usually divides in predictable ways. Someone suggests adding another template. Someone else proposes a few more fields. Eventually the idea of a page builder appears because it promises to remove the bottleneck altogether. For a long time I thought those conversations were about flexibility. Looking back, I do not think they were.

I think they were about responsibility.

The boundary we rarely discuss

Every content management system answers the same question, whether it does so intentionally or not.

Who is responsible for what?

Traditional CMSs place most of that responsibility in the hands of developers. The content model is carefully designed. Templates are predictable. The structure of the site is protected from accidental change. Those characteristics are valuable because they produce systems that remain understandable years after they are launched. Developers can change the application with confidence because they understand the rules that hold it together.

The downside appears when the business changes faster than the software. Marketing wants to tell a story the original model did not anticipate. A product launch needs a different flow. A seasonal campaign needs to emphasize something that never mattered before. None of those requests are unreasonable, yet they often require another deployment because the application has become the only place where new ideas can exist.

Visual page builders solve that frustration from the opposite direction. Instead of asking developers to anticipate every future requirement, they allow editors to assemble pages themselves. That freedom removes bottlenecks and gives content teams the ability to move at the pace their work demands. It is a compelling tradeoff, and there is a good reason these tools have become so popular.

Over time, though, I noticed the conversations changing. They became less about the message and more about the presentation. Discussions shifted toward spacing, layout, exceptions, and one-off variations of components that were originally intended to be shared. None of those decisions seemed harmful in isolation, but together they slowly moved responsibility for the design system away from the people who built it.

That is not a flexibility problem.

It is a boundary problem.

Responsibility is different from freedom

For a long time I assumed flexibility was the thing we were all debating. Some teams wanted more of it. Others wanted less. It seemed like every CMS existed somewhere on a spectrum between complete structure and complete freedom.

I no longer think that is the right way to frame the discussion.

Editors should have freedom. Developers should have freedom. The problem begins when that freedom quietly becomes responsibility for decisions that belong to someone else.

Developers think in systems. They care about accessibility, performance, maintainability, rendering, consistency, and whether today's decisions will still make sense years from now. Editors think in stories. They understand campaigns, messaging, priorities, and the audience they are trying to reach. Neither perspective is more important than the other, but they are fundamentally different disciplines. Good software should respect those differences instead of asking each group to compensate for the other.

The question that became Mason

Eventually I stopped asking whether I wanted a more flexible CMS.

Instead I began asking a different question.

What would happen if developers remained responsible for the system while editors remained responsible for the story?

That single question changed the direction of the project.

Developers define the vocabulary of the design system. They decide which concepts exist, what information those concepts require, how they are rendered, and how they evolve over time. Those decisions remain part of the application where they can be tested, reviewed, and improved with confidence.

Editors never need to think about any of that. Their responsibility is deciding which ideas belong on a page, how those ideas should be arranged, and what story they should tell. They are not building components. They are composing with concepts that already exist.

Developers build the vocabulary. Editors write with it.

Looking back, I think that sentence describes Mason better than calling it a page builder ever could.

Why Bricks exist

This is why Mason revolves around Bricks. If you are familiar with other page builders or block-based content systems, a Brick is Mason's name for the same basic concept you might already know as a block. I chose different terminology, but the underlying idea should be familiar: a reusable unit of content that an editor can place within a page.

What matters to Mason is not the name, but where the responsibility for that unit lives. A Brick is not simply a reusable component. It is a shared contract between the developer and the editor. The developer defines what it represents, which fields it exposes, how it behaves, and how it renders. The editor decides when it belongs, what it should communicate, and how it fits into the larger narrative of the page.

Those responsibilities are intentionally separate because they solve different problems. Developers are free to evolve the design system without rewriting every page. Editors are free to create new narratives without redesigning the system underneath them. Neither side has to renegotiate that relationship every time a new campaign begins.

From philosophy to implementation

Everything I have written here is really about a way of thinking. Mason is simply the implementation I arrived at after asking these same questions across many different projects.

If you are already using Filament, the philosophy should feel familiar. Filament encourages developers to express the architecture of an application in code while giving users interfaces that are focused on accomplishing a task instead of exposing implementation details. Resources describe the domain. Forms describe editing experiences. Tables describe presentation.

Mason applies the same thinking to content composition.

Developers define the concepts. Editors compose with those concepts. The goal is not unlimited flexibility. The goal is a healthier boundary that allows both groups to work confidently without stepping into each other's responsibilities.

Ready to try Mason?

If this approach resonates with you, getting started only takes a few minutes.

composer require awcodes/mason

From there, I recommend starting with the installation guide, creating your first Brick, and then building a page. The documentation explains the API, but I hope it also reinforces the philosophy behind it. The implementation matters, but it only exists because of the idea that came first.