Stet vs Payload

Side by side.

The same seven questions, asked of both. Checked against published documentation in July 2026.

Question	Stet	PPayload
Who models the content	Stet Marketing, in the UI. Collections, maps and fields with no deploy.	Payload Developers, in code. Collections and fields are a TypeScript config, so a new field is a commit and a deploy.
Types in your app	Stet A typed client generated from the live model by a Vite plugin.	Payload Excellent. Generated from your config, in the repository that defines it.
When the model changes	Stet A removed field becomes a deprecation in the types. The build stays green.	Payload Your own change, in your own repository, released on your own schedule.
Analytics	Stet Included. First-party and cookieless, through your own infrastructure.	Payload Not included.
AI	Stet Included. Drafting, suggestions and delegated tasks, approving every write.	Payload Available through enterprise plugins.
Hosting and licence	Stet Hosted cloud or self-hosted. Open source.	Payload Self-hosted, on infrastructure you run. Open source, MIT.
How pricing works	Stet $10 per user per month. Free to self-host.	Payload Free to self-host. Enterprise licensing for SSO and advanced workflow.

What Payload does better.

Types are first-class, the config is genuinely pleasant to write, it installs into an existing Next.js app, and it is MIT licensed with no seat counting.

1import { stet } from '@stetcms/client';2 3const post = await stet.posts.get('hello-world');4 5post.

The fields from that collection, arriving in the editor as typed properties on the generated client.

When to pick Payload instead.

Pick Payload if engineering owns the content model and wants it in code, or if you want the admin running inside the same Next.js application you already deploy.

Other comparisons.

The same seven questions, asked of everything else teams weigh Stet against.