Why we didn't build a CMS

Long term, sp8 isn't a classic CMS for me anymore. We see it more as an operating system for modern web and business processes.

The origin was actually quite different: For more than 25 years I worked as a managing director, project lead and project manager between clients and developers. I know TYPO3, WordPress and classic agency projects very well. And I kept seeing the same problems:

• technical debt,
• long development cycles,
• plugin chaos,
• hacked WordPress sites,
• painful relaunches,
• SEO losses,
• and clients who don't understand why an update suddenly costs thousands of euros.

sp8 came out of the desire to remove that friction.

It really started in September 2025 as a prototype for a client project.

I had just seen how powerful modern AI-assisted development had become. The first thing that emerged was a marketing automation solution. Then came our own editorial system. After that segments, pipelines, business apps and CRM functions.

Today sp8 rests on a much broader foundation:

• starter kits,
• mothership architecture,
• an extension system,
• SEO automation,
• content migration,
• and business-app integration.

From my perspective, the biggest problem is the huge amount of outdated web infrastructure.

There are hundreds of thousands of WordPress installs:

• that are technically outdated,
• have security issues,
• are hard to maintain,
• have become slow,
• or run completely fragmented.

Many companies carry technical debt with them for years.

Our goal is to make that move predictable – technically and editorially.

It always starts with the existing website. It gets read in – structure, content, media, URLs.

That becomes the basis for the migration:

• content is carried over in a structured way,
• media are remapped,
• redirects are mapped by meaning instead of guesswork,
• and the SEO substance is secured before anything is switched over.

It isn't a push of a button. But it is predictable. And that is exactly where classic relaunches fail: not on design, but on what quietly gets lost in the move.

Wiring the AI in so that it is powerful without becoming dangerous.

The obvious route would be to give the AI its own, far-reaching access. That is exactly what we did not want. Two things were needed for that:

• The AI has no rights of its own – it always operates with those of the signed-in user.
• The data schema explains itself to the AI at runtime, so it cannot invent fields that do not exist.

That sounds unspectacular. But it is the difference between an assistant you can hand to a team and one you would rather supervise.

Because SEO is one of the biggest pain points in any relaunch. Many companies lose rankings:

• through broken redirects,
• bad migrations,
• lost site structures,
• or technical errors.

That is where the sp8 SEO Suite came from. Not a single tool, but several modules. Three of them get a company on track in the first place:

• SEO Basic – the foundation: structured work on pages and content, even without prior SEO knowledge.
• SEO Advanced – analysis and prioritisation for teams that go deeper.
• SEO Overview – all the data in one place instead of spread across five tools.

The fourth module is the one for day-to-day operation:

• SEO Springboard – used to move individual pages forward deliberately. From page two to page one. From position ten to position three. Not across the whole site at once, but page by page.

The data behind it is live, not exported: Google Search Console is connected directly, Google Analytics runs as its own module in the back end, and SISTRIX data comes in on top.

The system actively guides marketing leads: "There's potential here." "These rankings could be improved." "These actions would make sense."

The next stage is in the works. I won't say anything concrete about it today – only this much: it changes how pieces of content relate to one another.

Yes. One of the first projects was a WordPress news portal with around 12,000 articles. The site had been hacked and was offline for several weeks.

We:

• took over the entire structure,
• migrated the content,
• remapped images and videos,
• built SEO redirects,
• and rolled out the portal again within a few weeks.

It was a real stress situation – but that's exactly where you find out whether an architecture works.

Sceptically at first, of course. Many clients first compare: "WordPress could do that too." And then you have to deliver feature by feature.

In our case we had to rebuild a custom AdRotate extension, for example. That was a lot of effort and went through many bug-fix rounds.

But by now the client says: he doesn't want to go back to WordPress.

For us, AI isn't a feature you switch on. It's part of the architecture. Which is why the interesting question isn't what the AI can do – by now everyone can do that. The interesting question is under what conditions it works.

Two things are in productive use today for exactly that.

The first is provider freedom. sp8 speaks MCP, the open standard that all the major providers now support. Thirteen AI providers are configured in the system – among them OpenAI, Anthropic, Google Gemini, Mistral, DeepL, Azure OpenAI, DeepSeek, Cohere and xAI, plus Mittwald AI Hosting for cases where data must not leave Germany. Providers can be switched on and off individually, and you decide who handles which task. If one of them doubles its prices in two years, you switch. No new website, no project.

The second is the permission model – and that is the real difference. Almost everyone has an MCP interface in 2026. What matters is what sits behind it: the AI gets no special rights, only those of the signed-in user. Someone who isn't allowed to publish in the system can't publish through the assistant either.

In practice: the team can work with an AI assistant directly inside sp8. Or from the outside, out of the assistant they already use every day. Both lead into the same website.

What carries all of that in the end is the structure behind it. I sometimes compare it to a huge shelving system: I build the structure piece by piece and know exactly which compartment goes where.

Then it gets added – but in a controlled way, not as a plugin from somewhere out there.

sp8 is modular. Functions can be added deliberately, instead of every installation carrying everything it will never need. What's missing gets added as an extension and becomes part of the system – reviewed, not glued on. For AI functions there's an internal credit system for that, sp8 Credits.

Keeping this tightly managed is a deliberate decision. We want first:

• stable architecture,
• clear standards,
• consistent UX,
• secure processes.

What we don't want is an uncontrolled plugin hell like in classic CMS systems. There, every additional plugin is also an additional risk – and that is exactly why clients come to us. A controlled opening can come later, but only with clear standards behind it.

Three things I would rather say myself before anyone asks:

• There is no four-eyes approval workflow yet. For clients with compliance requirements that is a hard requirement.
• Versioning: a changed page cannot be rolled back to an earlier state at the push of a button.
• Notifications: the system does not reach out on its own when something needs doing.

All three are specified and planned for the next build stage. I don't believe in keeping quiet about this. Named openly, it reads as planning. Admitted afterwards, it reads as a flaw.

sp8 is not a classic CMS. We are building an AI-powered platform to modernise and steer digital web and business processes.