Configuration Surface

Enterprise and B2B customers ask for bespoke behaviour, and each request is individually justified by revenue. The aggregate of granting them is a platform that behaves differently for every large customer and can no longer be changed — because any change might break one of the bespoke arrangements and nobody knows which.

A configuration surface is the alternative: a designed set of dimensions along which behaviour varies, so the common requests are satisfied by configuration rather than by code.

Why it matters

The decision is made request by request under commercial pressure, and each individual "yes" is defensible. Only the aggregate is catastrophic, and the aggregate is nobody's decision unless the surface exists as an explicit boundary.

It also changes the sales conversation productively: what is configurable can be committed to immediately, and what is not can be refused or priced.

Implementation patterns

• Derive the surface from repeated requests, not from imagination. The first request is hard-coded or refused; the third defines a configuration dimension. A surface designed before the second customer is flexible along the wrong axes.
• Cover the predictable dimensions: approval workflows, catalogue restrictions, pricing agreements, invoice and document formats, integration formats, notification rules, user roles.
• Make configuration validated, bounded, auditable and reversible. An unbounded configuration surface is code without review — which is worse than code, because it is changed by people with no visibility of the consequences.
• Refuse or price what falls outside, and record the refusal so the pattern of refusals informs the next expansion of the surface.
• Test the combinations, at least the ones in production. A surface with many independent dimensions has a combinatorial space that cannot be exhaustively tested, so the practical approach is to test the actual configurations in use, generated from production.

Industry example

B2B commerce platforms such as Moglix and Udaan serve enterprise buyers whose procurement processes genuinely differ — approval chains, catalogue restrictions, negotiated pricing, invoice formats mandated by their own finance systems. Those are real requirements rather than preferences, and refusing them loses the customer.

The platforms that scale are the ones where those specific dimensions became configuration early, and the ones that struggle are those where each was a bespoke integration.

Failure scenarios

• Bespoke code per customer, producing a platform that cannot be changed.
• A configuration surface built too early, generic along axes that never vary.
• Unbounded configuration, effectively giving customers the ability to break the product.
• No refusal discipline, so the surface expands without limit and becomes as unmaintainable as bespoke code.
• Untested combinations, where each dimension works and their intersection does not.

Trade-offs

Every configuration dimension is permanent complexity: more code paths, more test surface, more support burden, and more that cannot be changed without checking who depends on it. A surface with thirty dimensions is its own form of unmaintainability.

The discipline is that a dimension is added on evidence of repeated demand and removed when unused — and the second half almost never happens, which is why the addition bar must be high.

Interview question

"Your three largest customers each want a different approval workflow. Walk me through the options, and tell me what you would do differently if it were your thirtieth customer asking rather than your third."