Hi HN! I work on Plasmic. It’s a visual page builder and design tool that generates React components and integrates seamlessly into your existing web app codebase. It empowers content creators to build things for production without involving developers.
When we started on Plasmic two years ago, we didn’t begin with this product-market. I’d like to share the backstory of how we got to where we are, but first, a bit more explanation of what Plasmic is for:
Today, teams that have a marketing/ecommerce/etc. website frequently run on a “JAMstack”—typically statically generated using frameworks such as Next.js. Whenever marketing or other business units have a request, developers either have to code up everything by hand, or set up a “headless CMS”—giant JSON editors that business users use to specify the content a page should show. Developers need to define the schema to reflect the (near-infinite) design needs of the business users, who in turn must interface with the schema by filling out sprawling complex forms that look nothing like the final page they are creating. Companies do a ton of work to build out this sort of bespoke non-visual page editing infrastructure. CMSes have perfectly reasonable uses, but visual content isn’t one of them.
With Plasmic, developers just need to render a <PlasmicComponent/> placeholder wherever they want Plasmic content to show up. Content creators then create their content using Plasmic’s visual editor. At build time, the Plasmic content gets downloaded and swapped in, and goes live with the rest of the site. This eliminates tons of requests on developers and lets content creators iterate quickly.
The visual editor is at the core of Plasmic, but we wanted it to be more than just a big form for filling out CSS values. We wanted:
* A design surface that resembles Figma / Sketch, but powered by real browser layout, allowing you to design across multiple variants and screen sizes at once.
* Styling and layout that is intuitive and smooths over CSS’s rough edges.
* A deep system of components and variants, where variants can provide specific overrides without unnecessary duplication. This is used for everything from responsive design to A/B testing and personalization to component states.
* Design tokens and mixins (bundles of styles) you can use to systemize your designs.
* Ability to use arbitrary custom React components in your design.
This last bullet — using arbitrary React components — is critical; it allows developers to craft custom building blocks for content creators to drag/drop and visually manipulate in the editor. These components can be anything from design system components to data-fetching blocks to animation/interaction wrappers. For instance, you can trivially introduce new types of reveal animations or new data integrations not built into Plasmic. This effectively lets developers extend and customize the platform, and lets them “build their own page builder” for their broader team to use.
Here’s a segment from our recent Next.js Conf talk showing this in action: https://www.youtube.com/watch?v=fhEwNlzzobE&t=278s
Please check it out—sign up at https://www.plasmic.app. We’d love any questions and feedback you have!
===
And now some backstory of how we got here.
We’ve worked on many product teams, where designers create vector drawings, and developers try to recreate them from scratch using the “real” tech stack. Because there are two parallel sources of truth that often diverge, getting anything done involved tedious rounds of back-and-forth to get everyone on the same page. When we first started on Plasmic two years ago, we wanted to create a design tool for React that can produce not just pretty mock-ups, but actually generate the final production UI code; it can be the single source of truth for designs, empowering designers to directly impact production, and freeing developers from rounds of pixel-pushing. Far from a new idea, but no existing tool has quite executed on this vision the way that we think about it.
So we built a visual editor that tries to be familiar to users of Figma/Sketch/XD, but uses true browser layout with CSS and DOM. Then we generated real production-quality “presentational” React components from your designs that live in your codebase, which you can use for your real application. Critically, this is not just a one-time export—instead, the generated React components expose an API where you can attach event handlers, pipe in real data, and add React hooks, but still allows you to keep updating the design in Plasmic and re-generating the code without losing your changes. This API between design and code is what made Plasmic a powerful tool and shared source of truth across a team. You can see a video of our very first release here: https://www.youtube.com/watch?v=K_YzFBd7b2I.
We grew a budding community of users (both developers and non-developers) who believed in this vision, and they started designing and building complex and interactive applications with Plasmic. We ourselves use Plasmic to build Plasmic itself, a very complex web app—and we were hooked!
In general, however, we found it hard for larger teams to adopt this radical new workflow; some developers prefer hand-crafting their CSS, some designers would rather not carry the additional burden of designing directly for production, and it was challenging for everyone on a team to agree on the right approach. While we truly believe that the designer-developer hand-off is still ripe for disruption, we wanted to find a use case where the pain was more pronounced.
We soon noticed there was a specific segment that was growing fastest—e-commerce and marketing websites. Here, the pain is acute—marketers and designers are churning out new promotions and landing pages at lightning speed, but are then blocked on developers to make them real. The pain is real both for marketing—who is responsible for results and wants these pages live yesterday!—and for developers, who are often pulled away from deeper engineering work to build these pages. We found Plasmic to be the perfect tool here, with both sides of the table motivated to make this work. After our first enterprise contracts, we decided to double down on the direction.
We’re continuing to grow as a “visual CMS,” but we still have an eye on adjacent use cases within visual design, particularly given the heavy overlap. Designing directly for production is still a use case that is dear to our hearts, and we believe that there is still a ton of untapped potential for direct manipulation, visual creation, and democratizing software construction in general.
I’d love to invite any questions and thoughts you have!