Why we left Drupal, tried Storyblok, and what happened next

Two things I never thought I'd pay for: tap water and a CMS.

In June 2023, I made an impulsive decision to move Agiledrop's website from Drupal to Storyblok, a headless CMS with impressive marketing and $138 million in venture funding. I run a 70-person development company where 90% of our business comes from Drupal projects. My development managers pushed back hard on this decision. I overrode their concerns anyway.

This is the story of what happened next and what it taught me about the CMS landscape. More importantly, it's about understanding the difference between marketing visibility and market opportunity, and why some problems that look like technology issues are actually process problems in disguise.

Why I was vulnerable to the pitch

I had two reasons for considering a move away from Drupal. One was personal and tactical. The other was strategic and tied to the future of our business.

The personal reason was simple. As CEO, I wasn't hands-on with client projects anymore. The closest thing I touched was our own website. And updating that website felt slow. I wanted to add new features, change landing page components, etc. But our developers were busy with paying clients, which is exactly how it should be.

But I kept thinking: we should be able to do this faster. We're using Drupal, this powerful platform, for what's essentially a brochure site with a blog. Maybe we're using a bulldozer to dig small holes?

This seemed logical. It wasn't.

What I didn't realize at the time was that I was confusing a process problem with a technology problem. The issue wasn't Drupal. The issue was that I needed to start a whole machine in the company to do updates. Development processes, deployment pipelines, testing protocols – all the overhead that comes with maintaining a Drupal site properly.

I thought a different CMS would change this. It didn't. We'll get to that.

The strategic reason was bigger and harder to dismiss. We had about 50 developers at the time. Ninety percent of our revenue came from Drupal. We had great clients, solid projects, a good reputation. But I was watching Drupal's growth slow down. Market share wasn't increasing. Conference attendance was steady but not explosive.

I kept asking myself: what if we're too dependent on one platform? What's our hedge? What happens to 50 people if Drupal declines significantly?

This concern wasn't completely wrong. But my solution was.

The Storyblok marketing machine

I don't remember exactly where I first encountered Storyblok. But at some point, we decided Agiledrop should expand beyond Drupal. We started attending broader web development and software conferences.

Storyblok was everywhere. Conference sponsorships. Speaking slots. Booth presence. Polished marketing materials. Their tagline stuck with me: "Create with joy. Scale with intelligence. A headless CMS made for humans."

What I didn't fully appreciate at the time was why they were so visible. Storyblok had raised $138 million in venture capital funding. Their most recent round, an $80 million Series C in June 2024, was specifically allocated to marketing and expansion in the U.S. and Europe.

They weren't everywhere because they were winning. They were everywhere because they had the budget to be everywhere.

I have a business playbook that worked before. I joined the Drupal community in 2009 and incorporated Agiledrop in 2013, right as Drupal was entering the enterprise space. That timing was good for us. We rode that wave.

When I looked at Storyblok's growth trajectory and market presence, I thought I was seeing the same pattern. Get in early, ride the wave, diversify our technology stack. It seemed like a data-driven decision.

But I was making a critical mistake. I was confusing marketing reach with actual market adoption. Drupal grew organically through product-led growth and community contribution. Storyblok bought their exposure with venture capital. Those are very different growth models with very different implications.

June 2023: The decision

In June 2023, I made the call. I announced it to the development team on a conference call.

I remember that call clearly. The faces. The questions. Maybe some eye rolling.

Our development managers pushed back hard. They said we can't support a technology we've never used. We can't mentor developers on this. We can't help when things go wrong. We don't have the expertise.

They were right. But I did what I call in our company a "sudo command." I overrode their concerns.

I convinced them this was our hedge. With 50 people depending on Drupal, we needed to diversify. We needed to learn new technologies. We needed to expand our capabilities.

The development managers were completely right. We'll get to that too.

What I found when we started building

I'm not going to bash Storyblok here. They built a product. It has users. It works for certain use cases. But what I discovered was a series of gaps. Things that Drupal solved years ago that I had completely taken for granted.

Forms were the first surprise. I assumed any modern CMS would have a form builder. Storyblok doesn't have a native solution for this. In Drupal, there's Webform. We don't need complicated forms, but I wanted more than a simple contact form. I wanted to send confirmation emails, create automation around submissions, control spam.

For Storyblok, we had to build it ourselves. We abused their block system the same way we used to abuse content types back in Drupal 6, before we had proper entities. Anyone who started with Drupal 6 remembers this. Using content types for everything. Profiles, categories with images, all hacked together.

That's what we did with Storyblok blocks to create forms. But even that was a half-solution. Not even close to what Webform offers in Drupal.

Redirects were the second discovery. This was an afterthought for us. We didn't plan for it. Why would we? After working with Drupal for so long, you don't think about redirects. There's a module for that. Actually, it's part of Core now.

In Storyblok, we had to hack the block system again to create custom configuration for redirects. The result was that redirects now live next to blog posts in the content tree. That felt wrong.

Everything was possible. But we were solving problems Drupal had already solved a decade ago.

Configuration management was the third gap. Storyblok doesn't do version configuration in Git. When we asked support about this, they told us to configure things in the dev environment, then do the same manually on production.

Anyone who worked with Drupal before Drupal 8 knows how painful this was. We literally built our own version of the Features module from Drupal 7. We created a script that pulls configuration from one "space" (Storyblok's term for a website) and deploys it to another space.

Now we have initial config states, migrations, and our own commands. Configuration management was one of the best features of Drupal 8. We had to rebuild it ourselves for Storyblok.

The technology stack added another layer of complexity. We went with Next.js because it seemed like the obvious choice. But Storyblok's SDK support was much better for Vue.js and Nuxt. The documentation for Next.js wasn't great.

More importantly, there's no real community support. Storyblok has Slack and Discord channels, but I prefer forum-based or issue-based approaches like Drupal's issue queues. With Drupal, you Google a problem and find an issue queue where someone already solved it. There's a module. There's documentation. There's 20 years of accumulated knowledge.

With Storyblok, we were mostly on our own.

Did the promise come true?

Let's go back to my original motivation. I wanted to update our website without starting a whole machine in the company. I wanted speed and independence.

Did that promise come true? Not really.

We set up the CMS so we can build landing pages without developer help. But then there are special things we need to do, or we find bugs. And now it's actually worse because we don't have full control to fix things ourselves. We're dependent on vendor support or working around their architecture.

I traded constraints I understood for constraints I didn't. The process overhead didn't disappear. It just changed shape.

Every platform has constraints. I learned that I'd rather choose constraints we can control.

What this taught me about Drupal's positioning

Here's what this experience crystallized for me. If Drupal tries to compete the way Storyblok competes, we're going to lose.

Drupal can't out-market them. Storyblok has $138 million in venture funding specifically for marketing. They have 240 employees, SaaS business models that support aggressive growth, and polished campaigns everywhere. We don't have that in Drupal. We shouldn't try to have that.

That's playing someone else's game with someone else's rules.

Instead, Drupal should own what makes it different. Drupal is the best self-hosted, open-source CMS. Period.

Those qualifiers aren't weaknesses. They're competitive advantages.

Self-hosted means you control your infrastructure. When vendors change pricing tiers or feature availability, you're not helpless. You adapt on your terms.

Open source means no vendor lock-in and full flexibility. When we needed custom forms, redirects, and config management in Storyblok, we had to hack around their system. In Drupal, we extend it.

Digital experience means not just content storage but decades of solved problems. Forms, redirects, workflows, permissions, multilingual, accessibility. These aren't nice-to-haves. They're the product. They're invisible until you lose them.

Stop apologizing for what Drupal is. Start being proud of what makes it different.

The diversification question

I need to be honest here. My strategic concern about Drupal dependency wasn't completely wrong.

At Agiledrop, we have a unique perspective. We're an outsourcing company that works with Drupal agencies. When agencies don't have enough capacity to take on new projects, they come to us to augment their teams.

In the last couple of years, we're seeing less of that. Fewer requests from agencies. The projects we do get are increasingly not new builds. They're updates, new features on existing sites, maintenance work.

This tells us two things. Agencies have enough of their own resources to handle their workload. And there aren't a lot of new builds happening.

At DrupalCon, I talked to other agency owners. Everyone sees it. There's less demand for Drupal coming from the market. Not zero demand, but less than five or ten years ago. The market has changed.

We do need to adapt. We do need to diversify. But diversifying doesn't mean abandoning what works. It means adapting while staying true to what Drupal does best.

Here's the contrarian angle that kept coming up in conversations at DrupalCon. A lot of people think Drupal shouldn't try to compete with Wix or WordPress or even platforms like Storyblok. Instead, Drupal should focus on being a niche technology for a niche client.

Drupal had success as an enterprise development framework. Complex requirements, custom workflows, strict compliance needs, multilingual publishing, advanced permissions. That's where Drupal shines. That's where the community's expertise matters most.

The agencies and developers I talked to have doubts about trying to be everything to everyone. They want more focus on what Drupal does better than anything else.

I think they're right.

What we're doing with Storyblok now

We're still using Storyblok for the Agiledrop website. We'll stay on it until we're ready to do a rebrand. When that happens, we'll evaluate our options. We might stay on Storyblok. We might go back to Drupal. We might even look at something else entirely.

With AI platforms emerging, I'm leaving the option open to intentionally go find another story like this. To challenge ourselves again just because we want those learnings.

I think for a company like ours, those stories and those learnings are important. My team doesn't always agree. They have enough things on their plates without me creating experiments. But that's how we grow.

It's the same principle as building muscle. You do the hard work, you damage the tissue, and when it heals, that's where growth happens. I think it's the same with a company.

What I'd tell my June 2023 self

If I could go back and talk to myself before that decision, here's what I'd say.

The problem isn't Drupal. It's your process. You're confusing an organizational challenge with a technology problem. Changing the CMS won't fix the process overhead. It will just create different overhead.

Marketing visibility doesn't equal market opportunity. Conference presence doesn't equal project volume or product quality. Drupal grew organically. Storyblok bought exposure. Those are different things.

Solved problems are invisible until you lose them. Forms, redirects, config management – you won't realize how valuable they are until you have to rebuild them yourself.

Your development managers are right. Listen to them. They understand dependencies you're ignoring.

Community infrastructure scales better than vendor support. Twenty years of issue queues and contributed modules beats any support ticket system, no matter how polished.

Control matters most when you're blocked. Being able to fix things yourself is worth the maintenance cost.

But I'd also say this: the experience was worth it. Not because Storyblok was better. But because it taught you what Drupal really offers. You can't appreciate invisible infrastructure until you experience its absence.

What this means for you

If you're considering leaving Drupal, ask yourself these questions. Is this really a technology problem or a process problem? What am I taking for granted? What invisible infrastructure am I about to lose?

Listen to your developers. They're probably right about the dependencies and risks you're not seeing.

If you're an agency looking for new markets, look at actual demand data, not marketing hype. Conference sponsorships don't equal project opportunities.

If you're positioning Drupal to clients, stop apologizing for maintenance costs or complexity. Own the tradeoffs. They're features for the right clients. Emphasize what matters: solved problems, community infrastructure, control over data and code.

The real question isn't "Is Drupal modern enough?" The question is "Does my project need what Drupal offers?"

If the answer is yes, Drupal is your platform. If the answer is no, be honest about the tradeoffs you're making with whatever you choose instead.

The grass isn't always greener on the other side. Sometimes it's just better marketed.

I presented this talk at DrupalCon Vienna 2025. A link to the presentation will be added here shortly.