Blog /

Rebuilding a Legacy BOM, Zone by Zone

How we took a real production 16×66 single-section home's super-BOM and rebuilt it as a parametric platform template — and why the 16×80 came along for free.

engineeringparametric-bommanufactured-housingcase-study

The most useful artifact we’ve worked with this year is a legacy super-BOM for a real production 16×66 single-section home. Thousands of line items, exported from the systems and spreadsheets a factory actually builds from — not a demo dataset, not a simplified teaching example. Every quirk in it was earned over years of real orders.

This post is the engineering story of rebuilding that BOM as a parametric platform template in Manufacts: one model where quantities are formulas over parameters instead of numbers typed into cells. We did it zone by zone, because that’s how the home is actually organized — and because each zone taught us something different about what “parametric” has to mean in practice.

What a legacy super-BOM looks like

A super-BOM is the industry’s honest workaround: one giant flat list containing every part the model might use, with usage codes and option flags sprinkled through it, plus a sibling spreadsheet per floor-plan variant. The 16×66 has its list. The 16×80 — the same platform, fourteen feet longer — has another list, created by copying the first one and walking every length-dependent line by hand: more floor decking, more PEX, longer chassis rails, more shingle bundles, more of almost everything, in almost-but-not-quite proportional amounts.

That copy step is where the graveyard starts. Two spreadsheets that are 85% identical will drift. A cost update lands in one and not the other. A vendor substitution gets applied to the 16×80 tab but not the 16×66. Nobody decided to have unreliable data; the format guaranteed it.

Our claim going in: a 16-wide platform is one template. Length is a parameter. Let’s prove it against real production data, zone by zone.

Zone 1: Water lines and PEX plumbing

We started with plumbing because it looked easy and wasn’t.

The naive version — PEX quantity scales with home length — falls apart immediately. Supply runs don’t scale with length; they scale with fixture layout. A 16×66 and a 16×80 with the same two-bath plan have nearly identical supply trees; move the water heater or add a half bath and the runs change a lot while the length changes not at all.

So the plumbing zone taught us the first rule of parametric rebuilds: find the real driver. The template’s PEX lines carry qty_formula expressions driven by fixture-count and run-length parameters, some of which come from the floor plan itself (plan.* parameters published by the floor plan editor), not from the marketing dimensions of the home. Fittings resolve as functions of fixture count; trunk lines as functions of routed run length. When we regenerated the zone and diffed it against the legacy list, the disagreements were almost all cases where the legacy sheet had accumulated “just in case” padding — which we made explicit as scrap percentages instead of hiding it in inflated quantities.

Zone 2: Steel chassis underframe

The chassis was the opposite lesson: here, length really is the driver, but through step functions rather than smooth ones.

Main rails scale with length directly. But outrigger and crossmember counts come from spacing rules — a member every N inches, rounded to code — so the formula is a ceiling function over length, not a ratio. Axle and spring assemblies jump at weight thresholds, so their quantities are conditional expressions over a derived weight parameter, which is itself rolled up from the rest of the model. The legacy spreadsheet had all of this knowledge, but stored as answers (this many crossmembers for a 66-footer, that many for an 80) with the reasoning discarded. The parametric rebuild stores the reasoning and re-derives the answers.

This is the part of the rebuild that felt most like recovering lost source code from a compiled binary. The rules were always there. Someone knew them once. The spreadsheet only kept the output.

Zone 3: Shearwalls

Shearwalls were the zone where structure and options collide. How many shearwall segments you need depends on wall linear feet and opening layout — windows and doors interrupt shear capacity. Which means an option choice (add a window) has a structural consequence (framing and sheathing quantities shift).

In the legacy world this coupling was handled by a human reviewing the order. In the template, plan.window_count and plan.wall_linear_feet flow straight into the framing formulas, and structural rules auto-include the required hardware. The floor plan editor isn’t a drawing surface with a BOM stapled to it — the plan parameters are BOM inputs. Drag a window on the plan and the sheathing quantity, the header stock, and the cost all move live.

Zone 4: Cabinetry

Cabinetry was where phantom assemblies earned their keep. A “kitchen base cabinet run” isn’t a purchased thing — it’s a bag of boxes, faces, pulls, and fasteners that explodes into its components at resolve time. Modeling runs as phantoms let the option layer stay human-sized (“Shaker, 8-foot run, island”) while the resolved BOM stays purchasable. It’s also where unit-of-measure resolution matters most: components spec’d per linear foot, purchased per each, with vendor pack rounding at the end.

The punchline

Then we did the thing the whole exercise was for. We took the finished 16×66 template, changed the length parameter, and resolved a 16×80.

No copy. No second spreadsheet. No walk-every-line review. The chassis crossmembers stepped up per the spacing rule, the decking and PEX and shingles rescaled through their formulas, the plan-driven zones stayed pinned to their actual drivers, and the cost roll-up came out the other side as a complete, purchasable list. Where the legacy 16×80 sheet disagreed with our resolution, investigation favored the formulas — most deltas were drift the copy-paste workflow had introduced over years.

One platform template. Two homes (and any 16-wide length in between). The variant spreadsheet graveyard for this platform doesn’t get better organized — it disappears, because the thing it existed to store, the per-variant answers, is now computed instead of copied.

What we’d tell anyone attempting this

Rebuild zone by zone, and diff against real production data at every step — the legacy BOM is wrong in places, but it is wrong in informative places. Chase the real driver for every quantity; “scales with length” is usually a lie hiding a spacing rule, a fixture count, or a plan measurement. Make padding explicit as scrap instead of leaving it baked into quantities. And keep the legacy sheet around when you’re done — not to build from, but as the fossil record of what maintaining product knowledge by hand actually costs.

See it on your product, not our slides.

Bring a real order and we'll configure, cost, and resolve it live in 30 minutes.

Book a demo