Hey HN, my name is James and I founded Payload (
https://payloadcms.com/) with two close colleagues, Dan and Elliot. We're a dev-first headless CMS [1] that's half app framework and half CMS—we're closing the gap between the two. You can check out our demo here:
https://demo.payloadcms.com.
Imagine you're going to build a new SaaS app. Would you think of building it on a headless CMS? Probably not. To devs, "content management system" is usually a swear word. If a team of engineers gets assigned a CMS project, it's less than thrilling. Engineers want to avoid roadblocks, write code, and build things they're proud of—but existing CMS's get in the way of that left and right with their third-party integrations, point-and-click schema designers, code generation, etc.
Rather, you'd build your backend on an app framework like Django, Laravel, etc., for good reasons: ownership over the backend, better access control, customizable auth patterns, etc. Typically, headless CMS are super limiting; you'll end up fighting the platform more than having it help. But, with app frameworks, you're often left to roll your own admin UI, and that takes time. Not to mention building CRUD UI gets old quick after you do it a few times.
That’s where a headless CMS could shine, because they instantly give you admin UI that non-technical teams can use to manage digital products. That saves a ton of UI dev time— but without an extensible API, headless CMS's are far too limiting. They're designed for marketing teams, which usually only need the generic basics: log in, create a draft, preview the draft, publish the content. Go back and update some pages. Define editor roles and localize content. If you need more than that, you'll soon be out of luck.
Payload is different because we treat developers as first-class citizens. We provide the best of both ends: a powerful and extensible API and a fully customizable admin UI out-of-the-box. All with a developer experience that we obsess over, because we want it ourselves.
Payload is code-first, which allows us to get a lot of things right. We give you what you need, then step back and let you build what you want in TypeScript. You'll understand how your CMS works because you will have written it exactly how you want it. Version control your schema and use your own Express server. Completely control the Admin panel by using your own React components. Swap out fields or even entire views with ease. Use your data however and wherever you need thanks to auto-generated, yet fully extensible REST, GraphQL, and Local Node APIs.
Since it uses your own Express server, you can open up your own endpoints alongside what Payload does. In fact, you can extend just about everything that Payload does. It's MIT and open-source, fully self-hosted, comes with GraphQL and REST APIs, and completely customizable.
We realized the need for Payload while we were building the corporate website for Klarna. The Klarna engineers we were working with were among the best in the world, and while they evaluated headless CMS options, they saw restrictions in how all of the normal contenders "black-box" away the API. They wanted to build their CMS, deploy it on their own infrastructure, and truly "own" their CMS. They fell back to using WordPress. When that happened, Klarna inadvertently shined a spotlight on the CMS market and pointed out a significant void in proper code-based, developer-first CMS. There was no one to give them the developer experience they needed. That's what got us started working on this.
It might seem like a CMS is just a wrapper around a database with a nice UI to show different field types—but in reality, it's a lot more complex than that. We obsessed for years around how to build a proper API that minimizes breaking changes, but still exposes a simple way to extend everything. When you start to introduce things like field-based access control, field-based conditional logic, localization, versions, drafts, and autosave, the task becomes a lot more daunting. Doing it right requires a significant development investment—especially if you want it to perform at scale in addition to removing roadblocks at dev time.
It seems like every day, a new headless CMS pops up. But when you filter down to those that are completely self-hosted, the options quickly dwindle. And then when you remove the confused point-and-click "no-code" (argh!) GUI nature of the existing options, the options narrow to one: Payload.
Our users have built quite a diverse set of apps on Payload. We've seen a virtual events platform, a broadcast platform, SaaS apps of all shapes and sizes, video games, and an Uber-like snow plow service! There are over 1,000 projects in production as of last week, and we can't wait to see more.
Open source has been incredibly helpful. We've gotten significant PRs and our community has gone above and beyond in their contributions. We did not anticipate the level of skill and involvement that we are seeing daily from our community.
Our business model is based on two things:
1. Enterprise features like SSO, audit logs, publication workflows, and translation workflows. Of course, as Payload is open-source, you can build these functions yourself, but enterprises are opting to pay for our official functionality and SLAs rather than rolling it themselves.
2. Cloud hosting. Now that Payload 1.0 is released and ready for production after more than two years of development and dogfooding, we've shifted focus to building a deployment platform for Payload that will deliver permanent file storage, database, API layer, and CI. It will be the easiest way to deploy Payload, but not mandatory to use—much like the NextJS and Vercel model.
You can get started in one line by running `npx create-payload-app` or you can try out our public demo at https://demo.payloadcms.com. The code for the demo is at https://github.com/payloadcms/public-demo.
We would love to hear your feedback. If we don't have something, we'll build it. If there's a sticky spot in the DX (developer experience), we’ll fix it. Looking forward to hearing what you think—and thank you!
[1] Quick refresher: CMS stands for "content management system" and headless just means API-based, with no restrictions over where you use the content on the frontend.
> There's no point competing in that noisy market, so we're undercutting it instead, by treating developers as first-class citizens.
Who is the target market for this? who are the users and what is the job function in their company?
The vast majority of CMS use is by Marketing departments building the public web presence of their company. Marketing doesn't care about building or maintaining their own CMS, or making it easy for developers. In fact, those are costs they want to minimize and externalize.
Speed of creating, editing, reviewing, and publishing content is the most important thing. Integrating the site into the hundreds of mar-tech tools is also important (e.g. gating content for sales leads, funnel analytics, mailing list signup and validation, A/B testing, etc)
Large CMSs are pretty optimized for the create-review-publish flow, and I don't see you explain any advantage you provide here. Mar-tech companies live or die on adoption, so they invest heavily in making plugins for CMSs. Something they are not going to do for Payload. Why would marketing pay for internal developers to do this integration (regardless of how easy it is) when they get that for free with plugins to existing systems, written by the engineers of those systems?
In short, none of the benefits you cite at all align with the KPIs of a marketing department using a CMS (typical engagement numbers like time-on-site or page views, but also marketing-generated or marketing-influenced leads and opportunities)
And as an engineer who has built multiple SaaS apps, I've never needed CMS capabilities built into those apps. The closest need would be the help/documentation/API spec, which we've traditionally addressed using another site or SaaS app (e.g. a third party helpdesk or knowledge base SaaS).
Hence why I'm a little confused, but do want to be positive. Who is your ideal customer, why, what business problems do they have, and why is Payload the best option to those problems?