A Matrix of 209 Pages: Industries, Features, and Partners

Photo: Bob Richards · StockSnap (CC0 1.0), via Openverse

There's a moment in every product when you notice: a single homepage is no longer enough. A physical therapist searching for appointment booking doesn't want to read a generic "everything for everyone" page. They want the page that speaks to their industry and exactly their problem. And a gym thinking about member billing wants the same. Multiply those two axes — industry and feature — and you quickly end up with dozens, then hundreds, of combinations. This is the week I stopped thinking about these pages by hand and started letting them fall out of a catalog instead.

The idea sounds trivial until you take it seriously. Anyone maintaining 200 landing pages individually stops maintaining them after three months. The copy goes stale, the navigation drifts apart, and eventually nobody can find the page with the wrong price on it anymore. So the matrix not only had to exist, it had to explain itself, link itself, and verify itself.

The matrix: one axis industry, one axis feature

At its core is a marketing matrix that generates 209 feature pages per industry under the route pattern /solutions/{org}/{feature}. Each of these pages is the intersection of an organization type — studio, practice, association, clinic, and so on — and a concrete feature such as appointment booking, access control, or member billing. Instead of a flat feature list, every industry gets its own language: the same feature, but in the vocabulary of the people who actually use it.

And because Xircuit lives bilingually, every page exists in English and in formal German. That's not an automatically translated add-on, but part of the same structure — the culture-prefixed routes carry the respective language, and the formal tone on the German page is deliberate, not incidental. 209 times two languages is a lot of text, and that's exactly why not a word of it was allowed to be copied by hand.

Everything from the catalog, nothing by hand

The decisive design choice was to treat the pages not as files, but as output. They are generated from a feature and industry catalog instead of being maintained individually. The slugs — meaning /solutions/gym/appointment-booking and its siblings — come directly from this catalog. There is no second place where a slug is defined, no list that gets forgotten when a feature is renamed.

That has a pleasant side effect you only appreciate in operation: the truth lives in one place. When a new industry is added, its feature pages appear automatically in both languages. When a feature is dropped, the corresponding pages disappear without leaving a dead URL anywhere. The catalog is the source, the pages are merely its projection — and you don't have to maintain a projection, you just have to keep the source correct.

Two smaller building blocks joined the matrix, both following from the same catalog idea. A catalog-generated sitemap is produced directly from the known routes, so search engines see the full graph without me having to update the sitemap by hand. And a screenshot lightbox lets product images on the pages be enlarged instead of shriveling away at stamp size.

Partners get their own system

A product page tells you what the product can do. It rarely tells you who it works together with — and especially in the health and studio context, that is exactly a matter of trust. That's why there is now a dedicated partner system with a /partners overview and individual detail pages that introduce the integration partners.

Photo: Snappa.io · StockSnap (CC0 1.0), via Openverse

On the overview page, the reader lands on the names that play a role in the platform's everyday life: Apple with HealthKit for health data on iOS, Stripe for payment processing, Withings for body and vital measurements, and Abbott for glucose sensing. Every partner has its own detail page where the integration gets more room than a logo row — what gets connected, why it fits, and what the user gets out of it.

An honest note belongs here too: not every partner logo that appears there today is the final state. The Apple collaboration runs through the HealthKit framework, and the precise presentation — right down to the official badge — follows its own rules, which we respect before we display it prominently. The partner system is the structure; polishing individual tiles is the smaller, ongoing work.

About us, once again from the start

I rewrote the about page. The old one was a relic from a time when the product was smaller and the story shorter — it read like a placeholder, because it was one. The new version tells who is behind Xircuit and what the platform is for, without tipping into the usual about-page platitudes.

This is exactly where the screenshot lightbox mentioned above pays off: the page shows real product views, and anyone who clicks one sees it large instead of having to guess what's happening in the thumbnail. An about page is, in the end, also a sales argument — just one that runs on trust rather than feature lists, and trust doesn't tolerate blurry little images.

How you even review 209 pages at all

The real reason a generated matrix works while a hand-maintained one eventually falls apart is verifiability. Over 900 website tests safeguard the matrix. They ensure that every combination of industry and feature actually produces a page, that both languages are delivered, that the slugs match what the catalog promises, and that no route points into the void.

That's the part you never see from the outside, and without which I would never have put the whole thing live. With 209 pages, I can no longer click through them all; I have to be able to trust the test run. And because a green test suite on my machine still says nothing about the real page, the new routes were subsequently added to the marketing E2E suite. There, they are run against the actually deployed website — not "does the component compile," but "load the URL a visitor would call up, and verify what should be on it actually is." Only this second layer turns a catalog trick into something I trust in production.

What's next?

To close out the series: the multi-platform finish — fast iOS and Mac builds, a release, and a look at where things stand today. After weeks in which the work happened in the web and in the catalog, it's time to go back once more to the devices the product is ultimately meant to run on.