Skip to content
Breitloh

A CMS your team can actually use

Most content systems are built for the developer who installed them. This is the opposite: an editor shaped around the things you publish, with your own words on the fields, a preview before anything goes live, and no way to break the design by accident.

Book a callAll services
Three clients, each seeing only their own documents, with every view recorded

This is for you if

  • Publishing anything means waiting for somebody technical to be free
  • Your current editor lets anyone break the layout, so nobody dares touch it
  • The same information is typed into four pages and three of them are out of date
  • You publish regularly: news, events, case studies, courses, or people
  • You want the words to survive the next redesign rather than being trapped in this one

It is not for you if

  • You publish twice a year and a developer doing it is genuinely cheaper
  • You want a drag and drop builder: that is the thing this exists to replace
  • You want every editor to be able to change the design, which is how sites drift

What is included

An editor built around your content
If you publish courses, the editor has courses in it, with the fields a course actually has. Not a page with a blank canvas and instructions on how to lay one out. That single decision is why teams use these and abandon the other kind.
Preview before publishing
Every change can be seen exactly as it will appear, on a real address, before anyone else sees it. Approvals stop being screenshots in an email thread.
Roles that match how you work
The right people publish, everybody else drafts. Where a committee has to approve something, the approval is part of the flow rather than a convention nobody follows.
Content that can be reused
A person, a venue, or an event is stored once and shown wherever it is needed. Change it in one place and every page carrying it updates, which is the end of the three out of date phone numbers problem.
Your content, exportable, in your account
The content system is in your name, the data comes out in a documented format, and nothing about it is designed to make leaving hard. Including leaving me.

How it runs

  1. 01

    Work out what you actually publish

    An hour listing the things: news, events, people, services, whatever they are. This is a content modelling exercise dressed up as a conversation, and it decides whether the editor feels obvious or annoying.

  2. 02

    Model it, including the awkward parts

    The event that sometimes has two venues, the person who is both a trustee and a speaker. Modelled properly once, so nobody has to work around it every week for the next five years.

  3. 03

    Build the editor, then let your team break it

    Real editors, real content, before launch. Whatever confuses them gets renamed or removed, because the labels that make sense to me are not the point.

  4. 04

    Wire the site to the content

    Pages built from the model rather than typed as one offs. Publishing becomes a change to content, not a change to the website.

  5. 05

    Train the people who will use it

    Half an hour, recorded, with the person who publishes rather than the person who signs things. Most teams need it once.

How long it takes

A date sits beside the price from the start, and you get a note every week saying whether it still holds.

Usually part of a build
The content system goes in as the site is built, so there is no separate project and no second launch.
Two to three weeks on its own
Where a site already exists and only the editing side is being replaced, that is the usual shape.
The modelling is the part that pays
A day spent on the shape of your content saves an hour a week for years, which is the least glamorous return in this business and the most reliable.

Ten years on enterprise platforms, mostly ServiceNow, is ten years of building forms and records that other people have to use every day. The lesson that transfers: a system people avoid is a system that does not work, whatever the specification says.

Where this usually matters most

Some sites live or die on whether the content can be kept current by the people who know it. These are the ones that come up most.

Questions I get asked about this

The ones that come up on almost every first call. If yours is not here, ask it and you will get a straight answer.

What is a headless CMS, in plain English?

A content system that stores your content and nothing else. The website is built separately and asks for what it needs. That separation is why the words survive a redesign, why the same content can appear in more than one place, and why the site can be fast without the editor being crude.

Why Sanity rather than WordPress?

Because the editor can be shaped around what you publish rather than around pages and posts, and because there is nothing to patch on a Sunday. WordPress is a capable system that carries twenty years of assumptions, most of which you are paying for in plugins and speed. Moving off it is a page in its own right.

Is a headless CMS harder for non technical staff?

It is usually easier, because the fields say what they are and there is no layout to get wrong. The thing people miss at first is dragging blocks around a page, and after a fortnight most are glad it is gone. That is the honest version: it is a different way of working, and it takes a couple of weeks.

What does Sanity cost?

There is a free tier that covers most organisations comfortably, and paid tiers when you have a lot of editors or a lot of content. It is billed to your account, not through me, so you can see exactly what it is and stop paying it whenever you like.

Can we preview changes before they go live?

Yes, on a real address, exactly as it will look. That includes scheduled changes, so the person approving the January announcement can see the January page rather than a description of it.

Can we still use it if we already have a site?

Often, yes, though it depends what the site is built on. If the front end is modern, the content side can be replaced on its own. If the site is a page builder site, the editor is the least of the problems and a rebuild is the better conversation.

Who can publish, and can we approve things first?

Roles decide it, and approval steps can be part of the flow where a committee or a compliance step is real. I would rather build the approval you actually have than the one an off the shelf tool assumes.

What happens to our content if we leave?

It comes out, in a documented format, from your own account. That is worth checking with any supplier, and it is worth checking here: the answer is that the export exists and I will run it for you on the way out if you ask.

The other three things I do

Tell me what you have now

Half an hour on a call, and a straight answer about whether this is the right job and whether I am the right person for it.

Book a callhello@breitloh.com