A decisão entre desenvolver software sob medida e comprar uma solução pronta costuma ser tratada como uma comparação de preço: a licença do produto custa X por mês, o desenvolvimento custa Y — e Y é quase sempre maior. Colocada nesses termos, a resposta parece óbvia. E é exatamente por isso que tantas empresas se descobrem, três anos depois, pagando licenças crescentes por um sistema que a operação inteira aprendeu a contornar com planilhas.
O problema não é a conta. É que a comparação está sendo feita sobre a variável errada, no horizonte errado.
A pergunta que decide: o processo é commodity ou diferencial?
Antes de qualquer análise financeira, existe uma pergunta que resolve a maior parte dos casos: o processo que esse software vai suportar é igual ao dos seus concorrentes, ou é parte do que faz a sua empresa ganhar mercado?
Processos commodity — contabilidade, folha de pagamento, emissão fiscal, e-mail corporativo — são executados de forma essencialmente idêntica por qualquer empresa do seu setor. Não há vantagem competitiva em fazê-los "do seu jeito". Para eles, comprar é quase sempre a resposta certa: o fornecedor dilui o custo de desenvolvimento entre milhares de clientes, mantém a conformidade regulatória atualizada e entrega um produto mais maduro do que qualquer desenvolvimento interno alcançaria.
Processos diferenciais são o oposto: a forma como a sua empresa precifica, atende, roteiriza, aloca equipe ou gerencia obra é diferente da concorrência — e essa diferença é parte do resultado. Quando um software pronto obriga esse processo a se adaptar ao produto, a empresa não está economizando em tecnologia. Está pagando, em vantagem competitiva, um desconto que recebeu em licença.
É a mesma lógica que discutimos em quando um ERP pronto deixa de funcionar: o ERP não falha nos processos padrão — falha exatamente nos processos que fazem a empresa ser o que é.
A comparação certa: TCO de 3 a 5 anos, não o preço do primeiro ano
A comparação honesta entre construir e comprar não é licença mensal vs. orçamento de desenvolvimento. É custo total de propriedade no horizonte em que o software vai viver — tipicamente 3 a 5 anos.
Do lado da solução pronta, o custo total inclui:
- Licenças que escalam — por usuário, por módulo, por volume de transação. O preço de entrada raramente é o preço do ano três: a empresa cresce, o número de usuários cresce, e módulos que pareciam opcionais viram necessários.
- Custo de adaptação do processo — treinamento, retrabalho, perda de produtividade no período de ajuste e, mais grave, as concessões permanentes que a operação faz para caber no produto.
- Integrações — conectar o produto pronto aos sistemas existentes raramente está incluído na licença. Conectores, middleware e consultoria de implantação entram na conta.
- Funcionalidade não usada — a maioria das empresas usa uma fração dos módulos que paga. Esse desperdício é invisível porque vem embutido no pacote.
Do lado do software sob medida:
- Investimento inicial maior — não há como diluir: o desenvolvimento é pago por quem o encomenda.
- Manutenção e evolução — tipicamente 15 a 20% do investimento inicial por ano, previsível e sob controle de quem decide o que evolui.
- Nenhum custo por usuário — o sistema custa o mesmo com 20 ou 200 pessoas usando.
Colocados no mesmo horizonte, os dois trajetos se cruzam — e o ponto de cruzamento costuma ficar entre o segundo e o terceiro ano para operações que crescem ou têm processo específico. Antes disso, o pronto é mais barato. Depois, a curva de licenças segue subindo enquanto o sob medida amortiza.
Isso não significa que construir "sempre compensa no longo prazo". Significa que a decisão tomada só com o preço do primeiro ano está sendo tomada com um terço da informação.
Os custos que não aparecem em nenhuma proposta
Dois custos raramente entram na planilha de comparação — e são os que mais pesam em quem já passou por uma troca de sistema.
O primeiro é o lock-in. Quanto mais a operação se adapta a um produto, mais caro fica sair dele. Dados em formato proprietário, integrações construídas sobre a API do fornecedor, equipe treinada na ferramenta, processos redesenhados para caber no produto: cada ano de uso aumenta o custo de mudança. O preço da licença pode ser fixo; o custo de dependência é composto.
O segundo é o custo da exceção. Software pronto é desenhado para o caso médio. A operação real vive de exceções — o cliente que negocia condição especial, a obra que muda de escopo, o pedido que precisa ser faturado de forma atípica. Quando o sistema não suporta a exceção, ela vai para fora do sistema: planilha, e-mail, WhatsApp, memória de alguém. É assim que nascem os controles paralelos que descrevemos em quando a planilha vira sistema de gestão — e o custo deles nunca aparece na fatura do software.
Quando comprar é a resposta certa
Um framework honesto precisa dizer também quando não construir. Comprar é a decisão certa quando:
- O processo é commodity. Contabilidade, RH, fiscal, CRM padrão de funil simples: produtos maduros fazem isso melhor e mais barato do que qualquer desenvolvimento.
- A urgência é real. Se a operação precisa da capacidade em semanas, produto pronto entrega em semanas. Desenvolvimento entrega o primeiro módulo em dois a quatro meses.
- O volume não justifica. Time de cinco pessoas com processo simples não amortiza desenvolvimento — a conta do TCO favorece a licença por muito tempo.
- O processo ainda está se formando. Empresa jovem que ainda descobre seu jeito de operar se beneficia de adotar as práticas embutidas de um bom produto, em vez de cristalizar em código um processo imaturo.
Quando construir é a resposta certa
Construir sob medida é a decisão certa quando três condições se acumulam:
- O processo é diferencial — a forma específica como a empresa opera é parte da vantagem competitiva, e adaptá-la a um produto genérico custaria essa vantagem.
- A escala amortiza — o número de usuários, o volume de operação ou o custo das ineficiências atuais tornam o cruzamento de TCO visível no horizonte de 2 a 3 anos.
- A integração é estrutural — o sistema precisa conversar profundamente com ERP, chão de fábrica, CRM e ferramentas existentes, e os conectores prontos não cobrem o caso. Como mostramos em aplicações web corporativas: quando construir em vez de comprar, a integração costuma ser o fator que inviabiliza o produto pronto antes mesmo do preço.
Nesse cenário, o software sob medida não é um luxo de engenharia — é a forma de fazer a tecnologia servir ao processo, e não o contrário.
O caminho que a maioria ignora: híbrido
A decisão raramente é binária. A arquitetura mais racional para a maioria das empresas médias é híbrida:
Compre o núcleo commodity. Construa a borda diferencial.
O ERP continua responsável por contabilidade, fiscal e folha — ninguém deveria desenvolver isso. Em volta dele, os processos que diferenciam a operação — precificação, orçamento de obra, jornada do cliente, alocação de equipe, cockpit de gestão — são construídos sob medida e integrados ao núcleo.
Essa arquitetura captura o melhor dos dois lados: a maturidade e o custo diluído do produto no que é padrão, e a aderência total do sob medida no que é estratégico. E evita o pior dos dois: nem customização pesada de ERP (cara, frágil e refém de consultoria), nem reinvenção de módulo fiscal.
Como decidir na prática: cinco perguntas
Antes de assinar a licença ou aprovar o orçamento de desenvolvimento, responda por escrito:
- Esse processo é igual ao dos concorrentes? Se sim, compre. Se ele é parte do que faz a empresa vencer, siga para a pergunta 2.
- Qual é o TCO real dos dois caminhos em 4 anos? Inclua crescimento de usuários, módulos futuros, integração e treinamento — não apenas o preço de entrada.
- O que a operação vai deixar de fazer do seu jeito para caber no produto? Liste as concessões. Se a lista contém o que diferencia a empresa, o desconto da licença está caro.
- Quantos controles paralelos o sistema atual (ou o produto avaliado) vai gerar? Cada planilha de contorno é um sintoma de inadequação — e um custo recorrente invisível.
- Qual é o custo de sair daqui a 3 anos? Se a resposta for "impraticável", o preço da licença não é o preço real.
Se as respostas apontarem para construir — ou para o híbrido —, o passo seguinte não é orçamento: é diagnóstico. Mapear o processo real, as integrações necessárias e o escopo do primeiro módulo que entrega valor de uso em produção.
Sparsum na prática
Nos projetos que chegam à Sparsum, o padrão se repete: a empresa não procura desenvolvimento porque quer software — procura porque o produto que comprou parou de acompanhar a operação.
Em uma operação de serviços com forte sazonalidade, o sistema pronto de gestão cobrava por usuário e exigia que a alocação de equipe seguisse o modelo do produto. A empresa operava com um modelo próprio de escala — que era exatamente seu diferencial de margem. O sistema sob medida que construímos codificou esse modelo, integrou-se ao ERP existente para faturamento e eliminou as quatro planilhas que faziam a ponte. O cruzamento de custo com a licença anterior ocorreu no vigésimo sexto mês.
Em outra empresa, industrial, a resposta foi híbrida: o ERP ficou onde estava, responsável pelo núcleo fiscal e contábil, e o sob medida cobriu orçamentação técnica e acompanhamento de projeto — os dois processos que o mercado inteiro fazia em Excel porque nenhum produto atendia.
Em ambos os casos, a decisão não começou com tecnologia. Começou com a pergunta deste artigo: o que, na sua operação, é commodity — e o que é o motivo de os clientes escolherem você?