transjt blog – Figma Design to HubSpot CMS

AI Website Builders: Getting Generated Code Into a CMS

The last mile nobody budgets for

Describe a landing page to Claude Code, Lovable, v0 or bolt.new and you will have something on screen in under a minute. It looks right. It is responsive. It is, genuinely, a working frontend. And then the project stops — because a working frontend is not a website your marketing team can run.

The gap between those two things is where most AI-generated builds quietly die. Not because the code is bad, but because every one of these tools produces React, and neither WordPress nor HubSpot runs React as its content layer. Somebody has to translate — and that somebody is usually a developer with two spare weeks.

What these tools actually hand you

The eight builders people ask us about most all solve the same first problem — getting from an idea to a rendered interface — and they diverge sharply on what you are left holding afterwards.

Tool Where you work What comes out
Lovable Browser, prompt-driven React with Vite, synced to GitHub
v0 Browser, Vercel's prompt-to-UI Next.js, heavy on Tailwind and shadcn/ui
bolt.new Browser, StackBlitz WebContainers A full project running in a sandbox
Replit Cloud workspace An app deployed on Replit's own hosting
Claude Code Your terminal Files in your repository, already in git
Builder.io Visual editor or Visual Copilot Components wired to the Builder SDK
Figma Make Inside your Figma file React components carrying your design tokens
Rocket Browser, on rocket.new A generated full-stack application

 

Read that third column again. Every row is a JavaScript application. None of them is a CMS theme.

 

Why the handoff breaks

1. The rendering models do not meet

WordPress renders PHP templates. HubSpot renders HubL modules server-side. React renders in the browser, or on a Node server. These are not stylistic preferences — they are different execution models, and no export button reconciles them. This is why "just export the code" never ends the conversation.

2. Editability disappears

The point of a CMS is that someone who does not write code can change a headline on a Friday afternoon. A React component has no editable fields, no drag-and-drop slots, nothing the page editor can see. Drop the build in as an embedded app and you have technically shipped a website while removing the only reason the business wanted a CMS.

3. Everything around the pages is missing

Navigation that knows the site structure. A blog with categories and pagination. Forms that reach the CRM. Multi-language routing. Redirects. Your AI build has a homepage; a website has all of the above, and none of it is generated for you.

 

What "production-ready" has to mean

Before treating an AI build as launchable, it is worth checking it against what the CMS actually expects:

  • Native templates — real PHP for WordPress, real HubL for HubSpot, not an iframe or a mounted single-page app or java script code.
  • Defined editable fields — every headline, image and CTA exposed in the editor, with sensible defaults.
  • Reusable modules — sections your team can recombine into pages you never designed.
  • Server-rendered HTML — so search engines index content rather than an empty shell.
  • Working site plumbing — menus, blog, forms, language variants and canonical URLs.

Most AI builds satisfy none of these on day one. That is not a criticism of the tools — they were built to generate interfaces, not to furnish a content management system.

 

Two destinations, one decision

Which CMS you convert into matters less than people expect, and the deciding factor is rarely technical.

Choose WordPress when you want to own the hosting, reach for the plugin ecosystem, and hand your team an editor they already know. You get theme files that belong to you, and nothing that stops working because a vendor changed its pricing.

Choose HubSpot when the website has to sit next to the CRM — when pages should personalise against contact data, and marketing wants to assemble campaigns without filing a ticket.

The build you already made does not decide this. The same repository converts either way.

 

Closing the gap automatically

This translation step — components into modules, styles into a theme, layout into templates — is exactly what transjt automates. Point it at the GitHub repository your AI tool is already syncing to, and it produces a native theme: HubL modules with editable fields for HubSpot, PHP templates for WordPress, with the structure of your build preserved rather than approximated.

What changes in practice is the shape of the project. The two weeks of handoff work stop being a phase. The build you generated on Tuesday can be a site your team is editing on Wednesday — and, importantly, still editing six months later without calling a developer.

 

Where to start

If you already know which tool you built with, the specifics differ enough to be worth reading: v0 defaults to Next.js and needs a step Lovable does not, Builder.io carries an SDK dependency that has to come out, and Claude Code output is already in git with nothing to export at all. Each path is written up separately under AI to Website.

And if you have not built anything yet: generate the frontend with whichever tool you enjoy using. The conversion no longer depends on that choice.