Software sob medida ou software comercial: como decidir o que é melhor para a sua empresa

A pergunta certa não é "qual é melhor?"

Quase todas as discussões sobre software sob medida versus software comercial começam mal, porque são colocadas como preferência: "nós preferimos desenvolver" ou "nós compramos tudo". Essa é uma conversa de gosto pessoal, não de negócio.

A pergunta útil é outra: esse processo é uma fonte de diferenciação para a sua empresa ou é uma função de apoio que todos os concorrentes executam mais ou menos da mesma forma? Folha de pagamento, contabilidade, assinatura eletrônica, e-mail e controle de acesso são funções de apoio. Ninguém conquista clientes porque seu módulo de folha de pagamento é especial. Já o motor de cotação de uma seguradora, o algoritmo de roteirização de uma distribuidora ou o fluxo de aprovação de crédito de uma fintech definem, sim, a margem.

Regra prática: compre o que te iguala, construa o que te diferencia. Parece simples, mas ter disciplina para seguir essa regra evita a maioria dos projetos fracassados que vemos.

Três opções, não duas

Tratar a decisão como binária empobrece a análise. Na prática, você tem pelo menos três caminhos — e a maioria das empresas acaba combinando-os.

• Comprar e usar como está: você adota um SaaS comercial e adapta seu processo ao software. É a via mais rápida e barata em custo total, mas exige disciplina para não pedir exceções.

• Comprar e estender: você usa a plataforma como núcleo e constrói em cima o que é específico, via APIs, webhooks ou módulos próprios. É o modelo dominante hoje: Shopify + lógica própria de preços, Salesforce + integrações sob medida, um ERP padrão + um portal de fornecedores próprio.

• Construir: você desenvolve o sistema do zero porque não existe nada que resolva o seu caso ou porque o que existe impõe um modelo de negócio diferente do seu.

Sete critérios para decidir, em ordem de peso

Quando acompanhamos um comitê de TI nessa decisão, avaliamos explicitamente estes pontos. O importante não é o resultado numérico, e sim obrigar a organização a responder com dados em vez de intuições.

• Diferenciação: o processo é uma vantagem competitiva ou uma obrigação operacional? Se for obrigação, compre.

• Aderência funcional real: pegue seus 20 requisitos críticos e verifique quantos o produto comercial resolve sem personalização. Abaixo de 70% de aderência, o custo de forçar a solução costuma superar o de construir.

• Volume e escala: se você processa 500 transações por mês, o custo por licença é irrelevante; se processa 5 milhões, o modelo de preços por transação pode se tornar insustentável e a conta passa a favorecer o desenvolvimento próprio.

• Velocidade exigida: um SaaS está operando em semanas; um desenvolvimento sério leva meses. Se a sua janela comercial é de um trimestre, a decisão já está tomada.

• Capacidade de manutenção: o software sob medida é um ativo que exige equipe, não um projeto que termina. Se você não consegue sustentar ao menos duas pessoas dedicadas (ou um contrato de suporte de verdade), não construa.

• Regulação e dados: setores com requisitos rígidos de residência de dados, auditoria ou rastreabilidade às vezes não encontram produto comercial que atenda — ou o que atende custa três vezes mais.

• Risco de dependência: avalie o que acontece se o fornecedor aumentar preços em 40%, for adquirido ou descontinuar o produto. Pergunte sempre: consigo exportar meus dados em um formato utilizável?

Os custos que ninguém coloca na planilha

A comparação típica coloca o preço das licenças contra o orçamento do desenvolvimento. Essa comparação quase sempre está mal feita, nos dois sentidos.

Do lado do software comercial, esquecem-se: a implementação e a migração de dados (que costuma custar de uma a três vezes a licença anual do primeiro ano), o treinamento, os conectores e integrações, os módulos adicionais que você descobre que precisa no quarto mês, o crescimento de usuários e o reajuste anual de preço, que no setor gira em torno de 5-10%. Também o custo silencioso de adaptar a sua operação ao software: se o time de vendas perde 20 minutos por dia lançando a mesma informação duas vezes, isso é dinheiro.

Do lado do desenvolvimento sob medida, esquecem-se: a manutenção evolutiva (orce entre 15% e 25% ao ano do custo de construção), a dívida técnica, as atualizações de segurança e dependências, a infraestrutura, o monitoramento, a documentação e — o mais caro de todos — o risco de concentrar o conhecimento em uma ou duas pessoas que um dia vão sair.

Faça o exercício em cinco anos, não em um. É surpreendente quantas decisões se invertem quando o horizonte é ampliado.

Três cenários concretos

Caso 1. Distribuidora de bens de consumo, 180 funcionários. Queriam um CRM sob medida porque "seu processo de vendas é único". Ao mapear os 20 requisitos, 17 eram cobertos por um CRM comercial de mercado médio. Os outros três — cálculo de cotas por combo promocional, visibilidade de estoque em tempo real e cobrança em rota — foram resolvidos com integrações e um app móvel leve próprio. Resultado: em produção em 10 semanas, com custo próximo a um terço do desenvolvimento completo.

Caso 2. Empresa de logística de última milha. Avaliaram cinco plataformas de roteirização. Nenhuma atendia à restrição-chave: janelas de entrega negociadas no WhatsApp que mudam ao longo do dia. Era justamente a promessa comercial da empresa. Ali, construir fazia sentido — e construiu-se apenas esse motor, mantendo faturamento, contabilidade e folha de pagamento em produtos comerciais.

Caso 3. Instituição financeira regional. Tinha um core bancário próprio de 15 anos, mantido por três pessoas. O sistema funcionava, mas cada mudança regulatória levava meses e o risco de pessoal era crítico. A decisão não foi substituir tudo de uma vez, e sim encapsular o core com APIs e migrar módulos por etapas para produtos especializados. Três anos de plano, não três meses.

Como reduzir o risco, escolha o que escolher

Independentemente do caminho, há práticas que separam as implementações que sobrevivem das que são abandonadas.

• Faça uma prova de conceito com dados reais antes de assinar. Uma demo conduzida pelo vendedor não prova nada; carregue seu catálogo real, seus casos atípicos e meça.

• Defina o modelo de dados como um ativo próprio. Seus dados precisam poder sair. Exija exportação completa e documentada em contrato.

• Projete com fronteiras claras: se for construir, faça de forma modular e com APIs, para poder substituir peças sem refazer tudo.

• Nomeie um responsável de negócio, não apenas de TI. Projetos sem dono funcional acabam em catálogos de requisitos sem prioridade.

• Evite a personalização profunda de produtos comerciais. Cada customização quebra atualizações e cria uma versão órfã que ninguém quer manter.

• Comece pelo processo, não pela ferramenta. Automatizar um processo ruim só faz com que ele falhe mais rápido.

Uma decisão que se revisa, não se grava em pedra

Nenhuma escolha desse tipo é definitiva. As condições mudam: o volume cresce, surge um produto que antes não existia, o modelo de preços do fornecedor se torna hostil ou o processo que era diferencial vira padrão no setor. O saudável é revisar o portfólio de aplicações uma vez por ano e se perguntar, sistema por sistema, se ele continua sendo a opção certa.

Também vale aceitar que a maioria das arquiteturas maduras é híbrida: um núcleo comercial sólido para o que é padrão, peças próprias onde está o valor e uma camada de integração bem pensada que une tudo. A discussão "comprar ou construir" costuma se resolver em "comprar isto, construir aquilo, integrar bem".

Se você está no meio dessa decisão e quer confrontar sua análise com quem já viu como terminam os dois caminhos, na Da2 Group podemos revisar com você o encaixe funcional, os custos em cinco anos e as opções de arquitetura. Sem compromisso: às vezes a conversa mais útil é aquela que confirma que você já estava no caminho certo.