Every successful SaaS product eventually meets the same question: a customer asks for something specific to them, you build it, and now you have a feature in your codebase that's only meant to run for one tenant. A year later, you have a dozen of these. The codebase has if-statements checking tenant IDs, the test suite mocks out customer-specific paths, and the senior engineer who knows which branch belongs to which customer is the only person who can refactor anything.

There's a better shape, and it doesn't require giving up the per-customer customization. It does require separating, cleanly and firmly, the code that defines what behaviors are possible from the data that selects and parameterizes them. This article is about how to do that, where to store the data, and the security cliff you'll fall off if you let the data become code.

What not to do

A handful of approaches show up over and over, and each has a fatal flaw:

• Separate deployed instances per customer. This solves customization by forking the operational surface. Now you have N versions of the database, N sets of background jobs, N deploy pipelines, N versions of every bug fix to roll out. It works for two or three customers and collapses by ten.
• Conditional code in the backend — if tenant_id == "acme": .... Cheap on day one, untenable by month six. Every developer has to know the customer landscape to make changes safely. Every refactor is risky in proportion to how many tenants have branches. Customer-specific logic spreads across the codebase by capillary action.
• Code injected at build time. A configuration that produces a different binary per tenant. Has the same operational cost as separate instances, plus the added joy of debugging behavior that depends on what compile-time flag was set. Don't.

The pattern that scales is to keep one codebase, one running cluster, one deploy pipeline — and to let per-tenant behavior live in data that the code consults. Basically, I am describing multi-tenancy.

Code defines the possibilities; data selects among them

Identify the points in your system where behavior can vary per tenant. These are extension points: the discount engine, the approval workflow, the export format, the notification rules. At each one, your code defines a small set of behaviors it knows how to perform. Per-tenant data picks which behaviors to use and supplies the parameters.

Concretely: a class hierarchy. A common shape is a CustomRule base class with a contract — say, applies?(context) and apply(context) — and a set of concrete implementations:

class CustomRule:
    def applies(self, context) -> bool: ...
    def apply(self, context) -> None: ...

class PercentageDiscountRule(CustomRule):
    def __init__(self, percent, min_order):
        self.percent = percent
        self.min_order = min_order

    def applies(self, context):
        return context.order_total >= self.min_order

    def apply(self, context):
        context.discount += context.order_total * (self.percent / 100)

class FirstPurchaseDiscountRule(CustomRule):
    def __init__(self, amount):
        self.amount = amount

    def applies(self, context):
        return context.customer.order_count == 0

    def apply(self, context):
        context.discount += self.amount

A tenant's configuration is then a small declarative description — which rules they have, with what parameters:

{
  "discount_rules": [
    {"type": "percentage", "percent": 10, "min_order": 100},
    {"type": "first_purchase", "amount": 5}
  ]
}

At runtime, you load the tenant's config, hydrate it into instances of the right rule classes, and run them. The code knows how to perform every behavior; the data says which behaviors to apply, in what order, with what parameters. To add a new kind of rule, you add a new class. To add a new tenant configuration, you change data — no deploy, no migration, no engineering.

Notice that the apply methods mutate the incoming value. If you prefer to not do so, just return that result and apply it when called. A reasonable name for this operation is result. This is really up to your preference in terms of using mutable vs immutable data. In the context of a web app, you usually do want mutability (for example, encoding and decoding a value from the database to a particular meaning for a tenant). If there is more complexity, you can put it behind a port to unit test it separately.

The shape generalizes: any extension point in your system can have its own base class, its own family of implementations, and its own data schema describing how it's configured per tenant.

Where the data lives

The configuration has to be persisted somewhere. The options aren't equivalent:

• In-memory cache. Tempting because it's fast, but caches get invalidated, evicted, and reset on deploy. If the cache is the source of truth, you've lost the data the moment something restarts. Caches belong in front of the source of truth, not in place of it.
• Files on disk. Workable for very small, very stable configurations, but file I/O is slow at scale, file deployment is operational overhead, and "edit a file and redeploy" doesn't fit the case where customer success needs to toggle something for a tenant at 4pm on a Friday.
• Static configuration baked into the app. Fine for values that genuinely never change between deploys. But if the values are tenant-specific, you're back to the "code per customer" problem.
• A database. If you're already running one — and you almost certainly are — this is the clear winner. Reads are fast (especially with a thin cache in front), updates are transactional, the data sits next to the tenant records it's associated with, and you get backups, replication, and access control for free.

Use the database you already have. Don't introduce a new piece of infrastructure for this.

A note on schema

Whichever shape you pick, the configuration has to be retrievable by tenant. That means a tenant_id foreign key, typically a dedicated tenant_configurations table with tenant_id referencing tenants, indexed for fast lookup. The runtime question is always the same: "given the tenant for this request, what's their configuration?" Get that relationship in place first; everything else flows from being able to find the right rules for the right tenant.

If you're using a relational database, the principled approach beyond that is to model the configuration with normalized tables — a tenant_discount_rules table with tenant_id, typed columns for rule type, percent, min_order, and so on, or a polymorphic schema with a separate table per rule type. This is fine, and you may end up there. But I'd push back on starting there.

For an initial proof of concept, a single table is enough:

CREATE TABLE tenant_configurations (
  tenant_id   BIGINT PRIMARY KEY REFERENCES tenants(id),
  config      JSONB  NOT NULL DEFAULT '{}'::jsonb,
  updated_at  TIMESTAMP NOT NULL DEFAULT NOW()
);

One row per tenant, the primary key handles the lookup index, no migrations needed when you add a new kind of rule. You fetch the row by tenant_id, parse the config JSON, hydrate it into your rule classes, run them. When the configuration stabilizes, when querying into the configuration becomes important, or when validation needs to live at the database level, that's the moment to normalize. Until then, JSON in a column is the shortest path from idea to working code, and you can refactor toward structure once you know what the structure should be.

The security cliff

There is one thing you must not do, no matter how convenient it looks: do not store executable code in the configuration, and do not let configuration values be interpreted and run.

That means no eval, no exec, no embedded JavaScript or Python or Ruby expressions, no SQL fragments concatenated into queries, no template engines that allow arbitrary function calls. It is tempting (really tempting) to support a configuration that looks like:

{
  "discount_amount": "order.total * 0.1 if customer.tier == 'gold' else 0"
}

…and eval that string at runtime. Do not. The moment you do, anyone who can write to that configuration row can execute arbitrary code on your servers, with the privileges of your application. That's not a feature; that's a remote code execution vulnerability you built on purpose. It doesn't matter that the configuration is "only" editable by admins, or "only" through your UI — the surface area expands the moment another bug exposes that table, the moment a credential leaks, the moment an internal account is phished. The configuration becomes the attacker's payload delivery mechanism, and you handed them the loaded gun.

The correct discipline is strict: configuration is data. It selects between behaviors the code already knows how to perform and supplies typed parameters to them. It never describes a new behavior. If a customer needs a behavior the code doesn't have, the answer is to add a new rule class, not to let them write logic into a JSON blob.

This is also what makes the system safe to expose to customer-success people, support engineers, and eventually self-service customers. The blast radius of a misconfigured rule is "the rule doesn't apply" or "the rule applies wrong". Never "the server runs whatever I told it to."

The shape, summarized

• Identify per-tenant extension points and write a small base class for each.
• Implement the concrete behaviors as subclasses of that base.
• Store tenant configurations as data; start with a JSON column on the tenant record, normalize later if it earns it.
• Hydrate the data into classes at runtime; let the classes do the work.
• Never, ever let the data become code.

The principle underneath all of this is that code is the menu (the list of things your system is capable of doing) and data is the order. Customers can pick from the menu, in any combination, with any parameters. They cannot rewrite the menu. The chef writes the menu. That's how you keep the kitchen safe.