Comprender — the first white-label client
Comprender (an education provider) is tenant #1 — the first paying client and the first project on the platform. It is also the first white-label client instance: a client-facing app that reuses the platform's design system and screen views under the client's own brand and URL.
The Comprender client app is being reshaped under a separate, parallel effort. This page describes it at the platform level — its role and the pattern it establishes — rather than its current internal code, which is in flux.
Why Comprender matters
Comprender is the case study that drove much of the product architecture:
- The product System of Record. Building Comprender's identity layer is what shipped
@tedos/domain— a unified person deduped across channels, with fiscal data. See Product SoR. - Per-client isolation. A real client exposed the need for schema-per-client isolation, event-driven ingestion, and per-client memory. See Data, memory & assistant.
- The white-label pattern. Comprender renders the same shared screen views (extracted into the design-system package) as the operator admin, so every consumer renders the same view — with routing and data seams owned by the hosting app. See Design system.
The white-label pattern
A client instance is a thin app that:
- reuses the platform's shared, presentational screen views (data-in-props, pure — no data fetching inside the view);
- supplies its own data seam and own routing (views never hardcode operator routes);
- ships under the client's brand and URL, as a Clerk app on a subdomain sharing the root-cookie session. See Auth.
This is the "service outside, product inside" model in practice: the reusable core (design system, screen views, SoR, engine) makes each new client delivery cheaper than the last.