Case study · 0→1
Bespoke product configurator
A customer-facing builder for made-to-order electrical plates and switches: pick a finish, a layout and an engraving, see it rendered as you go, and have the result arrive at the factory as a manufacturing instruction.
The problem
Corston sells architectural detail — plates, switches, sockets — in a large number of finish and configuration combinations. Bespoke orders existed before this project, but they were quoted and specified by hand: a customer described what they wanted, someone translated that into a specification, and errors surfaced late, often after manufacture had started. The catalogue simply couldn't express the combinations, so the sale depended on a conversation.
What I built
- A multi-step builder that walks a customer through configuration one decision at a time, rather than presenting the full combinatorial space at once.
- Live preview, so the thing on screen is the thing being ordered. This is the part that carries the sale — bespoke products fail on doubt more than on price.
- A server-side engraving render API. Custom engraving needed to be previewed accurately and then reproduced exactly at manufacture, so the render is generated server-side and the same artwork travels downstream rather than being redrawn.
- Cart bundling through Shopify Functions (Cart Transform), so a configured product behaves like a single purchasable line item at checkout while retaining its component parts underneath.
- A NetSuite handoff, so the configuration lands in the ERP as manufacturing data rather than as a note for someone to interpret.
Why it was interesting
The hard part was never the rendering. It was making a customer completely certain about what they were about to buy, because behind that click sits a server-side render, a cart transform, and an instruction that causes metal to be cut. Every layer had to agree on what the configuration meant, and the failure mode for disagreement is an expensive physical object that is wrong.
Shopify's cart is not designed for products that are assembled at purchase time. Cart Transform makes it possible, but it moves a chunk of product logic into a Function that runs at checkout, which means the storefront, the Function and the ERP each hold part of the truth. Most of the design effort went into keeping those three consistent.
What I'd do differently
I would invest in automated coverage across the configuration → cart → ERP path much earlier. It's exactly the kind of multi-system flow where a regression is silent on the storefront and only visible in production, on a real order.