The Wouters Pyramid of Code Reuse

In March 2023 I sketched out a framework I'd been thinking about for a while. I called it the Wouters Pyramid of Code Reuse. It tries to answer a simple question: where should your code live, and why does it matter?

The pyramid

The pyramid has four levels, from bottom to top:

1. In-app reuse - modular internals within a single application
2. Intra-division reuse - a shared client module repository across projects in a team or division
3. Inter-company reuse - public libraries and SDKs shared across organisations
4. Open source - Drupal core, contrib modules, publicly maintained packages

The higher up the pyramid your code lives, the more people share the maintenance burden. And that directly reduces cost.

The cost equation

More reuse means:

• Lower distributed maintenance cost
• Reduced cost of security coverage
• Reduced cost of version upgrade support

This is not a new insight in isolation. But the pyramid makes it visual: every level you move up, you distribute the cost of keeping that code alive across a wider group of people.

The openness axis

The framework has a second dimension: openness. Each level of the pyramid corresponds to an API boundary:

• Function API - internal, implementation detail
• Internal (protected) API - accessible within the organisation
• Public API - accessible to partners or clients
• Standardised public API - aligned with community standards, the open source level

In a Drupal context: Drupal core and contrib sit at the top. The Dropsolid platform sits at the inter-company level. Client-specific modules sit lower. Application internals are at the base.

Monolith vs microservices: the wrong question

The pyramid also challenges the monolith vs microservices debate. The question isn't the architecture pattern, it's the reusability of the components:

• A monolith of reusable components has lower maintenance cost than a microservice mesh of non-reusable ones
• A microservice mesh of reusable components beats a monolith of non-reusable components

Reusability is the variable that matters. Architecture is secondary.

Why I drew this

At Dropsolid we think a lot about where code should live. Should something be in Drupal core? In contrib? In our platform? In a client repo? The pyramid gives a simple answer: push code as high up as you can justify. The higher it goes, the more the cost of maintaining it gets distributed, and the more value you extract from the investment.

It's also a useful conversation tool with clients and teams. "Where does this belong in the pyramid?" cuts through a lot of architecture debates quickly.