sneek_

WP made me want to pull my hair out

Check out Payload - fully OSS, modeled after the … few good parts of WP

https://payloadcms.com

I built it because I was in the same situation as you.

now that we're built on Next.js (3.0 beta), we now use Next.js as an optional head

you can still use Payload headless of course with any frontend but out of the box you have everything you need. it's pretty nifty

100%. We are actually working on a little "badge" style thing. Needed bad.

Hmm, one clarification - there is no enterprise Payload version. All of our enterprise features are just plugins - which anyone could build.

In this way, would you consider WordPress to be open-core as well, considering the amount of paid plugins there are available?

Fair. Good feedback. For what it's worth, we are actively looking at our licensing model trying to make it easier for situations exactly like yours.

Might have some updates for you soon.

Happy to hear this! Thank you for chiming in here. Hope to see you around the community.

Hey! Would love to hear more about this.

Performance problems are usually something related to maybe missing indexes in your database for fields that you query on often, or similar. Payload itself is super thin. Can you give me an example of where you're seeing slowdowns? Maybe I can point you in the right direction.

Also I would love to hear about where Payload is not flexible enough. Extensibility is one of our priorities so if there is something you'd like to accomplish, but can't, I will see what I can do about it!

Payload has a form builder plugin - https://payloadcms.com/docs/plugins/form-builder#form-builde...

have you seen that?

Hey there - small to medium orgs can use one of the available community, open source SSO plugins, with the only caveat that they are not officially supported by Payload. Or you could build your own!

Question - does the word "enterprise" make you think that the amount we charge would make it unfeasible for your org to pay to use Payload?

I don't think it's ideal that we hide all our "premium" features behind the word "enterprise" and have been thinking of alternative words / messaging to describe that.

I think server components have been very badly marketed. They're totally opt-in, so I don't see how this would make React instantly a terrible framework. I for one think they represent a lot of value.

If you don't use them, then React is quite literally no different to you.

Hey! I'm CEO of Payload and want to make sure we resolve any bugs you found. Pretty much the whole team is focused on closing issues right now as we work toward 3.0 stable so depending on when you were trying out Payload, I'd imagine you might see lots of the bugs you faced as already resolved.

Keystone would be my other vote though, if I were looking for a CMS and Payload didn't exist. I think that is a solid crew.

We have a package that allows you to deploy Payload in a NextJS app serverlessly, and it works great. I actually tried bundling as one endpoint early on while exploring with the NextJS approach and it seemed to work perfectly. But honestly I can’t remember the pros and cons.

I’d say give it a shot, and if you need anything, let us know!

Thank you! That’s one of my favorite features too. Pretty straightforward to implement too. We’ve got some examples in the docs and the repo if you’re interested.

Honestly you nailed the reason why Payload exists. Both the editor AND developer experience are important and when you have both, you end up with a better project.

If you need anything as you build, let us know and we will make it happen! Exciting stuff.

Awesome to hear! Thank you for your comments!

Hey Sanju - would love to know what you think about Payload (https://payloadcms.com).

We were in YC S22 and we've done a lot of what you've mentioned. Our ambitions are the same as yours. Maybe we could collaborate?

Hey there - I'm CEO of Payload (YC S22) [1] and you're speaking my language.

We're an open-source CMS where you completely own your database. Right now we're MongoDB-only, but we are actively working on adding Postgres support and that should be done VERY soon.

[1] https://payloadcms.com/

Don't worry, I've been a designer for 15 years and I know intimately that I can't please everyone.

It's hard to get under my skin. That's actually I think what your takeaway should be here - - you can't please everyone, but you should take all feedback as valid and try and deliver something that solves for your problem the most widely.

If someone feels something, then they felt it. Including your reaction to my site, and the others' reactions to your site.

Hi, I made the Payload site

Apparently it triggers you. I don't claim that it's perfect by any means (actually I think some of what you're saying is right).

Payload (YC S22) uses GitHub issues solely for bugs—no feature requests, RFCs, enhancements, good first issues, etc. It helps us prioritize, stay efficient, and provide an accurate picture of what a developer can expect to run into at any given time with the repo.

We're not the first, but it has been paying some dividends so I wrote up a little of our rationale.

Would love to know others' experience here and if anyone else is doing the same, or deliberately doing the opposite.

Ugh I am so happy that this paragraph resonated with you. I personally wrote it and it's so, so important to me. It represents the ethos of what we're trying to do with Payload. The whole team and I feel very strongly about this.

Thank you for your kind words and I would love to help you as you start your next project with Payload!

100%.

This is very good insight and I will take it to heart.

Thank you! I agree!

Ha actually that is a mockup and I personally wrote that in in there to give peoples' brains a blue screen :)

Sort of an easter egg. I also worked in a bunch of references to Metal Gear Solid (so good) elsewhere in our screenshots as well. This is likely going to all be removed though as I really wouldn't want people to think this is a Payload bug!

Yeah! That is, Chiselstrike with a purpose-built admin UI that accompanies your backend. That's a big one-up for Payload.

Thanks to using MongoDB as a database layer, you will not lose your data if you rename fields. This is a huge benefit for NoSQL in general honestly and it is one of the reasons why we chose to move forward with Mongo initially. We will be supporting Postgres + others in the future, at which point we will be introducing a migrations pattern, but for now, you don't need to worry about that at all.

With Payload as it stands now, to migrate data from one field to another, you can make use of Payload's Local Node API to move data from one property to another with ease.

I totally hear what you're saying. One thing I can say extremely confidently is that while my agency was eating our own dogfood with Payload during 2020/2021, we released some large projects on Payload and have kept Payload updated in all of those projects since. It's been seamless. A large focus of ours since the beginning was to identify an API that could reduce breaking changes to an absolute minimum and to restrict the use of other packages wherever possible, to avoid the NPM whirlwind. Our config-based approach has delivered exactly that. All of our projects, and our customers' projects, built even before beta release have been updated without issue. But this is certainly systemic to NPM and especially if you look at packages that are of lesser quality. That's the classic downside to the way that the JS ecosystem does things - it's basically open-ended at every turn. Even with React. But I am very confident, having had experiences very similar to yours, that it's handled quite effectively with Payload.

On another note, one of our goals with Payload was to rigorously minimize the amount of learning that you have to do to get up and running with Payload's specific conventions. This was a huge requirement of ours while we designed our initial API. We've always _hated_ having to learn the intricacies of another platform like Drupal or WordPress before being able to be proficient in those systems. It's like you have to get a degree in the CMS before you can use it rather than sharpening your skill set with the underlying language.

Payload's conventions are quite flat and are all config-based. From there, you write your own code to do whatever you want in the conventions that you're used to.

Oh I can intrinsically relate to what you're saying. I would love to see your project revived on Payload. If you need a hand, please do reach out on Discord!

Thank you! We would love to help support you in your first Payload project if you need a hand. We're super active on Discord. Stop by if you need anything!