Per-Tenant Configuration and Customisation

Configure, don't fork

Customers want the product to feel like theirs: their logo and colours, their own domain, their working days and time zone, custom fields on records, approval rules, notification templates. The multi-tenant way is configuration: per-tenant settings stored as data and read at run time, with sensible defaults so a new tenant works immediately. Validate settings against a schema, version them so changes can be audited and rolled back, and cache them with the tenant's other context. Customisation must stay bounded: a settings page, a rules engine, custom fields, webhooks and an API let tenants adapt the product without you writing tenant-specific code. The anti-pattern is the customer fork, a branch of the code for one big client. Each fork must be merged, tested and deployed separately, which slowly turns one SaaS product into many single-tenant ones and erodes every benefit of multi-tenancy.

A tailor versus a size chart

A ready-made shirt shop offers sizes, colours and collar styles, so most buyers find a fit from the same production line. Stitching a fully custom shirt for each customer is a different, much slower business. Configuration is the size chart; a fork is bespoke tailoring.

Custom domains need certificates

Letting tenants use app.theircompany.com means verifying they own the domain (often with a DNS record) and issuing and renewing a TLS certificate for each one, usually automated through ACME. Plan the verification flow before the first enterprise asks.

A validated settings document

An illustrative per-tenant settings record. Unknown keys are rejected by schema validation; missing keys fall back to defaults.

{
  "tenant_id": "acme",
  "version": 7,
  "branding": { "logo_url": "https://cdn.example-saas.com/tenants/acme/logo.png", "primary_color": "#0b5fff" },
  "locale": { "time_zone": "Asia/Kolkata", "week_starts_on": "monday" },
  "approvals": { "purchase_order_threshold_paise": 5000000 }
}

Quick check: A large customer asks for a different approval workflow. Which approach keeps the product truly multi-tenant?

• Create a separate code branch for that customer
• Hard-code the customer's id with an if-statement
• Deploy a separate copy of the app just for them
• Add a configurable approval rule that any tenant can set