Primo vs WordPress.
WordPress runs a huge share of the web for good reasons: your client can edit it, there’s a plugin for everything, and every developer on earth has touched it. The question isn’t whether WordPress works — it’s whether you want your site’s content tangled into PHP themes and a database you have to babysit, or kept as plain files you own. Primo keeps the thing WordPress gets right — a client editing in the browser — without the parts that make it heavy.
…you need a specific plugin ecosystem (WooCommerce, membership, LMS, the long tail), you’re handing off to a team that already lives in /wp-admin, or you want the safety of the most-documented platform on the web. Nothing else has WordPress’s breadth.
…you want to own the site as files, build it fast with an AI agent, and still hand your client a browser editor — without maintaining a PHP stack, a database, and a wall of plugins. Self-host, MIT, no per-site rent.
Side by side
Nothing matches its reach.
Let's be fair before we argue. WordPress is client-editable out of the box, it's been hardened for two decades, and its plugin ecosystem is unmatched — WooCommerce for commerce, membership and LMS plugins, SEO suites, form builders, the works. If your project needs a capability that already exists as a battle-tested WordPress plugin, reaching for WordPress is often the rational call.
It's also the most-documented platform on the web. Whatever breaks, someone has hit it before and written it up. For a certain kind of project — and a certain kind of client team — that ubiquity is the feature.
The site stops being yours to move.
The trouble shows up over time. Your content lives in a MySQL database, your layout in PHP themes, and the behavior in a stack of plugins — and those three are entangled. Moving the site, version-controlling it cleanly, or handing it to an agent to refactor all run into the same wall: there's no single, plain source you can pick up and carry.
Then there's the upkeep. Core updates, plugin updates, security patches, the occasional plugin conflict that takes a site down on a Friday. It's not catastrophic, but it's a standing tax — work you do to keep the thing running rather than to make it better.
One source of truth — files you own, still client-editable.
Primo keeps the part WordPress gets right: your client opens the browser and edits the site in place. What changes is everything behind that. The whole site — components, pages, content, config — is plain files in your repo. Locally it's just 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.
So 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, with no glue code. No PHP theme to untangle from content, no database migration to move a site, far less to keep patched.
An agent can build the whole thing.
Because the site is just files, you can point Claude Code, Cursor, or Codex at the repo and have it build or restyle the whole site the way it would a Next.js or SvelteKit project — then push, and hand the client the browser. With WordPress, an agent can touch the theme but the content stays locked in the database, so the round trip is never clean.
Start from a marketplace starter — a restaurant site, a portfolio, a SaaS marketing page — fork it, let your agent make it the client's, and ship.
Primo is for content sites, and it’s Svelte.
If your project leans on a specific WordPress plugin ecosystem — heavy WooCommerce storefronts, membership/LMS platforms, complex form workflows — WordPress's breadth is hard to replace, and Primo isn't trying to. Primo is built for custom content sites: marketing sites, portfolios, local-business sites, landing pages — the kind a freelancer or agency builds and hands off.
And today Primo's blocks are Svelte, not PHP. That's the trade that makes blocks "just files" the editor and renderer both read. If you need React or PHP today, weigh that honestly.
Questions people ask
Can my client still edit the site themselves, like in WordPress?
Yes — that’s the whole point. Your client opens the browser and edits the site on the rendered page: click a heading and type, swap an image, reorder sections. It’s the WordPress promise (non-technical people keep the site current) without the /wp-admin round trip or the PHP theme underneath.
Do I have to maintain a server, database, and plugin updates?
Far less than with WordPress. Your site is files; on the server it runs on a lightweight store (SQLite via PocketBase) you self-host, MIT-licensed. There’s no sprawling plugin surface to keep patched and no MySQL tuning. You can also primo pull a static export at any time.
Will I lose my WordPress plugins?
Honestly, yes — Primo doesn’t run WordPress plugins. If your site depends on a specific one (a particular WooCommerce setup, a membership/LMS plugin), that’s a real reason to stay on WordPress. Primo is built for custom content sites, where most “plugins” are just blocks you or your agent write directly.
Is Primo actually free, or is this a rented platform?
The core is open source and MIT-licensed — self-host it for free, forever, and own every file. Paid tiers (Maker $20, Studio $50, Agency ~$190) add hosting, more sites, real-time collaboration, and custom domains if you’d rather not run infrastructure — but there’s no lock-in and no per-site rent on the self-hosted path.