I Didn’t Design My CMS Architecture Up Front. It Emerged From Repetition

When I started working on the CMS behind Cordinant, I assumed products and blog articles needed separate systems.

On the surface, that made sense.

A product needs pricing, screenshots, technical requirements, documentation and a live demo link. An article needs long-form content, an author, reading time and a table of contents.

So I initially thought about them as two different content-management problems.

The interesting part appeared when I looked below the editors.

Both needed titles and descriptions. Both needed categories and featured images. Then there was publishing status, SEO metadata, clean URLs, structured data and relationships with other content.

The specialised fields were different, but many of the rules underneath them were not.

I eventually moved towards a shared foundation while keeping separate editors and fields where they made sense. I didn’t want to turn everything into one generic content type just for the sake of reuse.

This became more useful as Cordinant developed.

If an article needs to reference a product, or a product page needs related articles, they are no longer two completely isolated systems that need another mechanism to connect them. They already belong to the same content structure.

One thing I took from this is that I probably couldn’t have designed the right abstraction at the beginning. I needed some duplication first. The repeated fields and behaviours showed me what was genuinely shared.

That has also made me more cautious about abstracting too early. Sometimes duplication is information.

For anyone interested, I wrote more about how this evolved here:
https://cordinant.com/blog/custom-cms-shared-content-architecture

When building your own products, do you abstract shared functionality as soon as you notice it, or wait until you have repeated the same pattern a few times?