Vibe-coding my dream CMS (an internal monologue)

Whiteboard mind map with "My dream CMS" circled in the centre, surrounded by nine invented CMS feature names, and a hand-drawn water droplet with question marks in the corner
Summarise this post in your favourite AI tool:

Is Drupal outdated? Ask around and you might get a confident yes. Sitback developer Max spent a free weekend designing his ideal CMS from scratch, to work out what he’d build instead.

Step one: build your own CMS, how hard can it be?

Right. That’s it. I’ve had enough of legacy CMSes. Bloated, over-engineered, designed by committee. I have a terminal, I have an agentic coding tool, and I have a free weekend. I am going to vibe-code my own CMS, from scratch, the way it should be built. Clean. Modern. Mine.

Let’s start simple. Pages. A page has a title and a body. Done. Ship it.

…Although. The marketing team is going to want a blog as well, and blog posts aren’t really pages, are they? They have authors, tags, a publish date. And events have dates and venues. And case studies have clients and industries. OK, so what I actually want is a generic content thing, and then versions of that thing, each with their own configurable attributes. Text attributes, date attributes, image attributes, references to other content things. I’ll call them… shapes. With traits. This is genius; why has nobody done this?

Now, images. Editors will upload the same hero image fourteen times if I let them, so I need a central vault where assets live once and get reused. And nobody should be hand-cropping images for mobile, so the system should generate responsive variants automatically from named presets. Vault plus derivative pipeline. Easy. Two prompts, tops.

Listing pages. The blog needs an index, filtered by tag, sorted by date, paginated. The events page needs upcoming events only. I could hand-write a query for each one, but future me will hate present me. Better: a UI where a site builder declares “show me content of shape X, filtered by Y, sorted by Z, rendered as a grid or a table or a feed”. A sort of… saved lens onto the content. Lenses. I am on fire today.

Guardrails, governance and the unglamorous essentials

Hmm, but editors shouldn’t be assembling landing pages by begging a developer either. They’ll want to drag sections around, drop in components, preview before publishing. Fine, a visual page composer, but one that snaps to the design system instead of producing the cursed inline-styled word salad every other page builder produces. Structured components only. Guardrails. I’m a genius and responsible.

Speaking of responsible: not everyone should be able to publish. Junior editors draft, seniors review, someone approves, then it goes live. So I need roles, granular permissions, and an editorial pipeline with stages. Draft, in review, live. Maybe scheduled publishing while I’m in there. And point-in-time snapshots of every piece of content, obviously, because the first time someone fat-fingers the homepage I want one-click rollback.

What else does every site need on day one… SEO basics. Meta tags, XML sitemap, clean URLs generated from titles by some kind of fill-in-the-blank stencil, redirects when paths change. Accessibility shouldn’t be an afterthought either, so the default front end ships WCAG-compliant out of the box. And the whole thing should be multilingual-capable from the start, because retrofitting translation onto a CMS is how developers end up crying in stand-up.

Starter packs and agents

Now here’s where I get clever. I don’t want every new site to start from a blank database. I want to package up “a blog”, “an events section”, “SEO essentials” as installable bundles of configuration, shapes, and sensible defaults that compose cleanly together. Starter packs, basically. Pick your packs, get a working site in minutes instead of weeks of clicking.

And it’s 2026, so the AI story can’t be a chatbot bolted to the side. The content model is structured, which means agents can actually do things safely: scaffold a content type from a plain-English brief, draft alt text, build a landing page, audit a site section for tone drift. The CMS should expose everything over a clean API anyway, because the front end of tomorrow might be a website, an app, or some agent I haven’t met yet.

Oh, and updates apply themselves, securely, because the second-worst kind of website is a hacked one and the worst kind is the one nobody dares update.

Over-the-shoulder view of a man sketching a content management system architecture as connected icons on a paper napkin

Let me just review the spec before I start prompting:

  • Structured content shapes with configurable traits and references.
  • A central asset vault with responsive image handling.
  • Lenses: point-and-click saved queries for listings.
  • A component-based visual page composer with design guardrails.
  • Roles, permissions, snapshots, and an editorial pipeline.
  • SEO, accessibility, and multilingual support by default.
  • Composable starter packs of pre-built functionality.
  • AI agents that operate on structured content.
  • API-first, with automatic updates.

Beautiful. Tight. Modern. No legacy baggage. Now I just need a security team to triage vulnerability reports, a few thousand maintained extensions, and twenty years of production hardening, and…

Hang on.

Hang on.

I’ve just spec’d Drupal CMS. Not even old Drupal, not the “is that still around?” Drupal of conference-hallway folklore. The actual current product: recipes, canvas, AI agents, automatic updates, the dashboard, the lot. My blank-slate dream CMS, designed with zero nostalgia and maximum vibes, converged on Drupal, the CMS everyone insists is outdated. I didn’t even get the satisfaction of better names. My shapes are content types. My traits are fields. My lenses are Views. My snapshots are revisions, my pipeline is content moderation, my vault is the media library, my stencils are tokens, my starter packs are recipes, and my page composer with guardrails is canvas etc. etc. etc.

The gap is reputation

Which is rather Dries’ point in a recent article, The gap isn’t between Drupal and what’s possible. The gap is between Drupal and its reputation. The platform kept moving; the narrative didn’t. And while those of us who know better stay quiet, the stale story is the one that gets repeated by people and increasingly by the AI systems trained on what people wrote.

“Drupal is one of the strongest Open Source platforms out there right now, but too few people realize it. The Drupal community has been modernizing the platform faster than its reputation evolves.”

So no, I didn’t build a CMS last weekend. The one I wanted already exists. It’s called Drupal, and it’s free, and several thousand contributors, including me, maintain and develop it further for you, using many of the same tools one might use to try and vibe-code it from scratch.

I did, however, write this post. Consider the record slightly less silent.