Multi-Tenant Platform: Per-Client Landing & Branding

Multi-tenant isn't just database partitioning

For many software vendors, "multi-tenant" stops at partitioning databases. Necessary, but deeply insufficient. When a franchisee, an accounting firm or a reseller uses your platform to serve their own clients, they want the experience to bear their name, not yours. Their landing. Their logo. Their colors. Ideally, their domain.

When multi-tenant becomes strategic

• Franchises — every local outlet or office wants its own storefront, while sharing network tools.
• Partner networks — accounting firms, agencies, consultants reselling your solution. Their commercial edge is personalization.
• API resellers — integrators embedding your backend into their own product who don't want "Powered by X" plastered everywhere.

Custom header and shell

The TenantHeader and TenantShell components consume the current tenant's config at render time. Logo, display name, navigation links, right-hand elements (contact, client area) — all configurable without touching code.

Dedicated landing page

A landing engine lets them compose a home page out of reusable blocks (hero, features, testimonials, pricing, FAQ, CTA). Rendering is dynamic: the same public URL renders the tenant's landing detected via subdomain or path.

Colors, typography, logo

CSS variables are driven by the tenant config. An admin change propagates instantly to rendering — no build, no redeploy.

Domain and subdomain

Two modes available:

• Subpath — platform.com/my-partner, instant setup.
• Dedicated domain — my-partner.com, DNS + certificate configuration handled automatically by our edge layer.

Self-service branding API

A tenant shouldn't have to call us to change their logo. A REST API lets them read and update their config:

• GET /api/tenant/branding
• PUT /api/tenant/branding (logo, colors, SEO metadata)
• GET /api/tenant/landing
• PUT /api/tenant/landing (landing blocks)

The admin UI uses the same API — so tenants have the exact same control level as our operators.

Security and isolation

Three complementary layers:

• Logical DB isolation — all sensitive entities (clients, invoices, contracts, users) carry a mandatory tenantId, checked on every request.
• Session scoping — a user logged into a tenant sees only that tenant's data, never another's.
• Logging — every action is logged with the tenant.

Use cases already live

• An accounting firm in Wallonia — its own subdomain, its own brand, its invoices sent in its name while our platform powers the flow.
• A consultant network — per-consultant landing, scoped roles and permissions, network-wide dashboard on top.
• An API reseller — resells the product with its own T&Cs and support. We stay invisible.

Who is it for?

If you run a network, a franchise or a reseller program, and you're considering "building our own portal", ask yourself: how much time, how much money, how many people? Our multi-tenant brick delivers the same promise in a few hours of setup.