Saltar al contenido
Proyectos
Logo de Tool Center México

Tool Center México

Frontend del core multi-marca

Una marca propia sobre un core de ecommerce compartido, sin duplicar código.

  • Multi-marca
  • White-label
  • Ecommerce
  • Vue 3
  • Vite
  • Pinia
  • TypeScript
  • Cypress

Una base, varias marcas

Tool Center corre sobre el mismo core que Dinámica. La marca se resuelve en build por variable de entorno: no hay forks ni copias del código base.

Configuración declarativa

Cada marca tiene su archivo de configuración validado por schema (feature flags, precios, comportamiento) y su propio módulo de permisos por rol, cargado dinámicamente según la marca activa.

Identidad propia

Logos, tema de color, favicons y assets se sirven por marca; el color y el branding se aplican en tiempo de ejecución sin tocar el resto de la app.

Builds y pruebas por marca

Targets de build y despliegue independientes por marca, con suites de pruebas end-to-end dedicadas para su comportamiento y permisos específicos.

Storefront de Tool Center México en escritorio, con catálogo de productos.
Tool Center México — vista de escritorio.
El mismo storefront de Tool Center México en móvil.
La misma marca en móvil.

Tool Center México no es "otra tienda": es la misma plataforma de ecommerce que Dinámica, operando como una marca distinta sobre el mismo código. Es el caso que mejor muestra el tipo de arquitectura en la que trabajo —un core que se comporta como varios productos.

El mecanismo es una arquitectura multi-marca: la marca activa se define por variable de entorno al compilar (VITE_BRAND_NAME) y la API responde según su propio APP_TYPE. A partir de ahí, cada marca resuelve su identidad y su comportamiento desde configuración, no desde código duplicado:

  • Configuración por marca en archivos JSON validados por un schema, con feature flags, reglas de precio y opciones de la tienda.
  • Permisos por marca en módulos separados que se cargan dinámicamente según la marca, con Dinámica como fallback.
  • Assets y tema (logos, colores, favicons) servidos por marca y aplicados en runtime.
  • Build, deploy y pruebas independientes: cada marca tiene sus targets y sus pruebas end-to-end.

El resultado es que agregar o ajustar una marca es cambiar configuración y assets, no reescribir la aplicación. Esa capacidad —que un mismo storefront sostenga marcas con identidad, precios, permisos y flujos propios— es lo que después se empaqueta como producto en Hubsho.