BCMS published an article about what makes a CMS user-friendly. It contains five excellent questions that teams start asking about six months after implementation of their website (and CMS). I am going to answer all five for Usecue CMS.

Why does publishing take so long?

It doesn’t. Next question… Okay, fine, some proof. Here is a real website with 312 pages being rebuilt from scratch:

remote:                    | EN
remote: -------------------+------
remote:   Pages            | 312
remote:   Static files     | 414
remote:   Processed images | 426
remote:
remote: Total in 1897 ms

Under two seconds. That is not a clever cache trick, that is just Hugo being absurdly fast, and me refusing to build a CMS on anything slower. For comparison: I have watched another CMS take over 40 seconds to publish a site whose actual build took 500 milliseconds. Thirty-nine and a half seconds of pure ceremony, to fix one capital letter.

And speed is not just about the build. In instant publishing mode the publish button sits directly under the editor, with your live website next to it. You press it, and the site on the right updates while you are still looking at it. No dashboard detour, no “your deployment is queued”, no email telling you the thing you did four minutes ago has finally happened.

Why can’t marketing update content without engineering?

They can. That is the whole point. Usecue CMS is zero config: there is no schema to define, no content model workshop, no YAML archaeology. You point it at a Hugo repository and it works out what your content looks like. Multi-user, mobile-first, rich markdown editor. If you can write an email, you can update the website. Nobody has to file a ticket to fix a typo.

But there is a second half to this answer that most people get backwards. Marketing should be limited to existing components.

I do not think “user-friendly” means an editor can do anything. An editor gets markdown and the shortcodes the developer has already built, and that is deliberately the end of the list. You cannot invent a new layout, override the design, or drop a video player inside a pricing table. Every CMS that does let you build anything ends up with fourteen slightly different button styles and a homepage nobody dares touch. Constraints are not a missing feature, they are the reason the site still looks like itself after two years of edits.

So the division of labour is clean. Engineering builds the components and owns how the site looks. Marketing composes pages from those components, whenever they want, without asking permission. And because every change is a real Git commit with a real commit message, engineering still gets the diff, the review and the unlimited backups. People edit bravely when they know nothing can be permanently broken.

Why is finding content harder than creating it?

This one stung, because it is completely true of almost every CMS, and it used to be true of mine. You know exactly which page you want. You can see it in your browser. And yet you are now three levels deep in a tree of folders, guessing whether it lives under “Pages”, “Sections” or “Content Blocks”.

So I stopped making people search and let them point instead. In side-by-side mode, the editor is on the left and your actual website is on the right, and the two listen to each other. Navigate on the left, the preview follows. But more importantly: navigate on the right, and the editor jumps to that page. You find content by clicking around your own website, exactly like a visitor would, because that is the one map of your site that everybody already has in their head.

There is also a reference counter and smart linking, so before you delete something you can see what points at it. Fewer surprises, fewer broken links, fewer angry Mondays.

Why are we translating the same content multiple times?

Right, this is the one where I have to be honest, because I caught myself answering an easier question instead.

The easy answer is: translations in Usecue CMS are linked, not duplicated. Pages are connected by a translation key, so the CMS knows which Dutch page belongs to which English page. One-click translations give you a working draft instead of an empty box, and side-by-side editing lets you see the original while you fix the translation. All true, all nice.

But that is not what BCMS is asking. They are asking about content reuse. The scenario they mean is: the same product description, the same disclaimer, the same call-to-action appears on fourteen pages, and someone paid to translate it fourteen times. That is not a syncing problem, that is an architecture problem, and it is a genuinely expensive one. So here is my actual answer, in two parts.

Part one: yes, this is solvable in Usecue CMS, but a developer does it once. The reusable block becomes a Hugo shortcode or an entry in the translation file, and every page includes it instead of containing its own copy. Translate once, appears everywhere, change it in one place.

Part two: an editor cannot set that up on their own, and I am not going to pretend otherwise. Creating a new reusable block is a code change, not a checkbox. There is no translation memory, no “you have translated this sentence before, here it is again”, no glossary.

Most websites I see do not have a content reuse problem. They have twelve pages, two languages, and a nagging feeling that the whole thing has become more complicated than the actual amount of text on it. If that is you, a shortcode and a translation key are the entire solution, and you can stop reading brochures about content models.

Why are we using five tools to manage one content workflow?

Let me answer this by counting what would otherwise be five tools.

Usecue CMS handles the editing, and the hosting. Forms and spam filtering are built in, so you do not need a form service. Images are resized and cached for you (SVG included), so you do not need a CDN. Analytics are integrated. Backups are Git. There is hosting failover, plus daily rebuilds.

That is one login, one bill, one place to look when something is odd. The reason it can all live together is that a static website is genuinely simple underneath. Almost all CMS complexity, like deploy a pipeline, is invented complexity. Usecue CMS has a button that reads ‘publish’, that’s all.

And one last catch

Usecue CMS only works with Hugo. That is not an oversight, that is the entire strategy: pick the fastest static site generator in the world, refuse to support anything slower, and spend all the saved effort on making the editing experience genuinely pleasant.

If your website already runs on Hugo, you are one conversation away from all of the above. If it runs on WordPress, converting it is usually less painful than you fear.

Recognise any of these five questions from your own CMS? Contact me and let’s fix them.

()  Joost van der Schee