Comprar ou construir: quando vale desenvolver seu próprio CRM

Somos uma fábrica de software. Ganhamos dinheiro construindo sistemas sob medida. E, quando a pergunta é "devemos desenvolver nosso próprio CRM?", a resposta que damos na maior parte das vezes é não.

Isso não é modéstia. É que a decisão de construir costuma ser tomada comparando a coisa errada: o custo de desenvolver contra o preço de assinar. Essa comparação ignora que o desenvolvimento é apenas a primeira parcela de um compromisso que não termina.

O que se compara quando se compara errado

A conta que aparece na reunião é quase sempre esta: "a licença custa X por ano; desenvolver custa Y uma vez". Com Y parecendo menor que alguns anos de X, a decisão parece óbvia.

O que fica de fora:

• Evolução. Requisito novo aparece todo mês. Num produto pronto, ele chega no roadmap do fornecedor; num sistema próprio, vira demanda da sua equipe.
• Conformidade. LGPD, exigências fiscais, mudança de layout de nota, novas regras de canal. Quem construiu, mantém.
• Integrações que quebram. A API do WhatsApp muda, o banco muda o retorno, o provedor de pagamento deprecia um endpoint. Isso não é evento raro; é rotina.
• Conhecimento concentrado. O desenvolvedor que fez sai. O sistema continua.
• Custo de oportunidade. Cada hora gasta mantendo cadastro e funil é uma hora não gasta no que diferencia o negócio.

Os três critérios que usamos

Quando um cliente traz essa decisão, aplicamos três filtros. Eles resolvem a maioria dos casos sem precisar de estudo longo.

1. O processo é o produto?

Se o processo que você quer sistematizar é aquilo que a empresa vende, construir faz sentido — porque ali mora a diferenciação, e depender de um fornecedor significa depender do roadmap dele para diferenciar.

Se o processo é como a empresa opera — atender, cadastrar, propor, cobrar —, construir significa reconstruir o que já existe maduro no mercado. Funil de vendas não diferencia imobiliária nenhuma; o que diferencia é o que se faz com ele.

2. A especificidade é de núcleo ou de borda?

Quase todo cliente diz "nosso processo é diferente". Quase sempre é verdade — na borda. O cadastro de cliente é igual ao de todo mundo; o que muda são campos, papéis, regras de aprovação, textos.

Especificidade de borda se resolve com configuração e extensão. Especificidade de núcleo — regra que muda o significado de "cliente" ou de "pedido" — é rara, e é ela que justifica construir.

3. Existe exigência inegociável que nenhum fornecedor atende?

Dado que não pode sair de determinada infraestrutura, integração com um sistema legado sem API, certificação específica. Quando existe de verdade, decide a questão. Vale conferir se é exigência real ou preferência herdada.

O caminho que funciona na prática: os dois

A decisão raramente é binária, e tratá-la como binária é o que produz os dois piores resultados: reconstruir commodity, ou engessar o diferencial dentro de um produto que não foi feito para ele.

O arranjo que recomendamos:

1. Compre o núcleo. Cadastro, atendimento, funil, proposta, cobrança. É onde o mercado já é maduro e onde construir tem o pior retorno.
2. Construa o diferencial. O cálculo próprio, o motor de precificação, a integração com o equipamento da fábrica — o que ninguém mais tem.
3. Integre por API. Essa é a exigência que define se o arranjo vai funcionar. Produto sem API decente força a escolha binária de novo.

Por isso, ao avaliar um fornecedor, olhamos a documentação de API e webhooks antes de olhar as telas. Tela bonita com integração pobre é armadilha de médio prazo — assunto que já tratamos em 4 sinais de que sua empresa precisa de integração de sistemas.

O erro mais caro: construir para não pagar assinatura

Um padrão que vemos se repetir. A empresa decide construir para evitar a mensalidade. Dois anos depois, tem um sistema que faz 70% do que o produto pronto fazia, um custo de manutenção maior que a assinatura evitada, e nenhuma das funcionalidades que o fornecedor lançou nesse período.

O ponto não é que a construção foi malfeita. É que ela competia com um produto que tem dezenas de pessoas evoluindo em tempo integral, e essa competição não é justa quando o processo é commodity.

O que olhar no produto pronto

Escolher bem é o que torna a decisão de comprar sustentável:

• Os dados são seus e saem? Exportação completa, sem depender de suporte. Sem isso, a troca de fornecedor é impossível e você perde poder de negociação.
• Tem API e webhook? É o que permite construir o diferencial ao lado.
• O ciclo é completo? Produto que resolve atendimento mas não chega à cobrança recria o problema de integração que você queria eliminar.
• A conformidade é do fornecedor? LGPD, fiscal e regras de canal mantidas por ele é metade do valor da assinatura.

Na prática, o item mais subestimado é o terceiro. O custo não mora dentro de cada ferramenta — mora na emenda entre duas, e cada emenda cobra redigitação, conferência e divergência. Escrevemos sobre isso no blog do Dominus.OS, em Do lead ao caixa: o ciclo inteiro numa base só.

Nossa recomendação, em uma frase

Construa o que te diferencia. Compre o que te sustenta. E exija API dos dois lados, porque é ela que mantém a decisão reversível.