Across B2B SaaS teams, the same bottleneck keeps surfacing: marketing depends on engineering to make basic website updates. Content management systems promise editorial independence, but most deliver rigid workflows, outdated interfaces and approval processes that slow teams down. The gap between what CMSs promise and what they deliver is driving a wave of migrations.
Legacy platforms like WordPress served their purpose, but growth-stage companies are hitting limits: technical debt accumulates, page speed suffers and content teams remain locked out of their own sites. The shift toward headless architecture addresses these constraints by decoupling content from presentation. But "headless" is a category, not a solution. The market has fractured into competing approaches, and choosing the wrong one means another migration in two years.
I recently sat down with Nathan Garrow, Engineer at Webstacks, to discuss why Sanity has emerged as the dominant choice for B2B SaaS companies navigating this transition. Nathan has led multiple Sanity migrations for enterprise clients and has been a vocal advocate for the platform since before it became a trend. The conversation revealed what separates Sanity from alternatives like Contentful and when each makes sense for different team compositions.
Headless Architecture Shifts Control Back to Marketing Teams
The shift from monolithic to headless architecture changes how marketing teams interact with their websites on a daily basis. In a monolithic system like WordPress, content editing, design and publishing are tightly coupled. Updates that should take minutes often require developer involvement. Campaign launches stall in ticket queues. And when you want to change how something looks or works, you're constrained by what the platform allows.
Headless architecture decouples these layers. Content lives in one system. Presentation lives in another. The two communicate through APIs, which means marketing teams can update content without touching code, and development teams can evolve the frontend without disrupting content workflows.
"With headless, everything is decentralized," Nathan explained. "You can use whichever headless CMS with whichever framework you prefer, and it adds a lot more flexibility and customization because you're not tied to what one company's vision of a tech stack should be."
In practice, this means the website can evolve alongside business needs rather than requiring a full rebuild every time requirements change. But headless is a category, not a single solution. The market has split into two distinct camps, and understanding this split is crucial for making the right choice.
The Headless CMS Market Has Split Into Two Camps
As marketing teams scale, their CMS needs start to diverge. A ten-person startup launching its first site has different requirements than a 200-person company managing multiple product lines, regional teams and complex approval workflows. The headless CMS market has split along this line.
Structured Platforms Prioritize Speed and Guardrails
The first camp includes platforms like Contentful, Dato and Storyblok. These provide structured interfaces where teams build schemas within the platform itself. For marketing teams without dedicated engineering support, this approach offers speed: you can be up and running in days with consistent guardrails in place.
The tradeoff is flexibility. When your workflow changes or you need custom functionality, you work within the platform's constraints. The interface is what the vendor designed, not what your team needs.
Schema-as-Code Platforms Prioritize Flexibility and Customization
The second camp, where Sanity sits, takes a schema-as-code approach. Rather than configuring content models through a visual interface, developers define schemas in code. This creates more upfront work but unlocks deep customization.
"With something like Sanity and Builder, those schema-as-code models, you build out the schema, and you can build the CMS itself," Nathan explained.
This means marketing teams can shape the editing experience to match how they actually work. A content editor sees only what's relevant to their role. A campaign manager gets a dashboard optimized for launch workflows. Permissions, views and publishing flows adapt to organizational complexity rather than forcing teams to adapt to the platform.
Choosing Between the Two Camps
For growth-stage companies expecting their processes to evolve, schema-as-code flexibility becomes a strategic advantage. For lean teams that need to move fast with minimal technical investment, structured platforms often make more sense. Understanding where your team sits today, and where it's headed, determines which approach fits.
Sanity's Customization Model Adapts to Any Workflow
Sanity's growth in the B2B SaaS market stems from its ability to adapt to any workflow. Unlike platforms that impose their own interface patterns, Sanity allows teams to modify virtually every aspect of the editing experience.
Interface Customization Goes Beyond Configuration
Most CMSs offer configuration options: show this field, hide that one, rearrange the sidebar. Sanity goes further by allowing teams to replace core interface elements entirely.
Nathan shared an example: his team replaced the default publish button with a preview function in one Sanity instance. The actual publish action moved to a side menu alongside additional options like sharing and clipboard copying. This small customization matched exactly how that team preferred to work.
"You're not going to get that sort of customization on something like Contentful or Dato," he added. "The ability to customize the UI is one of the things that makes Sanity so special."
The Plugin Ecosystem Accelerates Implementation
This level of control extends beyond interface tweaks. Dashboard views can be reorganized. Content storage structures can be redesigned. The growing Sanity plugin ecosystem, driven by the platform's increasing adoption, provides pre-built solutions for common needs.
This ecosystem momentum creates a flywheel: more users attract more plugin developers, which in turn attracts more users. Teams benefit from solutions built by others facing similar challenges, reducing the custom development required for each implementation.
Successful Migrations Start with Workflow Documentation
The most successful CMS migrations start with workflow documentation, not feature comparisons. Teams that understand how they currently use their CMS can translate those patterns into the new system rather than forcing users to learn entirely new processes.
Document How Teams Actually Use the CMS Today
Migration planning typically focuses on content: what pages exist, what assets need to move, what metadata needs to be preserved. But the more important question is behavioral: how do people actually work in the current system?
"The most successful migrations we've had are when stakeholders document their workflows around how they use the CMS," Nathan explained. "Not just, 'I'm a blog editor, and I would like the blog to be front and center.' But explaining how they are using the CMS elsewhere. That guides us on the migration path we need to take."
Translate Existing Workflows Into the New System
This workflow-first approach prevents a common migration failure: building technically excellent systems that nobody wants to use. When teams skip workflow documentation, they often discover mismatches between the new CMS and actual user needs weeks or months after launch.
"Our job isn't to take them out of WordPress, throw them into a brand new CMS they've never used before, and say good luck," Nathan said. "It's to figure out how we can make their workflow better."
The goal isn't to replicate the old system exactly. It's to understand which workflows matter, which create friction and where the new platform can improve on what existed before.
Implementation Templates Compress Migration Timelines
Speed to launch depends heavily on starting points. Teams building Sanity implementations from scratch face weeks of foundational work before they can address client-specific requirements. Agencies with refined templates compress this timeline dramatically.
Standardized Foundations Enable Faster Customization
Every Sanity implementation requires certain foundational elements: authentication, media handling, content modeling patterns, preview functionality. Building these from scratch for each project wastes time that could go toward client-specific requirements.
"We have an internal template, and each project that template gets better and better," Nathan said. "We're able to go from creating an empty repository to having a functioning CMS with a lot of the basic building blocks in a matter of days. It used to take a couple weeks to get to the point where we have our template set up."
Time Savings Compound Across the Team
This time savings compounds across projects. Developers spend less time on foundational setup and more time on custom requirements. Project managers become subject matter experts in explaining consistent patterns. The entire team moves faster because everyone works from the same baseline.
"That time can go directly into building out the requirements that the specific client needs," Nathan added. "We don't have to worry about reinventing the wheel each time. We can actually focus on why the client is choosing Sanity, and that's customization."
Sanity Requires Engineering Investment to Realize Its Potential
Sanity's flexibility comes with a tradeoff: it requires development resources to unlock its potential. For some organizations, particularly early-stage startups, this investment doesn't make sense.
When Structured Alternatives Make More Sense
Companies with small teams often face a resource allocation decision. Engineering hours spent building out a CMS are hours not spent on the core product. For these teams, structured platforms offer a faster path to a functional website.
"For some companies, especially very early startups that don't have the largest development team and their development team is working on their product, you might not have the resources to put into building out a CMS," Nathan explained. "That's where something like Contentful, or Dato, or Storyblok shines. I can give you a little direction and have you creating a schema in Contentful within an hour."
The Long-Term Calculus Favors Flexibility
The decision framework is straightforward in the short term: teams with development resources who need long-term flexibility should choose Sanity; teams that need to move fast without dedicated engineering support should consider structured alternatives.
But the long-term calculus often favors flexibility. Companies grow. Requirements evolve. A CMS that can't adapt forces another migration.
"If a marketing team needs a CMS and they don't have the engineering team, they can go with something that's a lot more structured," Nathan said. "But in the long term, a solution like Sanity will win out. Because as companies grow, requirements grow, and if you don't have a CMS that can grow with it, then you're looking at a migration down the line."
Sanity's Architecture Supports Multi-Year Scalability
CMS decisions have multi-year implications. The platform that works for a 20-person startup may not serve a 200-person enterprise. Sanity's architecture is designed for this growth trajectory.
Flexibility Means Freedom from Vendor Roadmaps
Most CMS platforms evolve according to vendor priorities. Features that matter to your team may never materialize. Workflows that work today may break with the next update. Companies become dependent on decisions made by people who don't understand their specific needs.
Sanity's schema-as-code approach inverts this dynamic. Because teams define their own content models and interface patterns, they control their own roadmap.
"It can be whatever the company needs it to be," Nathan said. "It can be modified, customized, and self-hosted to meet security requirements."
Self-Hosting Addresses Enterprise Security Requirements
Self-hosting capability matters for organizations with strict security requirements. Regulated industries, companies handling sensitive data and enterprises with specific compliance needs often can't use vendor-hosted solutions. Sanity's self-hosting option removes this barrier.
The combination of flexibility and control creates a platform that scales alongside business growth rather than constraining it.
Handoff Planning Determines Long-Term Success
Successful Sanity implementations include a plan for ongoing ownership. The platform's flexibility means internal teams need to understand both the content editing interface and the underlying architecture to maintain and extend the system over time.
Content Editors Should Operate Independently
The goal of any CMS implementation is editorial independence: content teams should be able to do their jobs without waiting on engineering. A well-implemented Sanity instance achieves this for day-to-day operations.
"We try to hand it off in a place where it doesn't need an engineer to really touch it unless they want to start adding new components," Nathan explained. "The CMS itself, we like to have in a spot where it hits all the boxes for the client."
Engineering Involvement Remains Necessary for Extension
While content editors can operate independently, extending the system requires technical involvement. Adding new component types, modifying workflows or integrating with additional tools all require engineering work.
This handoff model works best when client teams have dedicated engineering resources for the marketing site. During implementation, Webstacks works alongside client engineers so they learn the system and can maintain it independently.
"During the process, we're able to work alongside client engineers," Nathan said. "They're able to learn the CMS if they're not already familiar with Sanity."
Work with Webstacks to Implement Sanity
The gap between Sanity's potential and realized value is implementation expertise. Teams that try to build from scratch face months of foundational work. Teams that partner with experienced implementers launch in weeks with systems tailored to their workflows.
If you're evaluating CMS options for your next website project, consider both platform capabilities and implementation resources. Ask potential partners about their template approach and how they'll translate your existing workflows into the new system.
At Webstacks, we've refined Sanity implementation across dozens of B2B SaaS clients. Our template approach compresses timelines while delivering customized systems that match how your team actually works. Talk with Webstacks to discuss how Sanity can power your next website migration.
