The best WordPress alternative for sites you own.

You're not leaving WordPress because it can't be edited — it can, that's the part it gets right. You're leaving because the site never feels like yours: content trapped in a MySQL database, layout buried in PHP themes, behavior spread across a stack of plugins you have to keep patched. The win you want is simple — a site that is plain files you own, that you can move, version, and hand to an agent, while your client keeps editing it in the browser exactly like before.

That's the bar for any alternative worth switching to: keep the client-editing, lose the rent and the upkeep, and end up with something you actually possess rather than something you maintain.

Before pitching anything, be fair. If your site leans on a specific plugin capability — a real WooCommerce storefront, a membership site, an LMS, complex form workflows — WordPress's breadth is genuinely hard to replace, and staying may be the rational call. There's no shame in keeping the tool that already does the job.

And if you're set on leaving, the honest map is: for commerce, Shopify is purpose-built and will save you months. For a hosted no-code builder where you never touch a server, Webflow is mature and well-supported. For a React headless stack on Next.js, TinaCMS or Sanity are strong content layers. Each of those is a good answer when the shape of your project matches it.

For custom content sites you build and hand off — the bread and butter of freelancers and agencies — Primo is the one to reach for. The whole site (components, pages, content, config) is plain files in your repo. Locally it's files an agent can change anything in; pushed to the server it lives in a lightweight row store (SQLite via PocketBase) your client edits visually, in place, on the live page.

The verified core of it: the block your developer or agent edits as code and the page your client edits in the browser are the same files. The editor generates itself from each block's field schema — a fields.yaml next to the .svelte — with no glue code to keep in sync. No PHP theme to separate from content, no database migration to move a site, far less to keep patched.

Because the site is just files, you point Claude Code, Cursor, or Codex at the repo and have it build or restyle the whole thing the way it would a SvelteKit project — then primo push, and hand the client the browser. The agent works through primo pull / primo push; your client never sees any of it.

Don't start from a blank page. Fork a marketplace starter — restaurant, portfolio, SaaS, local service — let your agent make it the client's, and ship. npx primo-cli init spins up the workspace in one command.

Primo isn't a WordPress-replacement for everything. It's built for content sites — marketing sites, portfolios, local-business sites, landing pages — not heavy commerce storefronts, membership platforms, LMS, or full web-apps. If that's your project, Shopify or WordPress is the better tool, and that's fine.

And today Primo's blocks are Svelte, not React or PHP. That's the trade that makes blocks "just files" both the editor and the renderer read. A roadmap item — primo integrate <framework> onto SvelteKit — points at more, but if you need React or PHP right now, weigh that honestly before you switch.