Um motor, várias peles: a tese da Inite para entregar 15 produtos SaaS verticais sobre um runtime compartilhado
Como a Inite entrega 15 produtos SaaS verticais sobre uma plataforma compartilhada. O modelo operacional constituição-vs-runtime, por que três camadas bastam, e o ciclo de clonagem de quatro semanas que prova que escala.
Quinze produtos, um time de engenharia
Em maio de 2026 a Inite entrega quinze produtos SaaS verticais: aluguel de carros, imobiliária, comércio agêntico, eventos com ingresso, longevidade e wellness, tutor IA, restaurantes, viagens, clubes esportivos, comunidade, visibilidade IA, publicação de conteúdo, geração de capas, decks de pitch, consultoria. Cada um é um SaaS multi-tenant completo com seus clientes, site de marketing, dashboard de KPI. Compartilham auth, billing, o inbox multi-tenant, o runtime do assistente LLM. Não compartilham nenhuma linha de código de domínio.
O número que importa é quatro. Nos quatro deploys de 2026 (rent, estate, shop, events) a mediana de tempo calendário entre repositório vazio e tenant vivo aceitando pagamento, com 1-3 workflows automatizados em produção, foi quatro semanas. Engenharia, quatro semanas. A descoberta do lado do cliente - entrevistar operadores, capturar dados reais de workflow, escolher quais processos automatizar primeiro - leva mais e decide se as quatro semanas de engenharia chegam a acontecer.
Como quinze produtos cabem em um time é o assunto deste post.
A estrutura compartilhada
Cada vertical implementa as mesmas cinco entidades core: usuário, tenant, papel do usuário dentro do tenant, chave de API, override de permissão por usuário. Em cima disso, declara quais dos capability bundles padrão consome: inbox se conversa com clientes em chat; módulo de billing se cobra; construtor de storefront se seus tenants precisam de página pública; pipeline de incidents se seus operadores precisam de fila de alertas. Abaixo, cada produto é dono do seu próprio domínio: veículos para o aluguel, propriedades para a imobiliária, eventos e ingressos para o ticketing, restaurantes e cardápios para o food.
Cinco entidades compartilhadas por todos. Capabilities escolhidas por vertical. Domínio soberano. A parte difícil é como essa divisão é forçada - e como a plataforma se impede de absorver coisas que pertencem ao produto.
Três camadas, não duas
Uma plataforma compartilhada típica tem duas camadas: a biblioteca de runtime que todo produto importa, mais os produtos em si. Funciona até dois produtos discordarem sobre como uma entidade deve parecer. Um chama o cliente final de customer, o outro chama a mesma coisa de lead, o inbox compartilhado tenta lidar com os dois e termina sutilmente quebrado para ambos.
A Inite parte a plataforma em três. Um repositório de especificação não entrega código executável - apenas os esquemas, validadores e templates de manifesto que definem o que uma vertical precisa declarar para entrar no ecosystem. Um SDK de runtime implementa essas declarações da mesma forma para todo produto que as adota. Os quinze produtos verticais herdam o runtime e aplicam o contrato ao seu domínio específico.
Chamar essas camadas de constituição, governo e cidadãos é a metáfora. O efeito mecânico é outro: contratos são validados antes do código ir para o ar. O produto de aluguel e o produto imobiliário declaram a forma da sua entidade de cliente final contra o mesmo schema. O validador rejeita divergências. O inbox compartilhado não sabe nada sobre carros nem sobre propriedades - sabe sobre conversas, mensagens e adaptadores de canal, e se recusa a alcançar a camada de domínio de qualquer produto.
O que cabe nas quatro semanas de clonagem
A semana um levanta o scaffolding multi-tenant e as cinco entidades core. A semana dois puxa os capability bundles que a vertical precisa e fia o assistente LLM. A semana três constrói as telas por vertical, configura o preset de storefront, monta a superfície de conteúdo AEO para que assistentes de IA enxerguem o produto. A semana quatro conecta pagamentos e adaptadores de canal (Telegram, WhatsApp, web), depois abre as interfaces chamáveis por agentes para que Claude ou ChatGPT dirijam o produto diretamente.
A saída sai com a mesma forma todas as vezes: um SaaS multi-tenant que o operador entrega a um cliente real no dia do lançamento. A decomposição semana a semana muda em detalhes entre deploys. A cadência de quatro semanas se sustenta.
As quatro semanas são custo de engenharia. O custo de descoberta cai antes da engenharia começar e é a restrição real - e é também o custo que decide se o projeto chega a ser entregue.
inite.fund fica fora desse stack
inite.fund não roda sobre a plataforma SaaS. É um plano de controle autônomo de portfólio para operadores que operam o próprio capital com chaves de corretora próprias: posições de trading, um cofre criptografado para credenciais de corretora, um log de auditoria em cadeia de hash para cada ação, uma fila de approval chamável por MCP com human-in-the-loop. A forma de SaaS multi-tenant não se encaixa em nada disso. inite.fund não implementa as cinco entidades core e não consome o runtime compartilhado.
A arquitetura por baixo compartilha a filosofia operacional com o lado SaaS: contratos explícitos em cada fronteira, audit-chained state, recusa de fazer qualquer coisa irreversível sem um humano confirmar. inite.fund roda em um stack Python e Go sem nenhuma linha de código compartilhada com o runtime SaaS. A plataforma SaaS prova o modelo em quinze tenants; inite.fund prova que a mesma disciplina operacional generaliza para fora da forma SaaS multi-tenant.
Por que esse é o moat
Empresas SaaS per-vertical competem em profundidade de domínio e cada uma reconstrói a mesma encanação. Plataformas horizontais competem em largura de ferramental e deixam o domínio para os clientes. Nenhum desses modelos escala normalmente para quinze produtos em um time de engenharia.
Um modelo de especificação-mais-runtime compete em outro eixo. Um único time de engenharia se move na velocidade de uma plataforma horizontal e entrega na profundidade de uma empresa per-vertical. Os quinze produtos são quinze apostas de go-to-market sentadas sobre um único substrato de engenharia. Quando uma vertical prova um mercado, a engenharia da próxima vertical adjacente são quatro semanas. Quando uma capability prova a si mesma - um novo fluxo de billing, um novo adaptador de canal, uma nova integração com agente - todo produto que opta por ela herda sem trabalho específico de vertical.
Isso acumula. O décimo quinto produto leva as mesmas quatro semanas do segundo. O post companheiro sobre o motor de diagnóstico AEO (como a Inite constrói produtos AI verticais) cobre o produto de visibilidade que inite.ai entrega, um dos quinze. Este post é o modelo operacional debaixo de todos eles.
01Por que dividir uma empresa multi-produto em um repo de especificação e um repo de runtime?+
Porque a alternativa é a armadilha do monorepo. Quando o runtime e a especificação vivem no mesmo repo, toda mudança de produto reverbera no contrato e toda mudança de contrato reverbera em todo produto. A divisão da Inite é deliberada: inite-ecosystem é a constituição (o que toda vertical DEVE descrever para ser um cidadão), inite-shared é o governo (o runtime genérico que executa o contrato), e as 15 verticais são os cidadãos (elas aplicam o contrato a um domínio específico - carros, propriedades, eventos com ingresso, restaurantes). A constituição, por design, tem zero imports de runtime e zero lógica de domínio. É isso que permite que uma vertical imobiliária e uma vertical de aluguel de carros compartilhem a mesma capability inbox multi-tenant sem que nenhuma puxe o código da outra.
02Qual é a diferença entre Ring 1, Ring 2 e Ring 3?+
Ring 1 (Core) é obrigatório para toda vertical em conformance: 5 entidades - User, Company, UserCompanyRole, ApiKey, CompanyPermissionOverride. Remover ou quebrar qualquer uma é um bump MAJOR de especificação. Ring 2 (capabilities padrão) é capability-gated: bundles opcionais como inbox, billing, incidents, notifications. Se uma vertical declara `capabilities: [inbox]` em seu manifesto, ela DEVE implementar todo o contrato inbox exatamente - o teste de conformance falhará caso contrário. Ring 3 (Domain) é o que a vertical precisar e o ecosystem não restringe sua forma: Vehicle para inite.rent, Property para inite.estate, Event para inite.events, Restaurant para inite.food. Os 3 anéis permitem que verticais divirjam em Ring 3 sem fazer fork em Ring 1.
03Quanto tempo leva realmente para clonar uma vertical?+
Medido em 4 deploys em 2026 (inite.rent como piloto, inite.estate, inite.shop, inite.events). Mediana end-to-end: 4 semanas. Semana 1 - scaffolding: clonar o template, declarar o manifesto, fiar as 5 entidades de Ring 1 via os pacotes @inite/auth e @inite/tenant, ajustar a coluna tenant_id em Postgres, passar o validador de conformance. Semana 2 - capabilities: puxar os bundles @inite/* que a vertical precisa (tipicamente inbox + billing + storefront), implementar as entidades de Ring 3, fiar o assistente via @inite/assistant. Semana 3 - UX por vertical: o router [companySlug], o preset de storefront, a superfície AEO (llms.txt, ai.txt, FAQPage schema), o dashboard de KPI. Semana 4 - integração: pagamento, adaptadores de canal em inbox (Telegram, WhatsApp, Max, web), emissão de chaves de API, monitoramento de ops, servidor MCP chamável por agentes. O gargalo nos 4 deploys foi a descoberta do lado do cliente (entrevistas, dados reais de workflow), não a engenharia.
04O que dá errado quando se pula o repo de especificação?+
Dois modos de falha aparecem imediatamente. (1) Drift - o runtime e as verticais começam a discordar sobre como uma entidade se parece. inite.rent chama de `customer`; inite.estate chama de `lead`; a capability inbox compartilhada tenta ser as duas e quebra as duas. O repo de especificação previne isso forçando cada vertical a declarar a forma de sua entidade contra um validador JSON Schema e quebrando o CI quando a forma da vertical contradiz o contrato que ela alega implementar. (2) Fork-sob-pressão - a primeira vez que uma vertical precisa de uma feature que o runtime não tem, o time faz fork de @inite/inbox para o repo da vertical e o fork nunca volta. O repo de especificação previne isso separando capability bundles (contratos de entidade Tier 2) de pacotes de runtime (o executor genérico). Quando uma vertical precisa de algo novo, ela adiciona ao seu Ring 3 - e se a adição se mostrar cross-vertical, a especificação absorve no próximo minor.
05Como isso se relaciona com o motor de diagnóstico AEO em inite.ai?+
inite.ai é uma das 15 verticais. Por acaso é a vertical que entrega o diagnóstico AEO - o pipeline de 9 etapas que recebe uma URL e devolve um plano de citação. O motor de diagnóstico em si vive em initeai/lib/ai/ - é o Ring 3 de inite.ai. O que inite.ai compartilha com as outras 14 verticais são as entidades Ring 1, os capability bundles Ring 2 e os pacotes de runtime. As outras verticais não recebem o motor AEO - elas recebem a mesma auth, billing e inbox multi-tenant que inite.ai recebe. É esse o modelo que torna rápido entregar inite.health, inite.estate ou inite.events: o modelo operacional é genérico; só o domínio é por vertical.
06Como inite.fund se encaixa no ecosystem?+
inite.fund é o produto financeiro-de-trading do ecosystem INITE: um plano de controle autônomo de portfólio para operadores que negociam capital próprio com chaves de venue próprias. NÃO é uma vertical Ring 3 sobre o runtime SaaS compartilhado. inite.fund não consome os pacotes @inite/* e não implementa as 5 entidades Ring 1 multi-tenant. Seu domínio - posições de trading, ledger de fills, cofres criptografados de chaves de venue, logs de auditoria em cadeia de hash, fila de approval via MCP - pertence a um modelo diferente do das verticais SaaS multi-tenant. O brand-canonical lista inite.fund como sub-brand para desambiguação no Knowledge Graph, de modo que o Google funda inite.ai e inite.fund em uma única entidade de empresa. Arquitetonicamente roda em um stack separado Python + Go com sua própria superfície de marketing em Astro. A filosofia operacional compartilhada é o que os une - contratos explícitos, audit-chained state, human-in-the-loop em violações de guardrail - não código compartilhado.
07Qual é o status de conformance das 15 verticais hoje?+
Por registry/verticals.yaml em 2026-05-03. Pilot (1): inite.rent - fonte do cânon para a especificação. Drift (3): inite.club, inite.estate, inite.shop - consomem pacotes @inite/* mas sem manifesto. Migration_pending (5): inite.education, inite.health (também listada como `break3`), inite.food, inite.travel, inite.sport, inite.ai (travada no modelo Company). Non_conforming (2): inite.events (API externa Hi.Events), inite.health (portal de longevidade). Candidate (2): inite.studio, inite.solutions. Legacy_or_consolidating (1): inite.figma - possivelmente substituída por inite.content. 0 das 15 estão em status `conforming` - a barra é intencionalmente alta. Drift é o estado estável esperado para um ecosystem que funciona; o objetivo não é 100% conformance, é 100% verificabilidade por conformance.
