From Lovable Prototype to Drupal Production: What the Handoff Actually Costs

You describe the website you want in a couple of paragraphs. Three days later, you're clicking through a working prototype that looks indistinguishable from a finished site.

That's the new normal. Tools like Lovable.dev have made it genuinely easy to turn a description into a clickable web design in a matter of days. For anyone who has lived through years of wireframes, mood boards, and round after round of Figma reviews, this is a real shift.

But there's a question that always follows the prototype: what now?

Because what Lovable produces looks like a website. It clicks like a website. It is not a website. Here's what actually happens between "great prototype" and "real production site on Drupal", and what that work actually costs.

What Lovable Is, In Plain English

Lovable is an AI tool that turns written descriptions into working web pages. You describe a homepage, and it generates the React code, the styling, the components, and a clickable preview. You iterate on the description, and you get a new version back in minutes.

It's important to be precise about what it produces. Lovable doesn't generate mockups. It generates real front-end code, in modern frameworks like React and Tailwind, that runs in a browser and behaves like a finished site. Think of it less like a design tool and more like commissioning a stage set: fast and convincing from the front, but you can't move in.

Where Lovable Earns Its Keep

For specific kinds of work, Lovable beats the traditional design-then-build cycle by a wide margin.

The clearest win is stakeholder buy-in. A clickable prototype is enormously more persuasive than a Figma mockup. Decision-makers can use it, click around, get a feel for the experience. Sign-off comes faster, and the things people would have flagged at user-testing surface in week one instead of week eight.

The second win is iteration speed. Layout decisions that used to take a week of designer time now take an afternoon. You try three header treatments before lunch, pick one, and move on.

What Lovable doesn't replace is the parts of a project that aren't visual. Content strategy, editorial workflow, integrations, performance, accessibility, hosting, the work of running a real website. The prototype is a fast, vivid answer to "what should this look like?" It is silent on every other question a real website needs to answer.

The Process That Actually Works

A few patterns separate prototypes that translate well to production from ones that have to be redone from scratch.

Establish the visual language on one page first
The temptation is to generate every page as quickly as possible. Resist it. Generate the homepage, lock in the design system (typography, spacing, colour, button styles, hero treatment), and then carry those decisions forward into the rest of the site. Pages generated independently drift, and the cleanup cost is real.
Write detailed prompts, not vague ones.
"A modern services page" produces generic results. "A services page with a left column listing six services as anchor links, each linking to a section with a hero image, three bullet points of value, a short paragraph, and a tertiary call-to-action button" produces something usable. The craft of using Lovable well is the craft of writing specific, structured prompts.
Plan for iteration, not one-shot generation
Even the best prompts produce output that needs review and refinement. Build that into the timeline. The first generation is rarely the keeper.

What Lovable Actually Generates

Here's the honest read on the code Lovable produces, written for non-developers.

The good: clean, readable React components, sensible Tailwind styling, decent component decomposition, modern patterns. A developer picking it up can usually understand what's going on without untangling spaghetti.

The gap: it's a static front-end with placeholder content. There's no content management system. No editors can log in and change text. There's no integration with anything: no contact form backend, no email, no analytics, no search. There's no SEO scaffolding beyond the page markup. There's no accessibility audit. There's no production hosting story. There's no design system documentation, no component library, no test coverage.

The fair summary: Lovable produces a polished demo, not a website you can run a business on. That gap is what productionising means.

What Productionising on Drupal Actually Means

Turning the prototype into a real Drupal-backed site involves a specific set of work items that don't go away just because the prototype looks finished.

You extract the design system into reusable components, so editors creating new pages get consistent results. You model content types in Drupal so the templates can be populated by real editors, not hardcoded text. You wire the front-end to Drupal, typically via JSON:API and a Next.js layer, so the site is dynamic. You set up editorial workflow: drafts, previews, roles, permissions. You harden the site for production: SEO meta tags, structured data, accessibility audit, performance budgets, image optimisation. You set up deployment, hosting, monitoring, backups. You wire in analytics, forms, search, and any third-party integrations the business actually uses.

None of this is in the prototype. All of it has to happen before launch.

Realistic Timeline

For a typical small-to-mid-size project starting from a Lovable prototype:

Lovable prototype: 3-7 days
Stakeholder review and Lovable revisions: 1-2 weeks
Drupal content modelling and configuration: 1-2 weeks
Front-end port and component wiring: 3-5 weeks
Editorial training, QA, hosting, launch prep: 1-2 weeks

Total: roughly 8-12 weeks from prototype kick-off to a stable production launch. Larger sites with custom integrations or multilingual requirements run longer.

Realistic Cost Bands

Sized for a solo specialist rather than an agency:

Lovable prototype phase only (a few days of prompt craft and iteration): £800 - £2,000
Lovable to small or brochure-scale Drupal site: £8,000 - £18,000
Lovable to mid-size content platform with integrations, and custom workflows: £20,000 - £45,000

The prototype phase is the small part. The production work is where the real budget sits, and that's true regardless of whether you start in Lovable or in Figma.

What Goes Wrong

Five mistakes show up regularly on projects that try to take a Lovable prototype to production.

Treating the Lovable output as production code
The prototype's React is not a finished application. It's a starting point that needs to be ported into a real architecture. Teams that try to "just clean it up and ship" end up with a brittle codebase nobody can maintain.
Stakeholders signing off on the prototype as "done"
This is the most common one. Decision-makers see a working clickable site, conclude the project is mostly finished, and balk when told there's still 8-10 weeks of work. Manage that expectation upfront, in writing, before the prototype lands.
Lovable's components drifting from editorial reality
A hero component generated in Lovable might look beautiful but assume the title is exactly four words, the image is exactly 16:9, and there's always a single call-to-action button. Real editors will break those assumptions in week one. Components have to be designed for editorial flexibility, not just visual polish.
Assuming SEO and accessibility are handled
They aren't. Lovable produces semantically reasonable markup, but a finished site needs structured data, proper heading order across templates, focus states, keyboard navigation, screen reader testing, and a meta strategy. None of that comes for free.
No plan for content migration
The prototype is full of placeholder text. The production site needs real content, written, edited, and migrated into Drupal. If nobody has accounted for this, launch slips by weeks while someone scrambles to write the homepage copy.

Where Human Expertise Adds Value

The handoff between prototype and production is where this kind of project succeeds or quietly stalls.

You need someone who can look at a Lovable component and tell you which patterns will translate cleanly to maintainable Drupal templates and which need to be rebuilt from scratch. You need someone who knows where the prototype's design system has to bend to fit editorial reality, because the editor who has to use this every week matters more than the visual purity of the prototype.

And you need someone who will push back when a prototype looks great but is a maintenance trap. The most expensive Lovable projects I see are the ones where nobody asked the hard questions about content structure and editorial workflow until the prototype was already locked in.

Making the Decision

Four questions worth asking before you start.

Are you trying to validate a design, or build a real site?
If validation, Lovable is excellent and cheap. If you want a production site, the prototype is step one of many.
Do your stakeholders have realistic expectations about the timeline after the prototype?
If they expect launch within two weeks of the prototype landing, you have an expectation problem to solve before any code gets written.
Do you have someone who can productionise what Lovable generates?
The handoff is where the real work happens. Without a developer who understands both modern front-end and Drupal, the prototype becomes a permanent prototype.
Is your content strategy ready, or is the prototype masking unanswered content questions?
A polished prototype with placeholder text can hide the fact that nobody has decided what the site actually says. Surface those questions before launch, not after.

Getting Started

If a Lovable to Drupal build is on your roadmap, here's what I'd do this month.

Run a small Lovable experiment yourself
Spend a few hours generating a homepage for your own site or a hypothetical one. You'll learn more about what Lovable does well and badly than any blog post can tell you.
Get clarity on the production scope before the prototype starts
Decide what content types you need, what integrations are required, who the editors are, and what the editorial workflow looks like. This shapes the prototype.
Get a realistic quote for the productionisation phase
The prototype phase is cheap. The production phase is where the budget lives. Get that quote upfront so the decision is informed.
Plan for an editorial review before launch
Get the people who will actually use the CMS into the system early. Their feedback usually reshapes the templates in ways that save weeks of post-launch rework.

A Final Word

Lovable is a genuine productivity gain. It compresses the design phase of a project from weeks to days, and the prototypes are persuasive in a way Figma mockups never were.

But the prototype is the smallest part of the project. Most of the work, and most of the budget, sits between the prototype and the production site. The question isn't whether to use Lovable. It's whether you understand what comes after, and whether you've planned for it.