# Per-Tenant Configuration and Customisation — Multi-Tenant SaaS Architecture

Source: https://www.skillbyai.com/en/multi-tenant-saas/mt-tenant-configuration

> Offer tenant-specific settings, branding and custom domains through configuration, while keeping a single codebase for every tenant.

## 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.

```json
{
  "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 }
}
```

**Quiz:** 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
- [x] Add a configurable approval rule that any tenant can set

*Answer:* Add a configurable approval rule that any tenant can set. Configuration keeps one codebase serving everyone. Forks, special-case ifs and separate deployments all multiply maintenance and drift.