New top story on Hacker News: Launch HN: Payload (YC S22) – Headless CMS for Developers

Launch HN: Payload (YC S22) – Headless CMS for Developers
34 by sneek_ | 9 comments on Hacker News.
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://ift.tt/QHqbwFT . 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. 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 table stakes when it comes to content: log in, create a draft, preview the draft, publish the content. Go back and update some pages. Define editor roles and localize content. Payload is different because we treat developers as first-class citizens. Payload provides 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. 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://ift.tt/QHqbwFT . The code for the demo is open source and available at https://ift.tt/ebULyaO . 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.