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 ma

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!