Launch HN: Payload (YC S22) – Headless CMS for Developers

Hey HN, my name is James and I founded Payload (https://payloadcms.com/ 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 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 https://demo.payloadcms.com. The code for the demo is at https://github.com/payloadcms/public-demo 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.