Loja Base & Loja Demo — White-label multibrand system for e-commerce delivery at scale
Design effort per store cut from ~60h to ~30–36h. 6× less rework. From two years of perception to a living product.
~60h → ~30–36h design effort per store
6× less rework per approval cycle
23 structural findings from pilot turned into prioritised backlog
Context
Bis2Bis delivers e-commerce stores to hundreds of B2B and B2C clients in the Brazilian market, with Magento on the backend. Before this product, every new project started from zero — components recreated, no shared standards, design and engineering running in parallel silos. The predictable consequence: high rework, unpredictable delivery time, visual drift across projects.
Challenge
Build an ecosystem that scales store delivery without locking clients into a generic look. In Design System terms, the terrain is among the most complex of the market: White Label + Multibrand.
Result before the product existed
Two years of work across four parallel fronts — Design Research, UX, Workflows and Tooling — had already moved the team’s numbers, even before the Loja Base product was born:
Design effort per store dropped from ~60 hours to ~30–36 hours. Rework per approval cycle dropped 6×.
That outcome was the case for consolidating everything into a product.
The solution in three pieces
Late 2025, design and engineering — until then running in parallel — converged into a single front. Three artifacts emerged from that convergence:
1. Loja Base (design + dev tool) White-label template. Ready store structure, brand layer swappable per client without touching the structural skeleton. Features toggleable per contract. The creation engine.
2. Loja Demo (commercial tool — my creation) A mirror of Loja Base with a facilitated control panel for the sales team to use live with the client in meetings — toggle sections, swap categories, switch PDP modes, simulate brand identity. Moves the pitch from PDF into a real, navigable store.
3. Flexi (parallel dev project) Frontend decoupled from Magento. The runtime that consumes what comes out of Loja Base. Accelerates the client-creation cycle.
Loja Base feeds Flexi. Loja Demo is the commercial face of both.
Key decisions
Three-layer ecosystem, not a loose template.
Base template → Commercial demo (all modules on) → Client fork. Template → Demo sync is automated via CI on every push to main. A client is born from forking the template, not the demo.
Brand layer separated from foundations.
Fixed tokens (tokens.ts) carry invariant scale — radius, fontSize, spacing, shadow, transition. Swap-able brand layer (brand.ts) carries what changes per client — palette, fonts, radius, elevation. Theme defined in CSS variables consumed by Tailwind 4 via @theme inline. Swapping client = swapping one file + assets.
Customization rules, not customization freedom. A client project can differ from the template in exactly four places: theme config, assets, data, flags. If you had to open a component to adapt the brand, that’s a hole in the template — fix the template, not the client. This rule traps divergence before it accumulates.
Audit scripts as build gates.
audit-tokens blocks hex literals and arbitrary Tailwind classes. validate-assets enforces kebab/webp conventions and resolved references. rebrand-check hunts demo-store strings that could leak to a client. validate-menu-coverage ensures every declared slug has menu and banner entries. The system enforces its own contract.
Per-client feature flags, no code branching.
Each client has a public/flags.json that overrides template defaults — flash sale, brand carousel, blog preview, wishlist on cards, login modal. Priority chain: localStorage (designer) > flags.json (client) > defaults (template). Features toggled without touching components.
Validation in the field
The first real client run on the template (anonymized: combat sports apparel vertical) surfaced 23 structural findings that became prioritised backlog and were fixed commit by commit on the template before the next client came in — rather than turning into accumulated debt.
To close the loop, I assembled a replication kit: the pilot client rebuilt on the corrected template. The operational success metric: “the AI rebuilds the client without opening a single component file.” If it had to open one, that’s a registered regression. That criterion changed how the template gets reviewed.
Result
~60h → ~30–36h of design per delivered store. 6× less rework in approval cycles. 23 structural findings from pilot became prioritised backlog and shipped fixes. Market positioning: Bis2Bis now operates in one of the most complex Design System categories (White Label + Multibrand).
Team and role
Design × engineering bridge. Design responsibilities: design-system architecture, Loja Base definition, full creation of Loja Demo as an independent product, client onboarding workflow (briefing/setup.html), audit tooling, internal and external documentation.
What I learned
- Migrating literals is surgery, not a shortcut. A first attempt to migrate hex literals with a single blind script broke intentional dark overlays — the mega menu turned transparent, the navbar overlapped the grid. The commit was reverted. Retake: one-shot only for unambiguous classes (
rounded,aspect,fontFamily); hex handled file-by-file. Automated audit complements but doesn’t replace human reading. - “Scalable system” is abstraction; “AI rebuilds the client without opening a component” is metric. Operationalising the success criterion changed how the template gets reviewed.
- A commercial tool is also a design tool. Loja Demo, built to sell, became a UX lab — putting clients to interact live with the store surfaced signals that formal research would take longer to capture.