Plataformas reutilizáveis: o motor para 5 verticais (e como arquitetá-las)

Quando você está montando o segundo ou terceiro produto de uma mesma família, chega o momento da verdade. Você começou com um CRM para salões de festas. Depois veio uma imobiliária que precisava de algo similar, mas adaptado. Depois uma oficina mecânica, depois uma clínica. Cada um parecia "completamente diferente", mas 70% do código se repetia.

Esse é o momento de pensar em uma plataforma reutilizável. Existe um jeito certo e um errado de fazer isso. Vamos começar pelo errado, porque é o que mais se vê por aí.

O erro: forçar a abstração precoce

O erro típico é generalizar antes da hora. Depois do primeiro produto, alguém diz: "isso pode ser usado para muitos negócios". Investe-se tempo abstraindo tudo, adicionando configurações infinitas, tornando o código "genérico". E acaba acontecendo uma de duas coisas:

• A plataforma se torna tão configurável que, para usá-la em cada novo caso, é preciso aprender uma linguagem própria.
• As "configurações" cobrem 80% dos casos, mas os últimos 20% exigem modificações no core da plataforma, o que acaba quebrando a funcionalidade de outros clientes.

A regra de ouro: abstraia apenas após o terceiro caso real, não antes. O primeiro produto resolve um problema. O segundo te ensina o que ele tem em comum com o primeiro. O terceiro confirma o padrão. Antes disso, tudo o que você abstrai é mera especulação.

O padrão que funciona: motor + adaptadores

Uma plataforma reutilizável bem construída possui duas camadas:

1. Motor (Core): o que é comum a todos os verticais. Pipeline de estados com transições, propostas com versionamento, gestão de contatos, calendário, pagamentos, notificações, auditoria de alterações, multi-usuário com permissões (roles) e multi-tenant isolado.

2. Adaptador por vertical: o que é específico de cada negócio. A definição dos estados (um salão de eventos tem "visita agendada", uma oficina tem "carro recebido"), as regras de transição ("não é possível faturar sem orçamento aprovado"), os campos customizados e os relatórios específicos.

O motor deve ser o mais opinativo possível sobre a estrutura comum (para não quebrar entre verticais) e o mais flexível possível na configuração do vertical.

Como aplicamos na La Carolina e além

La Carolina começou como um CRM para salões de eventos. O motor que construímos ali serve para:

• Catering: mesmo pipeline de pedido/proposta/evento/pagamento.
• Imobiliárias de locação: mudam os estados (visita, oferta, contrato), mas a estrutura é a mesma.
• Serviços profissionais com proposta: escritórios de contabilidade, agências, consultorias.
• Eventos B2B: feiras, congressos, treinamentos.

O motor já resolve: estados configuráveis, propostas com versionamento, sync com Google Calendar, pagamentos parciais com sinal, notificações automáticas por transição. Adaptar para um novo vertical é questão de semanas, não meses.

Multi-tenant: a decisão arquitetural chave

Se você vai vender a plataforma para múltiplos clientes (e não apenas para uma empresa com diferentes verticais internos), você precisa que cada cliente veja apenas seus próprios dados. Isso é multi-tenancy, e há três formas de implementar:

1. Database per tenant: um banco de dados completo por cliente. Máximo isolamento, mas custo e complexidade elevados. Faz sentido em indústrias altamente reguladas (saúde, financeiro) com poucos clientes grandes.

2. Schema per tenant: um único banco, mas esquemas separados por cliente. Um meio-termo: isolamento decente, custos razoáveis, mas maior complexidade operacional que um esquema único.

3. Shared schema com tenant_id: um único banco, uma única estrutura e uma coluna que identifica o cliente. Mais barato e simples, mas exige disciplina absoluta para que o isolamento seja respeitado (é aqui que entra o Row Level Security no nível do banco de dados, não apenas no código).

Para SaaS B2B com muitos clientes de médio porte, shared schema + RLS é o que oferece a melhor relação custo-benefício. Mas lembre-se: o isolamento NÃO pode depender apenas do código: ele deve estar garantido também no banco de dados.

O tradeoff entre produto e plataforma

Quando você constrói algo assim, você passa a ter dois tipos de clientes:

• Os que usam o produto vertical padrão (mais barato, configuração limitada).
• Os que precisam de adaptações específicas (mais caro, plataforma adaptável).

O erro é tratá-los da mesma forma. O que funciona: produto vertical com licença mensal padrão para os primeiros; projeto de implementação + licença para os segundos. Preços diferentes, contratos diferentes e, muitas vezes, equipes diferentes para atender cada um.

Quando NÃO construir uma plataforma reutilizável

Nem tudo se beneficia de virar uma plataforma. Não faz sentido se:

• Cada cliente for muito diferente: se as "configurações" em cada caso acabam sendo 80% do trabalho, não é uma plataforma, são produtos distintos disfarçados.
• Seu mercado for pequeno: se você terá apenas 3 clientes no total, uma plataforma é overkill. Faça os 3 produtos sob medida e pronto.
• O suporte e a implementação forem a maior parte do trabalho: se você vende consultoria com um software dentro, mais do que um SaaS B2B, você está vendendo serviços profissionais.

Conclusão

As plataformas reutilizáveis são incríveis quando bem pensadas, e um verdadeiro inferno quando mal executadas. A diferença está em esperar o terceiro caso real antes de abstrair, separar claramente o motor dos adaptadores e resolver o multi-tenancy desde o primeiro dia com segurança a nível de banco.

Se você está avaliando construir seu próprio motor reutilizável, ou já vende um produto vertical e quer expandir para outros nichos similares, fale conosco. Ajudamos você a pensar na arquitetura antes de escrever códigos que sejam difíceis de reverter depois.

---

Por Esteban Aleart, Founder & Lead Engineer da Pair Programming.