Tem uma ferramenta que funciona para um cliente e quer vendê-la a outros dez. É o reflexo certo: o desenvolvimento já está pago e cada cliente adicional custa menos do que o primeiro. Resta uma pergunta de aparência técnica cuja resposta é comercial: cada cliente tem a sua aplicação, ou toda a gente partilha a mesma?
Os dois modelos existem, têm nomes diferentes e não custam o mesmo.
O modelo de marca branca: uma aplicação por cliente
Uma só base de código, mas tantas aplicações publicadas quantos os clientes. Cada um tem a sua: o seu nome, o seu logótipo, as suas cores, a sua ficha nas lojas. Os utilizadores não sabem — nem precisam de saber — que a mesma base faz funcionar outras dez organizações.
O que lhe dá. O seu cliente existe perante os seus próprios sócios. Para uma associação, um clube ou uma franquia, é muitas vezes esse o argumento todo: a ferramenta não parece uma subscrição contratada a terceiros, parece algo que a organização fez para os seus.
O que lhe custa. Cada cliente é mais uma publicação. Uma atualização de segurança são dez submissões em duas lojas, dez revisões editoriais a passar, dez conjuntos de capturas a manter atualizados. A fatura real da marca branca não está no código, está na distribuição.
O modelo multi-tenant: uma só instalação para todos
Uma só aplicação, um só servidor, uma só base de dados. Os clientes convivem, compartimentados: cada um vê apenas os seus dados. É o modelo de quase todo o software vendido por subscrição.
O que lhe dá. Mais um cliente não custa quase nada: nenhuma publicação, nenhum servidor adicional, nenhuma versão para manter à parte. Corrige um defeito uma vez e todos beneficiam no mesmo dia.
O que lhe custa. A compartimentação dos dados torna-se a pergunta mais importante do projeto. Um único erro — uma consulta que se esquece de filtrar pelo cliente certo — e uma organização vê os dados de outra. É o género de incidente do qual não se recupera comercialmente, e não se trata no fim do projeto: decide-se nas primeiras semanas, na própria estrutura dos dados.
A pergunta que verdadeiramente decide
Não é técnica:
O seu cliente tem de aparecer como editor da ferramenta perante os seus próprios utilizadores?
Se sim — associação, clube, federação, franquia, rede de agências —, a marca branca impõe-se, e é preciso aceitar o custo de distribuição que a acompanha.
Se não — os seus clientes assumem que usam software do mercado, tal como assumem o seu programa de contabilidade —, o multi-tenant é quase sempre a escolha certa, e a única que permite acrescentar um cliente sem lhe dedicar uma semana.
Aliás, os dois combinam-se muito bem: é comum um mesmo servidor multi-tenant alimentar várias aplicações em marca branca. É até a configuração mais confortável, desde que tenha sido decidida antes de escrever o primeiro ecrã.
A armadilha que mata os dois modelos
É idêntica nos dois casos e comete-se sempre por boas razões.
Um cliente pede um ajuste. Não é grande coisa. Programa-se «só para ele», na versão dele. Seis meses e três clientes depois existem quatro variantes do mesmo software, e cada correção tem de ser escrita, testada e publicada quatro vezes. O produto morreu antes de ter sido rentável.
A disciplina que o evita cabe numa regra: nada de específico de um cliente entra no código de produto. Um cliente possui apenas uma configuração e umas imagens. Todo o resto é genérico — e quando um pedido não se consegue formular de forma genérica, quase sempre foi mal compreendido.
Aplicamos esta regra nos nossos próprios produtos: uma suite em marca branca para associações de um lado, e uma plataforma multi-tenant para clubes do outro. São duas respostas diferentes à mesma pergunta, e a escolha foi feita antes da primeira linha de código.
Está nesse ponto? É exatamente o tipo de decisão que uma fase de consultoria e arquitetura trata: alguns dias no início do projeto que determinam o que custará o seu décimo cliente. Vamos falar — a primeira conversa é gratuita.
