CMS Development — WordPress, Shopify & Headless

The point of a CMS is that you can change your own website. Most CMS builds fail that test within a year — not because the software is bad, but because the content model was designed around the page layout instead of the content itself.

Here is what that looks like in practice. You want to add a new service. The theme expects services to live in a page builder, so you duplicate an existing page, edit the text, and discover the layout has broken because your new service name is three words longer. Now you email your developer. That is not a CMS, that is a bill.

Content modelling first

Before touching a theme I work out what your content actually is. A service has a name, a description, a price, some images, maybe a testimonial. Those are fields. Once they are modelled properly, adding a service means filling a form — and the layout cannot break, because the layout is not your job.

This is the single biggest difference between a CMS build that lasts and one you replace in eighteen months.

Platform choice

WordPress — best when you want plugins, have a blog, and need a large pool of people who can maintain it later. Still the right answer for a lot of businesses, despite what developers on the internet say.

Shopify — if you are selling physical products, stop reading and use Shopify. Payments, inventory, tax and shipping are solved problems there.

Webflow — good middle ground when design control matters and content volume is low.

Sanity or another headless CMS — when you need the same content on a website and an app, or when performance is the priority. More setup, better long-term.

I do not have a favourite. The right choice depends on who is editing, how often, and what happens when you hire someone new.

Training is part of the job

Every build ends with a session where you edit your own site while I watch, plus a short written guide for the things people forget. If you cannot confidently add a page after that, the build is not finished.