The first large customer reveals SaaS product boundaries

An enterprise customer requests an additional approval while other customers use the existing workflow. This reveals a product decision for a SaaS team: does this variant belong in the shared offering, and how can it remain maintainable there?

The following example is entirely hypothetical. It describes no commissioned feature or measured project result.

Describe a variant as a traceable rule

Suppose the product processes orders for companies C10 and C20. The new customer needs approval from another authorised person. The person placing the order may not approve their own order. The other customer should retain the existing path.

Whether a managed customer setting can sensibly support this variant depends on the product model. In this example it would be testable: the rule, its scope and both customers' expected behaviour are defined.

A special solution has a future life too

A code copy tailored only to a customer name also needs future fixes, tests and updates. We would therefore first examine whether the requirement is sustainable as a clearly bounded variant in the shared product. This is a conditional recommendation, not a requirement to turn every exception into a setting.

If a customer needs a fundamentally different process with separate maintenance and support, a separate solution can be a deliberate choice. Its scope and responsibility should then be explicitly agreed. Dedicated resources or separate deployments do not automatically require a different product codebase.

Separate function, entitlement and data access

A feature flag can help with a time-limited introduction. A permanently agreed service entitlement, however, needs suitable management and enforcement. Nor does an enabled feature switch replace checking who may approve for which company.

For this example, an update would need to test both the approval variant and the unchanged workflow. The traceable product rule and maintenance effort matter; the first customer request alone does not determine the architecture.

Sources

• AWS Well-Architected — SaaS Lens: Operate

• Microsoft — Deployment and configuration of multitenant solutions

• Microsoft — Tenancy models for a multitenant solution