If you are adding a blog, changelog, or help center to a software product, the first fork in the road is architectural: do you want a CMS that renders your pages for you, or one that hands you content over an API and stays out of your frontend?
That is the entire difference between a traditional CMS and a headless one. Everything else — pricing, plugins, hosting — follows from that choice.
What a traditional CMS does
A traditional (or "coupled") CMS like WordPress bundles three things into one system: the editing interface, the content database, and the rendering layer that turns content into HTML. You pick a theme, editors write posts, and the CMS serves finished pages from its own server.
This model is excellent when the website is the product: a magazine, a restaurant site, a company brochure. You get a working site with zero frontend code, a mature plugin ecosystem, and non-technical editors can change almost anything.
The costs show up when the CMS has to live inside a larger product:
The rendering layer is theirs, not yours. Your blog looks like a theme, not like your app. Matching your design system means fighting the templating layer.
It is a second stack to run. A PHP application with its own database, updates, and security patches, sitting next to your actual product.
Content is stuck in one presentation. The same help article cannot easily feed a web page, an in-app widget, and a search index, because it was authored as a page, not as data.
What a headless CMS does
A headless CMS keeps the editing interface and the content database, and deletes the rendering layer. Content comes out as structured JSON over an API, and your own application renders it with your own components, on your own domain.
Concretely, fetching content looks like calling an SDK from your server code:
const posts = await kookee.blog.list({ limit: 10 });
const article = await kookee.help.getBySlug('getting-started');Your framework — Next.js, Astro, Nuxt, SvelteKit, anything that can fetch JSON — turns that into HTML the same way it renders the rest of your product.
The trade is explicit: you write the frontend once, and in exchange you get complete control over markup, styling, routing, and performance. For a SaaS team that already has a design system and a deployed frontend, that trade is usually a bargain, because the frontend work is a thin layer over components you already have.
The comparison that actually matters
Most "headless vs traditional" comparisons list abstract pros and cons. For a SaaS product, four questions decide it.
Who owns the design?
Traditional: the theme does, and you customize within its limits. Headless: you do, fully. If your blog and help center must look like your product — same navigation, same typography, same dark mode — headless is the only option that gets there without hacks.
Where does the content need to appear?
A traditional CMS produces pages. A headless CMS produces data, and data can go anywhere: your marketing site, an in-app changelog panel, a support chat that answers from your help articles, an RSS feed, a mobile app. If any surface beyond "a website" is on your roadmap, authoring content as structured data pays off immediately.
Who maintains the infrastructure?
A self-hosted traditional CMS means you patch it forever. A hosted headless platform means the vendor runs the editor, the database, the API, and the CDN, and your only artifact is frontend code in your existing repository — deployed, reviewed, and rolled back exactly like the rest of your app.
What happens to SEO?
This is the most common objection to headless — "if content comes from an API, can Google see it?" — and it is a solved problem. With server-side rendering or static generation, the crawler receives ordinary HTML on your URL. The content source is invisible to search engines; the domain serving the HTML is what matters, and with headless that domain is yours. That is strictly better than hosting your blog on a vendor subdomain, where the authority you build accrues to someone else's site.
Where each one wins
Pick a traditional CMS when:
The site is standalone content with no surrounding application.
Nobody on the team writes frontend code, and nobody wants to.
A theme that is 90% right is good enough.
Pick a headless CMS when:
Content lives inside or next to a product with its own frontend.
The same content feeds multiple surfaces — web, in-app, search, feeds.
You want content shipped on your domain, in your design, with your deployment pipeline.
The middle ground: headless with an escape hatch
The honest weakness of headless is day one: before your frontend exists, you have an API and nothing to show. Some platforms close that gap with a hosted portal — a ready-made public site for your feedback board, roadmap, changelog, and help center that works before you have written any code.
Kookee takes that approach: every project gets an optional portal at a public URL immediately, and you replace it surface by surface with your own pages as you build them against the API. The portal gets you live on launch day; the SDK gets you the fully-owned experience later, without migrating content between systems.
Bottom line
For pure content sites, traditional CMSs remain a fine default. For SaaS products, the pattern has clearly settled: content is authored in a dashboard, served as JSON, and rendered by the product's own frontend on the product's own domain. You keep your design system, your SEO accrues to your domain, and your content stays portable data instead of trapped pages.
The practical way to decide: prototype the headless path for one surface. Render your five most recent posts with your existing components. If that takes an afternoon — and with a typed SDK it usually does — you have your answer.