What Cursor vs. Sanity Tells Us About Custom Software
Two articles crossed my desk this week that crystallize a tension every business leader should be thinking about.
Lee Robinson, who works at Cursor, wrote about migrating cursor.com from a headless CMS to raw markdown files and code. He spent $260 in AI tokens and three days to do what he estimated would have taken weeks. The site is faster, cheaper to run, and his team can now just ask an AI agent to make changes instead of clicking through CMS interfaces.
Then Sanity, the CMS company Cursor migrated away from, published a thoughtful rebuttal. Their argument: yes, you can rip out a CMS in a weekend, but what happens next? All the problems that CMS solved will slowly creep back in. Content approval workflows. Preview environments. Multi-language support. Version tracking. You will end up building your own CMS whether you intended to or not.
Both sides make excellent points. And both are right in ways that matter for how you should think about software investment.
The Cursor Argument: Abstraction Layers Are Now Expensive
Lee's core insight is worth repeating: with AI and coding agents, the cost of an abstraction has never been higher.
When your team could simply type "@cursor add a new section to the homepage" and have it done in seconds, but instead has to log into a CMS, navigate menus, find the right content type, and manually configure settings, something has gone wrong. The abstraction layer that was supposed to make things easier is now making them harder.
This is a real phenomenon. CMS platforms were built for a world where business users needed friendly interfaces because they could not interact with code directly. The GUI was the point. But now that AI can serve as an intermediary between human intent and code, that GUI becomes a bottleneck rather than an enabler.
The numbers from Cursor's migration are striking. They removed 322,000 lines of code and replaced them with 43,000. Build times got 2x faster. They stopped paying $56,000 in CDN costs. And most importantly, their team can now ship changes to the website and product in the same pull request.
The Sanity Argument: You Cannot Delete the Problem
Here is where the counterargument gets interesting.
Sanity's response acknowledges that Lee's frustrations are valid. Preview workflows are clunky. Authentication fragmentation is annoying. The complexity overhead of headless CMS integrations is real.
But they point out something important: look at what Lee actually built to replace the CMS.
He built an asset management GUI with "3-4 prompts." He set up user management through GitHub permissions. He has version control through git. Content modeling through markdown frontmatter. Localization tooling.
These are CMS features, just distributed across different systems.
The features exist because the problems are real. You can delete the CMS, but you cannot delete the need to manage assets, control who can publish what, track changes, and structure content for reuse.
Give it six months, Sanity argues. Someone will need to schedule a post. Someone will need to preview on mobile. Someone will need approval workflows. The "simple" system will accrete complexity because content management is complex.
Where This Leaves Us: The Build vs. Buy Question Just Got Harder
I have been preaching the gospel of custom software for years. The core argument: AI-empowered development has made building custom software faster and cheaper than ever. You can create solutions tailored exactly to your business needs rather than paying for SaaS platforms that cover 80% of use cases and leave you working around the other 20%.
The Cursor migration is evidence for this view. Lee rebuilt their entire website architecture in three days for $260 in tokens. That is remarkable velocity.
But the Sanity response gives me pause. Not because I think they are wrong about CMSs specifically, but because they articulate a principle that applies broadly: when you build your own version of something, you inherit responsibility for every problem that thing was designed to solve.
The Real Question: What Are You Actually Building?
Here is where I land on this.
The Cursor vs. Sanity debate is not really about CMSs. It is about where to draw the line between commodity infrastructure and differentiated capability.
Some software you should rent. Systems of record, commodity functions, solved problems. Your content repository probably needs to exist somewhere stable and queryable. Your authentication system should probably be Auth0 or Clerk rather than something you built yourself. Your payment processing should be Stripe. These are solved problems where the abstraction layer still provides more value than it costs.
Other software you should build. The unique processes that give you competitive advantage. The integrations between systems that are specific to how your business operates. The custom tools that multiply force because they are designed exactly for your workflows.
The mistake is treating this as binary. It is not "build everything" or "buy everything." It is about identifying where custom software creates leverage and where commodity solutions are good enough.
What Changes in the Agent Age
AI agents change the equation in a specific way: they reduce the cost of building, but they do not reduce the cost of maintaining.
Lee could rebuild Cursor's website architecture in three days because AI agents could write scripts, migrate content, and generate code at remarkable speed. But maintaining that architecture over years requires ongoing attention to all the edge cases that will emerge.
The Sanity argument is essentially: yes, agents let you build faster, but faster building does not mean you want to take on every maintenance burden. Do you want to be in the business of maintaining content approval workflows? Or do you want to focus your engineering capacity on things that actually differentiate your product?
This is where the "build your own CMS" cautionary tale becomes instructive. CMSs are not exciting. They are infrastructure. The features they provide (versioning, workflows, permissions, preview environments) are necessary but not differentiating. Nobody chooses your product because you have a great internal content management system.
The Force Multiplication Framework
Here is how I am thinking about this for the businesses we work with.
Your systems of record should probably stay as off-the-shelf or commoditized solutions. Your CRM, your content repository, your financial systems, your HR platform. These are solved problems. Keep them simple. Maybe move toward open source versions where it makes sense. Maybe simplify how you interact with them. But they need to exist because the data repository is valuable.
Your force multipliers are where custom software creates disproportionate value. These are the places where connecting systems together, or applying your unique data, or building specific workflows creates outcomes that generic software cannot provide.
Example: A company has broad industry data that nobody else has access to. What if they built a custom intelligence engine that uses that data to power recommendations? That is differentiated capability. That is worth building.
Example: A firm has developed proprietary client assessment methodology. Building custom software that embeds that methodology creates competitive advantage that no off-the-shelf CRM can provide.
Example: A business has unique approval workflows that span multiple departments in ways that no SaaS tool handles well. Custom integration software that connects existing systems together in exactly the right way creates efficiency that compounds.
The pattern: keep your systems of record, but build the connections and intelligence layers that multiply their value in ways specific to your business.
The Practical Takeaway
When you are evaluating whether to build or buy, ask these questions:
Is this a solved problem? If thousands of companies have the same need and good solutions exist, lean toward buying. Do not rebuild authentication, payment processing, or basic content storage.
Does custom software here create competitive differentiation? If the software would embed your unique IP, connect systems in ways specific to your workflow, or enable capabilities that give you advantages competitors cannot replicate, lean toward building.
What is the maintenance burden, and do you want it? Faster building does not mean zero maintenance. Consider whether the ongoing responsibility of maintaining custom software is worth the benefit.
Can AI agents help you interact with existing systems differently? Sometimes the answer is not "replace the CMS" but "build an AI layer that lets your team interact with the CMS differently." The system of record stays, but the interface changes.
The Window Is Open
Here is what excites me about this moment: the tools for building custom software have never been better, and the opportunity to create differentiated capability has never been clearer.
The companies winning in competitive markets are the ones that recognize software as a strategic asset, not just a cost center. They keep their systems of record stable and boring. They build custom solutions where software creates leverage specific to their business.
The Cursor vs. Sanity debate is a healthy one because it forces us to think carefully about where to draw lines. Both "build everything custom" and "buy all SaaS" are wrong answers. The right answer is thoughtful deployment of each approach where it creates the most value.
AI agents have lowered the cost of building. That does not mean you should build everything. It means you can now afford to build the things that actually matter.
At FM, we help businesses identify where custom software creates leverage and where commodity solutions are good enough. If you are wondering whether to build or buy for a specific business challenge, let's talk.
