Why modularity is the real answer to manufacturing change

Modularity is the ability to take a system apart and recombine it without breaking it. That is the whole definition. Everything else is implementation. Modularity is not a new idea. In 1965, Martin Starr described "modular production" in his Harvard Business Review article, Modular Production – A New Concept. This was formalised as to why it works: modules hide their internal complexity behind stable interfaces, so design decisions can be decoupled, and teams can work in parallel. A well-designed module can be developed, tested, replaced, or upgraded independently, without dragging the rest of the system along.

My field test for any "modular" line follows directly: can you pull one unit, drop in an equivalent from a different build, and run again without rewriting supervisory code. If you can't, the modularity is cosmetic.

Before modularity: the age of the integral factory

Before modularity, factories were monoliths. One product, one line, every fixture built for that exact design. Perfect at making one thing. Terrible at making change. Henry Ford learned this the expensive way. Switching from the Model T to the Model A in 1927 shut the plant for six months and cost $250m ($4.5 billion today). General Motors (GM) shared components across brands, offered variety, and took a lead Ford never got back. Efficiency without adaptability is a trap that springs exactly once.

For 50 years, industry treated the symptom instead of the disease. Lean made changeovers faster; Shigeo Shingo cut Toyota's die changes from 4 hours to 3 minutes. The 1980s added reprogrammable Computer Numerical Control (CNC). But they optimised inside a coupled architecture instead of questioning it. You cannot tune your way out of a design problem;

modularity is the architectural answer. Change is inevitable, so build the system where change is local. The economics would seem to align with this approach: McKinsey finds 20 to 50% schedule compression in modular construction when work moves into standardised factory-built modules.

So why is modularity still rare? Because it frontloads the hardest thinking. The design rules between modules must exist before the design does. Get one wrong and you find out at integration, the most expensive place to learn. One-off builds let you decide later. Modular systems make you decide first.

Product modularity, process modularity, and why you want both

Product modularity builds the product itself into interchangeable building blocks: smartphone cameras and batteries, electric vehicle (EV) battery packs assembled from standard cell modules, solar arrays built from identical PV modules that scale from a rooftop to a utility plant.

Process modularity applies the same logic to production, organising operations into standalone, flexible stations, the way a fast-food kitchen assigns each station a task so the menu can change without rebuilding the kitchen.

Firms pursuing product and process modularity together see stronger new-product introduction performance and better cost outcomes than firms pursuing either part alone, because a modular product landing on a modular line launches without extensive retooling or downtime. Looking across different industries, wind turbines illustrate the integration of both kinds of modularity: modular blades and tower sections simplify transport and site assembly, while modular nacelles and power electronics simplify maintenance and mid-life upgrades. One architecture, paying out across the whole life of the machine.

How one company has built its business on modularity

Mainstream laptops are glued and soldered. Sealed objects, integrated products. Framework Computer (founded in 2020 in San Francisco) designed its laptop as a set of modules behind published interfaces: a socketed mainboard, swappable expansion cards on a standardised USB-C carrier, and replaceable batteries, screens, and keyboards. The consequences follow the theory exactly. Customers configure machines from a common module set (mass customisation). A 2021 chassis accepts newer mainboards (upgrade without replacement), repairs become module swaps (serviceability), and third parties design compatible modules against the open interface specs (an ecosystem).

The same architecture that drives the sustainability story also drives the manufacturing story: fewer distinct assemblies, reusable test procedures, and product variants created by configuration rather than redesign. Framework invented no new components. It invented the contracts between them. That is modularity.

Software is the cheapest module you will ever build

Software engineers learned this first. Information hiding: each module exposes only what others need, so each module can improve alone. Manufacturing code should get the same treatment but rarely does.

On Megapack general assembly at Tesla, vision logic was written for the designated station. Same problem, new code, new bugs, every time. I consolidated it into one reusable Structured Text vision library in Beckhoff TwinCAT: standard interfaces for multi-camera triggering, results, and fault handling. It now runs across multiple factories. Every new station inherits years of debugging instead of repeating it. Write once, deploy forever.

The counterexample taught the same lesson. The Model 3 and Model Y battery module ramp spanned Allen-Bradley, Siemens PLCs, Fanuc six-axis robots, Keyence and iRVision inspection. Nothing shared a contract. Every cycle-time and detection improvement had to be re-derived, station by station.

We eventually rebuilt those lines in software to run long-range and short-range modules on the same equipment, without millions for new lines. The recurring savings reached millions per quarter. But much of that effort existed only because the line was heterogeneous. Heterogeneity is a tax; you pay it on every change.

Design unit one as a template, and validate modules, not factories

Modular scale-up lives or dies on the first unit. Whatever unit one gets, unit fifty inherits. The temptation on a first-of-a-kind build is to treat it as a prototype: wire it, tune it, ship it, move on. The discipline is to build it as the template: consistent I/O mapping, parameterised recipes. A safety concept built to be revalidated, not reinvented. Unit one is not a machine; it is the template that sets the cost curve of everything after it.

The standards world codified this years ago. Start with the operator interface. ISA-101(Human-Machine Interfaces) standard: write the HMI philosophy once, derive the style guide, build a toolkit of validated templates, faceplates, and symbols, assemble every screen from the toolkit. Nobody draws a display from scratch. That is modularity by construction.

Take a pump faceplate. One template carries everything an operator needs: speed, control mode (local, remote, network), motor current, fault state. Design it once, validate it once and deploy it to every pump in the plant. Five hundred pumps, one interface. The operator who can run one can run them all, because every screen behaves like the last one. That is also what modular validation looks like; prove the template once. After that, every deployment is a check, not an investigation.

The practice: what implementing modularity requires

Knowing the theory is not the constraint; sequencing the work is. First, understand the whole product and process deeply enough to draw boundaries. The boundaries show how well you understand the system, and a boundary in the wrong place will cost you for years. Second, define the interfaces before detailed design: mechanical, electrical, data, and safety, each documented and versioned. Third, put the interfaces under governance; an interface anyone can change is not an interface. Fourth, build the software layer as versioned libraries with release discipline, since code is the module that replicates at zero marginal cost. Fifth, engineer unit one as the template, then validate every subsequent unit by recipe rather than investigation. Sixth, align the organisation to the architecture: modular systems need module owners, and integral teams quietly rebuild integral systems.

Build factories that change

Ford rebuilt a factory to change one product. Framework built a company around modularity at scale. The distance between them is not a century of better machines. It is one early decision: seams before steel.

Not a technology. A decision about where the system will bend, made before the metal is cut, defended after its makers move on. Everything in a factory compounds over a decade. Factories are built to produce; the best are built to change. That is all modularity is.