Most Odoo agencies have lived through the same story. The client approves a beautiful Figma file, the front end developer starts rebuilding it inside the Odoo website editor, and three weeks later the header still does not match, the spacing drifts on tablet, and half the layout is trapped in database records instead of version controlled code. The design was never the problem. The handover was.
Website Builder inside Odoo Pilot exists for that handover. It treats a figma to odoo website conversion as a structured development exercise rather than a drag and drop rebuild, producing website development tasks, QWeb templates, custom snippets, and code you can push to your own repository. This article walks through how that works from the perspective of developers, functional consultants, and implementation teams.
Why Figma to Odoo Handover Breaks Down in Real Projects
The Odoo website editor is excellent for content editing and poor as a design reproduction tool. It was built so a marketing user can swap an image, not so a developer can reproduce a 12 column grid with custom breakpoints.
The Gap Between Approved Design and Odoo Website Structure
A Figma file thinks in frames, auto layout, and components. Odoo thinks in QWeb templates, snippets, view inheritance, and asset bundles. Nothing maps one to one. A designer’s reusable component might become a custom snippet, a template include, or a t-call depending on whether the content team needs to edit it later. That decision is architectural, and it usually gets made accidentally by whoever builds the first page.
Where Snippets, Themes, and Assets Usually Get Lost
Three things go missing in a typical design handover process. Font files that were licensed in Figma but never added to the assets bundle. Hover and active states that exist as separate frames and get ignored. And mobile behaviour that was never designed at all, so the front end developer invents it, and the client rejects it during user acceptance testing.
How Website Builder Reads a Figma Design
You provide the supported Figma link or design access at the project level, alongside written requirements, branding instructions, or reference screenshots. Website Builder then analyses the design structure rather than screenshotting it.
Design Analysis: Sections, Spacing, Typography, and Components
The analysis identifies page sections, layout grids, spacing rhythm, typography scale, image placement, button styles, and repeated components that are good candidates for reusable custom snippets. For an implementation team, this is the artefact that has been missing: a written inventory of what the site actually contains, before anyone opens a code editor.
What the AI Can Infer and What You Must Specify
Odoo Pilot can infer a lot from a well structured Figma file. It cannot read your mind about which sections the client will want to edit themselves, which pages need to sit under the eCommerce controller, or whether you are building on Odoo 17 or Odoo 18. Put that in your project instructions once, and stop repeating it in every prompt.
From Design Analysis to Odoo Website Development Tasks
Website Builder does not attempt the whole site as a single generation. It breaks the work into tasks, the same task based execution model used across Implementation Mode and Pilot Studio.
Task Breakdown by Page, Section, and Snippet
A typical breakdown separates global work from page work. Global tasks cover the header, footer, colour and typography variables, and the assets bundle. Page tasks cover the homepage hero, the services grid, the pricing page layout, and the contact section. Snippet tasks cover anything reusable that the content team will place on multiple pages.
Reviewing and Editing Tasks Before Approval
This is where functional consultants earn their fee. You can edit task titles, instructions, and expected outcomes before anything is generated. If the client explicitly asked for the testimonial block to be editable through the website editor, say so at the task level. Approval before execution is a control, not a formality.
Building the Odoo Website Module Structure
Templates, Snippets, Assets, and Theme Inheritance
Approved tasks produce a website module rather than loose database records. That means QWeb templates, snippet definitions with their options, SCSS or CSS in the correct asset bundle, static images, and XML view inheritance where you are extending an existing Odoo website template instead of replacing it. Keeping the customization in a module is what makes the site deployable across staging and production, and reviewable in a pull request.
When Website Builder Hands Off to Module Builder
Not every website requirement is a website requirement. A custom quote request form that writes to a new model, a portal page that exposes filtered records, or a controller that serves a JSON endpoint belongs in code level development. When your scope crosses that line, Explore Module Builder to generate the models, access rules, controllers, and business logic that sit behind the pages Website Builder produces, so the front end and the backend stay in one project context and one repository.
GitHub Delivery and Code Ownership
Commit, Review, Deploy: Keeping Humans in the Loop
The project connects to your GitHub repository, and approved website code is prepared as commits you can review before merging. The practical benefit for agencies is ownership. The theme lives in your repository with a normal history, not inside a platform you would have to escape from later. Your usual review, staging, and deployment process stays exactly as it is.
What Figma to Odoo Conversion Will Not Do For You
Responsive Behaviour, Fonts, and Third Party Theme Conflicts
Be honest with clients about this. Output quality depends on the quality and structure of the design file. If only desktop frames were provided, responsive behaviour is interpreted rather than reproduced. Licensed fonts still need to be supplied and loaded. Complex animations, custom JavaScript interactions, and third party website apps still require developer work. And an existing purchased theme can conflict with new styling in ways no generator can predict. Review the result for responsiveness, browser compatibility, and performance before it goes anywhere near production.
Practical Workflow: A Six Page Corporate Site in Odoo
A consultant receives an approved Figma file for a manufacturing client: home, about, services, industries, resources, contact. The project is created, the Odoo version and existing theme are recorded in project instructions, and the Figma design is connected. Website Builder produces a section inventory and roughly twenty tasks. The consultant merges two redundant card components into one snippet, flags the industries page as content editable, and approves the global tasks first. Header, footer, and typography are generated and reviewed in staging. Page tasks follow. The contact form, which needs to create a lead with custom fields, is routed to Module Builder. Code is pushed to GitHub, tested across breakpoints, and deployed through the client’s normal release process.
Best Practices for Functional Consultants and Developers
Ask the designer for mobile frames before the project starts. Name your Figma layers meaningfully, because structure in equals structure out. Record the Odoo version, theme, and installed website apps in project instructions. Approve global styling before page level work so you are not restyling twelve sections later. And test complete journeys, including forms, eCommerce checkout, and portal access, not just whether the landing page looks right.
Conclusion
Turning a design into an Odoo website module is a planning problem before it is a coding problem. Website Builder gives Odoo teams a repeatable path from approved design to structured tasks to reviewable code in their own repository, with human approval at every important step. It does not remove the developer. It removes the guesswork, the silent architectural decisions, and the three weeks of rework.
Want to move from approved design to working Odoo website code without losing control of the build? Start with Odoo Pilot and turn your next Figma handover into a structured website development plan.
Frequently Asked Questions
Does Website Builder produce a pixel perfect copy of my Figma file?
No, and no responsible tool should claim it does. Odoo website customization runs on QWeb templates and an existing theme, so results depend on design structure, provided breakpoints, font availability, and Odoo version. Expect a strong, reviewable starting point that a front end developer refines.
Where does the generated website code actually live?
In a website module inside your connected GitHub repository, containing templates, custom snippets, and static assets. That is what makes the work deployable across environments and reviewable through your normal pull request workflow.
Can content editors still use the Odoo website editor afterwards?
Yes, if you plan for it. Sections built as editable snippets remain editable in the Odoo website editor. Sections hard coded into a template will not be. Decide this during task review, because retrofitting it later means rewriting templates.
What if the client has a purchased third party theme?
Record it in project instructions before generation begins. Theme development conflicts are one of the most common causes of rework, and knowing the base theme changes how view inheritance and asset loading are approached.
How does this connect with presale estimation?
Presale Mode can analyse the design and requirements to identify page count, custom snippet effort, and integration work, giving you a defensible estimate before the project starts. The same project context then carries forward into implementation and website development.
