Configurators are where 3D on the web earns its keep. A portfolio piece can be as strange as you want, but a configurator has a job: help someone pick the right product and feel sure about it. Over the past months I built three of them for Tenjam, a premium pool furniture brand from the US, and the process taught me more about client work than any experiment ever did.
This is the practical version of what I learned. Not the theory, the actual order of operations.
Start with the question the buyer is asking
Tenjam's Laylo lounger sits in the water, and the thing customers actually struggle with is riser height. Four inches or eight, and what happens at their pool depth. That one question shaped the entire interface: a depth slider, a visible waterline, and instant feedback on which setup fits. Everything else is secondary.
Before you open your editor, write down the single decision your configurator helps someone make. If you can't name it, the project isn't a configurator yet, it's a 3D viewer with buttons.
Your flashiest demo is a conversation, not the product
At the exploration stage I built Tenjam a demo from their document imagery and pushed it toward something properly immersive. Camera moves, atmosphere, the lot. They liked it. Then they told me something more valuable than praise: their users do not want a journey, they want to understand the product in about thirty seconds.
So we shipped the simple version, and it was the right call. The demo still did its job though. It showed range, built trust, and made the direction conversation concrete instead of theoretical. These days I treat the wild version as a scoping tool and the calm version as the product.
Separate the product data from the renderer
The second configurator request came in right after the first one shipped. That's the moment structure pays off. Model paths, thumbnails, finish options and depth rules all live as structured product data, and the scene code just reads it. Adding the Shayz lounger, their trickiest product to explain because you add weights to match pool depth, took a week start to finish. Not because I rushed, because nothing needed redesigning.
You can see how the series grew in my projects: the Laylo configurator, the Shayz configurator, and the full Tenjam catalog configurator that is being built to hold 18 products.
Manufacturing files are not web assets
Clients rarely have glTF files sitting around. Tenjam's models came as STL, straight from their manufacturing pipeline. STL has no materials, no UVs, no sense of scale, it's just triangles. Every model went through conversion, cleanup and texture compression before it touched a browser. That pipeline deserves its own write up, so I made one: From STL to glTF.
WebGPU is ready, with a seatbelt
All three configurators render through WebGPU with a WebGL fallback for devices that do not support it yet. Three.js makes this almost boring now, the renderer switches on its own. WebGPU coverage sits somewhere around seventy percent of browsers and keeps climbing, and the fallback quietly covers everyone else. For product tools this is the sweet spot: performance headroom where it exists, and no customer left staring at a blank canvas.
Keep the budget mobile shaped
People configure pool furniture from a phone, on a deck, in the sun. If the page struggles on a mid range Android, it does not matter how nice your water shader is. Lazy load models per product, compress every texture, keep the initial payload lean, and test on a real cheap phone rather than the simulator.
The short version
- Write down the one buying decision the tool supports, before any code.
- Build the bold demo to align on direction, then ship the calm version.
- Keep product data separate from the renderer so product two takes a week, not a month.
- Budget real time for converting manufacturing files into web ready assets.
- Render with WebGPU, fall back to WebGL, and never make the customer care which one they got.
- Test on the cheapest phone you can find.
The first configurator did not lead to more work because it was impressive. It led to more work because it shipped fast, matched their users, and created no maintenance headaches. The flashy stuff gets you the meeting. The boring decisions get you the relationship.