It usually starts the same way. A campaign date got moved. A funding announcement is going out Tuesday. A competitor shipped something and someone senior wants a response page live before the end of the week. And what exists right now is a Figma file, or a Lovable project someone spun up over the weekend, and a CMS that expects neither.
The instinct in that moment is to start building immediately. That instinct is what turns a two-day job into a five-day one. Urgent projects fail on sequencing far more often than they fail on effort — the hours get spent, they just get spent on the wrong things, in the wrong order, and the parts that actually block the launch get discovered on the last afternoon.
This is the sequence that works, whether you are starting from a design file or generated code.
"Urgent" covers three different projects with three different definitions of done, and confusing them is the single most expensive mistake in the whole process. Before anything else, name which one you are in.
| Type | What actually has to be true | What you can defer |
| Pitch or demo | It looks right on one screen size, on one machine, for twenty minutes | CMS editability, forms, SEO, everything below the fold of slide three |
| Real launch | Public URL, works on phones, forms capture leads, marketing can edit it on Monday | Design polish, animation, the second and third page templates |
| Internal deadline | Someone senior sees progress and the team stops being blocked | Almost everything — this is the one people over-build |
The trap is treating a pitch like a launch. A demo does not need a CMS at all, and building one costs you the day you needed for the pitch narrative. The opposite trap is worse: treating a launch like a demo, shipping something marketing cannot edit, and then owning every copy change by email for the next six months.
If it is a real launch, the rest of this article is for you. If it is a demo, stop reading, screenshot the Figma prototype, and go and rehearse.
Before a single component gets converted, write down three things. This takes an hour and it is the hour that saves the project.
One: the page list, ranked. Not "the website" — the actual pages, in the order they must exist. Most urgent launches need one page. A surprising number need one page and a thank-you page. If your list has eleven entries, the deadline is not the problem, the scope is.
Two: who edits it after launch, and what they will change. This determines whether you need real CMS modules or whether hardcoded HTML would survive. If the answer is "marketing will swap the headline and the three feature cards weekly", you need editable components, and that requirement has to be visible from the start rather than retrofitted on day two.
Three: the dependency you do not control. Every urgent launch has one thing that sits outside your own keyboard — publishing rights on the CMS, a domain or DNS change, a tracking container someone else owns, legal or brand sign-off. These have queues, and a queue cannot be shortened by working later. Find it in the first hour and start it moving the same morning, because it is the only item on the list where effort does not help.
A Figma file converts well or badly depending almost entirely on decisions made before you arrived. You cannot restructure someone else's design system on a deadline, but you can spend forty minutes on the handful of things that actually determine the output quality.
Lovable, Bolt, v0, Claude Code, Figma Make, Google Stitch — the output differs in style but not in kind. You get a working React frontend, usually good-looking, usually responsive, and structurally alien to both WordPress and HubSpot. That gap is not a bug in the tool. Those tools were built to produce an application, and you need a theme.
On a deadline, three specific things in generated code cause almost all the pain.
Generated code puts your headline directly in the JSX. That is fine for a prototype and fatal for a CMS, because every string that lives in code is a string marketing cannot edit. The conversion has to lift that text out and turn it into a field — and the cleaner the separation between structure and copy in the original, the better that goes.
An accordion built as React state becomes, in a CMS theme, either a small piece of vanilla JavaScript or a native details element. A carousel becomes a carousel library the theme already loads. None of this is hard, but if your page is built out of a dozen stateful widgets, you are converting an application, and that is a different size of job. On a two-day deadline, cut the interactive extras before you start, not after.
Tailwind classes, CSS-in-JS and component libraries all assume a bundler will be there at runtime. A CMS theme ships plain CSS. This is the most mechanical of the three problems and the one you should worry about least — but it is why "just paste the code in" never works, and it is worth knowing that before you promise a client it will.
Practically, this means one thing: get the code into a repository. transjt reads from GitHub, so the fastest route from a vibe-coded prototype to a CMS theme is to push the project, connect the repo, and let the conversion read the real source rather than a screenshot of it. If the repository is private, invite github.com/transjt or share a read-only link — that step catches people out at exactly the moment they cannot afford to wait.
Here is the honest accounting. The work between "we have a design or a prototype" and "marketing can edit this in HubSpot or WordPress" breaks down into roughly four buckets:
The first three are mechanical, and on a typical landing page they are most of the hours — ground through by hand precisely when you have no developer to spare. That is the part transjt automates: point it at the Figma file or the repository and it produces a native theme, with the pages, reusable components, blog templates and forms already wired, rather than a folder of code somebody still has to translate.
The relevant number for an urgent project is not how clever the conversion is; it is that the export runs unattended and the finished theme lands in your account within about two hours. Two hours is short enough that it fits inside a working day with room to review afterwards — which means the conversion stops being the thing the deadline waits on, and the deadline goes back to being about content and approvals, where it belongs.
What it does not do is invent the fourth bucket. Somebody still reviews the responsive behaviour, still checks the form actually posts to the CRM, still reads the page on a real phone. Budget for that. It is a couple of hours, not a couple of days, but it is not zero, and any plan that assumes zero is the plan that slips.
Assume the brief lands Thursday morning and the page has to be live Friday evening. This is what a version that actually works looks like.
| When | What happens |
| Thu, first hour | Triage. Page list, who edits it, the one thing that makes it fail. Scope cut agreed in writing. |
| Thu morning | Prepare the source: Auto Layout and naming pass on the Figma file, or push the vibe-coded project to GitHub and connect the repo. |
| Thu, before lunch | Start the conversion. It runs while you do something else — this is the point. |
| Thu afternoon | Start the dependency you do not control: request publishing access, raise the DNS change, send the page for sign-off. Queues start now, not Friday. |
| Thu, late | Theme lands. First review pass: does every section exist, is the content editable where it needs to be. |
| Fri morning | Real content in place of placeholder copy. This always takes longer than anyone estimates. |
| Fri, early afternoon | Responsive check on an actual phone, not a resized browser window. Fix what breaks. |
| Fri, mid afternoon | Tracking, metadata, the legal bits. Stakeholder review with a hard cutoff for changes. |
| Fri, late afternoon | Publish. Then open the live URL yourself and click the primary action before you tell anyone it is done. |
Note what is deliberately absent: there is no block called "build the theme". That is the block that used to consume both days, and moving it to an unattended two-hour window is what makes the rest of the schedule survivable.
Ask anyone who has missed an urgent launch what went wrong and almost nobody says the build. They say the copy was not ready, or the approval came back at six on Friday with three changes.
Copy. Placeholder text hides the problem until the last possible moment. A headline that works in a design frame is not the same headline once it sits above a real paragraph, and real copy is never the length the design assumed. Put the actual words in on Friday morning, not Friday afternoon, and expect small layout adjustments once they are there — that is normal, and it is much cheaper than discovering it an hour before launch.
Approvals. The review is not a step, it is a queue with other people in it. Name the approver in the first hour, tell them when the page will be ready and when their window closes, and send them something to react to earlier than feels comfortable. A stakeholder seeing the page for the first time at four on launch day will always find something, because that is the only moment you have given them.
Both of these are content problems rather than build problems — which is exactly the argument for automating the build. The hours you free up are the ones these two need, and they are the two that decide whether the date holds.
Every urgent project offers the same detours. Each looks like it saves an afternoon; each takes a week back later, usually from someone who was not in the room.
Embedding the prototype in an iframe. Live in ten minutes — and invisible to search engines, broken on mobile, impossible to edit. It will still be there in eighteen months, because nobody ever schedules the replacement.
Installing a page builder "just for this one page". The plugin never leaves. It brings its own rendering layer, its own performance profile and its own licence renewal, and every page built after it inherits the dependency. Both WordPress and HubSpot have a native content layer; use it.
Hardcoding the copy "because we can make it editable later". Later does not arrive. What arrives is a headline change by email on a Sunday.
Running an open-ended review round. "Any thoughts?" on launch afternoon invites thoughts. Set the cutoff when you set the deadline — changes accepted until a stated hour, anything later goes on next week's list — and put it in writing before anyone has formed an opinion.
An urgent project is finished when someone else can carry it, not when it renders. Two things should be true before you close the laptop.
The person who owns the page can change the copy without you. If the theme came out of a conversion, the components are already editable in the CMS's own editor — walk them through one edit while you are still there. A five-minute demo prevents a fortnight of email.
And the components are reusable. Not for tidiness: because the next urgent brief is already forming, and a page built from named, reusable modules makes the follow-up campaign a content task rather than another build. That is the compounding return on doing it natively the first time, and it is the argument that justifies the approach to whoever is paying.
The pattern underneath all of it fits in one line: on an urgent project the scarce resource is not hours, it is attention. Anything mechanical that can run without you should be running without you, and the hours you keep should go to the decisions only a person can make — what the page says, who it is for, and who has to say yes before it goes live.
If you want to see what your own file or repository turns into before committing to anything, the conversion runs on a preview first: start from a design at Figma to HubSpot or Figma to WordPress, or from generated code at AI to Website.