Contributing to Drupal's Future At Drupal Pivot

Last week I flew to Belgium for Drupal Pivot, an unconference for agency leaders, organized by the Drupal Association. Over sixty of us gathered in Ghent for two days of raw conversation about where Drupal needs to go. No polished presentations or vendor pitches. Just business owners trying to figure out what happens next.

The event operated on Chatham House Rules, which means I can share what I learned but not attribute specific ideas to specific people. What follows is my synthesis of themes that emerged, filtered through my own perspective. Other attendees will have their own takeaways.

The Business Model Problem

The most intense discussions centered on how AI is challenging traditional agency economics. Some clients are expecting lower prices because "AI makes everything cheaper," even when actual costs tell a different story. Developers using AI should be able to build complex Drupal sites dramatically faster, but advanced models burn through expensive tokens quickly, and quality still requires senior-level review. The math doesn't simplify the way some assume it will.

Nobody has solved this yet. The most honest framing I heard was: treat clients as partners in figuring it out, because we're all learning what AI actually costs in practice. Various experiments are underway with value-based pricing, fixed price with variable scope, and subscription models. No consensus has emerged.

This reminds me of the "outsource everything" wave from years ago. We still feel downward price pressure from that movement, too. What we learned: cheap and fast often means expensive and slow once you factor in the rework. The clients who came to us after failed projects understood that. I suspect the same pattern will play out with projects that exclusively focus on lowering costs with AI-generated vibe code.

The Rise of Disposable Code

Some agencies are leaning hard into "disposable code". If AI lets you build a complete website in a week, why chase perfection? If the client needs something different next month, just rebuild it. Move fast, and don't look back.

This may be a legitimate strategy for certain markets. I'm not dismissing it.

But it's not ours.

Tag1 builds things that last and work well. The disposable approach may work when what you're building is truly standalone, when nothing else depends on it, when institutional knowledge doesn't live in how it's configured. It quickly breaks down when your system is load-bearing infrastructure, when other systems integrate with it. When the cost of "just rebuild it" includes weeks of re-integration, testing, and rediscovering why the previous version made certain decisions.

Our clients tend to be in that second category. We rescue failed Drupal projects as often as we build greenfield sites. We've seen what breaks when speed of delivery and lower hourly rates are prioritized over a maintainable architecture. Prototypes should be disposable. Production infrastructure should not.

Repositioning Drupal

A major debate emerged about Drupal's target audience. Should we keep pitching to marketers, or pivot toward technical decision-makers like CTOs and enterprise architects?

The argument for the shift: marketing websites are increasingly commoditized. AI can vibe-code a marketing microsite. The real stability is in business-critical systems — intranets, support platforms, e-learning, complex integrations. These clients are less likely to cut budgets because the systems are core infrastructure, not discretionary marketing spend. And technical buyers naturally appreciate Drupal's depth.

The emerging consensus wasn't to abandon marketers entirely, but to stop leading with marketing use cases. Lead with business-critical applications where Drupal excels. Let marketing capabilities be a supporting benefit rather than the headline.

This validates where Tag1 has always focused. We do performance engineering and infrastructure for systems that can't go down. That positioning looks stronger, not weaker, as AI commoditizes the simpler work.

Digital Sovereignty

With shifting geopolitics and growing concerns about U.S. cloud dependency, digital sovereignty came up repeatedly as an opportunity for Drupal, especially in Europe. Organizations worry about routing data through U.S. jurisdiction. Compliance requirements are tightening.

Drupal's story here is strong: it is open source, it can run on-premises, there are no hidden dependencies on proprietary services, and you have full control over your data. This matters beyond just regulatory compliance. It's about organizations maintaining genuine ownership of their infrastructure and the ability to switch providers without rebuilding from scratch. And it's about being able to invest in your future.

Open source has always been about working together to make things better. When you build on Drupal, you're not just licensing software — you're joining an ecosystem where improvements flow back to everyone. That shared investment model is the opposite of vendor lock-in, and it's increasingly valuable as organizations think harder about long-term technology risk.

Looking Forward

Drupal has survived 25 years by adapting and leading. The fact that agency leaders are gathering to honestly confront challenges rather than pretending everything is fine gives me confidence we'll figure this out too.

There are big questions to consider:

• Will quality continue to command a premium when AI makes mediocre work cheaper and faster?
• How do we price work when the hours become unpredictable?
• What does junior developer training look like when AI changes the learning curve?

Nobody has definitive answers yet. But asking the questions openly, together, is how the Drupal community has always navigated change. I'm glad to be part of that conversation.

Image by Joris Vercammen from flickr