Do we build, or do we buy? It’s the question that frames most enterprise CMS conversations, and it’s been framing them the same way for years.

At rtCamp, we’re on the other side of these conversations. We build CMS/DXP infrastructure on WordPress for enterprises, which means by the time a team comes to us, they’ve usually already run some version of a build vs. buy analysis. We’ve seen enough of them to notice that the “build vs. buy” frame itself is the problem.

This article is about what this frame misses, what it costs enterprises that stick with it, and what makes TCO analysis more comprehensive.

TL;DR

The standard “build vs buy” frame

As the name suggests, the build vs. buy debate assumes two options.

The first is building a custom CMS. In theory, it’s the most powerful choice. You get exactly what you want, built around your workflows, your content model, and integration requirements. No vendor is telling you what’s possible. The catch is equally plain: building something production-ready at enterprise scale is neither fast nor cheap. And finding a team that can execute it is a challenge on its own. 

The second is buying off the shelf. The market has no shortage of options: Kentico, Sitecore, Arc XP, AEM, and dozens of others our team has encountered in client conversations in the past year alone. Some are more flexible, some less. But the tradeoff is consistent: you’re vendor-locked from the moment you sign.

build vs buy decision graph

Build always wins in the long run, yet getting to that crossover point takes a lot of time.  

Weigh the pros and cons, pick the lesser evil, make the call. Feels like a complete decision, right? Not so much. 

It’s not really about “buy or build”

Take “buy” first. It sounds like a one-time decision with a known price. Just sign the contract, get the platform, move on. But enterprise software doesn’t work that way. What you’re actually committing to is recurring costs. These include license renewals, upgrade cycles, bundled modules your team didn’t ask for and can’t opt out of, and features you’ll eventually need that aren’t included and aren’t free, as well.

“Build” has its own version of the same problem, just structured differently. There are two costs: building it and integrating/maintaining it afterwards. The first is significant as getting something production-ready at enterprise scale takes longer and costs more than most teams anticipate. The second is permanent. Because it’s your system, your team is the only party that knows how to keep it running. You’re not vendor-locked, but team-locked.

In the first case, you bought software, and you’re still paying recurring costs just to keep the lights on. In the second case, you built it, and you’re still building and maintaining it indefinitely.

This means the real question was never build vs. buy, but about what you end up owning.

The reframe: Owned vs licensed decision

The build vs. buy question asks how you acquire the platform. Yet, the more useful one is, what do you control once you’re running it? 

Through that lens, custom CMS is the only option that gives you full control. But that makes sense for maybe 1 in 10 enterprise teams, the ones where CMS infrastructure is the business, and handing it to a vendor isn’t an option. For everyone else, the instinct is to buy — go the “licensed” route. And that’s where Platform Tax introduces itself. 

The Platform Tax: What you’re paying for vs what you’re using

There’s one thing that connects every client that’s come to us after years on Kentico, Adobe Experience Manager, Sitecore or another enterprise CMS: they were using 40-50% of what they were paying for, at best.

We call it the Platform Tax. It’s the gap between what a vendor charges you for and what your team uses. We’re talking fancy modules you don’t need or upgrading for new versions even when your CMS worked just fine. Basically, you’re running a fraction of a platform you’re paying six figures for.

The platform tax

Most teams pay for 100% of a CMS but use 30-40% of it. The rest is Platform Tax. 

Take Kentico. When it released Xperience 26, it broke backward compatibility with version 13. Teams that had budgeted for an upgrade found themselves facing something closer to a full migration with a different architecture, different codebase, and significant reimplementation work.

AEM works the same way. The annual license alone runs $80K–$200K. But now that AEM 6.5 reaches end of support in 2027, Adobe is pushing users to move to AEM as a Cloud Service, which is, again, a full migration. On top of the license and maintenance costs, you’re paying just to stay on Adobe. 

Why most five-year TCO models are missing half the number

Meanwhile, most five-year TCO models only include two things: license and implementation cost. What doesn’t make it into the spreadsheet?  

Kentico’s example makes this concrete. A team running a standard TCO model would have budgeted for license renewals. What they didn’t include is a migration cost that came with a near-full reimplementation triggered by Xperience by Kentico. 

This is what makes the build vs. buy frame expensive. It sends teams into a procurement decision with an incomplete cost model, which, in turn, produces the wrong answer.

Build vs buy CMS — or consider a third option?

With any licensed platform, the Platform Tax is a given. No amount of contract negotiation changes the underlying model. What does change it is moving to a different category entirely, one the build vs. buy frame doesn’t account for.

Third option: CMS infrastructure you own, built on open-source platform

This is when you’re not starting from scratch, and you’re not renting access from a vendor. You’re adapting a proven infrastructure to your workflows.

Open-source CMS platforms like WordPress and Drupal work this way. Drupal is a legitimate option. If you’re evaluating it, we have a dedicated Drupal vs WordPress for Enterprise comparison worth reading. But WordPress is what we build on for a reason, and it’s what we can speak to with confidence. It powers Al Jazeera, Penske Media, the majority of the top 1,000 media sites globally — and 43% of the web, overall.    

The cost model of open-source CMS like WordPress is fundamentally different. There’s no per-seat pricing or upgrade cycles the vendor’s roadmap dictates. You invest in engineering WordPress infrastructure (in what you actually build and use) and that’s where it stops.  

Note: For enterprises that need more than a CMS (personalization, commerce, analytics, omnichannel delivery), WordPress can serve as the open foundation of a composable DXP. Unlike monolithic platforms that bundle everything whether you need it or not, you build what you need on infrastructure you own.

Owned WordPress infrastructure is also what makes AI capabilities possible without paying six figures for Sitecore Personalize or Adobe Target: content that surfaces in AI-generated answers, personalization you own, and editorial workflows that move at the speed your teams need.

licensed dxp vs open source (WordPress) and custom CMS

It all sounds good on paper, so why hasn’t WordPress been a standard option in the build vs. buy conversation? Partly because it’s not software you buy and deploy out of the box. It’s still infrastructure that needs to be engineered, which makes it easy to bracket with custom builds and dismiss for the same reasons. 

And even when teams do consider it seriously, migration at enterprise scale sounds like a project nobody wants to own. In practice, it’s a different story. We’ve migrated 300+ companies off AEM, Sitecore, Kentico, Drupal, and others to WordPress. Videojet, a Danaher company, had one of the more complex environments we’ve worked with: 28 sites, 12,000 pages in 22 languages. They moved off AEM CQ5 with zero marketing downtime. The scale that makes migration feel daunting is exactly the scale we’re built for.

TL;DR

The standard “build vs buy” frame  

It’s not really about “buy or build” 

The reframe: Owned vs licensed decision 

The Platform Tax: What you're paying for vs what you're using

Why most five-year TCO models are missing half the number

Build vs buy CMS — or consider a third option? 

Third option: CMS infrastructure you own, built on open-source platform 

On this page

Migration, WordPress

Credits

Aviral

Aviral Mittal

Author

Aviral Mittal

Author

Aviral Mittal is the Chief Marketing Officer at rtCamp, where he established and leads the marketing function, building and growing a team of 20+ specialists across content, SEO, design, and growth…

VIEW PROFILE

Related articles

Comments

Leave a Reply Cancel reply

Name*

Email*

Comment*

Submit

Δ