“En mis 6 verticales lanzados sobre el mismo template en los últimos 12 meses, el setup inicial bajó de 3-4 semanas a 3-5 días. Los paquetes compartidos eliminan entre el 60% y el 80% del código de infraestructura repetido. El costo de no tener template: 4 semanas de deuda de setup en cada nuevo vertical — 24 semanas perdidas en 6 lanzamientos.
Un template SaaS vertical de lanzamiento rápido es la estructura base que resuelve autenticación, layout, permisos, onboarding, billing y settings de una vez, sin mezclarlos con la lógica específica del mercado. Eso permite concentrar el primer sprint en la hipótesis de dominio, no en infraestructura repetida.
Template SaaS vertical: lanzar rápido no es escribir más rápido
Lanzar rápido un SaaS vertical significa reducir la cantidad de decisiones nuevas que hay que tomar antes de probar una hipótesis concreta. En casi todos los productos B2B hay piezas que se repiten: usuarios, organizaciones, permisos, navegación, pantallas de configuración, emails transaccionales, formularios, tablas, estados de carga, estados vacíos, suscripciones y logs básicos. Si cada vertical empieza desde cero, el primer sprint se consume en infraestructura que no valida nada del mercado.
El extremo opuesto también es peligroso. Un template SaaS demasiado ambicioso intenta resolver de antemano CRM, inventario, analytics, documentos, tareas, chat y automatizaciones. Parece potente, pero termina siendo una masa de opciones que cada nuevo producto debe desactivar, adaptar o ignorar.
El patrón que mejor funciona es más simple: un shell vertical delgado, paquetes compartidos fuertes y una zona deliberadamente no abstraída para la lógica que todavía está aprendiendo del mercado.
Qué es concretamente un shell vertical
El shell es la aplicación base que un usuario ve antes de entrar en la particularidad del dominio. No es una librería, no es un design system, no es el producto completo. Es el contenedor operativo que hace que el SaaS se sienta real desde el primer día.
En un SaaS vertical para estudios contables, clínicas, inmobiliarias o agencias, el shell responde las mismas preguntas iniciales:
- Cómo entra el usuario y a qué organización pertenece.
- Qué puede ver o modificar según su rol.
- Dónde están las secciones principales y cómo se navega entre ellas.
- Cómo se configura la cuenta, se gestiona el plan y se conectan integraciones esenciales.
- Cómo se representan errores, vacíos y permisos insuficientes.
Ese shell debe ser concreto. Tiene rutas reales, pantallas reales y decisiones de producto reales. La diferencia importante es que el shell no debería contener reglas de negocio profundas. Si el producto es para inmobiliarias, el shell puede saber que existe una sección llamada "Propiedades", pero no debería imponer cómo se calcula una comisión o cómo se clasifica una oportunidad comercial. Eso pertenece al vertical.
Qué contiene el shell capa por capa
El shell sostiene seis tipos de responsabilidades. Entender cuáles son ayuda a no meterle más de lo que le corresponde.
Estructura de aplicación. Rutas, layout, navegación, sidebar, topbar, breadcrumbs, páginas de error y estados vacíos generales.
Sesión y tenant. En un SaaS vertical casi siempre hay una unidad de trabajo: empresa, cuenta, workspace o equipo. El shell resuelve cómo se selecciona esa unidad y qué pasa si el usuario no pertenece a ninguna.
Settings comunes. Perfil, organización, miembros, invitaciones, roles, facturación, notificaciones y preferencias básicas.
Onboarding estructural. No el onboarding de dominio, sino el que prepara la cuenta: crear organización, invitar miembros, completar datos mínimos, elegir plan.
Billing y límites. El shell no necesita conocer todas las reglas comerciales del vertical, pero sí debe saber cómo representar planes, estados de suscripción, trial, bloqueo por falta de pago y upgrade.
Convenciones de feedback. Toasts, dialogs, confirmaciones destructivas, loading states, empty states y errores recuperables deben sentirse consistentes.
Qué contienen los paquetes compartidos
Los paquetes son para capacidades reutilizables que no deberían depender de un vertical específico.
| Paquete | Qué incluye | Qué no incluye |
|---|---|---|
| UI | Botones, inputs, tablas, modals, menus, primitives de layout | Pantallas completas de dominio específico |
| Datos | Clientes, adapters, validadores, helpers de paginación | Modelos de negocio del vertical |
| Emails | Templates base, layout, componentes reutilizables | Copy específico del dominio |
| Observabilidad | Logs, traces, métricas técnicas, captura de errores | Métricas de negocio del vertical |
| Permisos | Primitives: roles, policies, guards | Políticas que mezclan negocio y producto |
La regla de corte es esta: si una pieza mejora cuando se vuelve más genérica y estable, va a paquete. Si pierde claridad al separarse del producto, todavía no va.
Qué no se abstrae
Esta es la parte más difícil del patrón: aceptar que algunas cosas no se deben compartir.
No todo código repetido merece un paquete. A veces dos verticales tienen pantallas parecidas pero razones distintas. Forzar una abstracción común demasiado pronto produce nombres vagos, props interminables y excepciones por todos lados.
Los experimentos tampoco se abstraen. Si todavía se está probando si una vertical necesita scoring, pipeline, calendario o carga masiva, esa lógica queda dentro del producto. Si se repite en tres verticales y sobrevive cambios reales, recién ahí se considera extraerla.
El copy específico tampoco debería estar en el shell salvo que sea estructural. Un SaaS vertical gana confianza cuando habla el lenguaje del usuario. Si todo dice "items" o "records", el producto se siente como un template.
La arquitectura en cuatro capas
| Capa | Qué vive ahí | Ritmo de cambio |
|---|---|---|
| Paquetes base | UI, config, tipos compartidos, helpers, emails, observabilidad | Lento — muchas apps dependen |
| Shell | Rutas, layout, sesión, tenant, settings, billing | Moderado — cambia cuando el patrón SaaS cambia |
| Módulo vertical | Entidades, flujos, pantallas, textos, reglas, permisos del dominio | Rápido — es la hipótesis de producto |
| Adaptaciones locales | Integraciones de cliente, importadores puntuales, ajustes comerciales | Variable — no debe contaminar capas superiores |
El resultado es una arquitectura donde lanzar un nuevo SaaS no es clonar un producto viejo y borrar la mitad, sino instanciar una base conocida y concentrarse en la diferencia real.
Un criterio concreto para ubicar cada pieza
Cuando aparece una nueva funcionalidad, tres preguntas definen dónde va:
- ¿Si mañana lanzo otro vertical, necesito esta pieza igual? Si la respuesta es sí, puede ser shell o paquete.
- ¿Esta pieza tiene UI, rutas o experiencia de producto? Si sí, probablemente pertenece al shell. Si es una capability técnica sin opinión visual, probablemente pertenece a un paquete.
- ¿El lenguaje de esta pieza depende del mercado? Si sí, debe quedarse en el vertical por ahora.
Ejemplos concretos: una tabla reutilizable vive en UI package; una página de miembros del workspace vive en shell; una pantalla de propiedades disponibles vive en el vertical inmobiliario.
Por qué una semana es un plazo real
La semana no se gana escribiendo más rápido. Se gana porque las primeras decisiones ya están tomadas.
Día uno. La aplicación ya tiene login, tenant, layout y navegación. El trabajo empieza por el dominio.
Día dos. Los modelos principales del vertical toman forma sin discutir dónde va cada botón.
Día tres. Aparecen los flujos críticos: crear, editar, listar, filtrar, invitar, configurar.
Día cuatro. Se conectan billing, permisos y estados límite.
Día cinco. Se pule el lenguaje del vertical, se revisan vacíos y se prepara una versión usable.
No todos los SaaS llegan a producción en cinco días. Pero el shell evita que las dificultades del dominio se mezclen con trabajo básico de plataforma.
Errores que convierten el patrón en un obstáculo
Convertir el shell en framework. Cuando cada decisión necesita una abstracción, el equipo termina trabajando para el template, no para el usuario.
Meter dominio en paquetes. Al principio parece eficiente. Después aparecen las excepciones: isHealthcare, isRealEstate, customLabel. Esa es una señal de que el paquete está absorbiendo decisiones que no le corresponden.
No tener fronteras para adaptaciones. Una integración puntual puede entrar rápido al core y quedarse ahí para siempre.
Medir el éxito por cantidad de código compartido. El objetivo no es maximizar reutilización, sino maximizar velocidad sostenible.
Este patrón encaja directamente con la lógica de un solo founder 2026: cuando estás solo, no podés permitirte reconstruir la infraestructura base cada vez. El shell absorbe esa deuda de plataforma para que el tiempo disponible se gaste en lo que valida la hipótesis del mercado. Y si el problema es detectar cuándo la idea es demasiado grande para una primera versión, eso lo trabajé en Cómo validar idea SaaS y detectar si es demasiado grande antes de construirla.
Trabajo con founders técnicos que quieren lanzar sin perder meses
Este es el stack sobre el que construí varios verticales SaaS bajo solu30. Si estás en etapa de lanzamiento y querés arrancar con una base sólida en lugar de reconstruir lo mismo una vez más, puedo ayudarte a estructurar el primer sprint o revisar la arquitectura de lo que ya tenés.
Preguntas frecuentes
¿Qué diferencia hay entre un shell vertical y un boilerplate SaaS? Un boilerplate es un punto de partida técnico. Un shell vertical es una aplicación base con decisiones de producto ya tomadas: navegación, tenant, onboarding, billing, settings y patrones de experiencia. El boilerplate ayuda a compilar; el shell ayuda a operar.
¿Cómo sé cuándo extraer algo a un paquete? Cuando la pieza se repite en más de un contexto, cambia poco, tiene una API clara y no necesita lenguaje específico del mercado.
¿El shell debe ser igual para todos los productos? Debe ser consistente, no idéntico. La consistencia ayuda al equipo; la especificidad ayuda al usuario.
¿Dónde van las reglas de permisos? Las primitives viven en paquetes. Las reglas comunes de cuenta y organización viven en el shell. Las reglas que dependen del dominio viven en el vertical.
¿Este patrón reemplaza la investigación de mercado? No. La hace más barata. El shell acelera la construcción de una versión usable, pero no define el problema, el posicionamiento ni el canal.