Why did Figma buy a CMS?

Welcome to Syntax. We got a special one for you today. You probably saw the title, and I'm not gonna spoil it for James just yet because he's probably really excited about this. But when I heard about what had happened, I thought, like, let's get them on just for a little bit on the podcast and talk about, like like, what does it mean what does this mean for payload CMS? What does it mean that like, why why would Figma do this? And then third, like like, what is the future of building full stack apps, especially with all these AI tools, look like? And I think that, this was part of a play in that by Figma, and we'll find out. So welcome, James. Thanks so much for coming on. I love being here. Last time was a blast. Yeah. Super fun. We were we were staying. We had a a meetup in Denver a couple weeks ago, and we're like, man, we still gotta do Grand Rapids,

because I think that would be would be pretty fun to to do. Yeah. I think if you came here, we could make a pretty big deal out of it. We don't get a lot of interesting guests through this space, especially in the tech world. But, there's a little there's a little enclave of people that would be very interested. So That'd be fun. Cool.

Well, let's let's not beat around the bush here.

We'll do a quick intro. Payload CMS, give us a quick intro of what that JS, and then tell us your announcement.

Yeah. We actually in my head, we just refer to it as payload, but it is a CMS.

I think there's a huge, like, difference between payload and any other CMS Wes you usually think of CMS as something to manage web pages and blog posts and media. Right? But, like Yeah. And they're generally not very smiled upon by engineers because they're pretty tough to work with and very rigid, but Payload flips the script on all of that. And our biggest use cases are actually, like, application back ends for internal tools and whatever.

So we're kind of a hybrid app framework in CSS. And it's been a lot of fun to build, but, we're just beginning. That's exciting. And

what's the big announcement? Hit a layoff on us. Yeah.

I wanna kinda start from the beginning here. Payload was actively raising a series a, and I was out, you know, going down Sand Hill Road in San Francisco, doing the move, and talking to a bunch of investors. Got some pretty interesting opportunities, but Figma was interested in our series a. And I started talking to them, and it very quickly became apparent some very interesting things that we could build together.

And that went like, oh, Figma strategic investor, typical VCs.

My interest kind of centered fully on Figma because of this vision that we laid out together. And, yeah, it was a series a thing, but Figma and Payload are joining forces.

And the things that we're gonna be building over the next couple months, couple years are very, very exciting to me. But, yeah, Figma has officially, bought Payload, and now I work for Figma, which is very exciting.

Well, congratulations. That's awesome. So I guess my my first question is, what does Figma want to do with this? I'll I'll I'm gonna call it a CMS. Like, we understand that it is a suite of tools to build full stack applications and whatnot, but, like like, why does Figma want to buy a CMS?

Yeah. I don't think I'm gonna fight calling it a CMS either anymore.

Yeah. I think that the perception of CMS should change a bit, but, I think that is a pretty accurate description for us. So, you know, Figma is a digital design company. Right? They work very well with the design workflow and allow design systems to be crafted to high fidelity, and exploration can be just perfected.

But there's still a pretty big gap between design and code. And for me, personally, I don't wanna compromise on any of it. I wanna use a professional design tool for the design side of the work involved, but then I want to architect something beautifully in code that I understand, that I can build on top of in six months, and I can bring a whole team in, and we can all effectively work in a system together. Like, the better engineered that side of it is, the more interested I am in working on it.

And, Figma sees that. Right? There is currently kind of a gap between design and code, and they're making a lot of strides to closing that gap. But, I mean, imagine, like, a button in your design system. Right? It's in Figma. It is beautiful. It's got all the states.

And you can specify, like, the appearance and the the properties of the button in, like, the different varieties, but you could also go to code from that. Like, they just released an MCP server, which basically high fidelity, like, takes your frame and transforms it into JSX GitHub losing any detail. But that's only half the battle. There's also Wes does the data come from? Like, if you're gonna connect that button to an interface for admins to be able to place that button in different pages or different areas of your, website, whatever it is Yeah. Then you need to know about that too. Right? You need to know about the data, the source of the data, the shape, the types, everything.

And so to effectively close that design to code gap, a CMS is actually a pretty natural thing to slot into that equation.

And I'm really only hitting the obvious parts right Node, but I think what we're gonna be doing goes far beyond just informing design systems.

Mhmm. I was pretty excited when I heard this because, the idea with payload is that, like, like, it's both, like, kind of like your ORM. Right? Like, you can you set up your data types and your whole schema and everything like that, and then you also get, like, a, like, a UI that you can can use to edit it. Right? And and though that's not your typical, like, you log in and, like like, WordPress, you you have to find where that piece of data lives in the back end of it. Right? They're they're a little bit more connected.

And AI is is so good at writing like like you said, it's so good at writing JSX, and it's so good at writing interactive applications.

But wouldn't it be especially, like, AI is so good at Next. Js as well. Right? It can spit out components. We've seen v zero is very good at that.

But, like, the the one step further is is what if it was, like, totally trained on something that could save data? I know GitHub had something like that that they're they're kinda working on as Wes, but, like, going that one step further of it's able to spit out Scott to nuts absolutely everything. Like, kinda right now, we're just, like, in the the the the application. Right? And it can write some back end code and whatnot. But with this, at least I see it JS that it's it's pushing it a little bit further into the, like, saving to database and and being able to manage your data side. And then what I I hope comes of this is it goes a little bit further in the other side, which is it's it's hooked into, like, the actual design of the application as well.

Right.

I was laughing because I need to look up the origin of the phrase soup to nuts. I don't know what that could possibly have come from.

But, yeah. So for payload, we haven't really started focusing on this yet, but one thing that I know that is true is that large language models work best when they can use systems that have predefined guardrails for business logic. And this is how you do this. This is how you do that. And you write this, and then you get all this. Right? And that's why it outputs Tailwind 99% of the time. Right? Yep.

And that's also why it works well with declarative frameworks like like JSX. Right? But payload has our config, which is declarative. It takes the complexity and makes it simple. You don't have to open up your own endpoints.

Like in a typical MVC world, you define your models and your views and your controllers and all of that stuff, and you basically wire it up all from scratch. Right? And that's a lot of complexity. Even though it's a framework and it makes something simple, makes them maintainable, you still have a lot of Node, and it's verbose.

Whereas with payload, you just define your schema, and then you get your whole set of APIs. And you get your entire admin UI, and you get everything that is derived from that one config, which an LLM should be able to output very accurately.

And the result of the code that the LLM outputs is within the confines of predefined business logic. Right? So it's not creating something from scratch. You Node? An LLM JS very good at writing raw SQL queries, But is that really the future? Is an LLM is gonna write raw SQL queries for every single thing that your app needs to do? Probably not. Right? And so I think that's kind of a superpower of ours.

I think you will see us double down on that.

But, ultimately, one thing I also feel pretty passionately about is that large language models will automate a lot of what we do and make it easier to be efficient while we work as engineers.

But I personally have a great interest in not surrendering engineering perfection to something else. Right? And in certain complexity levels, an LLM will be able to get you going, but then you, as the author of this product, can enforce architecture that ultimately makes it more efficient and that makes it better organized and, more dry. And those types of things are really interesting to me. I don't wanna sacrifice on my ability to get in there and clean and to

organize. Right? So it'll play together, I think. And if you want to see all of the errors in your application, you'll want to check out Sentry at century.i0/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to century.i0/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

The the space of building sites, let's talk about that right Node, is like the or maybe the interface of of building sites right now. Right? You see there there's there's chat apps. Right? You got Bolt and v Deno and Lovable and and things like that where where you type into the chat box and it kicks something out on the out the other end.

And then the other hand, we've got, like, a cursor, which is you've got agents, and you kinda tell it what you wanted to do. And then there's there's several other sort of implementations of, like, what does the interface of building a website look like? And then throwing design into the mix as well.

What are I know you don't have concrete plans of of what this will look like, you know, specifically in Figma. But I just in general, like, what do you think is the interface of building sites will look like?

Yeah. I mean, I can give you a parable. So I have obviously used all of these, vibe coding tools, and I think they're incredible. Right? Like, they can do a lot. Yeah. And, clearly, the industry is changing, and there's real opportunity here.

Although Node time I was building a proof of concept for a prospect of payload, and I don't want to write tailwind classes myself. Like, I don't find that enjoyable. I don't want to write like HTML structures. I want to like if I can take a shortcut to get through that part, I'm going to take that shortcut. Yeah. Although so I tried to use I was using cursor. I was, like I personally did the back end in payload because I was excited about it. But then when it came to, like, the JSX on the front end, I was like, oh Node. I've done this so many times. I don't wanna do it again. Yeah. And so the front end was purely Cursor's responsibility.

Right? And it was like a checkout, like, multistep form. Right? So you have step one, like, I don't know, shipping address. Step two, billing info. Step three, review. Step four, congrats.

And I had this, like, Figma design, and it Wes, like, three circles or four circles with, like, step labels. Right? Everybody's done this. With, like, a little line that connects the Vercel, and the first step highlights the first one. And I had this JPEG, and I'm uploading it to cursor.

I'm like, please please make sure that the line that connects the dots is centered vertically and make the space have enough space for each label so that, like, step one, billing info. And I gave it the design intent, but it just could not hit what I wanted to do. And by this point, I'm not ready to tailwind. I'm not gonna get in there and clean up this AI generated code. Like, please, just can we get there with Vibes? And we did not get there with Vibes. And I actually had to, like, stop trying because it just was getting worse, and I was spending a lot of money. And, like, I think the fidelity of going from something that's well designed and deliberate to code Mhmm. Has lots of areas of improvement. Like, if I have something that's already deliberate, I know what it needs to be. I've designed it exactly how I want it. There's a lot of opportunity there to, continue to invest in the fidelity, which also has data ramifications as well. Right? So, to really create a seamless process that not only allows you to get to an MVP, but also allows you to continue extending and building and maintaining, you kinda need to know about all these different pieces altogether.

And so I think the future will have, it will require a system that can be well trained for specific goals, and design is where it starts. Right? That is you you I don't know if I've told you this before, but I started as a designer. Like, that is that is my history.

So I feel very passionately about like, the good products will start with intent.

They will start with explicit, goals, and those goals and that intent will be designed. And so, I'm very interested in payload actually having the ability to connect to design in more natural ways.

That'll be the future. Interesting. Interesting. And

something I've heard several times, which I'm not sure I buy or Yarn of me is like, that kinda makes sense, and part of me is like, nah, nah, is the fact that design or UI will not be something that is the same for everyone, meaning that the UI may be generated as you need it. You know? Like, I want to build my own UI for for Twitter or something like that. And part of me is like, that sounds great, but a part of me is, like, most people don't know what they want. And then the other part people say is that, like, there will be no UI. It it's just MCP servers all the way down, and you just simply talk to it back and forth.

Do you have any thoughts on either the generated or the just the Node UI as well?

Oh, I think there will always be some sort of visual interface.

Yeah. Doesn't it's never just gonna be text. Right? Like, as soon as you introduce any type of imagery, video, assets, brand, tone of voice, experiences will need to be crafted no matter what. I do think that there's a world where we just talk to our devices and, like, they do what we need, but they're still gonna communicate with you. Right? They're gonna get it's gonna be a back and forth. And so there will be an interface aesthetic, brand, tone of voice, all those things. Mhmm. As far as somebody creating their own interface for something like Twitter x, it's been years. I should just get on that train.

I've I, I can't even I I I don't say it, but I also don't apologize. I know what people are saying.

Alright. I'm gonna do that from now on Twitter. Like, there's this famous, like, Node on x that Yeah. There's an x button to close the window, but then there's the x icon Oh, yeah. Which is the logo.

Which one do I click? This is insane.

Yeah. I think there will be, like, human interface three point o coming soon. Right? Like, the touchscreen was a big evolution of interface design, but there is another wave of interface design that's coming that none of us can really fully predict right Node. But I do feel pretty confident knowing that each one will need to be deliberate, customized, complex, and have a lot of jobs to do. That you can't just cowboy your way into, like, oh, I want x to work this way. Right? Like, that's that's gonna be, I don't know that I buy that either.

Yeah. Yeah. Yeah. I agree. I'm I'm kind of excited about this because, like, a lot of the, like, AI generated apps do look good because a lot of them are built with Shad Sien, and Shad Sien looks awesome.

But they all do look somewhat similar because people don't go further and customize them for for what it is that they need. So I think, like, putting that into the mix of, like, being able to document it and and play around in a design tool and then push that into your your code and, like, keep those lanes open as well. You know? What happens if I change something in one spot and and then they're synced?

Well, there I think we should kind of disseminate between two different types of applications. Like, there is the small application that you need to get up and running quickly, and then there is the massive enterprise design system that's very deliberate and branded that needs to be pervasive across 16,000 different

digital footprints. Right? Yeah. And Eight different frameworks.

Yeah.

Yeah. Yeah. And so yeah. Eight different frameworks. Like, you might have, like, a ESLint app that has the same look and feel as the web equivalent, and they need to be consistent.

So there's that common denominator of the design system that needs to pervade both of those surfaces.

And so, you know, for for the the ShadCN, like, number one, I love what they're doing, and I think it has a lot of value. I don't even think that there's a problem with certain apps looking and feeling in the same way. No. It's like I do a job. That that consistent UI is good. Right.

Right. But that doesn't negate the need to have a well defined system, especially for scale. And those are two different outcomes. Those are two different goals. Right? Mhmm.

I've always liked systems. I've always liked working on larger projects that need to be thought through carefully.

And that's I think that's why Payload is good because it allows for that type of thinking, and it encourages it. But, yeah, there's both, really. There will perpetually be both of those, different worlds.

Let's talk about people who are using Payload right now are probably watching this and saying, like, what's gonna happen to Payload? So what's gonna happen to Payload?

I'm still running it. The whole team JS, and it will remain open source.

I you know, early on with conversations with the Figma team who have been fantastic, they've were very clear about, like, we love the open source community that you've built. This this community is fired up. They are making pull requests. They are contributing to RFCs on GitHub. They are helping shape your product.

The engagement is incredible, and the open source nature of the product is very important to us. And Figma as a company, I think they've always wanted to do more in open source, and they wanna foster this. They Payload will remain open source. I think it's easier now than it ever has been to deploy payload wherever you want. You can put it on Vercel because, obviously, with Next. Js, you could put it on Netlify. You can put it on a container.

You can spin up an e c two and manage your entire Tolinski, whatever, yourself if you want to. That will remain. Payload JS a core framework is kind of like layers of an onion Wes Payload JS the centerpiece, where we maintain all of our config and our business logic and our access control and our hooks, like, that doesn't even know that Next. Js exists. Right? Like, payload itself does not have a dependency on React or Next. Js.

But then if you wanna go with Next. Js, then boom, there's that Next. Js package that allows you to use the router and all that stuff.

But the core payload framework is gonna be built on, and it's gonna be integrated into new ways inside of the Figma ecosystem, and it's gonna be maintained.

It's gonna be doubled down on.

It will still be free and open source, but it will power a lot more. So it's gonna get a lot more exposure, a lot more usage, a lot more eyesight. And I'm pretty excited about that. I I I see very clearly where we're going, and I think everybody's gonna like it. And when you say power a lot more, like, what does that what does that look like? So being that we are called the CMS, right, CMS is often thought of as the core thing in a marketer workflow, not necessarily a developer workflow. Right? So there are a lot of opportunities. Like, when we talk to customers, they want AB testing. They want, better asset management.

Right? So, like, there's entire different, like, tool ecosystems called digital asset management, DAM.

And you upload a bunch of assets, and you mark these ones are public, these ones are private, these ones, like, the brand team has signed off on, whatever. But then you wanna use them in your CMS and, like, there's an entire another side of this. Like, the data in your CMS needs to connect to your design system. It needs to be integrated with other surface areas that the rest of your team can use, not just developers, but also the marketing team or content managers or anything.

And if you think about Figma as an ecosystem, there's so much potential there. Right? Like, imagine a frame in Figma.

You click that frame and export an asset to your CMS. Right? And it's linked so that if the designer goes and updates that frame, then the asset is automatically updated and used on your Node page of your website or something like that.

The ecosystem is huge. Right? So payload as an app framework is already damn good, and that will get better. But there's just a whole world of potential opportunities to make that brainstorm, design, build, publish, brainstorm, design, build, publish that that loop there Yeah.

Connected and seamless.

And I'm pretty excited about all that. Oh, that's awesome. I never even thought about that, but it it's true that the the people use Figma in many different ways. You know? It's not just a so Node just a design tool. The the amount of, like, slide decks now that I see or or, like, little pitches or, like, presentations that are are in Figma, it's like, oh, wow. I I think I I realized that this is not just to build some buttons on and and and export them for in CSS. You know?

Right. Yeah. And I don't have a full answer to what are we gonna build over the next five plus Yarn. But Yeah. I can tell you that it's going to be things that only we can do. And that is another part of the the decision factor of, like, okay. Are we gonna raise a series a? Are we gonna keep growing? Are we gonna keep taking investor funding? Are we gonna be another CMS face in the crowd? There's a million of them. Right? Or can we truly do things and fix different problems that no one else has even thought about before? Right? And that, I truly think that we're we're moving in that direction and that we don't need to make any compromises at all as we do it.

I don't wanna make compromises. I want developers to have the tool that they want. I want designers to have the tool that they want. I want them to work well together and finally remove some of that friction between those two processes.

Mhmm. And then once the once the product is built, it needs to be maintained and operated by an entirely different set of people.

So I just think there's a lot of opportunity to fix things in this industry that haven't ever been fixed before.

Well put. No. I mean, I think everybody's gut reaction is that payload is gonna be paid, and you're never gonna be able to use payload open source again. And that's just not true. That is very important to us that we're going to, continue to protect the open source nature of payload. Right. I think you're gonna see a lot of design to code improvements. I think you're gonna see a lot of native connections to tools that you already use, a lot of investment in, large language models outputting the config.

Just a lot of lot of good good stuff.

Sick. Well, I'm super stoked to see what you guys build.

Super excited, and congratulations again for you. I'm sure you're you're excited to get going and and start building all this stuff. I'm sure that was not a, I'm sure that was a very long process.

And now I'm you probably just wanna get heads down and start building stuff. Yeah. The team has been busy in the meantime. I mean, this has been in the works for a while, and we've shipped folder view. We've shipped orderable collections. We've shipped more join field features. Like, all those features, everything we've been doing recently has been in parallel to all of this.

And I had my second kid a couple months ago, so I have a newborn at home with that.

It's it's been a lot. Congrats. Yeah. I'm excited to build.

Sick. Sick. Cool. Well, hopefully, we'll be able to come down. If if you are listening to this and you wanna see us in Grand Rapids, let us know because, we we've been talking about doing a a world tour, and I've been I was telling them, I was like, we should do Michigan.

Scott from Michigan. He can visit his family.

So we'll we're gonna try and make it happen.

Alright.

Are we doing a sick pick? Because that just gave me an idea.

Wes. Yeah. Let give it. What's your sick pick? You let let lay it on us. Well, my first choice was gonna be my motorcycle because it's perfect, and I wanna buy a new one, but I don't have anything to buy because mine's already perfect. That's the Triumph Street Triple. But the real idea that you just gave me was that if anybody wants to stop by Michigan, there's this thing called Malort, which is really good. It's a liquor that is from Chicago that is kind of a thing around here, but you'll find out what that means. And that's my sick pick, Malort, for sure.

Oh, man. Extremely fast motorcycle and some alcohol. Those are some great sick picks. Please do not enjoy those at the same time.

No. No. No. Different times. Awesome. Well, thanks so much for coming on. Appreciate, you giving us the little bit of a scoop on this, and congrats again.

Thank you, and thanks for having me. I hope you're well. Peace.

See you.