/services/website-development
A website on the same data your team already works from.
Built on Odoo Website, so products, stock, jobs and enquiries come from one system — and your marketing team can edit it without raising a ticket.
- 1 system of record
- 0 developer tickets to change a headline
- This site built exactly this way
Facts. - 1 · system of record - 0 · developer tickets to change a headline - This site · built exactly this way
/the-problem
A separate website means a second version of the truth.
Most companies run their website on one platform and their operation on another, and then spend years reconciling the two. Stock figures that disagree. A price updated in the ERP and not on the site. A careers page listing a role that closed in March. An enquiry form that emails somebody rather than creating anything.
Each gap is small. Together they produce a website nobody trusts, which is why the sales team keeps a spreadsheet, and why customers ring to check.
Building on Odoo Website removes the reconciliation rather than automating it. Products, stock, job listings and enquiries live in one place because there is only one place. The site reads from the system your team already works in.
That's not a theoretical claim. This site is built this way — the jobs page is Odoo Recruitment, the articles are Odoo Blog, the enquiry form creates a CRM lead, and the whole thing is a theme module in a git repository.
/what-it-changes
What it changes
- Design and build as a theme module, version-controlled
- Reusable content blocks your team composes pages from
- Native SEO fields, structured data and a working sitemap
- Blog, careers and enquiry forms on Odoo's own apps
- eCommerce where it's wanted, on the same product and stock data
- Editor training so changes don't come back to us
- Performance and accessibility measured, not assumed
- One system of record, so nothing needs reconciling
- Content changes without a developer or a deploy
- Job listings that close when the role does
- Enquiries that become CRM leads, not emails
- Stock and pricing that match what the business actually holds
- A site that can be handed to another partner without a rebuild
/how-we-run-it
Six stages. Content is the long pole, and it always is.
A brochure site of fifteen to twenty pages runs eight to twelve weeks. eCommerce, multi-language or a migration with existing search rankings takes longer.
-
01
Structure
Sitemap, URL structure and what each page is for. Before any design.
1 week
-
02
Design system
Tokens, typography and a library of reusable blocks — not a set of one-off pages.
2–3 weeks
-
03
Build
Theme module in your repository. Blocks first, pages composed from them.
3–4 weeks
-
04
Content
Yours or ours. This is where projects slip, so it starts early and in parallel.
ongoing
-
05
SEO & migration
Redirects, canonicals, structured data, sitemap. Rankings preserved, not rebuilt.
1 week
-
06
Training & launch
Your team edits a real page before go-live. Then launch.
1 week
/what-you-get
Four artefacts you keep.
Everything in your repository and your Odoo instance. No page that exists only in a proprietary builder we control.
Theme module, in your repository
the whole site as reviewable, redeployable code.
/02Block library
every reusable section, with what's editable in each.
/03Redirect map
old URLs to new, so search rankings survive.
/04Editor guide
how your team changes content, written for someone who isn't technical.
/where-this-fits
What comes before this, and what comes after.
A website on Odoo assumes Odoo underneath it. Where the ERP comes first, this follows implementation; where the site comes first, it's often how a business gets to Odoo at all.
/questions
Asked on every first call.
-
If you don't run Odoo, probably don't. The argument is entirely about the second version of the truth — one system for products, stock, jobs and enquiries. If your operation isn't on Odoo, that argument disappears and a specialist platform is likely better.
-
They edit it. That's a design constraint, not a hope: pages are composed from reusable blocks with defined editable fields, and your team edits a real page before launch as part of training. If a routine content change needs a developer, the build was wrong.
-
Handled explicitly in stage five — redirect map from every old URL, canonicals, structured data and a sitemap that actually generates. Worth checking your current one; empty sitemaps are more common than people expect, and they cost rankings silently.
-
Yes, and it's a common starting point. Content migrates, URL structure is preserved through redirects, and the rebuild is an opportunity to fix an information architecture that usually grew rather than was designed.
-
Either. We build a design system — tokens, type, a block library — rather than a set of one-off pages, because that's what makes a site editable and extensible afterwards. If you bring a designer, we'll work to their system.
/next
Ask us how this site was built.
Thirty minutes, no slides. We will tell you straight if Odoo is not the answer.