Once you run more than one Odoo website theme — a main storefront skin, a seasonal variant, a B2B portal look — you hit a maintenance wall. Each theme carries its own copy of the same SCSS variables, the same QWeb snippet templates, the same JS widgets and the same website.snippet.filter records. A color-token change or a bug fix in a mega-menu widget has to be re-applied theme by theme, and the moment one theme drifts, your storefronts stop looking like one brand. Odoo core gives you website and the theme-installer mechanics, but it has no first-class notion of a shared library that several sibling themes can all depend on and inherit from — so teams end up copy-pasting, and technical debt compounds with every new theme.

Theme Base is the common library module we build to sit underneath your themes. It is packaged as an installable Odoo module whose __manifest__.py declares it as a dependency target (depends on website, website_sale, and your commerce stack), so each of your themes lists theme_base in its own manifest and inherits a single, versioned source of truth. Inside it we centralize the shared asset bundles (registered through web.assets_frontend and web.assets_wysiwyg in the manifest's assets dict), the reusable QWeb snippet templates and their snippet_options XML, the OWL/JS storefront widgets, and any helper models (models.Model extensions with compute methods and @api.depends) that your themes call — for example a theme.config settings model or product-badge computation shared across skins. Security is handled properly via ir.model.access.csv plus record rules where a model is multi-company aware, and any front-end data endpoints are exposed cleanly rather than through ad-hoc controllers duplicated per theme.

Technically, the win is inheritance instead of duplication. Your themes stop shipping their own copies of a snippet and instead xpath-extend the base templates; a design-token change happens once in the base SCSS and every dependent theme picks it up on upgrade. We wire the module so it is Community-compatible (no Enterprise-only dependencies unless your stack already requires them), and we validate it against the Odoo versions you actually run — 17.0, 18.0, and/or 19.0 — accounting for the website-builder and asset-bundle differences between those releases. Where you integrate with the XML-RPC/JSON-RPC API or with external PIM/marketing tools, the shared client and field definitions live in the base module too, so every theme speaks to them the same way.

Because this is build-to-order, nothing is a generic download. We start with a scoping call to inventory your existing themes, the snippets and models they share, and the Odoo edition and version they target, then we build the base module, refactor your themes to depend on it, and hand over installable source with a migration path. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope covering one Odoo version and a defined set of shared assets/snippets); additional Odoo versions, multi-company record-rule work, deeper theme refactoring, and extra integrations increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise.