House of CB: Next.js Platform Rebuild — Admin & Business Domain

Overview

House of CB is replacing its legacy PHP and Smarty commerce stack — built on CS-Cart, a monolithic e-commerce platform — with a new Next.js 16 system for an international team on a live store where a dress sells roughly every 30 seconds. This rebuild is the system the brand will run going forward for administration, internal operations and the business domain that pricing, stock and orders depend on — not a cosmetic UI refresh or a side experiment alongside the old admin. This role focuses on the admin panel and commerce domain logic — pricing, stock, orders, and internal operations. Work starts from real operational flows mapped with product, then extracts domain parity from the current production system rather than cloning legacy screens: a greenfield build with new architecture and technology that replaces the old platform’s capabilities. Data access goes through Prisma on MySQL. Redis is the shared application cache for hot catalog and expensive domain reads across services and instances; Next.js caching sits on the render and data-fetching layer so those paths do not recompute on every request — two complementary layers, not duplicates. The rebuild treats revenue-critical rules as first-class software: a pricing or inventory mistake costs money at this volume. Explicit domain boundaries also make internal process automation practical — work that was theoretically possible on the old codebase but nearly impossible to ship safely when rules lived scattered across a decade of mixed, multi-author legacy code.

Key Features

Challenges & Solutions

Replacing the live House of CB stack without breaking revenue paths means domain parity before cosmetic UI — this rebuild is the future admin and domain platform, so pricing, stock and order rules had to be pulled out of a CS-Cart PHP and Smarty codebase where years of contributors left hardcoding and tangled presentation logic. Coordinating with Front on storefront ownership while Back owns admin and domain required clear contracts so both sides do not reintroduce the same coupling. Caching had to be deliberate given the traffic: Redis for shared hot domain reads across instances, Next.js caching for render and fetch memoization, without serving stale catalog or inventory under load. Enabling automation of day-to-day brand operations on top of an explicit domain is only viable once those rules are testable and isolated — on the legacy stack the same automation was possible in theory and nearly impossible in practice.

What I Learned

Rebuilding the platform the brand will operate on going forward reinforced how to extract domain rules from legacy systems without cloning screens, how to split ownership between storefront and admin teams without duplicating business logic, and how Redis (shared application cache) and Next.js caching (render/fetch layer) complement each other on high-traffic read paths. Validated that explicit application layers and TypeScript boundaries make performance, safety, and future automation of internal workflows feasible in ways a mixed legacy stack never supported cleanly.

Built with