Contentive vs Strapi and Payload
Strapi and Payload are open-source and yours to run. A hosted Strapi alternative trades that ownership for hosting, staging and rollback you don't maintain.
Strapi and Payload are what a lot of developers reach for when they want a headless CMS they actually own. Open source, self-hostable, extendable to anything. If you're weighing a hosted platform against them, the question isn't which is better. It's which costs you less over twenty client sites.
What they do better
Ownership, first. Both are open source, so you can read every line, fork it, and run it on your own servers for as long as you like. No vendor can change the terms on you.
Both are code-first and extensible to almost anything: custom endpoints, hooks on every write, server-side logic, integrations with whatever the client already runs. Payload's configuration lives in TypeScript alongside the application, so the content model is reviewed, versioned and typed like any other code. For a developer, that's a very good place to be. Payload is now part of Figma and has said it remains open source. Strapi has a large community and a plugin marketplace, and has been through several major versions in production.
Strapi offers a hosted cloud, so on Strapi self-hosting is a choice rather than a requirement. Payload paused new sign-ups to its own cloud after joining Figma, so check its current hosting options on the day.
The real cost of self-hosting, times twenty
One self-hosted CMS is a pleasant project. Twenty is an operations job. Each one has a server or container to keep running, a database to back up and test restoring, major version upgrades with migration notes, security patches for the CMS and its dependencies, and a front end on another host with its own build. None of that is hard on its own. All of it repeats, on every site, for as long as the site lives.
That's the same pattern we described in every plugin is a decision you have to keep making. Choosing to self-host isn't a decision you make once. You keep making it every time an upgrade lands.
What we take off the table
On Contentive, hosting is ours. So are the database, the backups and the upgrades. Each site has a staging address next to the live one, publishing lands in staging, and production is reached through a deliberate promote step. Rolling back a theme creates a staging version from an earlier deployment's exact files, which you then promote. Every site gets a forms inbox with spam protection and CSV export, and a sitemap generated from its published pages. The theme renders on our side, so there's no separate front-end host to maintain. Staging vs production explains how that flow works in practice.
What you lose
This part matters, so it gets a plain list.
Source access. Contentive is closed source. Our SDK is MIT-licensed and on npm, but the platform isn't.
Running on your own infrastructure. If a client's compliance team requires their own servers or region, we can't help.
Arbitrary server code and hooks. You can't run your own logic inside our write path. Automations cover simple cases like "form submitted, send email", and webhooks let your own service react, but it isn't the same as code in the CMS.
Freedom of front end on our hosting. Our hosted path is Liquid themes. Build with any framework you like against the GraphQL API, but then you host it.
An upgrade, in practice
A major CMS upgrade on a self-hosted project usually goes like this. Read the migration guide. Update the dependency. Fix the breaking changes in your configuration and custom code. Run the database migration on a copy. Test the admin and the front end. Deploy, and watch the logs. On a well-kept project that's half a day. On a site you haven't touched in eighteen months, with a plugin that hasn't been updated, it's longer.
Now do it for every client site, and decide which ones are worth upgrading at all. The ones you skip become the security risk you'll eventually have to explain. On a hosted platform the upgrade still happens, but it isn't your afternoon, and it happens to every site at once.
Agents
Contentive has an MCP server with tools over the same Management API the Studio uses, so an AI agent can build the content model, pages, forms and theme, and work through scoped, read-only or content-only connections. Strapi and Payload both have official MCP support too: Strapi has a built-in MCP server you switch on, and Payload has an MCP plugin that respects its access control. Both reach the content on your own server. The difference is scope. Ours also covers the theme, the hosting and the route from staging to live, because those are ours to run.
Migrating
There's no Strapi or Payload importer. If the site is public, our scraper can crawl it, extract the content and suggest a content model, and the clone tool can capture the pages as a starting theme. Every import lands in staging, and re-running one updates rather than duplicates. For anything beyond that, the GraphQL API and the agent tools mean a short script or an agent session can move content across. Budget for rebuilding the front end as a Liquid theme.
Who it suits on your team
Strapi and Payload suit an agency whose developers want to own the back end and enjoy doing so, and whose clients will pay for that ownership. Contentive suits an agency whose developers would rather spend their hours on themes and sections than on servers, and whose account managers want to see a client's model, content and deployments in one place without asking a developer. Many agencies have both kinds of project. It's reasonable to use both tools, and to choose per client rather than once.
Modelling: code vs Studio
In Strapi and Payload, the model is defined in code, or generated by an admin panel into code. In Contentive, it's defined in the Studio, or by an AI agent working over MCP, and can be exported as JSON to reuse on the next site. Developers who want models in pull requests will miss the code-first workflow. Agencies who want a client's account manager to read the model without opening an editor tend to prefer ours. Neither is wrong.
Arithmetic, briefly
Our Agency plan is £39 a month for three live sites, then £10.99 a month for each further live site, with unlimited seats and nothing to pay for sites still in staging. Against that, put your own hosting bill for twenty CMS instances and front ends, plus your hours on upgrades and patching, at your own rate. Run your own numbers. The hosting is rarely the expensive part. The hours are. The real cost of a WordPress website walks through the same kind of sum.
When to pick which
If the client needs custom server logic, or must self-host for compliance, choose Strapi or Payload without hesitating. They're very good, and owning the code is a real advantage. If you're an agency who wants content models, themes, hosting, staging and rollback on every client site without running twenty servers, that's the gap we fill.