I've been building Augmentlee — a web-AR toolkit for e-commerce — for about a year now, on and off. The premise is simple: shoppers should be able to view a 3-D model of a product through their phone camera without installing an app. The pitch writes itself. The implementation is a series of small disasters.
If you're considering doing something like this, here's the brief version of what I wish I'd known.
Three.js is the easy part
You can build a working product viewer in an afternoon. Load a .glb, set up some lights, add an OrbitControls, and you've got something that looks like a real 3-D product on a webpage. Three.js is excellent — well-documented, well-maintained, and the community has answered most of the questions you'll have.
The trouble starts the moment you have to support more than one product.
Asset pipelines are a real engineering problem
Real merchants don't have .glb files lying around. They have, at best, an .obj or an .fbx from the manufacturer, with separate texture files in a folder somewhere, with naming conventions that vary by decade. Sometimes they have a SketchUp file. Sometimes they have a photograph of the box.
The first version of Augmentlee assumed a clean .glb. The second version is mostly the conversion pipeline.
I ended up writing a small Node service that accepts any common 3-D format, normalizes it to GLTF, optimizes the textures, decimates the mesh, and validates that it'll actually load in a browser. None of this is Three.js's problem — but if you're shipping a product, it becomes your problem.
WebXR support is uneven
iOS Safari supports its own thing (AR Quick Look) which is fine but isn't WebXR. Android Chrome supports WebXR proper. Everyone else supports neither. If you want a single viewer that works everywhere, you end up shipping three code paths — one for each major platform — and falling back to a non-AR product spin on desktop.
Detecting which path to take is also harder than you'd hope, because the answer depends on the browser, the OS version, and whether the user has granted camera permission, in some specific order. My detection code has more comments than logic.
Lighting is the difference between believable and uncanny
The single biggest visual upgrade I got, by far, was switching from default Three.js lighting to a real HDR environment map. The cost is a ~2 MB file per scene. The benefit is that the product stops looking like a polygon on a screen and starts looking like an object.
Beyond that, the work was almost all about shadows. Real objects sit in the world. A 3-D model floating in space — no contact shadow, no ground plane — reads as fake immediately, even when everything else is right. I now bake a simple contact shadow into every scene as a separate plane underneath the model. Cheap, fast, makes a huge difference.
The product is not the renderer
I think this is the real lesson from a year of Augmentlee. When I started, I thought I was building a 3-D renderer with some product features on top. What I'm actually building is a content management system for product 3-D models, with a 3-D renderer as a frontend feature.
The interesting questions are: who uploads the model? How do they preview it? How do they version it? How do they roll it back when it looks wrong? What happens when the merchant changes the SKU? These are CMS questions, not graphics questions. And they're the questions that determine whether anyone actually uses your product.
Should you build it?
If you have a single, motivated merchant with one or two hero products and you want to show off — absolutely. Three.js will get you there fast and look great.
If you want to be the "drop in AR for any e-commerce site" platform — be prepared to spend most of your time on file formats, content management, and the kind of unglamorous infrastructure that makes the glamorous part work. The renderer is the showroom. The pipeline is the factory.