Separate reusable product features from client customization

Forward-deployed teams learn valuable client specifics, but copying the codebase for each client turns learning into maintenance debt. The design question is which differences express product policy and which reflect an external system that truly varies.

Build the decision artifact

Classify requests by repeat frequency, business invariant, security consequence and operational burden. Build shared capabilities for recurring needs. Put policy differences in validated configuration and integration differences behind typed adapters. Reject arbitrary scripts that bypass tests and observability.

The enterprise delivery lab makes this reasoning executable with synthetic data:

from enterprise_cases import product_boundary_case

result = product_boundary_case()
assert result["reusable"] == ["approval timeout", "audit export"]
assert result["custom"] == ["ERP field map"]
assert result["forked_codebases"] == 0
assert result["extension_boundary"] == "configuration or typed adapter"

Approval timeout and audit export appear across several fictional clients and become reusable features. A one-client ERP field map stays behind an adapter. Zero forks is the architectural constraint, not a claim that every client behaves identically.

Test the failure path

A configuration surface can become an untyped programming language. Bound options, validate combinations and test each supported mode. Track support hours, incidents and upgrade delay by extension; retire custom paths whose value no longer pays their burden.

Save evidence that another reviewer can inspect:

• request classification and product decision
• extension contract and validation tests
• client capability matrix
• support-cost and deprecation record

This exercise aligns with the enterprise delivery, secure integration, operations and leadership work in the FDE for Professionals course. The course link describes the pathway; this local draft and its synthetic verifier do not claim that a client deployment, security approval or production result occurred.

Practice task

Review five client requests. Promote only the recurring invariant; design a typed extension for one real difference and decline one unsafe exception.

Continue learning

This article is part of the Enterprise AI delivery and architecture sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Build a second-tenant onboarding plan from a first deployment.
• Continue with Write an enterprise architecture decision record.

Reference: AWS Well-Architected SaaS Lens.