Vimo
Un sitio, un portal y un login para una suite de productos SaaS para pymes de Argentina.
Vimo agrupa siete productos, y cada uno vivía en su propio repo. No había un sitio que los vendiera juntos, ni un portal después del login, ni una marca común. El diseño repetía el precio y el color de cada producto en cuatro pantallas distintas.
Tres decisiones que lo definieron.
- 01
Un login para todos los subdominios
Por qué. Cada producto se despliega en su propio subdominio. Una sola instancia de Clerk comparte la sesión por el dominio padre. Los módulos contratados viajan en el token, así cada app chequea el acceso sin ir a la base.
El costo. El token tiene un límite de tamaño, así que sólo van los ids de los módulos. Un producto con dominio propio queda afuera del login compartido.
- 02
Marca y precios como código, no como texto
Por qué. Colores, nombres y precios viven una sola vez en paquetes de TypeScript. La calculadora de precios y el recomendador de plan usan las mismas funciones puras. Los tokens se compilan a CSS, así una app de React Native puede importar los mismos valores.
El costo. Los tokens necesitan un paso de generación. Si alguien cambia el TypeScript y no lo corre, el CSS queda viejo.
- 03
Desarrollo local en subdominios, no en puertos
Por qué. Los navegadores comparten cookies entre puertos, así que un test de login en localhost pasa por la razón equivocada. Un proxy Caddy sirve cada app en un subdominio de vimo.localhost. Los tests ven las mismas reglas de cookies que producción.
El costo. Correrlo en local pide Docker y algunos pasos más. La suite E2E además levanta cuatro repos hermanos.
Vimo
Un sitio, un portal y un login para una suite de productos SaaS para pymes de Argentina.
- Rol
- Implementación del diseño, arquitectura y frontend
- Stack
- Next.js 16, React 19, TypeScript, Clerk, Turborepo, Playwright
Vimo agrupa siete productos, y cada uno vivía en su propio repo. No había un sitio que los vendiera juntos, ni un portal después del login, ni una marca común. El diseño repetía el precio y el color de cada producto en cuatro pantallas distintas.
Tres decisiones que lo definieron.
Un login para todos los subdominios
Por qué. Cada producto se despliega en su propio subdominio. Una sola instancia de Clerk comparte la sesión por el dominio padre. Los módulos contratados viajan en el token, así cada app chequea el acceso sin ir a la base.
El costo. El token tiene un límite de tamaño, así que sólo van los ids de los módulos. Un producto con dominio propio queda afuera del login compartido.
Marca y precios como código, no como texto
Por qué. Colores, nombres y precios viven una sola vez en paquetes de TypeScript. La calculadora de precios y el recomendador de plan usan las mismas funciones puras. Los tokens se compilan a CSS, así una app de React Native puede importar los mismos valores.
El costo. Los tokens necesitan un paso de generación. Si alguien cambia el TypeScript y no lo corre, el CSS queda viejo.
Desarrollo local en subdominios, no en puertos
Por qué. Los navegadores comparten cookies entre puertos, así que un test de login en localhost pasa por la razón equivocada. Un proxy Caddy sirve cada app en un subdominio de vimo.localhost. Los tests ven las mismas reglas de cookies que producción.
El costo. Correrlo en local pide Docker y algunos pasos más. La suite E2E además levanta cuatro repos hermanos.