Showroom Engine

Merchants don't need a 3D viewer — Shopify gives them one for free. They need the models they don't have, and the data on which variant actually sells.

Overview

Showroom Engine is my product bet on a simple observation: every e-commerce platform now ships a free 3D/AR viewer, and almost no merchant uses it — because they have no GLB files and no way to produce them. The viewer was never the bottleneck. The asset is. Showroom Engine covers the whole pipeline: photos in, optimized 3D model out, wired to real product variants, embedded anywhere, reporting which options customers actually touch.

My Role

Product, architecture, design, development. Solo.

The Challenge

The naive version of this product dies in five minutes of due diligence — a merchant googles "Shopify 3D" and finds out it's free. So the product had to be positioned and built around what's genuinely scarce: asset production (the wide bottleneck), variant-aware configuration (which the free viewers don't do), two-way sync with the store, and analytics that justify a subscription. And it had to work for clients who have no store platform at all — a furniture maker, a B2B catalog — which meant resisting the obvious move of building Shopify-first.

Approach

Adapter architecture as a hard rule

The runtime and panel never import a platform adapter directly — they talk to a contract (getAdapter(), capability flags). Standalone is the default adapter, with WooCommerce, Shopify, and a generic REST adapter behind the same interface. The first if (platform === 'shopify') in the runtime would quietly kill the product's entire advantage, so the rule is enforced at the architecture level, not by good intentions.

AI asset pipeline with a human gate

Meshy turns product photos into 3D geometry; Blender post-processing splits parts, names meshes (the mesh name is the variant-targeting contract), and compresses to under 3 MB. AI gets you 60–80% of a publishable model — so a manual acceptance gate is designed into both the pipeline and the pricing. The promise is "model in 3 days," never "upload photos, done."

The embed

A 2.5 kB loader script with a strict 15 kB budget, talking to the host page over postMessage. The demo renders a procedural product with zero assets and zero database — the whole thing works before any client uploads anything.

Design

Workshop/print-shop aesthetic: paper, ink, vermilion. Contrast ratios are computed, not eyeballed — the accent color passes AA on interactive elements and is banned from small text.

Results

Phase 0: scaffold builds clean, all routes render, the demo runs SSR with no external assets. A library of eight demo models is specced, each showing a different configurator mechanic — color, material, engraving, combinatorics, dimensions — because "one engine, eight mechanics" is the sales argument. Phased rollout is gated by a rule I'm actually following: no phase N+1 until someone has paid for phase N.

Key Takeaways

Positioning was the hardest engineering decision in the project. Everything in the architecture — the adapter contract, the standalone default, nullable store bindings in the schema — exists to keep the product sellable to people the obvious version would have excluded.