Un motor, muchas pieles: la tesis de Inite para enviar 15 productos SaaS verticales sobre un runtime compartido
Cómo Inite envía 15 productos SaaS verticales sobre una plataforma compartida. El modelo operativo constitución-vs-runtime, por qué con tres capas basta, y el ciclo de clonación de cuatro semanas que prueba que escala.
Quince productos, un equipo de ingeniería
En mayo de 2026 Inite envía quince productos SaaS verticales: alquiler de coches, inmobiliaria, comercio agéntico, eventos con entrada, longevidad y wellness, tutor IA, restaurantes, viajes, clubes deportivos, comunidad, visibilidad IA, publicación de contenido, generación de portadas, decks de pitch, consultoría. Cada uno es un SaaS multi-tenant completo con sus propios clientes, sitio de marketing, dashboard de KPI. Comparten auth, billing, el inbox multi-tenant, el runtime del asistente LLM. No comparten ninguna línea de código de dominio.
El número que importa es cuatro. En los cuatro deploys de 2026 (rent, estate, shop, events) la mediana de tiempo calendario entre repositorio vacío y tenant vivo aceptando pago, con 1-3 workflows automatizados en producción, fue cuatro semanas. Ingeniería, cuatro semanas. El descubrimiento del lado del cliente - entrevistar operadores, capturar datos reales de workflow, elegir qué procesos automatizar primero - lleva más y decide si las cuatro semanas de ingeniería ocurren siquiera.
Cómo quince productos caben en un equipo es el tema de este post.
La estructura compartida
Cada vertical implementa las mismas cinco entidades core: usuario, tenant, rol del usuario dentro del tenant, clave de API, override de permiso por usuario. Sobre eso, declara cuáles de los capability bundles estándar consume: inbox si conversa con clientes en chat; módulo de billing si cobra; constructor de storefront si sus tenants necesitan página pública; pipeline de incidents si sus operadores necesitan cola de alertas. Debajo, cada producto es dueño de su propio dominio: vehículos para el alquiler, propiedades para la inmobiliaria, eventos y entradas para el ticketing, restaurantes y cartas para el food.
Cinco entidades compartidas por todos. Capabilities elegidas por vertical. Dominio soberano. La parte difícil es cómo se fuerza esa división - y cómo la plataforma se impide a sí misma absorber cosas que pertenecen al producto.
Tres capas, no dos
Una plataforma compartida típica tiene dos capas: la librería de runtime que cada producto importa, más los productos en sí. Funciona hasta que dos productos discrepan sobre cómo debería verse una entidad. Uno llama al cliente final customer, el otro llama a la misma cosa lead, el inbox compartido intenta manejar ambos y termina sutilmente roto para los dos.
Inite parte la plataforma en tres. Un repositorio de especificación no entrega código ejecutable - solo los esquemas, validadores y plantillas de manifiesto que definen lo que una vertical debe declarar para entrar al ecosystem. Un SDK de runtime implementa esas declaraciones del mismo modo para todo producto que las adopta. Los quince productos verticales heredan el runtime y aplican el contrato a su dominio específico.
Llamar a esas capas constitución, gobierno y ciudadanos es la metáfora. El efecto mecánico es otro: los contratos se validan antes de que el código llegue a producción. El producto de alquiler y el inmobiliario declaran la forma de su entidad de cliente final contra el mismo schema. El validador rechaza divergencias. El inbox compartido no sabe nada sobre coches ni sobre propiedades - sabe sobre conversaciones, mensajes y adaptadores de canal, y se niega a alcanzar la capa de dominio de cualquier producto.
Qué cabe en las cuatro semanas de clonación
La semana uno levanta el scaffolding multi-tenant y las cinco entidades core. La semana dos trae los capability bundles que la vertical necesita y cablea el asistente LLM. La semana tres construye las pantallas por vertical, configura el preset de storefront, monta la superficie de contenido AEO para que los asistentes de IA vean el producto. La semana cuatro conecta pagos y adaptadores de canal (Telegram, WhatsApp, web), luego abre las interfaces llamables por agentes para que Claude o ChatGPT manejen el producto directamente.
La salida sale con la misma forma cada vez: un SaaS multi-tenant que el operador entrega a un cliente real el día del lanzamiento. La descomposición semana a semana varía en detalles entre deploys. La cadencia de cuatro semanas se sostiene.
Las cuatro semanas son costo de ingeniería. El costo de descubrimiento cae antes de que la ingeniería empiece y es la restricción real - y es también el costo que decide si el proyecto se entrega.
inite.fund queda fuera de este stack
inite.fund no corre sobre la plataforma SaaS. Es un plano de control autónomo de portafolio para operadores que operan capital propio con llaves de venue propias: posiciones de trading, una bóveda cifrada para credenciales de venue, un log de auditoría en cadena de hash para cada acción, una cola de approval llamable por MCP con human-in-the-loop. La forma de SaaS multi-tenant no encaja con nada de eso. inite.fund no implementa las cinco entidades core y no consume el runtime compartido.
La arquitectura debajo comparte la filosofía operativa con el lado SaaS: contratos explícitos en cada frontera, audit-chained state, rechazo de hacer cualquier cosa irreversible sin un humano confirmando. inite.fund corre en un stack Python y Go sin ninguna línea de código compartida con el runtime SaaS. La plataforma SaaS prueba el modelo sobre quince tenants; inite.fund prueba que la misma disciplina operativa generaliza fuera de la forma SaaS multi-tenant.
Por qué este es el moat
Las empresas SaaS per-vertical compiten en profundidad de dominio y cada una reconstruye la misma plomería. Las plataformas horizontales compiten en amplitud de herramental y dejan el dominio a los clientes. Ninguno de esos modelos escala normalmente a quince productos en un equipo de ingeniería.
Un modelo de especificación-más-runtime compite en otro eje. Un único equipo de ingeniería se mueve a la velocidad de una plataforma horizontal y entrega a la profundidad de una empresa per-vertical. Los quince productos son quince apuestas de go-to-market sentadas sobre un único substrato de ingeniería. Cuando una vertical prueba un mercado, la ingeniería de la siguiente vertical adyacente son cuatro semanas. Cuando una capability se prueba a sí misma - un nuevo flujo de billing, un nuevo adaptador de canal, una nueva integración con agente - todo producto que opta por ella la hereda sin trabajo específico de vertical.
Eso acumula. El producto número quince toma las mismas cuatro semanas que el segundo. El post compañero sobre el motor de diagnóstico AEO (cómo Inite construye productos AI verticales) cubre el producto de visibilidad que entrega inite.ai, uno de los quince. Este post es el modelo operativo debajo de todos ellos.
01¿Por qué partir una empresa multi-producto en un repo de spec y un repo de runtime?+
Porque la alternativa es la trampa del monorepo. Cuando runtime y spec viven en el mismo repo, cada cambio de producto repercute en el contrato y cada cambio de contrato repercute en cada producto. La división de Inite es deliberada: inite-ecosystem es la constitución (qué DEBE describir cada vertical para ser un ciudadano), inite-shared es el gobierno (el runtime genérico que ejecuta el contrato), y las 15 verticales son los ciudadanos (aplican el contrato a un dominio específico - coches, propiedades, eventos con entrada, restaurantes). La constitución, por diseño, tiene cero imports de runtime y cero lógica de dominio. Es eso lo que permite que una vertical inmobiliaria y una vertical de alquiler de coches compartan el mismo inbox multi-tenant sin que ninguna tire del código de la otra.
02¿Cuál es la diferencia entre Ring 1, Ring 2 y Ring 3?+
Ring 1 (Core) es obligatorio para toda vertical en conformance: 5 entidades - User, Company, UserCompanyRole, ApiKey, CompanyPermissionOverride. Quitar o romper cualquiera es un bump MAJOR de spec. Ring 2 (capabilities estándar) es capability-gated: bundles opcionales como inbox, billing, incidents, notifications. Si una vertical declara `capabilities: [inbox]` en su manifiesto, DEBE implementar todo el contrato inbox exactamente - el test de conformance fallará en caso contrario. Ring 3 (Domain) es lo que la vertical necesite y el ecosystem no restringe su forma: Vehicle para inite.rent, Property para inite.estate, Event para inite.events, Restaurant para inite.food. Los 3 anillos permiten que verticales diverjan en Ring 3 sin forkear Ring 1.
03¿Cuánto tarda realmente clonar una vertical?+
Medido en 4 deploys en 2026 (inite.rent como piloto, inite.estate, inite.shop, inite.events). Mediana end-to-end: 4 semanas. Semana 1 - scaffolding: clonar la plantilla, declarar el manifiesto, cablear las 5 entidades Ring 1 vía los paquetes @inite/auth y @inite/tenant, ajustar la columna tenant_id en Postgres, pasar el validador de conformance. Semana 2 - capabilities: traer los bundles @inite/* que la vertical necesita (típicamente inbox + billing + storefront), implementar las entidades Ring 3, cablear el asistente vía @inite/assistant. Semana 3 - UX por vertical: el router [companySlug], el preset de storefront, la superficie AEO (llms.txt, ai.txt, FAQPage schema), el dashboard de KPI. Semana 4 - integración: pago, adaptadores de canal en inbox (Telegram, WhatsApp, Max, web), emisión de claves de API, monitoreo de ops, servidor MCP llamable por agentes. El cuello de botella en los 4 deploys fue el descubrimiento del lado del cliente (entrevistas, datos reales de workflow), no la ingeniería.
04¿Qué sale mal cuando se omite el repo de spec?+
Dos modos de fallo aparecen de inmediato. (1) Drift - el runtime y las verticales empiezan a discrepar sobre cómo se ve una entidad. inite.rent la llama `customer`; inite.estate la llama `lead`; el inbox compartido intenta ser ambas y rompe ambas. El repo de spec lo previene forzando a cada vertical a declarar la forma de su entidad contra un validador JSON Schema y rompiendo CI cuando la forma de la vertical contradice el contrato que dice implementar. (2) Fork-bajo-presión - la primera vez que una vertical necesita una feature que el runtime no tiene, el equipo forkea @inite/inbox al repo de la vertical y el fork nunca vuelve. El repo de spec lo previene separando capability bundles (contratos de entidad Tier 2) de paquetes de runtime (el ejecutor genérico). Cuando una vertical necesita algo nuevo, lo añade a su Ring 3 - y si la adición resulta cross-vertical, la spec la absorbe en el siguiente minor.
05¿Cómo se relaciona esto con el motor de diagnóstico AEO en inite.ai?+
inite.ai es una de las 15 verticales. Resulta ser la vertical que entrega el diagnóstico AEO - el pipeline de 9 pasos que toma una URL y devuelve un plan de citación. El motor de diagnóstico en sí vive en initeai/lib/ai/ - es el Ring 3 de inite.ai. Lo que inite.ai comparte con las otras 14 verticales son las entidades Ring 1, los capability bundles Ring 2 y los paquetes de runtime. Las otras verticales no reciben el motor AEO - reciben la misma auth, billing e inbox multi-tenant que recibe inite.ai. Ese es el modelo que hace rápido enviar inite.health, inite.estate o inite.events: el modelo operativo es genérico; solo el dominio es por vertical.
06¿Cómo encaja inite.fund en el ecosystem?+
inite.fund es el producto financiero-de-trading del ecosystem INITE: un plano de control autónomo de portafolio para operadores que operan capital propio con llaves de venue propias. NO es una vertical Ring 3 sobre el runtime SaaS compartido. inite.fund no consume los paquetes @inite/* y no implementa las 5 entidades Ring 1 multi-tenant. Su dominio - posiciones de trading, ledger de fills, bóvedas cifradas de llaves de venue, logs de auditoría en cadena de hash, cola de approval vía MCP - pertenece a un modelo distinto del de las verticales SaaS multi-tenant. El brand-canonical lista inite.fund como sub-brand para desambiguación en Knowledge Graph, de modo que Google fusiona inite.ai e inite.fund en una sola entidad de empresa. Arquitectónicamente corre en un stack separado Python + Go con su propia superficie de marketing en Astro. La filosofía operativa compartida es lo que los une - contratos explícitos, audit-chained state, human-in-the-loop en violaciones de guardrail - no código compartido.
07¿Cuál es el estado de conformance de las 15 verticales hoy?+
Por registry/verticals.yaml en 2026-05-03. Pilot (1): inite.rent - fuente del canon para la spec. Drift (3): inite.club, inite.estate, inite.shop - consumen paquetes @inite/* pero sin manifiesto. Migration_pending (5): inite.education, inite.health (también listada como `break3`), inite.food, inite.travel, inite.sport, inite.ai (atascada en el modelo Company). Non_conforming (2): inite.events (API externa Hi.Events), inite.health (portal de longevidad). Candidate (2): inite.studio, inite.solutions. Legacy_or_consolidating (1): inite.figma - posiblemente reemplazada por inite.content. 0 de 15 están en estado `conforming` - el listón es intencionalmente alto. Drift es el estado estable esperado para un ecosystem que funciona; el objetivo no es 100% conformance, es 100% verificabilidad por conformance.
