The Public Face: Industry Pages and Bilingual Support

A website on a laptop Photo: Rawpixel (CC0 1.0), via Openverse

A product can be built ever so well — before anyone uses it, they have to find it and understand within a few seconds whether it fits them. Those few seconds are exactly what decide things on the homepage. A gym operator has different questions than a physical therapy practice, and both have different questions than someone who wants to use Xircuit purely privately for their own health data. A single landing page that's the same for everyone only half-serves each of these groups.

This week wasn't about the core of the application, then, but about the public face in front of it: the marketing website. It's the part people see before they even register — and from the start it had to do two things that are easy to underestimate: deliver the right message to the right audience, and do so cleanly in two languages.

Why a Dedicated Marketing Website

One could argue that the application itself is its own best selling point. In practice, that's not true. Anyone hearing about Xircuit for the first time doesn't want to create an account right away — they want to first understand what the product does for their specific situation. That explanatory work belongs before sign-up, not after it.

So there's a dedicated marketing website with its own page per industry. Instead of a generic overview, each audience gets a page that speaks their language — both literally and figuratively. The homepage carries an audience router: an element that asks visitors who they are and, from there, guides them to the matching industry page. That sounds simple, but it's the most important building block. It turns a generic greeting into a targeted conversation, without the visitor having to dig through a menu.

The Audience Router on the Homepage

The homepage deliberately carries little content. Its main job is routing, not completeness. The router takes the visitor's self-identification and directs them to the industry page that matches. There — and only there — sits the full, tailored argument.

This approach has a pleasant side effect for maintenance: if the message for a single industry changes, that only touches that page. The homepage stays stable because it carries hardly any content statements of its own — mainly it opens paths. Each industry page thus becomes its own self-contained unit that can grow and sharpen independently of the others.

Just as important is what the router doesn't do: it doesn't force anyone. Anyone who doesn't recognize themselves in any of the offered categories can skip the selection and browse freely. The router is a shortcut to the right message, not a barrier in front of the content. That balance — guiding without patronizing — was the real work in shaping the homepage.

Two Languages, Decided by the Route

Xircuit targets both a German-speaking and an English-speaking audience, and both are meant to feel equally at home. Instead of determining language via a hidden toggle or a server-side guessing game, it sits visibly in the URL: all paths are culture-prefixed, i.e. /en and /de. The route decides which language gets served.

That's a deliberate decision with several advantages. A link is unambiguous — anyone who shares /de/... is guaranteed to be sharing the German version. Search engines can crawl and index both language versions separately. And the language can't accidentally get "lost" through a cookie, because it's always explicit in the path.

Still, nobody should land on the wrong language on their first visit. If someone arrives without a language prefix, a fallback kicks in: first a previously set cookie with the last chosen language, then the browser's Accept-Language header. Only if neither gives a clear answer does the choice fall back to the default language. That way, the visitor gets their language right away with high probability, while always retaining control over the explicit URL.

A globe as a symbol for bilingualism Photo: World Maps · StockSnap (CC0 1.0), via Openverse

The Right Form of Address in German

Bilingualism is more than a word-for-word translation. In German there's a decision you make once and then stick to consistently: the form of address. The German texts use the formal "Sie" throughout — no switching, no informal "du" in one spot and formal "Sie" in the next.

That's not a small thing. A single stray informal "du" on a page that's otherwise formal instantly feels sloppy and undermines exactly the trust a marketing page is supposed to build. Especially for a health product that handles sensitive data, this tone matters. The formal address is therefore a fixed rule for all German texts, not a matter of taste from page to page.

SEO and Sitemap from the Start

A marketing website that nobody finds through search only fulfills half its purpose. That's why search engine optimization and a generated sitemap weren't a later add-on but were built in from the start. The pages deliver the metadata search engines expect, and the sitemap is generated rather than maintained by hand — which, with multiple industry pages in two language versions, would otherwise quickly become error-prone.

The culture-prefixed paths pay off directly here. Because each language version has its own stable URL, the versions can be cleanly cross-annotated, and search engines can serve the right language for the right region. The generated sitemap ensures that when a new industry page is added, both of its language versions automatically show up, instead of being forgotten.

Technically, these pages run as Razor Pages within the same project group as the rest of the platform. That's a pragmatic choice: no separate technology stack that would need to be run and kept up to date separately, but server-rendered pages that fit well with predominantly static marketing content and stay machine-readable without detours.

Embedded, Not Bolted On

The website doesn't sit isolated next to the product but is wired in through the AppHost — it's part of the same orchestrated application. That has a concrete benefit: it shares infrastructure that already exists. Errors and exceptions flow into the same Sentry integration as the rest of the platform, so I see problems on the website in the same place as everywhere else. And when the website needs to send something — for instance from a contact form — it uses the same email integration instead of building a second delivery path.

This shared foundation doesn't just save work, it also reduces the number of things that can drift apart. A second, loosely bolted-on website would be a separate operation with its own error handling, its own email delivery, and its own monitoring. As part of the project group, the marketing website instead inherits the foundations that are maintained for the platform anyway.