Our future without WordPress: why we are moving to Payload

MManfred

This is an English version of the German original.

Almost 40 % of all websites worldwide run on WordPress. The platform is widespread for good reason. It is reliable, has mature workflows and a huge ecosystem of themes, plugins and service providers.

We ourselves have used WordPress for many years. That is exactly why we know where its limits and problems lie. For this reason we are moving our own web projects to a new foundation: Payload CMS. Internally this runs under the project name ARR. ARR comprises the platform itself, the deployment image and the complete deployment pipeline. The pipeline reaches from AI-supported content creation through design system management and implementation to automated deployment as a CI pipeline.

WordPress: the pros and cons

The good first. WordPress is not a niche product but the reference in content management. The install base is huge. There is a plugin for almost every problem. Agencies like us can draw on a large pool of know-how. Stability and predictability are (were?) not a marketing claim here but lived practice.

The problem is unfortunately the same number. Almost 40 % market share also means: WordPress is one of the biggest attack targets on the internet. In the age of AI, new security flaws are permanently discovered and exploited. Every installation must be patched, secured and monitored.

Then there is the plugin and theme landscape. Every single extension must be trusted. Every one must be maintained. Every one extends the attack surface. For us as a service provider this means: the effort for a secure WordPress operation grows faster than the benefit for the customer.

A third argument weighs heavily for us. The workflows of WordPress are designed for the classic logic "maintain content, publish page". They do not fit how we want to work with AI-supported processes today. This applies to content creation, design and deployment.

Where we are moving to: Payload CMS

Payload is an open-source content management system based on TypeScript and Next.js. We develop our other web projects on the same technological basis. Payload is "headless": content is provided through clean APIs. The design is fully under our control. There is no pre-built theme structure that constrains us.

Why Payload is the right choice for us:

  • Code-first instead of click-building blocks. Content, data models and logic are defined as code. That makes them versionable, reviewable and reproducible. What in WordPress is scattered across the admin interface is a readable, testable artefact in Payload.
  • Self-hosted, no vendor lock-in. We run Payload on our own infrastructure with our own database. No subscription pressure, no dependency on a SaaS provider, full data sovereignty. That is also an important point with regard to the GDPR.
  • Modern security posture. No flood of third-party plugins. Everything that runs is code we control ourselves. We decide which building blocks an installation really needs. That is significantly fewer than in a typical WordPress setup.
  • API-first for AI workflows. Content, media and design tokens can be read and written programmatically via REST API. That is exactly the interface our AI-supported processes need.
  • Lean instead of bloated. Payload ships only what an installation really needs. No theme flood, no mandatory plugins, no legacy from twenty years of marketplace history. A fresh, minimal codebase means: less code to read, fewer places for errors, faster builds and iterations.

Payload is not a niche experiment. The companies and organisations that use Payload in production include Microsoft (for the AI design tool "Designer"), Vodafone, ASICS, Mazda, Sonos and Blue Origin. Anyone who builds content platforms for global brands relies on Payload meeting these requirements. We benefit from the same maturity and the same ecosystem.

ARR: from content creation to deployment

Moving to Payload would only be half the job if we then still had to do every step by hand. ARR automates the complete path:

  • Content creation: texts and pages live as Markdown files in our content repository. The repository is the single source of truth for everything that is published. Markdown can be edited easily and quickly by people and by AI agents alike. No copy-paste into an admin interface, no accidentally unsaved changes.
  • Design: the styling of pages is not hard-wired into the application code. It is provided as design tokens per brand and pushed via API to the respective site. Behind this is our internal design system Biti. One image, many sites, each with its own design.
  • Synchronisation: a dedicated sync tool transfers the content to Payload via REST API. Media, SEO metadata and the URL structure are transferred along. The blog post you are reading right now is also a product of this system.
  • Human gate: agents can only prepare content. The final version and publishing always remain a conscious decision of humans. Automation yes, but with clear decision and control points.
  • Deployment: code changes run via pull requests, a build pipeline and pinned container images to our servers. Kestra orchestrates the actual rollout to the target systems. That is reproducible, traceable and without manual intervention.

The result: new content passes through the path from specifications in Markdown via draft and content as Markdown files to the published page without a media break. Everything is versioned with Git. Every step remains documented and verifiable.

What this means for our customers

  • Faster implementation: with AI support, content can be created and rolled out in a fraction of the time previously required.
  • Smaller attack surface: no plugin dependencies, self-controlled code, modern architecture.
  • Full data sovereignty: content and hosting stay with us or with the customer. No vendor lock-in, no dependency on SaaS providers.
  • Design freedom: instead of pre-built themes, the design system determines the look.

Conclusion

WordPress was a good companion. It brought us exactly to where we stand today. But the requirements have changed: more security, more automation, more AI. Payload, provided via ARR, is our answer. A platform we control. A pipeline that maps the path from idea to published page without friction.

This is a decision for our own infrastructure, not the end of WordPress at WIT. Existing WordPress projects of our customers will not be switched off overnight. They are migrated only on request and as needed. Managed WordPress hosting with Divi and WPML (licences available) for your own projects remains on offer. We no longer start new WordPress projects. New projects start directly on the new foundation.

Manfred Wisniewski is the owner of WIT. This article was created by him with AI support and reviewed by him.