Software sob medida: quando vale mais que o pronto

Software sob medida é o sistema construído para o processo de uma empresa específica, em vez de adaptado a partir de um produto pronto vendido para muitas. A diferença não está na tecnologia: está em quem se adapta a quem. No software pronto, a empresa ajusta o processo à ferramenta. No sob medida, a ferramenta é desenhada em volta do processo que já dá vantagem competitiva.

A pergunta que interessa não é qual dos dois é melhor, porque nenhum é melhor sempre. É em que condições cada um sai mais barato no prazo de três anos, contando o que não aparece na proposta: licença por usuário, integração, trabalho manual que sobra e o custo de esperar. Este guia é escrito para quem vai assinar a decisão, não para quem vai escrever o código.

O que é software sob medida, sem jargão

É um sistema desenvolvido para uma empresa, a partir do processo dela, com as regras de negócio dela. Pode ser um sistema completo de operação, um módulo que resolve uma etapa específica, ou a camada que liga sistemas que já existem e não conversam.

Software pronto, também chamado de solução de mercado ou SaaS, é o produto construído para servir a muitas empresas ao mesmo tempo. Ele é mais barato porque o custo de desenvolvimento é dividido entre todos os clientes, e é mais limitado pelo mesmo motivo: o que atende a muitos não pode ser específico para um.

Vale desfazer um mal-entendido comum. Sob medida não significa começar do zero em tudo. Um projeto bem conduzido usa componentes prontos para o que é commodity, como autenticação, cobrança e envio de e-mail, e constrói apenas o que é diferente na sua operação. Quem constrói tudo do zero costuma estar cobrando pelo que já existe.

Quando o sob medida vale mais que o pronto

Existem quatro situações em que a conta vira a favor de construir. Elas raramente aparecem sozinhas.

• O processo é a vantagem. Se a empresa ganha dinheiro justamente porque faz algo de um jeito que os concorrentes não fazem, adaptar esse jeito a um software genérico é abrir mão da vantagem para caber na ferramenta.
• O pronto exige gambiarra permanente. Quando a operação vive de planilha auxiliar, exportação manual e retrabalho para contornar o que o sistema não faz, o custo real já não é a mensalidade: é o tempo da equipe. Esse é o cenário de processos que pedem automação.
• A licença por usuário virou o maior item da conta. Software pronto cobra por assento. Operação que cresce em número de pessoas chega a um ponto em que a assinatura anual passa o custo de construir, e continua subindo.
• Ninguém no mercado atende à regra. Setor regulado, cálculo proprietário, integração com sistema antigo que não tem conector. Aqui o pronto não é caro: é inviável, e o assunto vira sistemas legados.

Quando o software pronto é a escolha certa

Na maior parte dos casos, é. E dizer isso é parte do trabalho de quem desenvolve software: projeto sob medida que não deveria existir vira prejuízo dos dois lados.

Compre pronto quando o processo não é diferenciado. Folha de pagamento, nota fiscal, e-mail, CRM padrão de vendas: são problemas resolvidos, com produtos maduros e baratos. Construir o próprio ali significa pagar para reinventar, e depois pagar de novo para manter.

Compre pronto também quando o problema é urgente e o processo ainda está mudando. Software sob medida cristaliza um processo em código, e cristalizar o que muda toda semana é caro. Nesse caso, rode no pronto, deixe o processo estabilizar, e só então avalie construir.

Quanto custa, e o custo que ninguém soma

A comparação honesta é o custo total em três anos, não o preço de entrada. O pronto começa baixo e sobe com o uso; o sob medida começa alto e o custo depois é de manutenção, tipicamente uma fração do investimento inicial por ano.

O item que decide quase sempre é o penúltimo. Duas horas por dia de uma pessoa exportando planilha e conferindo dado à mão custam, em um ano, mais do que a maioria das empresas imagina, e esse custo não aparece em nenhuma linha de orçamento porque está dentro de um salário que já existe. Para dimensionar o investimento antes da conversa comercial, vale quanto custa desenvolver um aplicativo.

Prazo: o que muda entre comprar e construir

Software pronto entra em semanas, e é uma vantagem real. Sob medida leva meses, e o erro comum é tratar esses meses como espera improdutiva.

Um projeto bem estruturado entrega valor antes de terminar. A primeira versão útil resolve a etapa mais cara do processo e entra em produção com um grupo pequeno, enquanto o resto é construído. Isso é o que diferencia um cronograma de um voto de confiança, e é o papel de um MVP bem definido.

Se o fornecedor propõe seis meses sem nada em produção no meio, o risco não é técnico: é de descobrir tarde que o entendimento estava errado. Peça entrega parcial em uso real, não demonstração.

Propriedade, dependência e saída

Três perguntas resolvem o que costuma virar problema no segundo ano do contrato, e todas devem estar respondidas por escrito antes da assinatura.

1. De quem é o código? Em projeto sob medida, o normal é a propriedade ser do cliente. Se o contrato diz o contrário, você está pagando desenvolvimento e recebendo licença.
2. De quem é o dado, e como ele sai? Vale para os dois modelos. Exportação completa, em formato aberto, precisa ser um direito contratual e não um favor.
3. Outra equipe consegue manter? Documentação, padrão de código e ambiente reproduzível são o que separam um sistema de um refém. É a diferença entre trocar de fornecedor e recomeçar.

Quem vai conduzir essa avaliação sem viés técnico do fornecedor é normalmente alguém de dentro, ou uma liderança contratada para isso, como descrevemos em CTO as a service.

O caminho híbrido, que é o mais comum

Na prática, a decisão raramente é entre construir tudo e comprar tudo. A arquitetura que mais se sustenta usa produto pronto no que é commodity e software próprio na camada que diferencia, com integração entre os dois.

O desenho típico: ERP ou sistema financeiro de mercado, CRM de mercado, e um sistema próprio para a operação específica, puxando e devolvendo dado para os outros dois. A qualidade dessa costura é o que define se o conjunto funciona, e é o assunto de integração de sistemas.

Esse caminho tem outra vantagem: ele reduz o tamanho do projeto sob medida ao mínimo necessário, que é onde o risco e o custo diminuem de verdade.

Os erros que encarecem um projeto sob medida

• Especificar a solução antes de entender o problema. Chegar com a tela desenhada e pedir orçamento produz software que atende ao desenho e não ao processo. O caminho inverso está em product discovery.
• Replicar o sistema antigo. Pedir “igual ao que temos, mas moderno” carrega vinte anos de decisões que ninguém lembra por que foram tomadas.
• Construir tudo de uma vez. Escopo grande em uma entrega única é a forma mais confiável de estourar prazo.
• Não ter um dono do projeto do lado do cliente. Sem alguém com poder de decidir e tempo de responder, o projeto para esperando resposta e o custo continua correndo.
• Escolher pelo menor preço. Proposta muito abaixo das outras normalmente significa escopo menos entendido, e a diferença volta como aditivo.

Como decidir em uma reunião

Quatro perguntas, respondidas com número em vez de opinião, resolvem a decisão na maioria dos casos:

1. Esse processo é o que nos diferencia, ou é administrativo? Se é administrativo, compre pronto.
2. Quantas horas por semana a equipe gasta contornando o sistema atual? Multiplique por cinquenta semanas e pelo custo da hora.
3. Quanto vamos pagar de licença nos próximos três anos, com o crescimento previsto de equipe?
4. Existe produto no mercado que atenda à nossa regra sem customização paga? Se sim, o sob medida precisa justificar a diferença.

Se as respostas apontarem para construir, o passo seguinte não é escolher tecnologia: é delimitar a primeira entrega que já resolve algo em produção. Para entender como um parceiro de desenvolvimento se organiza para isso, vale desenvolvimento de software e, para o formato de time dedicado, squad as a service. Se o gargalo for tarefa repetitiva e não sistema novo, o caminho mais curto está em RPA e automação de processos.

Perguntas frequentes