Why Developers Hate Their CMS (And What to Do About It)

There's a running joke in the developer community: being assigned a CMS project is career punishment. As one developer put it during Payload CMS's Y Combinator launch, "To developers, 'content management system' is usually a swear word."

We wanted to understand why. So we read through 30+ threads on Reddit, Hacker News, GitHub Discussions, and DEV Community to find out what developers actually complain about when it comes to their CMS. Not vendor-sponsored surveys. Not paid reviews. Real, unfiltered developer frustrations.

Here's what we found.

---

1. The Pricing Cliff Nobody Warns You About

The most visceral complaints we found were about pricing — specifically, the shock of scaling past a free tier.

"The next tier up is $300 a month, and the following tier shoots up to tens of thousands per month."

This was about Contentful, but the pattern repeats across SaaS CMS platforms. Free tiers lure you in, and by the time your project has real content and real users, you're locked into a pricing structure that feels punitive.

Contentful's April 2025 Changes Made It Worse

Contentful reduced their free plan to just 25 content models, 50 GB/month bandwidth, and 100,000 API calls — with no grandfathering for existing users. Community analysis found their pricing is up to 934% higher than comparable services.

Storyblok followed a similar pattern: their new Growth plan includes fewer assets (2,500) than the old Entry plan (4,000), effectively forcing upgrades.

Per-Seat Pricing Punishes Growth

Beyond usage-based billing, per-seat pricing creates its own problems. It "forces business decisions about whether new employees are worth paying for individual seats" — turning your CMS into a bottleneck for team growth.

One SaaS founder shared that jumping from $39 to $119 because of a single additional user "made customers furious and caused churn and angry emails."

The recurring advice on Reddit? "Don't fall in love with a CMS until you calculate what it'll cost once the team or site grows."

---

2. Complexity for the Sake of Complexity

The second most common complaint is that modern CMS solutions are drastically over-engineered for what most projects actually need.

"Setting up React, GraphQL and surrounding tooling just to assemble text files into templates — it's complexity for the sake of it."

This was from a developer writing about their journey away from the JAMstack, and it resonated deeply. The Hacker News thread generated hundreds of comments, many echoing the sentiment.

The Headless CMS Paradox

Headless CMS was supposed to give developers freedom. Instead, many found themselves rebuilding basic CMS features from scratch — preview systems, page builders, navigation managers — all of which traditional CMS platforms had solved years ago.

As one developer bluntly put it: "Headless CMS is great when you need flexibility. But if your client just wants a blog, you're making their life harder."

WordPress's Gutenberg Disaster

On the other end, WordPress tried to modernize with the Gutenberg block editor. The developer community's response was brutal:

• "I just want to write a blog post, not design a new web page each time"
• "Gutenberg tries to do too many things. So it's too complicated for a non-technical user, and too rigid for a developer"
• "Gutenberg is making web development much harder and more frustrating, projects are taking longer, and it's making me look incompetent and unprofessional to my clients"

An analysis of 340+ developer opinions found the community nearly split 50/50 — but the negative feedback was far more specific and passionate than the positive.

Sanity's Learning Curve

Even well-regarded platforms like Sanity face complexity complaints. Their custom query language (GROQ) becomes a burden at scale: "When queries go from 'simple' to 'nested twelve levels deep with filters, joins, conditionals, projections,' complexity becomes apparent."

One Reddit user summed up the editor experience in five words: "Client opened Sanity Studio and immediately noped out."

---

3. Performance That Degrades Over Time

Performance complaints span the entire CMS spectrum — from traditional to headless to static-site generators.

WordPress: The Frankenstein Platform

Industry audits show 80% of WordPress sites exceed 3-second loading times. Developers describe the platform as "a Frankenstein platform: stitched together with plugins, patches, and outdated architecture" that results in "a bloated backend with too many ways to do the same thing, and none of them working seamlessly."

Contentful API Latency

Even headless CMS platforms aren't immune. One developer documented Contentful API requests taking "nearly 15 seconds compared to 100-200ms locally" in production. Gatsby builds paired with Contentful were reported to jump "from 5-8 minutes to 90+ minutes sporadically."

Strapi's Memory Leaks

Self-hosted solutions have their own issues. Multiple GitHub issues report that "Strapi Admin and API slow down after Strapi runs for about two days" — requiring periodic restarts.

The Static Site Rebuild Tax

Static site generators introduce a different performance problem: "a 'compilation'/'rebuilding' step that gets longer and longer as your site gets bigger, while dynamic sites require no 'rebuilding' step — you just click 'Save' and changes appear immediately."

One developer calculated that fixing a single typo triggered a full rebuild that "eats up a ton of build minutes" — an operational cost that adds up fast.

---

4. The Two-Audience Problem Nobody Solves

Perhaps the most fundamental CMS challenge is serving two very different audiences: developers who build the site and editors who manage the content.

"Not just Git, marketing people also hate headless CMSes because they're hard to use."

This problem plays out in predictable ways:

• A developer builds a site on a headless CMS, then the editor can't figure out how to use it — "Built the site on Payload. Now I handle all content edits myself" — the developer became the content bottleneck
• Contentful "doesn't allow product or marketing teams to manage page design/layout — engineers are still needed to implement page structure and styling"
• Content creators working with headless CMS find that "managing interconnected content pieces can start to feel like you're trapped in Christopher Nolan's Inception"

WordPress's Code Quality Tax

WordPress historically solved this by being editor-friendly, but at a massive developer cost. The codebase has been called "the best example of spaghetti code I've ever seen" and "a database schema that appears to be designed by a beginner."

The practical result: sites "end up juggling 25-40 plugins — each with its own settings, conflicts, and update schedule."

The Reddit Litmus Test

The most practical advice from Reddit was refreshingly simple: "Hand the CMS to an editor before you commit — if they get lost, move on."

---

5. Vendor Lock-in Disguised as Convenience

Trust issues run deep in the CMS community. Developers have been burned — repeatedly.

"SaaS is just vendor lock-in with better branding."

The Directus License Switch

When Directus changed their open-source license, the community response was immediate. Developers started planning to "work on removing references to Directus" and "figure out a strategy for the codebase" — trust destroyed overnight.

WordPress's Governance Crisis

The WordPress ecosystem faced its own trust crisis when Matt Mullenweg took over ACF (Advanced Custom Fields) and renamed it "Secure Custom Fields." The fallout was severe:

• 159 Automattic employees left after Mullenweg invited dissenters to resign
• A core contributor stated: "Mullenweg and Automattic have been toxic for some time"
• Developer Gavin Anderegg wrote: "The WordPress community is in trouble. It's hard to see how to move forward from here"
• One HN thread title captured the sentiment perfectly: "WordPress is a hell I can't escape"

Cloudflare's EmDash Concerns

Even promising newcomers face skepticism. When Cloudflare launched EmDash as a "spiritual successor to WordPress," developers immediately flagged the risk: "Cloudflare's new business model is to find popular OSS projects, create a vibe coded alternative that only runs on Cloudflare's infrastructure."

---

6. The WordPress Security Nightmare

WordPress security has become a category of complaint unto itself — and the numbers are staggering.

• 7,966 new vulnerabilities discovered in the WordPress ecosystem in 2024 — a 34% increase over 2023
• More than half of plugin developers did not patch reported vulnerabilities before disclosure
• The Really Simple Security plugin vulnerability affected more than 4 million WordPress websites
• 827 plugins and themes were reported as abandoned, with 58% permanently removed from the repository
• 500,000+ websites became infected in 2024 alone

In April 2026, a supply chain attack made headlines: someone bought 30 WordPress plugins and planted a backdoor in all of them. As one HN commenter noted, "generic firewall rules, nonce verification, role-based access controls — none of them apply when the malicious code is delivered through the trusted update channel."

The root cause is architectural. WordPress's plugin ecosystem is its greatest strength and its greatest vulnerability: "If a platform allows users to develop and install their own stuff, then the platform can't be secure in the face of user incompetence or inattention."

---

7. Upgrade Terror: When Updates Break Everything

The fear of upgrading is universal across CMS platforms, but Strapi's track record stands out.

Strapi's v4 to v5 Migration

One developer reported that "upgrading the default Strapi code and data migration took approximately 40 hours" for the v4 to v5 transition. The shift from id to documentId "introduced widespread downstream impact across URLs, integrations, background jobs, and external API consumers."

Months later, they were "still dealing with the impacts on a weekly basis."

Strapi's v4 Patch Regressions

Even minor updates caused chaos:

• v4.5.x: Items in draft mode started appearing in GraphQL responses
• v4.6.x: GraphQL queries returned only 10 items for related records
• v4.10.5: Sorting stopped working entirely
• v4.10.6: Long text fields became read-only

"None of these regressions were known in prior release notes."

This led some developers to a blunt conclusion: "Broken and don't work properly when you upgrade them" — a description applied to headless CMS platforms as a category.

---

What Developers Actually Want

After reading through all these complaints, a clear picture emerges of what the ideal CMS looks like. It's not a fantasy — it's a checklist built from thousands of real developer pain points.

The Developer CMS Wishlist

1. Simple but not stupid — Power without unnecessary complexity. Not a static site generator, not a 50-plugin Frankenstein, not a GraphQL-everything architecture
2. Editors don't need developers — Content teams can publish, edit, and manage pages without filing a ticket. Visual preview that actually works
3. Predictable pricing — No usage-based surprise bills. No per-seat punishment for growing teams. Ideally self-hosted so the cost is entirely under your control
4. You own your data — Standard database, exportable content, no proprietary formats. "Own your data, don't store content, don't become a dependency"
5. Stable upgrades — Updates that don't require 40 hours of migration work. "What can I pick that I won't regret in a year?"
6. No plugin casino — Core features built in, not bolted on through a marketplace of varying quality and security
7. Code-first when you need it — Configuration as code, type-safe APIs, version control for schemas. But also a visual admin panel for the team members who prefer GUIs

The Gap in the Market

The frustration is real, and it's widespread. Developers who searched for years for the right CMS consistently reached the same conclusion:

"I've done a similar annual comparison over the last 5 years and have found the perfect CMS doesn't exist."

WordPress is too messy. Headless CMS is too complex. SaaS platforms are too expensive. Static site generators are too limited for non-technical teams. Every option requires significant compromises.

---

A Different Approach

We built Unfold CMS because we kept running into the same problems described in this article. Not as observers — as developers dealing with these frustrations firsthand on client projects.

Instead of choosing between "powerful but complex" and "simple but limiting," we started with a different question: what if the CMS had everything built in, so you didn't need plugins at all?

Here's how Unfold addresses the core pain points:

• Self-hosted, one-time pricing — No monthly fees, no per-seat charges, no usage limits. You host it on your server, you own everything
• Built-in features, not plugins — SEO tools, contact forms, media management, user roles, newsletters, analytics, backups — all included. No marketplace to browse, no third-party code to audit
• Editor-friendly admin panel — A clean, modern interface that content teams can use without training. Visual homepage builder, WYSIWYG editing, scheduled publishing
• Laravel + React under the hood — For developers, it's a standard Laravel application with React frontend. Type-safe, well-documented, and extensible through normal Laravel patterns
• Template system, not themes — Templates control layout and design. Switching templates doesn't break your content. No widget areas to configure, no theme options pages to hunt through

We're not claiming to be the perfect CMS — the developers in those threads made it clear that probably doesn't exist. But we are building what we wished existed every time we got assigned a CMS project.

Explore what Unfold CMS includes or see the pricing — it's transparent, and there are no tiers that cost $300/month.

---

Methodology

This article is based on an analysis of 30+ discussion threads from:

• Reddit: r/webdev, r/nextjs, r/javascript, r/wordpress
• Hacker News: Front-page discussions and "Ask HN" threads
• GitHub: Issue trackers and discussions for Strapi, Payload CMS, Directus
• DEV Community: Long-form comparison articles and experience reports
• G2 and Trustpilot: Verified user reviews

All quotes are reproduced as they appeared in the original threads. We focused on recurring themes that appeared across multiple sources, not isolated complaints.