Introducing Configure-to-Manufacture

Every company that makes what it sells runs on two software categories that were never designed to meet.

CPQ prices what it can’t engineer. It knows your option list and your price book, but it has no idea whether the thing it just quoted can actually be built, what it’s made of, or what it truly costs at the material level. It emits a number and a PDF.

PLM engineers what it can’t sell. It holds the real product record — the BOMs, the revisions, the effectivity dates — locked in a vault that sales will never touch and could not operate if they did. It answers “what is this product?” but never “what does this customer’s version of this product cost, right now?”

Between them sits the translation layer. That layer is not software. It is people re-keying configurations into spreadsheets, engineers maintaining a graveyard of variant tabs, phone calls that start with “can we even build this?”, and quotes built from a cost sheet that was accurate eleven months ago. Every one of those handoffs is a place where the order drifts from the truth. Margin doesn’t die in a dramatic accident. It dies in the translation layer, one stale copy at a time.

The thesis

We think the fix is not a better integration between CPQ and PLM. Integrations synchronize copies; the copies are the problem.

The fix is a claim about data modeling: the drawing, the rules that sell it, and the costed BOM must be one living model. Not three systems with an ETL pipeline between them. One model, where a customer clicking “add a second bathroom” and a purchasing manager asking “how many bundles of shingles does this order need?” are two reads of the same structure.

We call the category Configure-to-Manufacture — C2M. A customer or dealer configures a one-of-a-kind product through a guided, validated, visual flow. The factory receives a complete, costed, manufacturable BOM automatically. Nothing is re-keyed, because nothing needs translating: the configuration is the engineering input.

What actually qualifies as C2M

Categories get diluted fast, so here is the bar. A system is Configure-to-Manufacture if and only if it does three things:

1. A live, resolvable BOM at quote time. Not a price lookup — a resolution. When the buyer picks options, the system walks a parametric BOM where quantities are formulas, not constants. One 16-wide platform template serves both a 16×66 and a 16×80 because floor area, wall linear feet, and joist counts are functions of parameters, not hand-copied rows. The quote is the recursive cost roll-up of the exact material list the factory will build from, resolved at the moment of the click. If your “configurator” prices from a matrix and someone downstream builds the real BOM later, that’s CPQ with extra steps.

2. Provably-safe rules. Configurable products have combinatorial option spaces, and humans cannot inspect combinatorial spaces by eyeball. So the rules that constrain the configurator — this option requires that one, this pair conflicts, this package swaps that part — must be checkable before release. Our rule verifier sweeps the option combinations offline and reports plainly: “No problems found · 18 combinations tested.” In the configurator itself, constraints propagate live: choose “Dual Skylights” and “Laminate – White Ice” greys out immediately, with a human-readable reason attached, not a mystery disable. A rule engine you can’t verify is a liability you’ve automated.

3. Explainable orders — forever. Orders outlive rule sets. A home ordered in 2026 will generate a warranty question in 2031, and the answer to “why does this order contain this part?” cannot be “the rules have changed since then, we’re not sure.” Every released rule set is versioned and frozen; every order records which version it resolved under. Years later, the system re-derives exactly why each rule fired: as ordered under rule set v1. If an order can’t explain itself, you don’t have a source of truth — you have a snapshot with amnesia.

Live resolvable BOM. Provably-safe rules. Explainable orders. Miss any one and you’re back to the translation layer, just with nicer screens.

Why this is possible now, and why it wasn’t before

The honest answer to “why hasn’t this existed?” is that each generation of tooling solved the half of the problem its buyer paid for. CPQ was bought by sales leaders, so it optimized for quote velocity. PLM was bought by engineering, so it optimized for revision control. Nobody’s budget owned the seam.

Three things changed.

First, the modeling problem got tractable. Formula-driven quantities, constraint propagation, unit-of-measure resolution with scrap and purchase rounding — these are well-understood techniques individually. What was missing was a schema that holds parts, variants, BOM trees, parameters, rules, and price books in one relational model instead of five products. We run the whole thing — dealer portal and admin portal alike — over a single Postgres model, and it turns out that’s enough. This is a data-modeling problem wearing an enterprise-software costume.

Second, the browser became a legitimate engineering surface. A floor plan editor whose parameters drive BOM quantities live, and a Three.js walkthrough rendered from the actual configuration, both run in a dealer’s browser today. Ten years ago that demo required a workstation and a CAD license.

Third, the buyer changed. The people evaluating factory software now grew up expecting that when they configure something, the price is real and the picture is their picture. The tolerance for “an engineer will confirm your quote in two weeks” is gone.

Where we’re starting

Our beachhead is manufactured and modular housing — an industry that sells the most configurable durable good most families will ever buy, and largely runs the sell-to-build handoff on spreadsheets and re-keying. A single-section home has thousands of parts, dozens of option groups, and real physical constraints between choices. If C2M works here, it works.

But the category is bigger than housing. Cabinetry, trailers, industrial equipment, made-to-order machinery — anywhere the sales question “can we build this and what does it cost?” currently requires an engineer, there is a translation layer waiting to be deleted.

CPQ asked “what should this cost?” PLM asked “what is this product?” C2M asks the only question the factory ever actually needed answered: what exactly are we building for this customer, and can we prove it?

One model. From the first click to the factory floor. That’s the category. We’re building it.