A pergunta mais comum que recebemos de outros fundadores não é sobre preços ou entrada no mercado. É tranquilo e um pouco suspeito: como uma equipe do seu tamanho mantém 150 módulos sem que tudo entre em colapso? A resposta honesta é que não mantemos 150 módulos. Mantemos uma plataforma e uma camada muito fina sobre ela. O truque é a crueldade sobre a qual camada pertence um determinado trabalho.
A matemática que assusta as pessoas.
Se você imaginar 150 módulos como 150 pequenos aplicativos — cada um com seu próprio modelo de dados, suas próprias permissões, seu próprio faturamento, suas próprias notificações — então 22 pessoas são obviamente uma loucura. São seis módulos por engenheiro, cada um um produto por direito próprio. Nenhuma equipe sobrevive a isso. O medo está correto, para essa arquitetura.
Mas essa não é a arquitetura. Um CRM, uma ferramenta de faturamento e um help desk parecem três produtos diferentes para um usuário. Por baixo, eles são o mesmo punhado de elementos primitivos: registros, relacionamentos, uma linha do tempo de eventos, funções e permissões, dinheiro, documentos e um barramento de notificação. As diferenças são principalmente vocabulário e layout, não máquinas.
Não estamos construindo 150 produtos excelentes. Estamos construindo um pequeno número de primitivas bem construídas, configuradas de 150 maneiras.
A divisão núcleo/módulo.
Tudo o que é difícil reside no núcleo e é construído uma vez: identidade, permissões, camada de dados relacionais, pagamentos, armazenamento de arquivos, pesquisa, registro de auditoria, sistema de notificação, mecanismo de exportação. Estas são as partes que são genuinamente difíceis e genuinamente compartilhadas. Um bug corrigido aqui foi corrigido para todos os 150 módulos de uma vez. Um recurso adicionado aqui – digamos, assinaturas eletrônicas – torna-se instantaneamente disponível para todos os módulos que o desejarem.
Um módulo, então, é deliberadamente fino. É um esquema de dados, um conjunto de visualizações, um ou dois fluxos de trabalho e o vocabulário para um trabalho. "CRM" é uma configuração que diz: esses tipos de registro são leads e negócios, esta é a visão do pipeline, estes são os estágios, aqui está o que significa uma conversão. Ele depende inteiramente do núcleo. Um novo módulo é principalmente uma declaração, não um código.
A regra difícil: conquiste sua singularidade.
A disciplina que impede que isso apodreça é uma regra única, aplicada em revisão: um módulo não pode ser especial, a menos que realmente o mereça. Cada vez que um módulo deseja seu próprio modelo de permissão personalizado, seu próprio formato de notificação único, sua própria forma privada de armazenar uma data - a resposta padrão é não. Empurre-o para o núcleo como uma capacidade geral ou não o faça.
Isto é irritante no momento e decisivo ao longo dos anos. A maioria das solicitações "precisamos de algo personalizado aqui" são na verdade "não pensamos o suficiente sobre o caso geral". Quando você força o caso geral, o núcleo fica mais rico, cada módulo se beneficia e a área de superfície que você precisa manter permanece praticamente plana, mesmo à medida que a contagem de módulos aumenta.
Do que desistimos.
Esta abordagem tem um custo real e devemos nomeá-lo. Uma ferramenta de ponta de ponta, desenvolvida por uma equipe obcecada por um trabalho, superará nosso módulo equivalente nesse trabalho. A plataforma de e-mail mais profunda possui automação que não temos. A ferramenta de projeto mais profunda tem visões que não temos. Não estamos fingindo o contrário.
O que buscamos nessa profundidade é a coerência – módulos que compartilham um modelo de dados, um login, uma fatura, uma exportação e uma camada de notificação. Para uma equipe de 5 a 50 pessoas, essa coerência vale mais do que os últimos 20% de profundidade em qualquer categoria. Para uma equipe cujo negócio inteiro é essa categoria, não é. Sabemos exatamente para quem servimos e a arquitetura é a razão pela qual podemos atendê-los com 22 pessoas.