The Manifesto

WordPress won the last era

For twenty years WordPress was the fastest way to put a small or medium website in a client's hands. You picked a theme, added a few plugins, uploaded it all to a cheap shared host and handed over a login. The client wrote their own pages from then on. Nobody needed a server team, and one developer could deliver a site in days.

That was a good deal. It is why so much of the web runs on WordPress, and it should be respected.

The era changed

Today the developer does not type most of the code. A coding agent does: it reads the project, makes the change, runs the tests and hands back a diff to review.

So speed no longer comes from how much you can click together in an admin screen. It comes from how much of the site an agent can read, change and prove.

By that measure WordPress is slow.

Why WordPress stops an agent

The site lives in the database. Menus, widgets, page builder layouts, plugin options and custom fields are rows in wp_options and wp_postmeta, often as serialized PHP. An agent cannot read them in a diff. Nobody can review a change to them, and a commit cannot carry them from a local copy to production.

The code belongs to someone else. Much of what a WordPress site does sits in third-party plugins. An agent cannot fix a plugin, only work around it, and the next plugin update can undo the work.

Nothing proves the site works. A WordPress site comes without a test suite. An agent that cannot run tests can only guess, and you are left to check its guesses by clicking around.

Every site is different. Each one has its own mix of plugins, versions and page builder. What the agent learned on one site does not hold on the next.

The basics cost extra. Translated content, custom fields and serious SEO are usually plugins, often paid ones, each with its own data model to learn.

A language decision is forever. With a multilingual plugin such as WPML, each translation is a separate post, linked to an original in the default language. The licence is the small cost. The big one comes when the client decides, a year later, that the site should open in English instead of Italian, or when a junior developer set the wrong default language on day one. Every post, page, menu, slug and string was built around that choice, and changing it turns into a migration project.

Shipping is manual. Files go up over FTP, databases are copied between environments, and updates are clicked in production.

None of this mattered when a human did the clicking. It is the bottleneck now.

And WordPress pays for its flexibility at runtime

WordPress is flexible because it stores almost everything in the same few tables. Every post, page, product and menu item is a row in wp_posts. Every custom field of every one of them is a separate key/value row in wp_postmeta, with the value in a text column that has no index.

That one design fits any content type. It also means:

• a record with twenty fields is twenty-one rows,
• filtering or sorting by a field is a join on that text column, done once per field,
• wp_postmeta grows faster than any other table and slows down every query that touches it,
• every active plugin loads on every request, whether the page needs it or not.

The usual fix is more caching, a bigger server or a managed host, which is the opposite of the cheap shared hosting that made WordPress popular.

Flexible and fast

MelaCMS keeps the flexibility and drops the cost:

• Each kind of content has its own table, with real columns of the right type that you can index. A record is one row. Filtering a list of services by date is a plain indexed query, not a join through a meta table.
• Translations live in the same row, in JSON columns. Adding a language adds no rows and no joins.
• The default language is a setting, not a foundation. An admin picks another default language on the Languages page and saves. No data moves, however much content is already translated. The new default goes to the root of the site, the old one moves under its prefix, and every page keeps an address.
• Flexibility where it belongs. A field that only one page template needs goes into a single JSON column on the page, with no migration. Content that grows or gets queried gets its own table, which an agent writes in a minute.
• Nothing runs that the site did not ask for. There are no plugin hooks loading on every request. The site's settings are read with one query per request, and the deploy caches the config, routes, views and events.
• Images are ready before the visitor arrives. WebP sizes are made once at upload, not resized on the fly.

The result is a site that stays fast on the cheap host as its content grows. This is not a separate feature: it follows from the site being code.

What MelaCMS keeps

WordPress was right about what matters to clients and to small studios. MelaCMS keeps all of it:

• An admin panel the client understands. They log in and write pages, upload images, translate content and change the site's details, without calling you.
• Cheap hosting. A shared host with PHP and SSH is enough. No containers, no Node server, no queue worker, no managed platform to pay for.
• What every site needs, out of the box. Pages, a media library, languages, SEO, a sitemap, users and roles.
• One person can deliver a site.

What MelaCMS changes

Everything else becomes code.

• The site is a Laravel repository. Models, migrations, admin screens, views and routes are files that an agent reads, changes and tests.
• The core is a dependency. It arrives through Composer, is never edited, and is updated with one command. Every site runs a known version.
• The agent gets instructions. The installer writes a MelaCMS section into the site's AGENTS.md and CLAUDE.md. A guide shipped with the core takes the agent from the migration to the test of a new kind of content, and the core's own test suite runs that guide's code, so it cannot go stale.
• Shipping is set up from the first commit. CI, conventional commits, versions, changelog and a deploy over SSH on every release.
• Content and structure are kept apart. Editors own the pages and the media, in the database. Developers own how the site works, in git.

What MelaCMS refuses

• No plugin marketplace. A feature the site needs is code in the site: written with the agent, tested, and owned.
• No page builder. Templates are Blade views. Editors choose a template and fill in its fields.
• No structure in the database. Anything that changes how the site works lives in git.
• No update button on the server. An update happens on a developer's machine, passes CI and ships as a release.

Who it is for

MelaCMS is for freelancers and small studios who build client websites with a coding agent, who work with Laravel or want to, and who want to hand over a site that:

• the client can edit,
• the next developer, or the next agent, can understand,
• runs on the hosting the client already pays for.

It is not for building a site without code, for a client who expects to install plugins themselves, or for a host with FTP and no SSH.

The bet

Building a website keeps getting cheaper. What stays expensive is a website nobody can safely change.

MelaCMS bets that the CMS of this era is the one an agent can read from end to end, change with confidence and prove with tests, while the client still logs in to an admin panel on a cheap shared host, as they always have.

That is the WordPress deal, rebuilt for the agentic era.

Read the vision → · Get started →