AURA | أورا
Premium Luxury Fashion E-commerce & ERP Platform
- Role
- Product design, architecture & full implementation
- Type
- E-commerce Storefront + Internal ERP
Overview
AURA is an enterprise-grade luxury fashion platform that unifies a couture storefront with a complete internal ERP — one codebase where the customer experience and the back-office share the same data layer and react to each other in real time.
I designed and built it end-to-end: information architecture, two distinct visual languages, and the frontend engineering underneath. The storefront reads like an editorial lookbook in Arabic-first RTL; the admin is a dense operational cockpit — two opposite design worlds living inside one application.
The Problem
Luxury brands typically run their storefront, inventory, orders, content, and finances on disconnected tools. Stock reconciliation lags behind sales, promotional layout changes wait for developer deploys, and every hand-off between systems is a chance for error.
The product also had to serve two opposite audiences at once: shoppers who expect quiet, editorial luxury, and operations staff who need dense, fast, data-heavy screens. Most platforms compromise one to serve the other.
Goals
One source of truth
A checkout on the storefront must appear in the ERP instantly — no sync jobs, no reconciliation.
No-code content operations
Operators update homepage sections, collections, and navigation from a website manager with live preview — no deploys.
Arabic-first luxury
Full RTL editorial design conceived in Arabic from the start — not a translated afterthought.
Enterprise-ready structure
Services, repository contracts, and RBAC from day one, so the demo data layer can be swapped for real APIs without touching the UI.
Research
I studied how established luxury e-commerce houses use whitespace, serif editorial typography, and restrained motion to signal price point — and noted that regional Arabic storefronts are almost always translated layouts, not Arabic-first designs. That gap became AURA’s positioning.
On the operations side, I mapped the real workflows an operator walks through — order placement to invoice and packing slip, stock adjustment to low-stock alert, content edit to publish — and let those journeys define the ERP’s seventeen modules rather than copying a generic admin template.
Auditing who touches what surfaced the RBAC design: financial records and staff management restricted to senior roles, plus a “view as role” switcher so permission boundaries can be verified visually in seconds.
Design Decisions
Two design languages, one system
The storefront is warm parchment, serif, and air; the admin is a glassmorphic dark cockpit. The hard context switch is intentional — it tells staff they have crossed from brand into operations.
The CMS previews the real storefront
The website manager renders the actual homepage components inside a framed preview with desktop, tablet, and mobile toggles — operators see exactly what customers will see before publishing.
Editorial typography as brand
A spaced latin serif wordmark coexists with Arabic display type; generous whitespace and full-bleed photography do the selling instead of badges and banners.
Mobile commerce ergonomics
A sticky add-to-bag bar, bottom tab navigation, and a size assistant keep the purchase path reachable with one thumb on every product page.
Architecture
A decoupled monolith: one Next.js App Router application, layered so every module talks through services and events — never directly to another module’s state.
Presentation
Next.js App Router · React · Tailwind CSS73 routed pages across two route groups — the couture storefront and the admin cockpit — each with its own layout shell and design tokens.
Domain services
TypeScript service singletons21 service singletons (ProductService, OrderService, InventoryService…) own all business logic; UI components never compute domain rules themselves.
Event layer
Custom EventBus + React hookA custom EventBus with a useEventBus hook: checkout emits, and the orders board, inventory alerts, and dashboard KPIs all react — no module imports another.
Data contracts
Repository pattern · localStorage adaptersRepository interfaces sit between services and storage; 36 mock repositories persist to localStorage for the demo and can be swapped for real APIs without touching the UI.
Auth & RBAC
Permission context · role guardsSession auth with hashed credentials stored apart from staff profiles; a permission context gates routes and actions per role, with a live “view as role” switcher.
Delivery & safety
Vercel · DOMPurify · dynamic SEODeployed on Vercel with dynamic metadata, OpenGraph, and sitemaps; all operator-entered HTML passes through DOMPurify before it renders.
Technology Stack
Next.js (App Router)
- Why
- One deploy serves two products — storefront and ERP — with route-group layouts and per-module code splitting.
- Where
- All 73 pages: storefront routes and the admin (dashboard) route group.
- Value
- The heavy ERP never weighs down the customer-facing bundle.
TypeScript
- Why
- The service/repository architecture only holds if the contracts between layers are enforced by the compiler.
- Where
- 334 fully typed files — every service, repository contract, and component.
- Value
- Refactors across 17 modules stay safe; the mock-to-real API swap is a type-checked operation.
Tailwind CSS
- Why
- Two opposite design languages needed one utility system with swappable tokens, plus first-class RTL support.
- Where
- Parchment editorial tokens on the storefront; glassmorphic dark tokens in the admin.
- Value
- Shared primitives, divergent skins — without duplicating a component library.
Custom EventBus
- Why
- Cross-module reactivity without dragging in a global state library the architecture didn’t need.
- Where
- Order placement, stock movements, notifications, and dashboard KPIs.
- Value
- Modules stay decoupled: new subscribers appear without editing the emitting module.
Framer Motion
- Why
- Luxury reads in restraint — micro-reveals and eased transitions, never spectacle.
- Where
- Storefront hero reveals, product galleries, and section transitions.
- Value
- Motion that supports the editorial tone instead of competing with it.
DOMPurify
- Why
- A CMS that accepts operator HTML is an XSS surface by definition.
- Where
- Every rich-text and banner field in the website manager, sanitized before render.
- Value
- Operators get flexibility; customers get a safe page.
Challenges & Solutions
Challenge
Real-time flow from checkout to ERP — orders, inventory, and dashboards must all update the instant a customer buys, with no backend queue to lean on in demo mode.
Solution
Domain events over shared state: checkout emits through the EventBus, and each module’s service reacts independently — the orders board, low-stock alerts, and KPI cards update from the same single event.
Challenge
A CMS that cannot break the storefront — operators needed layout power without the ability to ship a broken homepage.
Solution
Schema-driven sections rendered by the same components as production, previewed live across three device widths, with sanitization and validation gating every publish.
Challenge
Enforcing RBAC across 54 admin screens without scattering permission checks through every component.
Solution
A single permission context feeds route guards and action gates; the “view as role” switcher makes every role’s boundary visually testable in seconds.
Challenge
Luxury typography in RTL — Arabic display type, a latin serif wordmark, and mirrored layouts had to feel composed, not converted.
Solution
Arabic-first composition from the wireframe stage: line lengths, letter-spacing, and grid direction were designed in Arabic, then verified against the latin brand marks.
Performance
Route-level code splitting
The App Router keeps every admin module in its own chunk — a shopper never downloads a gram of ERP code.
Optimized imagery
Catalog and editorial photography served through next/image with responsive sizing and modern formats.
Zero-error compile
The full 334-file codebase builds with zero TypeScript and zero ESLint errors — a hard gate, not an aspiration.
Results
73
Routed pages
54
ERP admin screens
21
Domain services
17
Admin modules
36
Swappable data repositories
100%
TypeScript, zero lint errors
Every figure above is counted directly from the codebase — no estimates, no vanity metrics.
Lessons Learned
Events beat props at module scale. Investing in the EventBus early kept modules decoupled as scope grew from a storefront into a full ERP.
Design languages may diverge; the system underneath must not. Two skins over shared primitives cost far less than two component libraries.
Contracts first. Writing repository interfaces before implementations made the mock-to-real swap honest — and trivially verifiable by the compiler.
Arabic-first is a design decision, not a translation pass. Rhythm, line length, and hierarchy behave differently when the layout is born RTL.
Gallery
