What is Plasmic, and how does it ship pages?
Plasmic is a visual builder for web pages and components, with a built-in headless CMS. Designers and marketers compose pages in Plasmic Studio, while developers register their own React components so those pieces can be dropped onto the canvas. The result reaches your site in one of two ways, and the choice shapes the whole project.
The first is the Headless API, also called the loader. No Plasmic-generated code lands in your repository. Your Next.js app fetches published designs at build time or on the server and renders them. The second is codegen, which writes React source files into your repo and leaves syncing them to you. Plasmic’s own documentation recommends the loader unless you need code-level control, and there is a build-time codegen hybrid for runtimes that cannot evaluate code dynamically. We follow that advice: loader by default, codegen only with a clear reason.
As of October 2026 the pricing page lists a free plan, paid tiers priced by collaborators, and custom Enterprise terms. Features like A/B testing and scheduled content sit on higher tiers, and Plasmic AI is marked beta. Check the page before you size a team, since plans move.
Who should pick Plasmic, and who should not?
Plasmic suits teams where a designer ships real pages without waiting for a sprint, and where developers want those pages to use their own component library. It is also useful for internal tools and for sites that mix hand-written routes with visually built landing pages.
It is a poor match for content-heavy sites with strict editorial roles, long-form articles or many content types with complex relations. Plasmic’s CMS handles models and entries, but it is not a replacement for a dedicated content platform. For that we recommend Sanity or Strapi. For marketing teams that want a more established visual editor and testing, Builder.io is the closest alternative, and Storyblok adds a stricter component model. Our comparison of page builder headless CMS options shows the trade-offs.
What we build with Plasmic
Component registry
The core job is deciding which components designers can use and which props they can set. We register buttons, sections, cards and layouts with sensible defaults, and we keep stateful or data-bound components in code. A small registry stops pages from drifting away from the design system.
Next.js frontend and data
We wire Plasmic pages into Next.js routes, handle dynamic paths for CMS entries, and fetch data through server code rather than the browser. Metadata, sitemaps and structured data stay in code. See our Next.js development page for how we run that side.
Handoff from Figma and design systems
Plasmic can import from Figma, but imports rarely map one to one. We use them to speed up the first pass, then rebuild repeating patterns as proper components so designers edit variants, not copies.
Migration and coexistence
We rarely replace a whole site in one go. A common plan is to build new landing pages in Plasmic, keep existing routes as they are, and move over only where the visual workflow pays off. Redirects are mapped before any old page is retired.
If you need people who know both the builder and the React side, see how to hire Plasmic developers. Broader platform choice is covered in the headless CMS overview.
What does it cost to own?
The subscription grows with collaborators, and the higher tiers add testing and scheduling. Our part depends on the size of the component library, the number of page types and how much content moves into Plasmic’s CMS. We scope after a short review of your design files and codebase.
