Philosophy
What Modularity Really Means
Why modularity begins with shared interfaces, not factory-built boxes.
In From ETO to CTO, we argued that construction must move from bespoke project delivery toward a Configure-to-Order (CTO) marketplace. This essay asks a simpler question: what kind of modularity makes that shift possible?
In everyday language, “modular” often suggests bounded flexibility, efficiency, or ease of assembly. But in systems theory, the word has a more precise meaning.
A modular system is divided into distinct components. Each component has its own internal logic, but the system still works as a whole because the parts follow shared interface rules. These rules specify how parts connect (physically, digitally, or procedurally) so that each can be developed independently while still functioning within a larger whole.
What makes modularity powerful is not the existence of parts alone, but the interfaces that coordinate them. A well-structured interface allows each module to be developed more independently. That makes parallel innovation, specialization, and substitution possible.
Parallel innovation is what allowed the computing industry to scale so rapidly in the 1980s and 1990s. Once IBM published stable specifications for internal buses and peripheral slots, third-party firms could develop CPUs, memory chips, and software without renegotiating every connection. The result was not just better components, but a product ecosystem.
Automotive platforms, aircraft assemblies, and camera systems followed the same pattern. In every case, modules existed as assemblies, before the interoperability of “modularity.” Modularity emerged only when interfaces stabilized.
Why hasn’t construction embraced full, inter-firm modularity like these other industries? Inertia. And existing verticals. In construction, methods often win not because they are inherently superior, but because they fit the incumbent delivery stack of contracts, codes, labor practices, software, review pathways, and interfaces.1 When a project’s surrounding systems are not prepared to receive a new method, the industry can misread a promising idea as an impractical one. In that sense, modularity has not been judged on its own terms; it is judged by its fit with the larger stack around it.
Now we have a vocabulary problem unique to the architecture, engineering, and construction (AEC) industry. In AEC, ‘modular’ is used as a shorthand, only meaning “…volumetric components fabricated offsite.” These modules are only designed by a single firm, shipped to site, and projects are mis-described as modular because they contain larger factory-made parts. That lesser meaning dilutes “modularity” from its stronger (systemic) sense. Without shared interfaces, these products remain trapped inside firm-specific systems and project-specific coordination. That is why AEC’s “volumetric modular” systems are so often judged unfairly inside a delivery environment… one still optimized for bespoke coordination. The lack of inter-firm industry product interface standards retards interoperability; this prevents scaling of offsite methods.
The recent history of the AEC industry has telegraphed this state, shackled one-step-away from interchangeable products. A major commonality among failed modular firms (including Katerra, FactoryOS, Crate, Veev, and Bella) is that each tried to control its own interface standard. The result was dependence on narrow supplier networks, brittle coordination chains, and limited interoperability. Neglecting interfaces is not just a technical oversight. It is a strategic vulnerability.


Image Credit(s): Peck & Hale 1996 catalog of ISO 1161 compliant shipping container twist lock mechanisms.
Without shared interface standards (that is, without collaborative design rules) these products remain bespoke. Each mod or pod must be re-detailed, coordinated, inspected, and approved for every new project. Risk accumulates in the seams. Transaction costs rise. Innovation stalls because nothing repeats cleanly.
In the AEC industry, IKEA shows a way around this trap. The majority of their casework interfaces with a steel French cleat, hung from the wall. Their sales volume, and limited scope, has protected the firms’ growth, converting collaborators into Tier 2 suppliers.

Even the youngest children grasp interfaces-leading-to-modularity at an intuitive level, when building LEGO sets.

The North American offsite industry’s failure to scale modularity is the predictable outcome of an industry that ships modules (and other products) without shared interfaces. Until AEC adopts common physical, digital, and regulatory couplings, offsite construction will remain locked in an Engineer-to-Order (ETO) mindset.
Interfaces transform isolated products into a marketplace because they make interoperability2 possible3. That allows multiple suppliers to compete and collaborate without custom negotiation for every transaction. In industries from electronics to logistics, stable interface specifications have enabled buyers to mix and match components from different vendors, confident that they will connect and perform as expected. This predictability reduces technical risk and market friction. It allows specialized producers to focus on what they do best while integrators assemble complete systems from a broader, more competitive field. Without such interoperability, there is no true market, only a series of one-off, closed supply chains.
This is why the CfOC has focused its early efforts on writing the interface standards that offsite construction has long needed. Through our partnership with the International Code Council and ANSI accreditation, we are defining open-standard design rules for modular buildings: where value is exchanged, where scope is handed off, and where modules connect. Our goal is not just better products, but an open architecture others can build upon.
To learn more about how the CfOC is treating modularity not as a loose style of project delivery, but as a system of defined interfaces that lets many actors coordinate and improve:
- To see how we’re completing the modular functions between pods and base buildings, see the CfOC-ICC-1220 standard we’re developing at “Modular Interoperability & Interface Standard.”
- To see why interface standards matter only as part of a larger shift away from bespoke delivery, read “From ETO to CTO.”
- To see how interface rules eventually become repeatable choices inside a real product marketplace, explore the Configurator File Type project and the ”Designing the Rule Layer” whitepaper
- Adapted from “The Hardware Lottery” by Sara Hooker — August, 2020 ↩︎
- “Interoperability is a characteristic of a product or system to work with other products or systems.” (Wikipedia). See interfaces enabling interoperability in e commerce, data management, weaponry, etc. ↩︎
- Carliss Y. Baldwin, Design Rules: Volume 2 — How Technology Shapes Organizations (2023) Chapter 13. Cambridge, MA: MIT Press, p. 474. “Well-specified interfaces make it possible for different actors to innovate independently, coordinating only through the shared interface definition. The result is an expansion of the space of possible designs that can be realized without centralized control.” ↩︎