You Don’t Always Need a CMS: A Decision Framework for Modern Websites

As a remote web agency in Nepal, we build a mix of service websites, marketing sites, and product web apps. One question comes up in almost every project kickoff: “Do we need a CMS?” The honest answer is: not always. Many websites are structurally simple, and adding a CMS creates new operational surfaces: auth, databases, permissions, plugin risk, upgrade work, and editorial training. This post is a practical decision framework, grounded in what’s changing right now: static-first stacks, headless CMS maturity, and AI-assisted editing workflows.

Start with the job the “CMS” is supposed to do

When people say “CMS”, they usually mean one (or more) of these jobs:

A place for non-engineers to update pages without opening a PR.
A structured model for content types (posts, case studies, services, FAQs).
Editorial workflows: drafts, approvals, scheduling, roles, revision history.
Content ops: redirects, internal linking, SEO fields, media management.

You might only need one of these, not the full “traditional CMS bundle”.

The “you don’t need a CMS” profile (most service sites)

You likely don’t need a full CMS if most of these are true:

Content changes are occasional (not daily).
The site is primarily: homepage, services, about, contact, and a blog.
Your content model is shallow (few relationships).
Your team can live with “content changes ship via a release process”.
You care more about predictable HTML output than admin plugins.

In that case, a static-first approach (MDX/Markdown + typed components + a build pipeline) can be a clean fit. If you’re on Next.js, this is usually paired with a strong technical SEO baseline:

“But what about editing?” The real constraint is workflow, not technology

The strongest historical argument for a CMS has been editing experience: “our team can’t edit Markdown and deploy”. That’s still a fair constraint for many teams. But the shape of the constraint is changing:

Many teams are already using Git-based workflows for docs and product marketing.
Visual preview tools exist for static and headless setups.
AI-assisted editing is reducing the “must learn the tooling” barrier.

The practical takeaway: if you can make editing safe and previewable, you can often skip a traditional admin panel.

When you genuinely need a CMS (and should choose one intentionally)

A CMS earns its complexity when the website is part of an operational system with ongoing editorial volume or complex content requirements. You likely do need a CMS if you have:

Multiple editors publishing frequently.
Role-based access control and approvals.
Content scheduling, revisions, and audit trails as non-negotiables.
A highly structured / relational content model:
- products
- locations
- authors
- categories
- knowledge bases
Personalization or content that changes per user/session.
A site that is effectively an application (membership, LMS, gated content).

In these cases, a headless CMS or a “CMS + app framework” approach is often the right tool.

The trap: “We’ll just build a small CMS”

This is where teams get burned. The first version sounds small:

a login screen
an editor
media uploads
publish/unpublish

But the real CMS requirements show up later:

roles and permissions
drafts, previews, approvals
revision history and diffing
schema migrations
image transformations and optimization
link integrity and redirect governance
abuse prevention, rate limits, and content security

If you build a CMS, you’re signing up to maintain an ecosystem of concerns that exist because content is production infrastructure. If your goal is “ship pages fast and safely”, the better pattern is:

use a CMS that already handles the hard parts, or
skip a CMS entirely and invest in a workflow that makes content changes safe

A decision matrix we use in real projects

Here’s a simple set of questions that usually makes the right choice obvious.

1) How often does content change?

Monthly or less: static-first is usually fine.
Weekly with multiple authors: consider a CMS.
Daily editorial cadence: choose a CMS early.

2) Who needs to publish?

Only engineers: MDX/Markdown is clean and reliable.
A small team that can use preview + structured forms: lightweight content tooling works.
Many non-technical editors: CMS.

3) Do you need workflow features?

If you need drafts, approvals, scheduling, and roles, you are describing a CMS.

4) Is your content relational?

If your content depends on relationships and queries (not just pages), you want a CMS-backed model.

5) Is “pixel-perfect output” critical?

Static and MDX-first approaches often win here because you control the HTML output end-to-end.

“CMS” alternatives that work well for agencies

Instead of defaulting to a CMS, choose the smallest tool that satisfies the real requirement:

MDX/Markdown in-repo:
- best for service sites, technical blogs, and docs
- pairs well with strong QA gates and internal linking discipline
A headless CMS:
- best when you need structured content + editorial workflows
An agent-native CMS (emerging category):
- aims to make automation and AI-driven operations first-class
- example: EmDash: Cloudflare’s Agent-Native CMS

Our own example: Lunover moved from WordPress to Markdown (2024)

In 2024, we moved the Lunover site from WordPress to a Markdown/MDX-first setup. Today our “CMS” is essentially:

well-structured Markdown/MDX files in-repo
a small set of reusable components for consistent sections (CTAs, callouts, layouts)
a release workflow (preview, review, deploy)

This works for us because our content behavior matches the “no CMS” profile:

most pages do not change frequently
edits are usually small and intentional (not constant editorial publishing)
everyone on the team can read and work with Markdown
structure is enforced by templates and conventions, not by a dashboard

The key point is not that WordPress is “bad”. It is that once your content is stable and your team can handle Markdown, a CMS can become extra surface area without adding proportional value.

Where this lands for a web agency

For most service websites, the “CMS decision” is really a delivery decision:

Do you want content changes to be governed like releases?
Or do you need a self-serve editorial system with workflow controls?

We build both types of systems, but we choose deliberately because the long-term maintenance surface is different. If you’re planning a new build or a migration and want a recommendation tailored to your team and update cadence: