Launch HN: Payload (YC S22) – Headless CMS for Developers
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 ...
138 comments
[ 3.1 ms ] story [ 238 ms ] threadFor instance:
- Field-based access control - This allows a developer to use code to write complex functions in order to regular access to a field. This can also reference the currently logged in user's permissions/fields etc.
- Conditional logic - Functions can be written to show/hide certain fields in the admin UI
- Dynamic field types - Complex layouts can be built with the Block and Array field types. This allows the ability to build out more of a "page builder" type input vs. simple CRUD.
I hope that answers your question. Here are some links to the docs on each of those:
- https://payloadcms.com/docs/access-control/overview
- https://payloadcms.com/docs/fields/overview#conditional-logi...
- https://payloadcms.com/docs/fields/blocks
Prior to building Payload I was a consulting full-stack engineer. I have built large web apps using Laravel and have rolled my own admin UI a dozen times and I've worked within the official 'Nova' package too. Laravel had a few open source options which I didn't try as it seemed like support was better with Nova. The project I built went okay, but it was a ton of work over what you can do with Payload.
To add a field you have to: 1) create a migration to add a column to the DB 2) add your field to the model 3) define the field again in the nova "resource"
In Payload you do all of this in one place. Every field you define will have the proper DB schema, API and admin UI in a streamlined way without having to touch your app in a bunch of places.
Two other things that made me scratch my head while using Nova specifically. The first, I had to cobble together plugins for building blocks for component based field defintions and image uploads, but these didn't play well together at all. How could image uploads and blocks not be built-in core features? The other pain point with Nova is that it isn't refined at all, and they say it shouldn't be used for customer facing UIs.
Do you have a favorite framework/package you would suggest for mananging admin UIs and APIs that do a great job?
But if you've got something more significant that you'd like a hand with, we'd be happy to chat. Sounds great!
I'm constantly looking about for a new CMS system, either Strapi, Wordpress, etc, how does PayloadCMS compare to these?
What is PayloadCMS's killer feature?
WP is a blogging platform from the early 2000's that still uses many of the same code conventions that it started with. It does have a REST API, and you can extend it with plugins to work as a headless CMS, but it's riddled with inefficiencies and is truly a great example of why most devs would not think to reach for a CMS if they were building a SaaS app. Can you build a SaaS app with WP? Sure. Should you? Absolutely not. WP is good for its plugins and themes, but for anything more robust, it falls apart.
Strapi is a contender that is quite similar to Payload but they have a mixed focus on "GUI-based" logic and code-based logic. You design your content models with a GUI, and access control is highly limited to a typical RBAC pattern. Where in Payload, everything -starts with code-. You can version control your schema, because it's all just a config. Deploy to other environments (stage, prod, etc) with ease. Use and re-use functions across different collections. Even access control is handled beautifully with functions in Payload, and is significantly more powerful than RBAC.
I'd say our killer feature though is the simplicity, yet robustness of our admin UI. We have many features that Strapi does not have - like field conditional logic (Check a checkbox field, see more fields. Uncheck checkbox, those fields go away). Our admin UI is also completely extensible. You can create custom field types easily just by importing React components and passing them to a field config - then boom, your React component appears in the admin UI rather than the built-in component. It's intensely powerful.
There's a lot more, but these are just a few quick points. I've been using headless WP for ~6 years, and I've always liked the idea of Strapi, but never trusted it enough to hit production. That's why we built Payload.
Payload's config is straight up TypeScript. Import a React component, pass it to your config, and boom — it shows up in your admin UI.
Everything is written like that and this is certainly where we shine!
Outside of being written in TypeScript with more modern conventions, the fact that Payload borders on an application framework is what would make someone choose it over something like Drupal.
Feature-wise, this commonly means reusing Payload's auth in your own app(s), defining function-based access control rather than RBAC, swapping in React components into the admin UI, and more.
But another HUGE reason is that when we built Payload, we tried to keep its own internal conventions as close as possible to just regular JS / TS. If you know JS, you know Payload. With Drupal and even WP to an extent, you need to know how _their_ conventions work. It's all very specific to the platform and the Payload team has always hated that. Devs don't want to learn CMS - they want to learn the underlying language, and Payload embraces that to its core.
Drupal suffers tremendously from "by engineers, for engineers" and it's just an incredibly poor experience if you don't fit that mold. It's non-stop pain for no reward.
Having used it for a major project (both in daily use and in a big migration from D7 to D8/9), I will NEVER take another job that uses Drupal again... it is the second most dreaded web framework for a reason (above only Angular): https://survey.stackoverflow.co/2022/#section-most-loved-dre...
Halfway through our Drupal "upgrade" (rewrite, because D7 had no upgrade path), we just gave up on it and went to Next.js + a headless CMS instead. Everyone was massively happier after that... the devs, the editors, IT, marketing, content writers, analytics... Drupal was just soooo bad that even its newest version was years if not decades behind modern experiences.
Sorry I feel so strongly about this... the mere word makes my blood boil. I've never HATED a technology the way I hate Drupal, before or since. If you're considering it for a project for the first time, don't walk, SPRINT as far away as it as you possibly could.
I ran a team at a weekend hackathon event for non-profits. We needed to finish building their new site on the latest version of Drupal. I had SEVEN devs working on a 5 page brochure site with a page to manage events and we couldn't get it done! I felt terrible leaving it incomplete at the event, but honestly, with Drupal as the tech stack—my hands were tied. Luckily the developer who started the work was able to finish it a few months later.
To do it all over again, I would have convinced them to throw away what they had and use a different platform. If we used any other tech stack, we could have finished and launched the site during the event.
That was the first, and last time I touched Drupal.
Did you ever work with Magento 1? :)
Honestly, I hate to say this, but if you really want that level of server-side all in one power... maybe Drupal IS worth considering after all. Most modern sites aren't built that way anymore, instead opting to compose a site out of many services (eg a CMS for marketing pages, Discourse for a forum, an auth provider linking them all together, etc.)
A monolithic community on a single engine is in fact the kind of (rare) use case that Drupal actually fits... making its complexity possibly worthwhile. It's just overkill for most sites that aren't like that.
WordPress might also be able to get there eventually, with a lot of plug-ins, but at that point it would be so bloated that Drupal might actually be cleaner. Might also be worth checking to see if any of the older PHP CMSes (Joomla, etc.) are still being maintained.
Sorry, I haven't looked at this sort of use in years and wouldn't be able to provide more details than that :/
> To devs, "content management system" is usually a swear word.
Yet "CMS" is in your tag line. Is that not a bad idea then?
One goal of ours is to make this not the case - but you are 100% right. The whole notion of "app framework / headless CMS" doesn't have a good label so right now we've gotta make some concessions. We have this discussion quite often!
> 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?
(this does not affect your question)
I think that your comment is pointing at one of the areas that traditional CMS -do not successfully address- in that CMS is typically only thought of as a means to manage website content. But content is much more broad. Think of Spotify (managing album art, playlists, artist descriptions) but using that content through native apps, smart TV apps, web apps, etc.
For example, some of our current enterprise clients are using Payload to deliver _their_ clients with a customized copy of Payload to manage their own virtual events (attendees, webinar links, landing page content, post-webinar video recordings, etc). Or to manage a "broadcast platform" where their client can publish their own Roku channel (episodes, series, seasons, playlists, etc). This is all content, yet it's not marketing page content.
One of the bigger uses of Payload so far has actually been to power the entire backend for an Uber-like snow plow service, where the business side can log in and provide customer support, manage requests, approve service providers, and more. The devs were able to leverage Payload's auth, access control, hooks for Stripe integration, and last but not least - the entirety of its admin UI.
That's not to say that we -can't- power marketing websites. Of course Payload can do that in spades. But that is only one small aspect of our target market and we make the most sense for enterprise content needs, where dev teams may need to manage more than just marketing pages. Maybe they also need to manage customer support resources or more intense content needs (like Klarna).
In my experience implementing enterprise websites for large companies, the buying process usually goes like this:
- Director or VP of Marketing says we need to modernize and move to a better web stack, let's go headless
- They start to evaluate options, but need engineering backup because headless CMS is a tech decision
- They tell their engineering team to go find the best headless CMS
- Devs do the recon, then report upward
Our strategy is to appeal straight to devs, and by being a solid product that they can advocate for, they will. This is actually how Klarna found my agency when we were hired to build their enterprise site - by the engineers. Decision to go headless came from the top, but then engineers found me and selected tech. Same with a few of Payload's bigger inbound enterprise opportunities in the pipeline right now.
Long story short, I fully understand your question and in all reality our messaging is nowhere near sharp / completed. We've seen a lot of growth over the past few months and are about to the point where we can take a breath, revisit some of this, and razor-sharpen our positioning!
I worked in consulting for many years doing a lot of CMS projects for Fortune 500s. They always bought their CMS products based on the marketing pitch to marketers. It was mostly bs, but the pitch was always focussed on engagement, testing, analytics, funnels, acquisition. I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like. The current kind of this space is Adobe. They built up their "Marketing Cloud" vis a series of acquisitions and sell it as a fully-baked product that does everything you'd ever need and then attach an 8-figure price tag and hand you off to integrators (like the companies I worked for) to do the (also very costly) implementation. And it's really very hit and miss to get adoption after you've delivered them such an ornery beast to manage 30 pages of brocureware.
We managed to push a few clients towards Contentful which is headless and a lot more dev friendly but they also are pretty sneaky with pricing and get fairly expensive with anything beyond basic usage. I actually begged their sales team to do a better job selling to marketers because their pitch was too tech focussed. I think the sweet spot is to not just say "developers like it" but rather "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders. Also, my firm belief that building a suite of marketing tools by picking and mixing the best products is likely still easier and cheaper than buying any all-in-one tool that isn't great at anything.
> I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like
Totally agreed. A CMS should stick to managing content. And its flexibility should allow it to integrate with services that are purpose-built. In addition to those that you mentioned, a good example of this would be Algolia for search experiences.
> "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders.
I also resonate with this, and I think this needs to be worked into our positioning more, because that, at its core, is what Payload tries to do -through- its developer friendliness. When you don't have to fight your software, you save an incredible amount of time. At the core of any larger content infrastructure is code, and the more efficiently you can implement it, let alone maintain it, the more time / money you can save.
Just make sure your growth motion doesn’t stop there and layers in a way to nab the buyer.
Standard way is to outright ask for introduction or outbound, but there’s usually a clever referral mechanism you can discover somewhere.
e.g. “Ask your marketer for demo content” prompt, but with better copy.
This is very good insight and I will take it to heart.
Ever hear of contentful? https://www.crunchbase.com/organization/contentful
Or the entire category of headless CMS (A $600m/yr market growing at 20%+/year), for which eng is a primary stakeholder in the buying decision?
2. My initial thought was, "this looks fantastic… just as good as Sanity, which is a problem because Sanity is already around so what's the point? Really my only gripe with Sanity is that there's no free open sou—" oh dang, there it is.
Yeah, I will definitely give your product a shot on my next project.
However, v2 is coming and that will 100% be open-source!
And to be a bit nit-picky and to clarify our world-view: The API side of Sanity isn't 3rd-party (it's native to the platform), but it is hosted and propertary.
There are always trade-offs, so no, you don't get the kind of control you get when you host your own Express-server or sit on your own MongoDB instance, but then again, you don't have to do those things to have a scalable real-time document store that supports deeply nested document structures with queryable references (with referential integrity). We build our APIs specifically to improve developer experience where we take care of the hard parts™ so that you can focus on the productive things. All of our HTTP APIs are versioned, because we specifically want to avoid breaking changes as much as possible.
Furthermore, there are other things that you just get. Like GROQ which is way more expressive and flexible for querying data compared to GraphQL (which we also offer). You get on-demand image transforms. You get both content and assets behind a CDN. You have a mutation/patch API that can do transactions with pretty specific operations (“change only this value in an nested array for this key if it matches this value”). Since the backand has full attributed revision history, you can also have controls that prevents race conditions, so that you can programatically update documents even if people are editing them. You can define triggers for webhooks and its payload with GROQ, so you can use serverless functions (or a server) to update content based on conditions. You can hit the export API endpoint and get all of your stuff over a stream wherever you want it. And so on and so forth.
Of course, there are always use cases where you want a solution that can be run fully on-prem or specific bespoke behavior in the database/API-layer beyond the capabilities in the platform. If you need those things, then you should probably look elsewhere than Sanity.io, and Payload might be an excellent choice.
good job
How do you do your content nowadays? Git-based CMS? Markdown? Would love to know!
There's a loot of CMSs already, but the quality open-source ones is usually.. lacking. A high quality one with great DX has a huge potential
We never found anything that would have done the CI automation we wanted, or not without significant customisation. Do you support CI workflows at all?
I would love to hear more about this at some point too, btw.
It's true that some will self-host Payload, and that's awesome. But look at NextJS - you can self-host NextJS as well, but most people go to Vercel. Hosting a CMS is quite a bit more complicated than a static site or a set of serverless functions, because you need to have a database and permanent file storage as well. Payload will provide all of that out of the box with a one-click Git integration.
Our users thus far have been telling us that they struggle with cobbling together vendors and wish that this was easier, so we're building Payload Cloud as a result.
One other aspect of Payload Cloud is that even though we -provision- the infrastructure for you, you'll always have access to it. You'll be able to connect to your DB, back it up, export it, etc. This is all in the works now!
Would this work as a sort-of wiki, for crowd-sourced documentation and translations? Or is it a bad idea to let the public edit things?
Would love to see if you gave this a shot, and we'd be happy to help along the way on Discord!
From a quick look the key difference is that Payload's backend can be self-hosted, but Contentful is SaaS only.
You've said that you're targeting enterprise customers and mention an SLA in that respect. Does that mean your enterprise offering is also SaaS only?
[1] https://www.contentful.com/
- We are open source / MIT
- You can re-use Payload's auth layer in your own apps and with Contentful you can't
- Contentful has rigid RBAC, but Payload features function-based access control down to the field level
- Payload supports field conditional logic, meaning "check a checkbox, see more fields, uncheck it, extra fields disappear". This is huge. And is super hard to build right but it's very important for a good admin experience.
- Payload gives you a local Node API (note: not HTTP / REST / GraphQL.) Contentful does not. With Payload's local API, you can do lots of awesome things within hooks, access control, etc. - and even reuse it in your own endpoints. All of this is impossible with Contentful without going through their HTTP layer
- Payload lets you add your own admin UI views
- Payload has no usage limits
- Payload is code-first, Contentful is "point and click"
Phew. There's a lot more. This all is just top-of-mind word vomit.
Our enterprise offering can either be self-hosted or it can leverage Payload Cloud, once we have it built. Some enterprises opt to manage Payload on their own infrastructure, and just pay us for SLA and premium features like SSO, audit logs, etc. But we do have enterprises in line to use our managed infrastructure as well... so basically, the answer is "both".
Does that help answer your questions?
For the enterprise offering can you give a rough idea of pricing without having to book a demo etc.?
For hundreds of seats, with a more robust SLA, your costs would scale linearly, but it's entirely based on what you need.
Does that help?
most people wont read it, but the serious people will. and better to claim your narrative than leave it in the hands of users who know less than you about your own market.
What is the difference between this, and say a customized vBulletin et al.? (or, did I misunderstand what the offer is?)
Payload could power the same use cases as something like vBulletin, but its use cases are significantly more widely applicable because Payload is not geared solely toward being community software. Instead, Payload delivers a content API and admin UI to power / manage just about any type of digital product you can think of, ranging from enterprise marketing websites, to native apps, to omni-channel content (think Spotify music), to SaaS app backends, to video games. Of course, forums are included here.
Does that help clarify?
How simple is it to install Payload in an existing Next.js app to power basically just the /blog/* subdirectory?
Great question!
You'd be interested in the example repo: https://github.com/payloadcms/nextjs-custom-server
The example is set up to manage Pages, but with a few tweaks you'd be able to manage blogs posts instead.
Would love to learn more about:
* What you find finicky with installing basic components * What SEO issues that are connected to using GROQ/TypeScript
As far as I can gather from the docs, Payload doesn't come with more out-of-the-box components, and doesn't support custom blocks in the rich text editor, unless you commit to building the UI for it yourself?
I'm guessing this mostly makes sense for a SaaS that's mostly about serving content to users. I wonder how common that kind of SaaS is, as opposed to a SaaS where the core functionality wouldn't be served well by a CMS, and the administrative tedium that one wants to alleviate mostly has to do with account management, payment processing, enabling or disabling service based on billing status, etc.
The tedium of development in my experience is building CRUD—whether it is for a SaaS app or anything else. When you're rolling a project using a framework you've got to set up a database, write the API logic and build an admin UI to manage that data. It is complicated and time consuming work even with a great framework. To be able to skip all that is a massive advantage.
I personally would not build a SaaS app on Wordpress and ACF, but I would use Payload to build just about any custom business app.