An AI builder gives you a working React frontend in an afternoon. A CMS gives your team something they can edit on Monday. The gap between those two things used to be a fortnight of a developer's time, and that fortnight is what makes "a website in a day" sound like a lie.
It is not, but only if you do the steps in the right order and know which ones cannot be hurried. Here is the whole route, from an empty prompt to a live site on WordPress or HubSpot, with the parts people skip marked as they come.
The same route works at both ends of the market, but it is worth being precise about what it saves, because the answer is different depending on which end you are at.
For a small or mid-sized business, the build was the thing that made a custom site unaffordable. Not the design, not the copy — the fortnight of developer time between having a design and having something editable. Remove that block and a properly built, native site stops being a budget decision. Afterwards the marketing team owns it: headline changes and new pages are content tasks, not tickets, so the cost does not quietly return in maintenance.
For a corporate team, the constraint was never affording a developer — it is that the developers are booked. Campaign pages queue behind roadmap work for weeks, and the campaign date does not move to accommodate the queue. This takes the build off the engineering backlog entirely, and because the output is a native theme rather than a page-builder layer, it clears the governance questions IT and brand will ask: no extra plugin in the stack, no licence to renew, no vendor rendering layer between your content and your CMS.
The honest framing in both cases: what disappears is the mechanical block — rebuilding markup in HubL or Gutenberg, wiring every editable field, rebuilding blog templates and forms. On a typical site that is most of the hours. We broke one 300-hour project down line by line if you want the arithmetic. The strategy, the copy and the approvals still take exactly as long as they always did.
Most companies do not prompt an AI builder themselves, and they do not need to. The more common shape is that a freelancer or a design agency creates the initial concept and the rest is finished from it. If that is your situation, the useful thing to understand is not the tooling — it is who holds what, and where you sign off.
The freelancer or agency creates the initial idea in Figma. Not the whole site — the concept. The visual direction, the design system, and enough key screens to establish it: a home page, a typical content page, the components that repeat. This is where the thinking is, and it is what you are actually paying for.
The AI finishes it. Given that concept, an AI builder extends it into the complete site — the remaining pages, the states nobody drew, the copy for sections that only existed as a grey box. It follows the design system it was given, so the twentieth page looks like it belongs with the first. This is the change worth noticing commercially: you are commissioning a concept rather than twenty page designs, and those are very different invoices.
If the design is already finished and you would rather skip that step, a completed Figma file goes straight into transjt with no code stage in between. Both routes end in the same place.
transjt turns it into a real website inside WordPress or HubSpot: every page, every reusable block, the blog, the forms. Not a picture of a site and not a locked template — the actual thing, in the system your team already uses.
Your team takes it from there. Changing a headline, swapping a photo, adding next quarter's campaign page: those become jobs for whoever writes the copy, not a request that joins a development queue.
The two checkpoints worth insisting on are the design sign-off, before anything is built, and half an hour in the CMS afterwards — with the person who will actually maintain the site — confirming they can edit what they were promised they could edit. Everything between those two points is mechanics.
Which CMS. Decide now, not after the build. It does not change how you prototype, but it decides what you connect in step 5 and who needs to give you access. If you are still weighing it up, the practical differences are covered separately — this guide works identically for both.
The stack constraint. This is the one that ruins days. Most AI builders reach for Next.js with server components by default, and neither WordPress nor HubSpot has a Node runtime waiting to execute a server layer. Say so in the prompt, before you generate anything: React with Vite, client-side routing, no SSR, no server components. Discovering it after the design is approved costs a rebuild.
Lovable, Bolt, v0, Claude Code, Replit, rocket, Figma Make — pick whichever you enjoy. The conversion does not care. What it does care about is what you ask for.
Three things to specify while you are still prompting, because retrofitting them costs more than requesting them:
Budget the morning for this. It is the only step where the thinking is yours, and it is the one worth the hours.
transjt reads the real project rather than a screenshot of it, so the code has to sit somewhere it can be read from. That place is GitHub — think of it as the shared drive that code lives in. Most AI builders can send the project there in one click; if yours cannot, your developer or agency will do it in a couple of minutes.
If the repository is private, this is the step that quietly costs people an hour: invite github.com/transjt or share a read-only link before you go any further. It is a two-minute job that blocks everything after it.
In transjt, add your GitHub account, pick the repository and select the branch you just pushed. Choose your target — WordPress or HubSpot — and start the conversion.
The preview runs before you commit to anything, so this is the moment to check that what came back is what you expected: the pages you built, the components you named, the content you wrote.
This is the part that used to be the fortnight. The export runs unattended and the finished theme lands in your account within about two hours, which is short enough to fit inside the working day with room to review afterwards.
What you get is not a folder of code somebody still has to translate. It is a native theme: HubL modules or Gutenberg blocks, the pages assembled, every reusable component available as an editable module, blog templates wired, and forms with their fields already in place.
Start it before lunch and do something else while it runs. That is the whole point of this step — it is the only one that does not need you in the room.
The theme has to land somewhere, and that somewhere needs setting up first. On HubSpot, authorise the portal you are deploying to — and check you actually hold publishing rights on it, because in most companies somebody else does. On WordPress, install and activate the transjt plugin on the target site, and make sure it is on the current version; an out-of-date plugin is the most common cause of an import that half-works.
Access requests sit in other people's queues, and a queue cannot be shortened by working later. If you do nothing else early in the day, do this one.
Now open the site in the CMS's own editor and read it as a visitor would. You are checking two different things at once.
Is everything there? Every section, every page, the blog listing and at least one blog detail page. Anything the prototype was missing is missing here too.
Is it editable where it needs to be? Click into the modules your marketing team will actually change — headline, feature cards, pricing rows — and confirm they are fields rather than fixed text. This is also the moment to add pages that were never in the prototype, using the components you already have. That is the compounding return on doing it natively: a new page is now a content task.
A generated frontend has no reason to know about your CRM, your analytics or your search presence. Six things to connect, and none takes long:
Test on a real phone, not a resized browser window. More than half of a launch day's traffic arrives on one, and a desktop window at 375px does not tell you what an actual device does with your hero section.
Then walk the site the way a visitor would: click every navigation item, every button, every card. Submit the form once more. Tab through the page with the keyboard to check nothing is unreachable. Look at the largest images — a prototype has no reason to have optimised them, and a hero image straight out of an AI builder is often several megabytes.
Publish, then do the three things people skip because the day is over: open the live URL yourself and click the primary action; submit the sitemap in Search Console; and watch one real form submission land before you close the laptop.
If the site sits on a new domain, the DNS change is the last thing that is genuinely out of your hands — start it in the morning alongside the CMS access, not at six in the evening.
| When | What happens |
| First hour | Decide the CMS. Request portal access or install the plugin. |
| Morning | Build the frontend in your AI builder, with real content on every page and the stack constraint stated up front. |
| Before lunch | Push to GitHub, grant repository access, connect it in transjt and start the conversion. It runs while you eat. |
| Early afternoon | Theme lands. Review it in the CMS editor: every section present, the right things editable. |
| Mid afternoon | Forms to the CRM, tracking, metadata, favicon, redirects. Test the form end to end. |
| Late afternoon | Real device test, full click-through, image weight check. Fix what breaks. |
| End of day | Publish. Open the live URL, submit the sitemap, watch a real submission arrive. |
Being straight about this is what makes the rest of the plan hold.
A migration will not. Moving an existing site means redirect mapping, content audits and preserving URLs — that is a different project with a different shape. Neither will a site built out of a dozen stateful widgets: if your prototype is really an application, you are converting an application, and that is a larger job. Approvals will not compress either — if three stakeholders need to sign off, the calendar belongs to them, not to you. And final copy almost never arrives on time; real words are never the length the design assumed, so expect small layout adjustments once they are in.
What does fit in a day is the build. Which, until recently, was the part everything else was waiting for.
If you want to see what your own repository turns into before committing to anything, the conversion runs on a preview first — start at AI to Website. And if the reason you are reading this is a date that just moved, the urgent project playbook covers the sequencing when there is no room for error.