Client context
CubeCom Pro is client work. Introfinity contributed product and engineering work on a configurable commerce platform; client-owned brand assets, commercial terms, and unpublished internals remain with the client.
Configuration is the product, not the renderer
CubeCom Pro started from a common commerce failure: visual customizers and cart systems drift apart. A shopper can assemble something that looks valid in 3D while the commerce layer quietly resolves a different SKU, price, or availability state. Merchants then maintain two stories of the same product — one for looking, one for buying.
The product promise that survived was sharper than “build a 3D configurator”:
Turn product data into interactive, rule-bound, purchasable product experiences.
That framing forced a kernel decision early. 3D is an important surface. It is not the system of record. The configuration graph is. The same graph can drive 3D, 2D, headless storefronts, embedded experiences, APIs, and commerce integrations.
Rules first. Variants last.
Many commerce stacks invert the problem. They explode SKUs, then try to reconstruct selection UX on top of the explosion. CubeCom Pro encodes configuration logic first, then resolves legal configurations to SKU, external variant, price, inventory, and cart behavior.
The conceptual kernel stayed intentionally small:
- Product — the configurable thing being authored and sold
- Choice / ChoiceValue — selectable dimensions and options
- Constraint — rules that keep combinations coherent
- Selection — runtime value object for the shopper’s current state
- ValidationResult / Availability — computed outcomes, not hand-edited truths
Everything else — revisioning, visual authoring, assets, commerce mapping, persistence — hangs off that kernel. The platform should not require merchants to replace their existing PIM, catalog, storefront, or commerce engine. CubeCom owns configuration semantics and resolution. External systems keep their commerce responsibilities.
Published means frozen. Active means served.
Authored state needs a hard freeze boundary. A product revision moves from draft to published. Once published, anything capable of changing how that revision resolves or renders must stop being mutable behind the revision — including visual bindings and model linkage, not only a GLB file.
The platform also separates two words teams often collapse:
- Published — an immutable revision exists
- Active — a revision is the one currently selected for runtime
Publishing does not automatically mean activation. That distinction keeps authoring safe and serving explicit.
What the monorepo actually carries
The CubeCom Pro repository is a Turborepo monorepo spanning admin console, API, backoffice, commerce, customizer, editor, docs, and landing surfaces. The admin console covers organizations, entitlements, feature flags, integrations, jobs, leads, audit, and plan/usage controls — the operational shell around a configurable commerce core.
That breadth matters because configuration platforms fail in the seams: entitlement mismatches, unpublished revisions leaking into storefronts, and integrations that assume every merchant’s commerce engine speaks the same dialect.
What this case study claims
CubeCom Pro is not marketed here as a finished universal commerce replacement. It is a product thesis proven in code:
Keep validity, availability, visual state, and commerce state as projections of one configuration graph — or accept silent disagreement between looking and buying.
Status: In development. Public site: cubecompro.com. Proprietary implementation details remain with the client engagement.