Going multilingual is easy to underestimate. The visible part — the words on the page — is the small part. The hard part is keeping a large, technical catalogue consistent across six languages while product data keeps changing, without turning one site into six sites that slowly drift apart. That drift is where the real cost lives.
One catalogue, many locales
We modelled the catalogue on a headless CMS with localisation built into the structure, not bolted on: a single source of product truth, with translated fields versioned next to the original so a spec change is never silently left untranslated. The front end renders fast, statically-generated pages per locale with correct hreflang, so search engines — and customers — always land on the right language version.
Make adding a market a configuration, not a project
The goal was that the sixth language should cost far less than the second. Because content is authored once and structure is shared, expanding to a new market became a matter of configuration and translation rather than another front-end build. Content teams work in one place; every market stays in step automatically.
The figures here are illustrative of what this kind of multilingual, content-led build delivers; this is a representative, industry-level example and the client is not named. What generalises is the architecture: one structured source of truth, localisation as a first-class field, and a build that turns each locale into a fast static site rather than a maintenance liability.
Expanding across languages or markets? That’s exactly the kind of build our web development and cloud teams do together. Start a conversation.