912: Why did Figma buy a CMS?

Welcome to Syntax. We've got a special one for you today. You probably saw the title, and I'm not going to 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 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 um 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 staying.

We had a meetup in Denver a couple weeks ago and we're like, man, we still got to do Grand Rapids because I think that would be pretty fun 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 is especially in the tech world. But, um, yeah, there's a little, there's a little enclave of people that would be very interested. So that'd be fun. Cool. Um, 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 is 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 difference between payload and any other CMS where you usually think of CMS as something to manage. web pages and blog posts and media, right? But like, 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 backends for internal tools and whatever. So we're kind of a hybrid app framework in CMS. And it's been a lot of fun to build, but we're just beginning. That's exciting. And what's the big announcement? Yeah, I want to kind of 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. 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. The things that we're going to 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 first question is, what does Figma... want to do with this 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 going to fight calling it a CMS either anymore. 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. 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 want to compromise on any of it. I want to 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. 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 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 without losing any detail. But that's only half the battle. There's also where does the data come from? Like if you're going to 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, 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 now. But I think what we're going to be doing goes far beyond just informing design systems. 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 UI that you can use to edit it, right? And that's not your typical, like you log in and like WordPress.

to find where that piece of data lives in the back end of it, right? They're a little bit more connected. And AI is so good at writing, 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 V0 is very good at that. But like... The one step further is what if it was totally trained on something that could...

save data. I know GitHub had something like that, that they're kind of working on as well. But like going that one step further of it's able to spit out. soup to nuts absolutely everything like kind of 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 is that it's pushing it a little bit further into the like saving to database and being able to manage your data side. And then what I hope comes of this is it goes a little bit further in the other side, which is. it's hooked into 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. Yeah. And that's also why it works well with declarative frameworks.

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 code.

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 know, an LLM is very good at writing raw SQL queries.

But is that really the future? Is an LLM is going to 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.

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 want to sacrifice on my ability to get in there and clean.

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 sentry.io forward slash 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.io forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right. The space of building sites, let's talk about that right now, or maybe the interface of building sites right now, right? You see there's chat apps, right? You got Bolt and VZero and Lovable and things like that.

where you type into the chat box and it kicks something out the other end. And then the other hand, we've got like a cursor, which is you've got agents and you kind of tell it what you want it to do. And then 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. I know you don't have concrete plans of what this will look like, specifically in Figma, but just in general, what do you think the interface of building sites will look like? Yeah, I can give you a parable. I have obviously used all of these... vibe coding tools and i think they're incredible right like they can do a lot and clearly the industry is changing and there's real opportunity here

Although one 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. Although, so I tried to use, I was using cursor. I was like,

I personally did the backend 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 God, I've done this so many times. I don't want to do it again. And so the front end was purely cursor's responsibility, right? it was like a checkout, like multi-step 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 was like three circles or four circles with like step labels, right? Everybody's done this with like a little line that connects the circles 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 writing Tailwind. I'm not going to 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 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 kind of 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. I don't know if I've told you this before, but I started as a designer. 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.

Something I've heard several times, which I'm not sure I buy or part of me is like, that kind of makes sense. And part of me is like, no, no, 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 the 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'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 no UI as well? Oh, I think there will always be some sort of visual interface. It's never just going to 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 they do what we need, but they're still going to communicate with you. It's going to be a back and forth. And so there will be an interface aesthetic brand. tone of voice, all those things. 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 can't even. I don't say it, but I also don't apologize. I know what people are saying. All right. I'm going to do that from now on Twitter. Like there's this famous like modal on X that. There's an X button to close the window, but then there's the X icon, which is the logo. Which one do I click? This is insane. Yeah, I think there will be like human interface 3.0.

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 now. 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 going to be...

I don't know that I buy that either. Yeah. Yeah. Yeah, I agree. 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 ShadCN and ShadCN looks awesome. But they all do look somewhat similar because people don't go further and customize them for what it is that they need. I think like putting that into the mix of like being able to document it and play around in a design tool and then push that into your code and like keep those lanes open as well. You know what happens if I change something in one spot? And then they're synced. Well...

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. thousand different digital footprints. Right. Yeah. And eight different frameworks. Yeah. Yeah.

Yeah, eight different frameworks. You might have a Swift 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 for the ShadCN, number one, I love what they're doing. 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. If they do a job. 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? 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 going to happen to payload? So what's going to happen to payload? I'm still running it. The whole team is. And it will remain open source. I, you know, early on with conversations with the Figment team who have been fantastic, they were very clear about like, we love the open source community that you've built.

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 want to foster this. 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 we're Next.js. You can put it on Netlify. You can put it on a container. You can spin up an EC2 and manage your entire Linux, whatever, yourself if you want to. That will remain. Payload as a core framework is kind of like layers of an onion where payload as 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 want to 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 going to be built on and it's going to be integrated into new ways inside of the Figma ecosystem and it's going to be maintained. It's going to be doubled down on.

It will still be free and open source, but it will power a lot more. So it's going to get a lot more exposure, a lot more usage, a lot more eyesight. And I'm pretty excited about that. I see very clearly where we're going and I think everybody's going to like it.

And when you say power a lot more, 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 A-B testing.

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 want to 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 homepage 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 loop there connected and seamless. And I'm pretty excited about all that. Oh, that's awesome. I never even thought about that. But it's true that. The people use Figma in many different ways. It's not just a design tool. The amount of slide decks now that I see or little pitches or presentations that are done.

In Figma, it's like, oh, wow, I think I realized that this is not just to build some buttons on and export them for in CSS, you know? Right.

Yeah. And I don't have a full answer to what are we going to build over the next five plus years, but I can tell you that it's going to be. Things that only we can do. And that is another part of the decision factor of like, okay, are we going to raise a Series A? Are we going to keep growing? Are we going to keep taking investor funding? Are we going to 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 moving in that direction and that we don't need to make any compromises at all as we do it. I don't want to 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. And then once the product is built, it needs to be maintained and operated by an entirely different set of people. I just think there's a lot of opportunity to fix things in this industry that haven't ever been fixed before. Wow. Well put. No, I mean, I think everybody's gut reaction is that...

payload is going to be paid and you're never going to 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. I think you're going to see a lot of design to code improvements.

I think you're going to 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 good stuff. Sick. Well, I'm super stoked to see. what you guys build. I'm super excited. And congratulations again for you. I'm sure you're excited to get going and start building all this stuff. I'm sure that was not a... I'm sure that was a very long process. And now...

you probably just want to 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. It's been a lot. Congrats. But yeah, I'm excited to build.

Sick, sick. Cool. Well, hopefully we'll be able to come down. If you are listening to this and you want to see us in Grand Rapids, let us know because we've been talking about doing a world tour. And I was telling them, I was like, we should do Michigan. Scott's from Michigan. He can visit his family. So we're going to try and make it happen. All right. Are we doing a sick pick? Because that just gave me an idea.

Yes. Yeah. Give it. What's your sick pick? Lay it on us. Well, my first choice was going to be my motorcycle because it's perfect. And I want to 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 pics. 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 ya.