CMS (Content Management System)

Traditional vs modern CMS approaches

Traditional CMSs like WordPress bundle content management, hosting, themes, plugins, and database management into one platform. This all-in-one approach creates familiarity but also complexity—you manage servers, security patches, plugin updates, and performance optimisation.

Modern headless CMSs separate content storage from presentation. Contentful, Sanity, and Strapi provide APIs for accessing content, while your front-end uses any technology stack. This flexibility comes with infrastructure complexity—managing build processes, API authentication, and content synchronisation.

The Fernside CMS approach

Fernside CMS takes a different path: focused editing panels for approved sections only, while we handle hosting, security, and technical maintenance. You get control where you need it—updating text, images, and structured content—without the burden of platform management.

This approach works because most marketing sites don't need complex content workflows. You need to update service descriptions, add case studies, or publish blog posts. You don't need user management, role permissions, or workflow approval systems that enterprise CMSs provide.

When you actually need a CMS

A CMS makes sense when multiple non-technical team members update content weekly or more. Blogs, news sites, resource libraries, and frequently-changing product catalogs benefit from streamlined editing workflows.

Many SMB sites update quarterly or less. For these, editing markdown files or requesting changes through support tickets proves simpler than managing CMS infrastructure, user accounts, and permissions. Don't add complexity for editing frequency that doesn't justify it.

CMS and site performance

Every CMS impacts performance. WordPress generates pages on-demand with database queries. Headless CMSs require build-time API calls. Git-based CMSs trigger rebuilds on every change. Each approach has trade-offs between editing experience and site speed.

We design sites to work brilliantly without a CMS first, using fast Astro builds and static deployment. Then add lightweight editing only where justified—maintaining performance while enabling team autonomy.