Soluções customizadas ou software de prateleira: o critério que decide

Autor: Pedro Tebaldi PM do KeepGreen

Publicado jun/2014Atualizado ago/2026

A decisão quase nunca chega anunciada. Ela chega como pedido: o comercial precisa de um campo que o CRM não tem, a operação quer um relatório que o ERP não gera, o financeiro pede uma integração que o fornecedor cobra caro para entregar. Alguém então pergunta se não sai mais barato mandar fazer.

A partir daí a conversa costuma escorregar para preferência pessoal. Quem já sofreu com produto engessado defende construir. Quem já herdou um sistema sem documentação defende comprar. Os dois estão respondendo à pergunta errada.

A pergunta útil é outra: qual processo da sua empresa justifica código próprio, quanto custa sustentar esse código depois que a fábrica entregar a chave. Este artigo trata a escolha pelo que ela é, um cálculo de custo ao longo do tempo, com uma regra de camada que evita o erro mais caro do tema.

O que muda entre uma solução customizada e um software de prateleira

Soluções customizadas são sistemas construídos ou estendidos para o processo específico de uma empresa. Software de prateleira é o produto pronto, vendido em escala para muitos clientes. A diferença decisiva não está na aderência ao processo: está em quem paga a evolução.

No produto de mercado, o fornecedor dilui o custo de evoluir entre toda a base de clientes. No sob medida, a conta fica inteira com você, mês após mês, enquanto o sistema existir.

Essa assimetria explica por que a comparação por preço de entrada engana. A licença aparece no orçamento do ano, o desenvolvimento também. O que não aparece em nenhum dos dois é a linha de sustentação do terceiro ano.

Por isso a tabela abaixo compara as duas opções pelas dimensões que continuam cobrando depois da assinatura, não pelas que se resolvem na primeira reunião.

 
Repare que nenhuma coluna vence em tudo. O produto pronto perde em aderência porém ganha em previsibilidade. O sob medida ganha em encaixe porém transfere para dentro de casa uma obrigação que não termina. Modelos de assinatura como o SaaS mudam o formato do contrato, mas não mudam esse fato.

O custo que aparece depois da entrega

A entrega é o começo do gasto, não o fim. Depois do aceite, o sistema passa a exigir manutenção corretiva quando quebra, adaptativa quando o ambiente ao redor muda, evolutiva quando o negócio muda. As três continuam cobrando todo mês.

A manutenção adaptativa é a mais subestimada. Uma versão nova do banco, uma mudança na API do parceiro, uma alteração de regra fiscal: nada disso foi pedido por ninguém e mesmo assim consome sprint.

A norma ISO/IEC/IEEE 14764, que define os processos de manutenção de software, trata essa fase como a parcela dominante do ciclo de vida financeiro do sistema.

Quando a manutenção não acompanha o ritmo da mudança, o atraso vira dívida técnica: retrabalho futuro embutido em cada correção adiada.

O relatório do consórcio CISQ estimou essa dívida acumulada em US$ 1,52 trilhão nos Estados Unidos, em 2022.

Some a isso o fator humano. Um sistema sob medida costuma ter duas ou três pessoas que entendem o código de verdade. Quando uma delas sai, o prazo de qualquer mudança dobra. Esse risco de concentração não aparece na proposta comercial e aparece inteiro no primeiro turnover.

Coloque a manutenção na conta antes de comparar

Uma comparação honesta usa custo total de propriedade em um horizonte de três a cinco anos, com licença, infraestrutura, horas de sustentação, treinamento e o custo de sair depois. Sem esse horizonte, o sob medida sempre parece barato no primeiro ano e o produto pronto sempre parece caro no quinto.

Reserve também a linha da implantação. Migração de dados, testes de aceitação e o período de operação assistida existem nos dois caminhos, com peso diferente em cada um. O que muda de verdade está nas etapas de implantação que você vai executar sozinho quando o sistema for seu.

Quatro perguntas que decidem entre comprar e construir

Antes de pedir orçamento, responda quatro perguntas com dado do seu ambiente, não com impressão. Elas separam o processo que merece código próprio daquele que só precisa de configuração melhor.

 
Uma resposta merece atenção especial. Quando o processo é commodity porém a área insiste em algo próprio, o problema raramente está no software: está em um fluxo que ninguém padronizou. Construir nesse cenário apenas registra a bagunça em código. O sintoma clássico é a proliferação de ferramentas paralelas, o que já é um caso de shadow IT em formação.

A camada certa para customizar

Existe uma diferença de risco que quase nenhum comparativo faz: customizar o núcleo de um produto não se parece com estender a borda dele. São decisões de custo e de reversibilidade opostas.

Customização de borda usa pontos de extensão que o fornecedor oferece e mantém: API, webhook, plugin homologado, script de coleta, painel próprio sobre dados exportados. Ela é barata, isolada e sobrevive a upgrade. Se der errado, você desliga a extensão.

Customização de núcleo altera o comportamento interno do produto, às vezes o próprio código. Ela resolve rápido e cobra depois, porque cada atualização do fabricante passa a exigir análise, reaplicação e reteste. Em ambientes de ERP monitorado de ponta a ponta, é a origem mais comum de travamento de versão.

Na rede do Marista Brasil, toda a customização ficou na borda. Construímos mais de 100 dashboards, um por unidade escolar, integramos o ambiente Meraki com scripts próprios e colocamos monitoramento sintético para exercitar o ERP como um usuário faz.

São 97 escolas acompanhadas sobre plataforma padrão, com o que é específico do cliente vivendo em cima dela, nunca dentro dela. O relato completo do projeto do Marista Brasil descreve o desenho.

Quando a customização vira um fork

O ponto de virada é discreto. Alguém precisa de um comportamento que o ponto de extensão não permite, o fornecedor entrega o código, um desenvolvedor altera uma classe interna. Funciona na sexta-feira.

O preço chega na atualização seguinte. A correção de segurança publicada pelo fabricante não aplica limpo, o suporte pede o produto sem modificação para abrir chamado. Enquanto isso, a decisão de atualizar compete com outras prioridades e o sistema congela na versão onde a alteração ainda cabia.

Regra prática que evita esse caminho: só customize no ponto que o fornecedor documenta como extensível. Quando o requisito exigir mais que isso, o problema mudou de natureza. Ele agora é escolha de produto, não pedido de ajuste. A integração entre aplicações costuma resolver boa parte desses casos sem tocar em nada por dentro.

O que precisa estar no contrato

Três cláusulas separam o projeto sustentável do projeto refém. A primeira define a propriedade do código e o acesso ao repositório desde o primeiro commit, não na entrega final.

A segunda exige documentação mínima executável: como subir o ambiente, como rodar os testes, quais variáveis o sistema espera. Sem isso, trocar de fornecedor custa uma reengenharia inteira.

A terceira trata da saída. Formato de exportação dos dados, prazo de entrega e responsabilidade pela migração precisam estar escritos antes de existir dependência. Depois da dependência instalada, a negociação já acontece em posição desfavorável.

Como medir se a customização se pagou

Customização se justifica por número, não por satisfação declarada em reunião. Antes de começar, registre a linha de base do processo. Depois de estabilizar, meça de novo os mesmos indicadores.

Quatro medidas costumam bastar: horas gastas por ocorrência do processo, volume de retrabalho e correção manual, tempo de ciclo ponta a ponta, quantidade de chamados abertos por mês naquela função. Se nenhuma delas se moveu em três meses de uso estável, a customização entregou conforto, não resultado.

Acrescente uma quinta medida, que separa projeto sadio de projeto que vai virar problema: horas de sustentação por mês em relação ao esforço original. Quando esse número sobe mês a mês, o sistema está pedindo refatoração ou substituição. A decisão de investir mais precisa voltar à mesa.

Vale ainda combinar a expectativa antes da contratação. Fornecedores maduros aceitam discutir indicador de sucesso no contrato. Essa conversa revela muito sobre o parceiro: quem trata o assunto como detalhe costuma repetir o comportamento no suporte, tema recorrente quando CIOs avaliam seus fornecedores de tecnologia.

O que decidir antes de assinar o contrato

A escolha entre soluções customizadas e produto de prateleira não se resolve por preferência técnica. Ela se resolve com quatro respostas: se o processo é diferencial ou commodity, quanto do escopo o mercado já cobre, quantas exceções o fluxo carrega hoje, quem sustenta o resultado daqui a três anos.

Respondidas essas perguntas, aplique a regra de camada. Customização na borda do produto é reversível e cabe no orçamento de operação. Alteração no núcleo é permanente na prática, porque o custo de voltar cresce a cada versão que passa.

Por fim, contrate a medição junto com a entrega. Linha de base antes, mesmo indicador depois, revisão trimestral das horas de sustentação. É esse acompanhamento que transforma uma decisão de gosto em uma decisão auditável.

Quer avaliar onde a customização compensa no seu ambiente e onde a plataforma padrão já resolve? Fale com um especialista da OpServices para revisar o caso com dados do seu parque.