
Building Scalable Product Configurators: A Three-Generation Pipeline
The 'Three-Generation Pipeline' is a term we developed internally to describe how serious configurator projects evolve — not in one clean arc, but in three distinct architectural generations, each requiring a conscious decision to rebuild rather than iterate.
Generation one is the proof-of-concept. For luxury projects, this usually means Unreal Engine's Variant Manager, hardcoded logic, static camera setups, and a UI bolted on top. It gets you to a demo fast. The NORQAIN Wild ONE of 1 started here — built under a 4-month deadline for Watches & Wonders 2024. Gen one configurators have one job: prove the concept is worth pursuing. They do it well. But they are not meant to scale.
The problems emerge immediately after launch. Every new option requires manual Variant Manager work. Materials are baked rather than procedural. UI changes mean touching Unreal directly. Business rules — pricing logic, availability rules, regional variants — live inside Blueprints, making them invisible to anyone without Unreal access. The system is owned by developers, not by the brand.
Generation two fixes the architecture. The core shift: separate data from logic, and logic from presentation. Options, combinations, pricing, and rules move into structured data assets — or better, into a backend the brand can manage without touching Unreal. The UI moves out of Unreal entirely; in our case, into React, connected via Socket.IO. The Unreal runtime becomes a renderer, not a decision-maker. This is where configurators become products rather than demos.
But Gen two still carries architectural debt. Data might live in Unreal's asset system rather than in a proper backend. The pipeline between content authoring and runtime is slow. Small changes still require full rebuilds. Cross-platform support is bolted on rather than native.
Generation three is the platform. Core logic moves from Blueprints to C++. Data ownership transfers entirely to the backend — Unreal becomes a pure rendering client. The system supports hot-patching: configurations, pricing, and rules update without touching the executable. Multiple output formats — PC, WebGL, Pixel Streaming, mobile — share a single source of truth. At this stage, non-technical staff can manage the full catalog without developer involvement.
The jump between generations is not about adding features. It is about recognizing when the architecture has become the bottleneck — and having the courage to rebuild rather than patch. In our experience, most teams wait too long. The signal is consistent: when fixing one thing breaks two others, you are already overdue.
For teams planning their first configurator, our advice: design for Gen two from the start, even if you are building Gen one. The decisions that are hardest to undo — where data lives, who owns it, how the UI connects to the engine — are the ones made in the first sprint.