Cursor Ditched Its CMS — Should Your Enterprise Copy It?

What Cursor Actually Did

Cursor — the company behind the popular AI code editor — runs one of the fastest-growing websites in software. In December 2025, the team moved cursor.com off its headless CMS. Lee Robinson rebuilt the site on raw code and Markdown, and he documented every number. The migration took three days. It cost $260.32 in tokens across 344 agent requests. The commit log shows 67 commits, 43,000 lines added, and 322,000 removed.

Notice the framing carefully. Cursor did not build a new CMS. Instead, it removed one. Content now lives in Markdown files inside a Git repository, edited exactly the way engineers edit code. There is no editor portal, no publishing UI, and no separate content service — just files, pull requests, and deploys.

That headline number traveled fast. A company replaced its content infrastructure for the price of a team dinner, and the debate that followed was loud. Predictably, the build vs buy CMS question landed back on every CIO’s desk. So before your next architecture review treats $260 as a mandate, it helps to separate what actually happened from what it means for you.

Why It Worked for Cursor

The migration succeeded because Cursor’s situation is genuinely unusual. First, every person who touches the website writes code. Robinson is explicit about it — at Cursor, the designers are developers. Therefore, a Git-based workflow adds zero friction, because it is simply how the whole team already works.

Second, the site has exactly one destination. Content flows to cursor.com and nowhere else. As a result, nobody needs to syndicate the same product description to a mobile app, a partner portal, or a sales tool.

Third, Cursor ships content infrequently and governs it lightly. There are no approval chains, no compliance audits, and no role-based permissions beyond what GitHub already provides. Finally, Robinson himself drew the line: “For many teams, the cost of the CMS abstraction is worth it. They need a portal where writers or marketers can log in.”

In other words, the engineer who ran the migration told you plainly that it does not generalize. That caveat matters far more than the $260 headline.

The Build vs Buy CMS Decision Changes at Enterprise Scale

At 500 or more employees, almost none of Cursor’s conditions hold. In fact, the build vs buy CMS decision is rarely about the CMS itself. Instead, it comes down to two questions: who edits your content, and how many places that content has to reach.

First, consider who publishes. Marketers, product managers, legal reviewers, regional teams, and outside agencies all touch an enterprise site. Most of them do not write code, and frankly they should not have to. A Git pull request is a hostile interface for a marketing lead updating a campaign page.

Second, consider where the content goes. Enterprise content almost never has a single destination. The same pricing table, legal disclaimer, or product specification appears on the website, in the mobile app, inside sales-enablement tools, and across regional microsites. Therefore, when one fact changes, it has to change everywhere at once.

Finally, consider language. Cursor’s own list of frustrations even included “internationalization complications.” For a Quebec enterprise, bilingual EN/FR delivery is not a nice-to-have — it is a legal and customer expectation. Markdown files make structured translation harder, not easier. That single requirement rules the Cursor approach out for most organizations we advise.

The Hidden Costs of Building Your Own CMS

The $260 figure is seductive precisely because it hides the recurring costs. Building your own CMS — even a lightweight Markdown one — quietly recreates the work a commercial platform already handles. As the team at Sanity argued in a detailed response, you rarely escape that work; you just relocate it.

Start with structured content. When one fact lives across many pages, you either update every file by hand or build a templating system that pulls from a single canonical source. That templating system is, of course, a CMS feature you now maintain yourself.

Next, consider collaboration. Git resolves code conflicts mechanically, because code diffs line by line. Content conflicts, however, are semantic, so they demand human judgment. Teams end up building elaborate review processes that become bottlenecks — or coordinating edits over Slack to avoid collisions.

Then there is querying. A request like “every article mentioning this product, published after September” is trivial in a CMS. Against flat Markdown files, it needs a query engine you would have to write. Finally, governance simply disappears: no audit trail, no role-based permissions beyond repository access, and no real-time co-editing. For a regulated enterprise, that is not a minor gap — it is a failed audit.

A Build vs Buy CMS Framework for CIOs

So how should a CIO actually decide? In practice, the build vs buy CMS question resolves cleanly once you score your organization honestly against five criteria.

1. Who edits content? If every editor writes code, a code-based workflow is viable. If marketers, legal, or regional teams publish, you need a real editorial interface.
2. How many channels consume it? One website favors simplicity. Multiple apps, sites, and tools favor structured, API-driven content.
3. How often do you publish? Infrequent, batched releases tolerate Git workflows. Daily, time-sensitive publishing does not.
4. What does governance demand? Light governance suits a custom setup. Audit trails, approvals, and role-based access push you toward a platform built for them.
5. How many languages do you serve? A single language is manageable in files. Bilingual or multilingual delivery needs the translation workflows a mature CMS provides.

If your answers land mostly in the first half of each pair, a Cursor-style move may genuinely fit. If they land in the second half — as they do for nearly every enterprise — then ripping out your CMS trades one known cost for a stack of hidden ones. As a result, the honest build vs buy CMS answer is rarely “build.” Far more often, it is “buy something better” or “right-size what you already own.”

What Cursor Got Right — And Worth Stealing

Dismissing the Cursor story outright would be a mistake. The team was right about one real thing: their old setup was heavier than their actual needs. They had spent $56,848 on CDN costs for a CMS-backed site, and they watched content shipping slow down. That is a genuine problem — and many enterprises have the very same one. They simply have not measured it yet.

So steal the discipline, not the tactic. Audit your CMS against what your team genuinely uses. For example, many enterprises run a heavyweight DXP just to publish what is effectively a brochure site, paying for personalization engines, workflow modules, and features nobody touches. That is real waste. However, the fix is right-sizing, not removal.

This is exactly where a composable approach earns its keep. Rather than one monolithic platform — or no platform at all — you choose a content layer matched to your editors, your channels, and your governance, and nothing more. The lesson from Cursor is not “the CMS is dead.” It is “pay only for the abstraction you actually need” — and that nuance is the heart of any honest build vs buy CMS decision.

Make the Build vs Buy CMS Call With Confidence

Most platform decisions go wrong for one reason: every advisor has something to sell. The CMS vendor defends the CMS. The agency that builds custom software defends custom software. As a result, genuinely neutral guidance is rare — and hard to find.

Sengo is built for exactly this call. We are an official implementation partner of eight platforms — Sitecore, Optimizely, Contentful, Storyblok, Kentico, Coveo, Netlify, and ai12z — and we also build custom when that is genuinely the right answer. Because we can deliver either path, we have no incentive to push one over the other. Our team holds two Sitecore Technology MVP awards, and we have delivered enterprise platforms for Cirque du Soleil, iA Financial Group, FTQ, CCQ, and LCI Education. Moreover, we work fully bilingual, in English and French, from Quebec.

When a CIO asks us whether to copy Cursor, we run the build vs buy CMS framework above against the real organization — its editors, its channels, its compliance load, its languages — and then we give a straight answer. Sometimes that answer is “modernize.” Sometimes it is “keep what you have.” It is never “whatever earns us the bigger project.”

Before your next architecture review turns a $260 headline into a strategy, get a neutral read on your own stack.