What this prompt does
This prompt designs the multi-tenant settings and white-label configuration interface for your SaaS platform. You describe [product_name], [product_type], the [isolation_model], [tenant_hierarchy], [white_label_level], and [framework], and it lays out a tenant switcher, an organization settings dashboard, a white-label branding studio, feature flags and plan gating, an audit log, and [framework] implementation patterns.
The structure works because multi-tenancy and white-labeling touch many surfaces that must stay coherent — switching tenants, applying per-tenant branding, gating features by plan, and logging every change. The prompt maps all of it before you touch the theme provider or tenant-context code. It ties branding depth to your [white_label_level] (just colors, or full custom-domain and email customization) and grounds the architecture in your [isolation_model], so the design matches how your data is actually partitioned.
When to use it
- You're building a multi-tenant SaaS and need the settings and tenant-switching UX mapped before coding.
- A client wants to resell your platform under partner brands and needs white-label depth defined.
- You need a tenant switcher with search, recent tenants, and a clear active-tenant indicator.
- You're designing plan gating and feature flags with graceful upgrade prompts, not hidden features.
- You need an audit log of setting changes with before/after values for compliance.
- You want
[framework]patterns for a theme provider and tenant-context hook driven by CSS variables.
Example output
You get a full interface design: a tenant switcher with logo, role badge, search, and a keyboard shortcut; an organization settings dashboard (General, Billing, Members, Security, API) with vertical-tab navigation; a white-label branding studio with color pickers, logo upload, custom-domain verification, and a live split-screen preview scoped to your [white_label_level]; a feature-flag matrix of features-by-plans with per-tenant overrides and usage meters; an exportable audit log; and [framework] implementation notes for a CSS-variable theme provider, tenant-context hook, and role-based UI.
Pro tips
- Describe
[isolation_model]accurately (shared DB with tenant_id vs. separate schemas); it shapes the whole architecture. - Set
[white_label_level]precisely — colors-only and full custom-domain branding are very different builds. - Spell out
[tenant_hierarchy](Org > Workspace > Team) so the switcher and settings scope correctly. - Use the feature-flag matrix to plan plan-gating early; show locked features with upgrade prompts rather than hiding them.
- Don't skip the audit log; before/after values on setting changes are often a compliance requirement.
- Match
[framework]to your stack so the theme-provider and tenant-context patterns are directly usable.
