When the CMS becomes bigger than the problem

Most content projects do not fail because people cannot write content. They fail earlier: domain decisions, CMS setup, themes, form plugins, SEO plugins, cookie consent, newsletters, images, internal links, legal pages, analytics, and ads all arrive before the first useful page exists.

On paper, a CMS is the solution. In practice, it often becomes the beginning of a new operational problem. This is not an argument against CMS products. WordPress, Webflow, headless CMS systems, and similar tools all have their place. The problem starts when a relatively small publishing workflow requires the same amount of operational attention as a serious product platform.

Litepress came from that pain: how do you build publishing infrastructure that is not just another layer of CMS complexity, but a smaller, more explicit, and more technically predictable system for content sites?

Markdown is not magic. It is good at describing text: headings, paragraphs, lists, links. That is enough while the page is really just a document. Real pages quickly need more: newsletter forms, galleries, comparison tables, callouts, ad slots, image placeholders, future internal links, and components with privacy consequences.

The moment an author writes a block such as :::newsletter-form, it is no longer just text. It is a semantic instruction. The system has to understand what the block means, which model it expects, how it renders in production, how it appears in editor preview, which JavaScript it needs, which styles it uses, and whether it depends on an external integration.

In Litepress, Markdown is therefore not treated as a final HTML string. It is structured input into a system that understands extensions, integrations, design, and publishing rules. Markdown becomes a small DSL for the publishing runtime. Slightly nerdy, yes. But at least we do not need seven plugins to render one form.

For systems like this, it is tempting to say: let us build a plugin system. That almost always sounds good in the first diagram. Then reality arrives: versions, security, unpredictable JavaScript, CSS conflicts, server-side rendering edge cases, broken upgrades, and plugins that nobody maintains anymore.

Litepress does not currently aim for a public plugin marketplace. It does have the foundations for extensibility. That distinction matters. The architecture is built around controlled extension points, not arbitrary execution of third-party code.

The system has registries, contracts, and separated runtime responsibilities, while execution stays under the control of the core platform. This makes the platform extensible without immediately turning it into plugin archaeology. WordPress PTSD can stay where it belongs: in our memories and occasional nightmares.

Every serious Markdown extension has two sides. The backend side handles what the system needs for rendering, validation, and publishing: model, parsing, SSR behavior, JavaScript, CSS, integrations, and consent requirements.

The frontend side handles the authoring experience: toolbar button, editing popup, preview rendering, custom editor styles, user help, and LLM help. One logical extension therefore lives in two execution environments.

Not because more files are beautiful. Because the editor and the renderer do not have the same responsibility. The editor helps a human and an AI agent create a valid block. The backend ensures that this block is valid, renderable, safe, and correctly connected to integrations.

Many publishing projects do not need a full CMS ecosystem. They need clear content structure, predictable publishing, a few well-defined extensions, a stable design, support for images, links, legal pages, analytics, and ads, and a workflow that both humans and AI agents can understand.

Litepress is my attempt to build a system for that class of problem. Not as a CMS killer, but as publishing infrastructure for cases where the classic CMS becomes larger than the problem it is supposed to solve.

The best sign of good architecture is not that it can do everything. It is that it can clearly say what it is not trying to solve.