what a cms is
a content management system is a layer between the person who updates the site and the code that runs it. the best-known example is wordpress. others include sanity, contentful, and ghost. all of them provide a login — a dashboard where someone types text, uploads images, and publishes content without writing html.
the cms stores the content in a database. the website reads the database when a page loads and renders what is there. the trade-off is complexity: a cms adds a database, a backend, an admin dashboard, and a security surface that a static site does not have.
when you need one
a cms is the right choice when two things are true at the same time: someone other than the developer needs to update the site, and that happens regularly.
a café adding two new menu items every month. a law firm publishing one article a week. a school updating the events page every term. a tour operator changing seasonal prices. the update is frequent enough to be a real cost if it requires a developer call — and the person making the update does not know html. a cms solves both problems at once.
when you do not need one
a business whose site changes twice a year — a new team member, a revised services page, a changed phone number — does not need a cms. a developer can make those changes in ten minutes. the cms adds a monthly hosting cost, a database to maintain, and a security posture that requires regular updates. for two changes a year, those costs are not justified.
a cms also stops helping when the person updating the site is not confident with technology. a complex wordpress installation — plugins, themes, woocommerce — can be harder for a non-technical user than a shared document sent to the developer. the cms adds overhead without the benefit it was meant to deliver.
wordpress, headless, or nothing
wordpress is the right choice when the site is primarily content — articles, portfolio pieces, event listings — and the client is comfortable with the interface. shallow learning curve, large plugin ecosystem, enough documentation that most questions are answered by a search.
a headless cms (sanity, contentful) is the right choice when the site is a custom next.js application and the content needs to be edited by someone who is not a developer. the frontend stays custom; the editing interface is the headless cms. this is what we use for content-heavy sites where brand control and performance matter.
nothing — a static site or a hardcoded data file — is the right choice when the site changes rarely, the developer is the one making updates anyway, and the budget is better spent elsewhere than on a database and a login screen.