Design Philosophy

Build what matters. Question everything else.

Software can become complicated one reasonable idea at a time. A new setting solves an edge case. Another button makes one task possible. A new feature looks useful in a demonstration. Individually, each addition can make sense. Together, they can turn ordinary work into a sequence of decisions nobody wanted to make.

VerdinCore is developed with a different measure of progress: not how many capabilities can be added, but how much useful work the product enables without adding unnecessary friction.

That does not mean avoiding sophisticated functionality. It means being selective about where complexity is necessary, where it belongs, and who should have to deal with it.

Every feature has a cost after it is built

A feature is not finished when its code works. It becomes part of the product: something to explain, maintain, test, secure, and keep compatible with everything around it. It also becomes one more thing people encounter while trying to get their work done.

Before an idea earns a place in VerdinCore, it has to answer some demanding questions:

Question	Why it matters
What problem does it solve?	A feature needs a real purpose, not just an interesting implementation.
Who benefits?	A need shared by many editors is different from a rare personal preference.
How often will it matter?	A daily obstacle deserves a different response from a once-a-year inconvenience.
How much does it improve the work?	Saving a meaningful step is not the same as adding another way to do the same thing.
What will it cost to keep?	Maintenance, testing, dependencies, and interface complexity continue long after launch.
What would people actually lose without it?	Sometimes the clearest answer is that very little would be lost.

These questions are not a ban on experimentation. They are a way to prevent experiments from becoming permanent obligations by default.

Simplicity is not the absence of capability. It is the absence of unnecessary decisions.

Put complexity where it can do the most good

There is a difference between a simple product and a simplistic one. A simplistic product leaves difficult work unfinished. A well-designed product handles complexity where the software can handle it reliably, while preserving the decisions that genuinely belong to people.

VerdinCore's image-processing pipeline offers a concrete example. An editor chooses an image for a post or page. The system has defined processing paths for different uses, including content imagery, featured images, and sharing assets. It can prepare the appropriate variants instead of requiring the editor to perform every conversion manually.

The technical work does not disappear. It moves behind the publishing experience.

The same idea appears in other parts of the product:

Product decision	What it means in practice
Posts and pages are distinct	Ongoing articles and lasting site structure do not have to pretend to be the same kind of content.
Pages have a real hierarchy	Parent relationships, ordering, and nested paths are managed as part of the content model rather than improvised in the navigation.
Images follow purpose-specific processing paths	Editors can focus on selecting suitable imagery instead of repeatedly manufacturing every output format.
Content Blocks use typed elements	Shared information can be maintained as content while its presentation remains defined by the site's templates.

None of these choices is a claim that every possible task has been automated. They show something more useful: repeatable work can be handled consistently without giving up editorial control.

Boundaries are part of the design

More freedom is not always more useful.

Consider reusable content. It would be possible to approach every shared message as a miniature page-building exercise, with unrestricted layout decisions every time someone edits it. VerdinCore's Content Blocks take a more focused approach: named groups of structured elements, such as text, rich text, links, and images, that a site's templates can present consistently.

That boundary matters. The person maintaining the information does not have to reconstruct its design; the person responsible for the theme does not have to surrender presentation to a series of one-off editorial choices.

The feature does a specific job. It does not need to become a universal drag-and-drop page builder to justify its existence.

((Screenshot from the Content Blocks administration interface: open a realistic sample group showing clearly labeled typed elements, such as text, rich text, a link and an image. Focus on the structured editing interface, not the entire dashboard. Use demonstration content, hide private identifiers, and capture approximately 1440 × 900. Place here to illustrate the separation between content and presentation.))

Boundaries also help a product remain understandable as it grows. A capability can be useful precisely because its responsibilities are clear.

The features we choose not to add

Some ideas never make it into VerdinCore. Not because they are impossible, or necessarily bad ideas, but because they do not offer enough benefit to justify their lasting cost.

A feature might help only a tiny number of situations. It might duplicate an existing workflow. It might shift a technical decision onto every editor. Or it might introduce a dependency that demands more attention than the underlying problem deserves.

Saying no to such an idea is not a lack of ambition. It is a product decision.

It also leaves room to say yes when the evidence changes. There is no virtue in omitting a capability that people genuinely need. The principle is to make additions earn their place rather than treating every conceivable option as a commitment.

This is why VerdinCore is not designed around an ever-expanding checklist. A longer list is easy to advertise. A coherent product is harder to build.

Real websites are part of the design process

The work behind VerdinCore began in 2017, but longevity alone is not the point. The product has been developed and refined through use on actual websites, practical testing, feedback, and changes prompted by the realities of publishing and maintaining those sites.

That experience is valuable because real use exposes problems that feature planning cannot predict. A workflow that seems elegant in isolation may be tiring after repeated use. An option that looks important in a specification may turn out to be unnecessary. A seemingly small task may deserve automation because it happens every day.

The interface, the workflow, and the maintenance burden all have to survive contact with real work.

VerdinCore continues to change. New capabilities can be introduced, existing ones can be refined, and earlier decisions can be reconsidered. The philosophy is not to freeze the product in a minimal state. It is to keep improving its usefulness without allowing complexity to grow unchecked.

A better question than “What else can we add?”

The more revealing questions are:

What do editors need to accomplish with less effort?
Which decisions genuinely require their attention?
Which repetitive steps should the software take care of?
Which features make the product clearer, and which only make it larger?

Those questions guide the development of VerdinCore as much as the technologies used to build it.

A mature CMS should not make people admire its complexity. It should let them get on with publishing.

Explore how these principles appear in practice in Why VerdinCore, Reusable Content Blocks, and the Image Processing Pipeline.