Duct ordering, where the 3D preview stops the wrong part being cut.

The problem

Ductwork is ordered in dimensions and delivered in metal. Between those two points sits a translation — a sales person writes numbers on a form, someone in the workshop reads them and cuts. When the translation is wrong, the cost is not a corrected line in a database. It is material, machine time, and a delayed job.

Text-based orders make this worse, because a wrong number looks exactly like a right number. Nothing about 450 × 300, 2 m, 45° bend tells you it is not the shape the customer meant.

What the system does

• Parametric geometry — dimensions, angles, and transitions are entered as parameters, and the shape is generated from them rather than drawn by hand.
• Interactive 3D preview — the ordered part is rendered in the browser and can be rotated before anything is confirmed. A wrong shape becomes obvious in a way a wrong number never is.
• Approval flow — orders are confirmed before they reach production, with the approved geometry stored alongside the approval.
• Workshop queue — approved work appears in production order, so the floor works from the system rather than a printed stack.
• Cut-list exports — the flat-pattern measurements the workshop actually needs, generated from the same geometry the customer approved.

How it is built

Three.js renders the geometry directly in the browser, which is the whole point — a preview that requires installing CAD software is a preview nobody looks at. The geometry logic is deliberately separated from the rendering, so the same code that draws the 3D model also produces the cut-list measurements.

One source of truth for the shape

The preview and the cut list are generated from the same parametric definition. This sounds obvious and is the single most important decision in the system. If the 3D view and the workshop measurements were computed separately, they would eventually disagree, and the preview would become something people stopped trusting — at which point the system is just a slower order form.

Docker, because the workshop is not a laptop

The system is containerised so it deploys the same way regardless of where it runs. For an operation where the software may sit on a machine in the building rather than in the cloud, a reproducible deployment is the difference between a system that survives a hardware replacement and one that does not.

What I would change

The geometry code handles the standard shapes well but grew conditional branches for each special case. A composable approach, where complex parts are assembled from a small set of primitives, would have handled the long tail of unusual orders without expanding the code each time one appeared.

Need something similar?

Order-to-production workflows show up across manufacturing, printing, and fabrication. The business systems service covers this type of build, and the internal audit system shows a related approach to approvals.