Why I Built My Own CMS (Again) — This Time with Laravel + Filament

Most developers don’t wake up thinking:

“You know what the world needs? Another CMS.”

And yet… here we are.

The Problem with Existing CMS (From a Developer’s POV)

I’ve worked with a lot of CMS platforms over the years — from WordPress to headless setups.

They all work… until you try to do something slightly different.

That’s when things get messy:

• You fight plugins instead of building features

• You bend your architecture around the CMS

• You inherit years of legacy decisions you didn’t sign up for

At some point, I realized:

I wasn’t building products — I was working around the CMS.

The “What If” Question

So I started asking:

What if a CMS was built the way we build modern Laravel apps today?

• Not constrained by legacy.

• Not pretending to be everything for everyone.

Just:

• Clean architecture

• Developer-first

• Extensible by design

• Actually enjoyable to work with

Why Laravel + Filament?

If you’re in the Laravel ecosystem, this part will make sense.

Laravel gives you:

• Structure without being restrictive

• A clean service layer

• First-class DX

Filament gives you:

• A powerful admin panel out of the box

• Forms, tables, actions — already solved

• A consistent UI layer

Together, they solve 80% of what a CMS needs.

The remaining 20%? That’s where things get interesting.

The Hard Parts (That No One Talks About)

Building a CMS isn’t about CRUD.

It’s about abstractions.

1. Content as Blocks (Not Fields)

What I wanted:

Flexible, composable content blocks

But that introduces problems:

• How do you store them?

• How do you version them?

• How do you render them cleanly?

2. Editor Experience vs Developer Control

There’s always tension between:

• Giving non-tech users flexibility

• Keeping developers sane

Too flexible → chaos Too strict → unusable

Finding that balance is harder than it sounds.

3. Plugin Architecture

I didn’t want:

“Just hack it into the codebase”

I wanted:

A system where features can be dropped in cleanly

Which means:

• Discovery

• Registration

• Isolation

• Extensibility points

I ended up building TallCMS, an open-source CMS powered by Laravel + Filament.

Current features:

• Block-based page builder

• Pages & posts

• Publishing workflow (draft → scheduled → published)

• Revision history

• Media library

• Menu builder

• Plugin architecture

Still early. Still evolving.

Unexpected Lessons

1. Frameworks Matter More Than You Think

Working within Laravel + Filament constraints actually made things better.

It forced:

• Consistency

• Reusability

• Less over-engineering

2. Agentic Coding Is Powerful… But Dangerous

I’ve been experimenting with AI-assisted development.

What I learned:

Without structure → chaos With a clear plan → massive acceleration

I now always:

• 1. Generate a plan
• 2. Review it
• 3. Execute in controlled steps

3. CMS Is a Systems Problem

It’s not:

“Build pages”

It’s:

“Design a system that lets others build anything”

That shift changes everything.

Where This Is Going

I’m still exploring:

• Better block composition

• AI-assisted content creation

• Multi-site architecture

• Developer experience improvements

Curious What Others Think

If you’ve ever:

• Built your own CMS

• Fought with one

• Or are happily using one

I’d love to hear:

What’s the one thing your CMS does really well — or really badly?

Closing

I’m building this as an open-source project called TallCMS.

Not trying to replace everything.

Just trying to make something that feels right for modern Laravel developers.

If you’re curious, happy to share more.