The CMS Decision Nobody Thinks About Until It Is Too Late
Why the content management system matters more than the design.
Every website project begins with a conversation about design. Colours, layout, typography, imagery. This is the visible layer, the part the client can see and react to. Nobody begins a project by asking "what content management system should we use?" It is an infrastructure question, and infrastructure is invisible. Until it is not.
Twelve months after launch, the client needs to update their homepage. Maybe they have a new project to add. Maybe they have won an award and want it on the about page. Maybe their phone number has changed. They open their CMS and discover one of three realities.
Reality one: they can see the content, find the field, change the text, and hit publish. Five minutes. This is the outcome of a well-chosen CMS with structured content.
Reality two: they open the editor and find a wall of HTML. The text they want to change is buried between div tags, inline styles, and image references. They are afraid to touch anything because last time they accidentally deleted a closing tag and the page broke. They email the developer. The developer is busy. The update happens next week, or next month, or never.
Reality three: they cannot find the content at all. The text is hardcoded in a template file. Updating it requires access to the codebase, a deployment pipeline, and a developer. The "content management system" manages nothing. It is a login screen with an empty dashboard.
These three realities are determined entirely by decisions made before a single pixel was designed. The CMS choice is an infrastructure decision that directly controls the client's independence after handover. Get it right and the client can maintain their own site indefinitely. Get it wrong and every text change requires a developer invoice.
The landscape divides into three broad categories. Traditional CMS platforms (WordPress, Squarespace, Wix) combine the content with the presentation. The client edits content in the same environment that displays it. The advantage is familiarity. The disadvantage is that the design is constrained by the CMS's template system. Every WordPress site carries the structural fingerprint of WordPress, no matter how custom the theme.
Headless CMS platforms (Sanity, Strapi, Contentful) separate content from presentation entirely. The content lives in a structured, API-accessible database. The front end is built independently, using whatever technology is best for the project. The client edits content in a clean, purpose-built studio. The developer has complete freedom over the design and technology. There is no template fingerprint.
The third category is no CMS at all: content hardcoded into the application. This is common with developer-built sites where the developer assumed they would always be available for updates. It works until they are not.
For premium personal brand sites, consultancy sites, and portfolio sites, a headless CMS is almost always the right answer. The client gets a clean editing experience (structured fields, image uploaders, preview). The developer gets complete design freedom (no template constraints, no plugin conflicts, no theme updates that break custom code). The site loads fast because there is no CMS overhead in the browser. And the technology is invisible to the visitor, which is exactly how premium should feel.
The decision also has a financial dimension. Traditional CMS platforms often seem cheaper upfront but accumulate costs through plugin licences, theme updates, security patches, and hosting that scales poorly. A headless CMS on a generous free tier (Sanity offers three users, 500,000 API requests, and 20GB of assets for free) paired with modern hosting (Vercel's free tier handles most personal sites) can cost literally nothing per month to maintain.
The CMS decision is not glamorous. Nobody will compliment you on your content management system. But twelve months after launch, when the client updates their portfolio in five minutes instead of emailing you for help, the decision pays for itself in independence, speed, and trust.
Build on infrastructure you actually own.
The systems your business runs on decide how far it can scale. The 12 Principals programme builds every one of them around your expertise, from the website to the app to the pipeline.
