Pattern 1.2

Revenue Gravity

When a few large customers pay for the work, the organization forms around them, and shared code ends up with nobody paying for it.

In This Context

A business that depends on a small number of high-paying customers lets each of them demand, and pay a premium for, customizations that differentiate them from their rivals. Engineers are allocated to each large customer, and those groups become long-lived customer teams. Each customer team has a direct money line from its customer. The shared components that every team depends on have none. In a startup, the same pull shows up as forking the closest codebase for each new customer to hit a contract deadline and get paid.

Large customers expect the control they had over their in-house systems.
Bespoke work earns a respectable margin, so management rarely resists it.
Delivery to each client is urgent; shared quality is not on anyone’s invoice.

Therefore

Recognize that the product is being shaped by who pays for it, not by its architecture. Then either fund the shared components directly (Fund the Commons Separately) or, where the patrons themselves hold the product in place, look for the rarer moments when the patrons can change (Change the Patrons).

Consequently

Ownership of shared components can be made explicit and funded.
But without a change, the result is bespoke forks, unclear ownership of shared code, heavy integration work for each client, and less emphasis on testing.
But turning a collection of custom solutions into one product means changing the business model, which is exceedingly difficult.

Seen In

Chapter 3, “WidgetSoft: A B2B Case Study”, Chapter 5, figure “Collaboron’s customers and codebases in year two”.