Loja Base & Loja Demo — Sistema white-label multibrand para entrega de e-commerce em escala

Contexto

A Bis2Bis entrega lojas de e-commerce para centenas de clientes B2B e B2C no mercado brasileiro, com backend em Magento. Antes deste produto, cada projeto começava do zero — componentes recriados, sem padrões compartilhados, design e dev correndo em silos paralelos. A consequência era previsível: refação alta, tempo de entrega imprevisível, inconsistência visual entre projetos.

Desafio

Construir um ecossistema que escalasse a entrega de lojas sem prender o cliente em visual genérico. Em termos de Design System, o terreno é dos mais complexos do mercado: White Label + Multibrand.

Resultado prévio (antes do produto existir)

Dois anos de trabalho em quatro frentes paralelas — Design Research, UX, Workflows e Ferramentas — já tinham mudado os números do time, mesmo antes do produto Loja Base nascer:

Esforço de design por loja caiu de ~60 horas para ~30–36 horas. Refação por ciclo de aprovação caiu 6×.

Esse resultado foi o que justificou consolidar tudo num produto.

A solução em três peças

No final de 2025, design e dev — que até então corriam em paralelo — se juntaram numa frente só. Três artefatos nasceram dessa convergência:

1. Loja Base (ferramenta de design + dev) Template white-label. Estrutura pronta de loja, visual adaptável por cliente sem alterar o esqueleto. Features ativáveis/desativáveis por contrato. Camada de marca intercambiável separada das fundações. É o motor de criação.

2. Loja Demo (ferramenta comercial — minha criação) Espelho da Loja Base com painel de controle facilitado para o time comercial usar ao vivo com cliente em reunião — liga/desliga seções, troca categorias, alterna entre modos de PDP, simula identidade visual. Tira a venda do PDF e leva pra dentro de uma loja real navegável.

3. Flexi (projeto dev paralelo) Frontend desacoplado do Magento. Runtime que consome o que sai da Loja Base. Acelera o ciclo de criação de cliente.

Loja Base alimenta Flexi. Loja Demo é a face comercial dos dois.

Decisões-chave

Ecossistema em três camadas, não um template solto. Template base → Demo comercial (todos os módulos ativos) → Fork por cliente. O sync Template → Demo é automatizado via CI a cada push em main. Cliente nasce de fork do template, não da demo.

Camada de marca separada das fundações. Tokens fixos (tokens.ts) carregam escala invariante — raio, fontSize, spacing, shadow, transition. Marca intercambiável (brand.ts) carrega o que muda por cliente — paleta, fontes, raio, elevação. Theme em CSS variables consumido pelo Tailwind 4 via @theme inline. Trocar de cliente = trocar um arquivo + assets.

Regras de customização, não liberdade de customização. Um projeto de cliente só pode diferir do template em quatro lugares: configuração de tema, assets, dados e flags. Se for preciso abrir um componente para adaptar a marca, isso é um buraco no template — conserta-se o template, não o cliente. Essa regra trava a divergência antes que ela se acumule.

Scripts de auditoria como gates de build. audit-tokens bloqueia hex literais e classes Tailwind arbitrárias. validate-assets exige convenção kebab/webp e referências resolvidas. rebrand-check caça strings da loja demo que poderiam vazar pro cliente. validate-menu-coverage garante que todo slug declarado tem entrada no mega menu. O sistema enforça o próprio contrato.

Feature flags por cliente, sem branch de código. Cada cliente tem um public/flags.json que sobrescreve defaults do template — flash sale, brand carousel, blog preview, wishlist nos cards, login modal. Cadeia de prioridade: localStorage (designer) > flags.json (cliente) > defaults (template). Liga e desliga features sem tocar em componente.

Validação no campo

O primeiro cliente real rodado no template (anonimizado: vertical de artigos esportivos de combate) revelou 23 falhas estruturais que viraram backlog priorizado e foram corrigidas commit a commit no template antes do próximo cliente entrar — em vez de virar dívida acumulada.

Para fechar o ciclo, montei um kit de replicação: o cliente piloto refeito sobre o template corrigido. A métrica de sucesso operacional: “a IA recria o cliente sem precisar abrir nenhum arquivo de componente”. Se precisar abrir, é regressão registrada. Esse critério mudou o jeito de revisar o template.

Resultado

~60h → ~30–36h de design por loja entregue. 6× menos refação em ciclos de aprovação. 23 falhas estruturais do piloto viraram backlog priorizado e fixes versionados. Posicionamento de mercado: Bis2Bis passou a operar em uma das categorias mais complexas de Design System (White Label + Multibrand).

Equipe e papel

Ponte design × dev. Responsabilidades de design: arquitetura do design system, definição da Loja Base, criação completa da Loja Demo como produto independente, workflow de onboarding de cliente (briefing/setup.html), audit tooling, documentação interna e externa.

O que aprendi

• Migração de literais é cirurgia, não atalho. Uma tentativa de migrar hex literais com script único quebrou overlays escuros intencionais — o mega menu virou transparente, a navbar sobrepôs o grid. Commit foi revertido. A retomada virou one-shot só de classes não-ambíguas (rounded, aspect, fontFamily); hex passou a ser tratado um arquivo por vez. Auditoria automatizada complementa, não substitui leitura humana.
• “Sistema escalável” é abstração; “IA recria o cliente sem abrir componente” é métrica. Operacionalizar o critério de sucesso mudou o jeito de revisar o template.
• Ferramenta comercial é também ferramenta de design. A Loja Demo, criada pra vender, virou laboratório de UX — ao botar o cliente pra interagir ao vivo com a loja, surgiram sinais que pesquisa formal demoraria pra capturar.