CMS apps explained: what marketing and product teams actually get

By Nayan Kyada · · 7 min read

Part of The Sanity + Next.js Guide

If you're researching CMS apps for your team and finding yourself buried in feature matrices and pricing pages, this is the post to read first. Before you evaluate any specific tool, it helps to understand what a modern CMS actually does — and where the real differences between products show up in daily editing work.

What CMS apps actually do

A content management system is software that lets non-developers create, edit, and publish content without touching code. That's the old definition. Modern CMS apps have expanded well beyond that: they now manage content structure, enforce editorial workflows, deliver content to multiple channels simultaneously, and connect to the rest of your marketing stack.

The shift matters because the original generation of CMS tools — WordPress, Drupal, older Joomla installations — bundled the editing interface, the content database, and the website display layer into one product. That worked fine when a website was the only destination for your content. It breaks down the moment you want the same product description to appear on a website, a mobile app, a digital kiosk, and an email campaign without copying and pasting between systems.

Modern CMS apps split those concerns apart, or at least give you more control over how they connect.

Content models: the layer most buyers overlook

Before your editors ever type a word, someone has to define what kinds of content exist in the system and what fields each type has. This is called the content model, and it's the most consequential architectural decision in any CMS project.

A content model for a software company might include document types like Blog Post, Case Study, Product Page, Team Member, and Pricing Tier. Each type has fields: a Blog Post has a title, a publication date, a main image, an author reference, and a body. A Pricing Tier has a name, a monthly price, a list of features, and a boolean for whether it's the recommended option.

Why does this matter to you as a buyer? Because a poorly designed content model creates editorial friction that compounds over years. If your Case Studies are modeled as a long unstructured text blob rather than discrete fields (client name, industry, outcome metric, quote), your team will fight the CMS every time they try to filter, sort, or reuse that content elsewhere. A good CMS app gives developers the tools to build a tight content model; a good developer actually uses them.

Different CMS apps approach content modeling differently. Some give you a fixed set of field types and a visual schema builder. Others — Sanity is the clearest example here — define schemas entirely in code, which means the model lives in version control, can be reviewed like any other change, and can be tested before deployment.

The editing interface

This is what most buyers focus on, and reasonably so — your marketing team will live in it every day. Modern CMS apps generally offer:

Structured fields. Dropdowns, date pickers, image uploaders, reference selectors. Editors fill in discrete fields rather than formatting everything inside a single rich-text box.

Rich text with portable structure. When you do need long-form text, good CMS apps represent it as structured data rather than raw HTML. This means you can render the same content differently on a website versus a mobile app, and custom components — a callout block, an embedded video, a product card — can be inserted inline without embedding fragile markup.

Visual previews. Most modern CMS apps support some form of live preview, where editors can see what a page will look like before publishing. The implementation quality varies significantly: some are full visual editing with click-to-edit overlays; others are just an iframe that refreshes when you save a draft.

Asset management. Images, documents, and video are usually managed inside the CMS or via a connected digital asset management tool. Decent CMS apps handle focal-point cropping (so an image looks right when displayed at multiple aspect ratios) and serve optimised formats automatically.

Publishing workflows

A basic CMS has two states: draft and published. Most teams outgrow that within months.

Marketing teams typically need: draft → internal review → legal or brand approval → scheduled publish → live. Product teams doing feature launches often need content staged and ready to go live the moment a deploy ships.

Look for CMS apps that support:

  • Role-based permissions. Editors create; senior editors approve; admins publish. A junior contractor should not be able to push to production.
  • Scheduled publishing. Set a date and time; the CMS handles the rest. Non-negotiable for any team running campaigns.
  • Content versioning. The ability to see what a document looked like three weeks ago and restore it if needed.
  • Draft preview URLs. Shareable links that show a draft to a stakeholder without publishing it publicly.

Not every CMS app does all of these well. Some charge extra for workflow features. Some implement them only at the enterprise tier. It's worth pressure-testing these specifically during any evaluation.

Integrations with the rest of your stack

CMS apps don't live in isolation. The relevant integration categories for most marketing and product teams:

Search. If your site has more than a few dozen pages, you'll want full-text search. Most headless CMS apps integrate with Algolia or a similar index service, syncing content automatically when you publish.

Analytics and personalisation. Some CMS apps have first-party analytics add-ons; most rely on you connecting Google Analytics, Segment, or similar via your frontend.

E-commerce. If product content needs to stay in sync with a Shopify or similar catalogue, check whether the CMS has a native connector or whether that sync is a custom build.

Email and marketing automation. Content reuse across CMS and email campaigns is often messier than vendors suggest. The honest answer is: most teams still copy and paste, unless they invest in a deliberate integration.

Deployment triggers. Headless CMS apps typically fire a webhook when content is published, which triggers a rebuild or cache invalidation on the website. This is nearly invisible when it works and very confusing when it doesn't — worth asking any developer you're evaluating how they handle and monitor it.

Choosing the right class of CMS app

The broad categories you'll encounter:

TypeBest forWatch out for
Traditional (WordPress, Drupal)Simple sites, tight budgets, familiar editorsCoupling to one frontend, plugin maintenance debt
Hosted headless (Sanity, Contentful, Storyblok)Multi-channel, design-system-driven sitesPer-seat costs, API call limits at scale
Self-hosted headless (Payload, Strapi)Teams that want full data controlInfrastructure and security burden on your team
Visual / page-builder (Webflow, Builder.io)Marketing teams who need layout controlCan create brittle designs outside a design system

The right answer depends on your team's technical capacity, how many channels you publish to, and how much editorial flexibility you actually need versus how much you think you need. Most marketing sites do not require the most sophisticated option. Most fast-growing product companies hit the limits of the simplest option faster than they expect.

When you're ready to evaluate specific tools or talk to a developer about implementation, the content model conversation is the one worth having first.