Vamos começar pelo lado impopular para quem desenvolve software: na dúvida, compre.
Software de mercado tem custo previsível, começa a funcionar em semanas e alguém já resolveu os problemas que você ainda não conhece. Reinventar cadastro de clientes, folha ou emissão fiscal é queimar dinheiro.
O ponto é que existe uma faixa da operação onde essa lógica se inverte. E reconhecer essa faixa é o que separa um projeto que gera retorno de um que gera arrependimento.
Os quatro casos em que construir vence
1. O processo é a sua diferença competitiva
Se o jeito como você programa a produção, calcula custo ou atende o cliente é parte do motivo pelo qual você ganha do concorrente, colocar isso dentro de um software genérico significa nivelar por baixo. O sistema passa a ditar o processo — e o processo era o ativo.
2. O software existe, mas o custo de adaptação passou o de construir
Acontece mais do que parece. A licença é acessível, mas a customização para caber na sua realidade vira um projeto maior que o sistema. Quando a soma de licença, customização e manutenção de gambiarra encosta no custo de um sistema próprio, a comparação mudou de lugar.
3. O gargalo está no que ninguém vende
Muito do que trava a indústria não tem categoria no mercado: a interface entre dois setores, o controle de um recurso específico, a conferência que só a sua operação faz. Não existe prateleira para isso.
4. Integração e experiência importam mais que funcionalidade
Às vezes a função existe em três sistemas diferentes, e o problema é que o operador precisa abrir os três. Um sistema sob medida que consolida a informação certa numa tela resolve mais que qualquer módulo novo.
Construir não é sobre ter tudo customizado. É sobre ter sob medida o pedaço onde padrão não serve — e comprar todo o resto.
Os quatro casos em que construir é erro
Para ser justo com o outro lado:
- Quando é commodity regulada. Fiscal, contábil, folha. A regra muda de fora para dentro, e acompanhar isso é o produto de quem vende.
- Quando não existe dono do processo. Sem alguém que decide as regras, o projeto vira coleta de opiniões e não termina.
- Quando o objetivo é organizar a bagunça. Sistema não organiza processo indefinido, ele o congela. Primeiro se define o fluxo, depois se constrói.
- Quando ninguém vai manter. Software é organismo vivo. Sem previsão de evolução, o sistema novo é a próxima planilha legada.
Um teste rápido antes de decidir
Responda, para o processo em questão:
- Se dez indústrias parecidas com a sua fizessem isso do mesmo jeito, existiria um produto de mercado para isso? Se sim, procure o produto.
- Quanto custa hoje o retrabalho, o atraso e o erro desse processo por mês? Se não sabe estimar, esse número vem antes do projeto.
- Existe uma pessoa que pode decidir as regras e homologar? Se não, o projeto não está pronto para começar.
- Qual é o menor recorte que já entregaria valor sozinho? Se a única resposta possível é “tudo”, o escopo ainda não foi entendido.
O formato que reduz risco
Quando a decisão é construir, o que mais protege o investimento não é escolher tecnologia — é escolher formato de entrega:
- Recorte crítico primeiro. Uma parte do processo em produção, com usuário real, em semanas — não o sistema completo em um ano.
- Aprovação por demanda. Cada evolução estimada e aprovada antes de ser executada, para que escopo e custo caminhem juntos.
- Homologação antes de produção. Ambiente para validar sem risco para a operação.
- Evolução contínua. Capacidade mensal reservada, porque o processo vai mudar depois de digitalizado — e isso é sinal de que está sendo usado.
Construir sob medida deixa de ser aposta quando a primeira entrega é pequena, real e mensurável. A partir dela, a discussão para de ser sobre software e volta a ser sobre operação — que é onde ela devia estar desde o começo.
Quer avaliar se o seu caso está numa das quatro situações? Agende um diagnóstico ou veja a frente de software sob medida.
