what is a cms and do you actually need one?

if you've had any conversation with a web developer in the last decade, you've heard the acronym. "do you need a cms?" or "we'll build this on top of a headless cms." if you've nodded along without being sure what that actually means for your business, this post is for you.

the simple explanation

a cms — content management system — is software that lets you edit the content on your website without writing code. instead of opening a file, changing text, and deploying a change through a developer, you log into a dashboard, click on a page, type your update, and hit save.

wordpress is a cms. squarespace is a cms. shopify has cms features built in. so do contentful, sanity, webflow, and dozens of others. they all exist to answer the same question: how do people who aren't developers keep a website up to date?

that's the whole job.

when a cms is worth it

you update your site regularly. if you publish blog posts, update service pricing, swap out team members, add event listings, or change promotional offers more than once or twice a month, a cms pays for itself quickly. the alternative — emailing your developer every time you need to change a word — is expensive, slow, and frustrating for everyone.

multiple people need to make updates. a cms with user roles lets you give a marketing coordinator access to update the blog without giving them the ability to accidentally delete your checkout page. that kind of controlled access is exactly what you'd want in any team environment.

you're running a blog or resource library. this is where cms tools genuinely shine. creating, scheduling, categorizing, and updating articles through a clean interface is vastly better than managing static files manually.

your content changes seasonally. restaurants updating their menu, retailers swapping out featured products, event venues publishing upcoming shows — all of these benefit from the control that a cms provides.

when a cms is overkill

here's the part that doesn't get said often enough: not every website needs a cms.

if your site barely changes. a law firm with a homepage, a practice areas page, an about page, and a contact form might update that content once a year. for a site like that, paying for the complexity and ongoing maintenance of a cms is unnecessary. a well-built static site or a simple platform handles this perfectly.

if you're the only person who touches it. the convenience of a cms is proportional to how often you use it. if you're making two updates a year, the "convenience" of a cms often means dealing with software updates, security patches, and plugin conflicts every time you log in. a simpler setup has fewer moving parts and fewer things that can go wrong.

if the build cost matters. integrating a cms adds time to a project. for small, budget-conscious projects, skipping it in favour of a simple structure makes the work faster and cheaper.

if your content is highly structured. some websites are essentially applications — they pull data from a database, apply complex logic, display results. a cms designed for editorial content doesn't naturally fit those scenarios. here, a proper database is the right tool.

the headless cms option (explained simply)

you might also hear about "headless" cms platforms. ignore the jargon — the concept is simple.

a traditional cms like wordpress handles both the content storage (the database of your posts and pages) and the display (the theme that makes it look like a website). headless cms separates those two things. the cms only stores content; a separate frontend application handles the display.

why would you want that? it lets you use a modern, fast frontend framework (like next.js) while still giving content editors a clean dashboard for updates. you get the performance and flexibility of custom development with the usability of a proper editing interface.

this is increasingly the right answer for growing businesses: fast sites that non-developers can maintain.

how to decide

three questions:

how often do you need to update content? more than once a month → you probably want a cms. less than that → probably don't need one.

who needs access? just you, rarely → keep it simple. multiple people, regularly → cms makes sense.

what's the content structure? articles, pages, products, events → cms. complex application logic → probably a database instead.

there's no universal right answer. what matters is building something that fits how you actually work — not how someone assumes you'll work.

if you're not sure which direction makes sense for your project, talk to us. figuring out the right foundation before building is one of the most valuable conversations you can have.