Live data from Hacker News

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

news.ycombinator.com

21–30 of 139 posts

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

#21

Nice job getting to launch. However I'm really confused about the value prop. > 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. M…

Agreed! Do you have a favorite CMS?

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

#22

1. Outstanding marketing site. 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.

Yeah! The other big difference with Sanity is that the API side of Sanity is 3rd-party. So you never truly have control over the API logic or backend side at all. Whereas with Payload, you control both the admin UI AND the entirety of your API. That's what I mean by "closing the gap" between an app framework and a headless CMS. Lots more backend potential with Payload.

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

#24

Nice job getting to launch. However I'm really confused about the value prop. > 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. M…

Hey, great question. Our target market is enterprise uses of Payload, where we can power critical content-based infrastructure, but that does not solely mean marketing websites.

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!

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

#25

It looks awesome, I will give it a try. 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

Thank you! I totally agree. I've been using headless CMS since the start and have ridden along with a few of the options out there, but never trusted them enough to hit production.

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

#26
post #20

Nice. A page comparing this with existing solutions would be useful. In particular how does it compare to something like Wagtail which is a CMS but also has all of Django to fall back on for custom backend work.

Hey there - we do have a set of comparisons on our site (linked in the footer of the site), but we don't have a comparison to Wagtail yet. Would be happy to add this to the list!

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

#27

I just evaluated all the javascript headless CMS just last week and my conclusion is that the best offering in this space is probably directus. Maybe I'll do a writeup when my directus app gets up and running.

Yeah - Directus certainly provides a lot of value out of the box. We're a bit more razor-focused on a code-first approach vs. Directus, as the content model is stored directly in the database rather than being defined in a version-controlled schema. And in Payload it's much easier to swap in your own React components / customize the admin UI. But we really respect the Directus team for sure!

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

#28
post #13

Congratulations! > To devs, "content management system" is usually a swear word. Yet "CMS" is in your tag line. Is that not a bad idea then?

I lolled at this - gonna cause me to do some introspection, huh.

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!

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

#29
post #18

Looks great. Lots of little "nice to have"s all over the place, and the latency is pretty snappy. Not the way I'm interested in doing my content these days but I can see the appeal for sure. good job

Thank you! Yep, the fact that we ate our own dogfood for over a year really helped us fill in the "nice to haves" all over the place.

How do you do your content nowadays? Git-based CMS? Markdown? Would love to know!

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

#30
post #17
post #11

Earlier quoted context omitted.

Thank you! 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…

What you describe sounds similar to Statamic. The config and even the content is yaml files, and the admin UI is also quite extensible. But I always wish it was easier to change stuff with code in Statamic, so maybe that's where Payload shines.

Nailed it.

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!

Post reply on HN