912: Why Did Figma Buy a CMS?  ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 912: Why Did Figma Buy a CMS? - Category: #podcasts - URL: https://share.snipd.com/episode/a8b8214a-bd23-43f6-a607-42c8ca69a25f ## Document Notes ## Highlights - **Payload's Unique CMS Vision** - Payload CMS is designed as a hybrid app framework focusing on application backends, not just content management. - Payload aims to bridge the gap between design fidelity and code architecture. Transcript: James Mikrut 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? 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 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. Wes Bos And what's the big announcement? Hit a layup on us. James Mikrut Yeah. I want to kind of start from the beginning here. Payload was actively raising a Series A. And I was out 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 going to be building over the next couple months, couple years are very, very exciting to me. But yeah, Figma has officially bought Payload. ([Time 0:01:17](https://share.snipd.com/snip/3fcdcc19-1768-4935-974c-790a6b693a2d)) - **Why Figma Bought a CMS** - Figma bought a CMS to close the gap between high-fidelity design and practical code implementation. - Payload's CMS naturally slots into Figma's workflow to manage data sources and design-to-code integration. Transcript: James Mikrut Work for Figma, which is very exciting. Well, congratulations. Wes Bos That's awesome. So I guess my first question is, what does Figma want to do with this? I'm going to call it a CMS. We understand that it is a suite of tools to build full stack applications and whatnot. But why does Figma want to buy a CMS? James Mikrut 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, 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 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. 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 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 into JSX and 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. ([Time 0:02:58](https://share.snipd.com/snip/4f7936d8-74bb-47f1-af39-a6330d0d6428)) - **LLMs Thrive with Declarative Config** - Large Language Models (LLMs) perform best when operating within predefined business logic and declarative configurations. - Payload's declarative config gives LLMs a powerful set of guardrails for accurate and maintainable output. Transcript: Wes Bos 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 those, that's not your typical, like you log in and like, like WordPress, you have, you have 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 like 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 backend code and whatnot. But with this, at least I see it is that it's, 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 on the other side, which is it's hooked into the actual design of the application as well. Right. James Mikrut 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. And that's also why it works well with declarative frameworks like JSX. 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 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. 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. ([Time 0:05:31](https://share.snipd.com/snip/252f6912-05aa-4e52-9780-bfb457c87470)) - **AI Frontend Generation Challenges** - James Mikrut shared his experience using an AI tool like Cursor for frontend JSX and how it failed to meet his design expectations. - He emphasizes the difficulty in automating high-fidelity design output with current AI tools. Transcript: James Mikrut I mean, I can give you a parable. So I have obviously used all of these, um, 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. And it was like a checkout, like multi-step form. Right 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 I think the fidelity of going from something that's well-designed and deliberate to code has lots of areas of improvement. ([Time 0:10:51](https://share.snipd.com/snip/194b4d75-b94d-450b-9003-3e24892881b0)) - **Visual Interfaces Remain Essential** - There will always be a need for visual interfaces that handle imagery, branding, and tone of voice. - Even conversational interfaces require visual feedback to craft user experiences. Transcript: Wes Bos 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? James Mikrut Well, I think there will always be some sort of visual interface. It's never just going to be text, right? 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, right? 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. Wes Bos I can't even, I don't say it, but I also don't apologize. I know what people are saying. All right. James Mikrut I'm going to do that from now on Twitter. There's this famous 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. 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? ([Time 0:14:38](https://share.snipd.com/snip/445af7c8-06f0-4464-9628-56261f7a270d)) - **Small Apps vs. Enterprise Scale** - Differentiate between quick small applications and massive enterprise design systems requiring pervasive, consistent design. - Payload supports scalable design system thinking important for large teams and diverse platforms. Transcript: James Mikrut 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 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, you know, for, for the, the Shad CN, 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. If they do a job. I always prove that consistent UI is good. Wes Bos Right. James Mikrut 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 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. ([Time 0:17:00](https://share.snipd.com/snip/2373e9a3-0444-4925-8bb2-655d4f2e86b9)) - **Keep Payload Open Source and Flexible** - Payload CMS will remain open source despite acquisition by Figma to protect community contributions. - Deploy Payload anywhere, ensuring flexibility for developers post-acquisition. Transcript: James Mikrut I'm still running it. The whole team is. And it will remain open source. Early on with conversations with the Figment team, who have been fantastic, they were very clear about, 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. That doesn't even know that Next.js exists. 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. 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 i see very clearly where we're going and i think everybody's going to like it and ([Time 0:18:30](https://share.snipd.com/snip/de42b9d7-8045-4701-8cc4-43088ac6e17d)) - **Figma-CMS Ecosystem Potential** - Integration of CMS with design tools like Figma opens huge ecosystem potential. - Automated asset syncing between Figma frames and CMS can streamline design-build-publish cycles. Transcript: James Mikrut Um, 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 is signed off on whatever. But then you want to use them in your CMS. And like's an entire other side of this. 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, that loop there, um, connected and seamless. ([Time 0:20:28](https://share.snipd.com/snip/468baf1c-9d19-4176-a5d7-f54503d1e118)) - **Building Unique Tools with Figma** - Payload aims to build unique features that solve problems no other CMS has tackled. - The goal is to empower both developers and designers while removing friction between design and engineering. Transcript: James Mikrut 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? 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. So 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. ([Time 0:22:42](https://share.snipd.com/snip/3bd20f42-cbc4-4f83-b3e1-956afcc0ccda)) - **James's Motorcycle and Malort Picks** - James Mikrut's sick picks included his perfect Triumph Street Triple motorcycle and Malort liquor. - He humorously cautioned not to enjoy both simultaneously. Transcript: James Mikrut Yes. Wes Bos Yeah. Give it. What's your sick pick? Lay it on us. James Mikrut 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. Wes Bos 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, ([Time 0:25:16](https://share.snipd.com/snip/024d9974-4221-4ecf-bb62-b2b08d2737ba))