A decisão entre construir ou comprar software costuma ser tomada com dois números que não são comparáveis: uma proposta de desenvolvimento com um valor total e uma subscrição com um preço mensal por utilizador. Um parece enorme, o outro parece insignificante.
Uma comparação honesta entre construir ou comprar software precisa das duas linhas ao longo do mesmo período, com tudo o que cada uma arrasta atrás de si. O software à medida tem um custo de entrada alto e uma curva plana. Uma subscrição tem um custo de entrada baixo e uma curva que sobe com o número de pessoas. A questão não é qual é mais barato. É em que ano as duas linhas se cruzam e se o seu horizonte de decisão chega até lá.
- 80% Cobertura do seu fluxo de trabalho por um produto existente a partir da qual comprar costuma ser o certo
- 2–3× Quanto o custo total de posse representa face ao preço anunciado da subscrição
- 30–100 mil € Onde cai a maioria dos projetos à medida pequenos e médios
- 15–20% Do custo de construção, por ano, para manter software que é seu
Construir ou comprar software: quanto custa cada opção a cinco anos?
O erro habitual ao decidir entre construir ou comprar software é comparar o preço de entrada. Os produtos de prateleira têm um custo de entrada baixo, custos de configuração reais e subestimados, integrações muitas vezes vendidas à parte por conector e um custo recorrente que cresce com utilizadores, volume e módulos. O software à medida tem um custo de entrada alto, integrações que acrescentam 20 a 30 por cento à construção inicial, alojamento de 200 a 1.500 € por mês e manutenção anual de 15 a 20 por cento do custo de construção.
A linha que muda a conta é a recorrente. Uma subscrição por utilizador cresce quando a empresa cresce, que é exatamente quando o sistema está a gerar mais valor. A manutenção de software próprio é uma percentagem do custo de construção e não acompanha o crescimento do negócio. A linha que mais surpreende é a configuração: as referências de mercado apontam para um custo total de posse de duas a três vezes o preço anunciado da subscrição, quando se contam implementação, integrações, formação e administração interna. O preço anunciado é a parte mais pequena da fatura.
| Opção | Curva de custo | O que implica |
|---|---|---|
| Comprar | Entrada baixa, curva a subir | O custo recorrente cresce com a empresa. O controlo é baixo, os aumentos de preço não dependem de si e, se deixar de pagar, perde o acesso. Serve processos comuns e regulados. |
| Construir | Entrada alta, curva plana | 15 a 20 por cento por ano em manutenção, mais alojamento. Controlo total e, se deixar de pagar a um fornecedor, continua a ter o sistema. Serve processos que diferenciam. |
| Híbrido | Núcleo de produto, periferia construída | Subscrição mais manutenção. Um produto trata do núcleo comum e da conformidade; constrói as integrações e as interfaces que diferenciam. |
Quando é que comprar é a decisão certa?
Quando o processo não é seu nem precisa de ser. Há categorias inteiras em que construir é desperdício de capital: contabilidade, processamento salarial, email, videoconferência, assinatura de documentos, gestão de pedidos. Estes processos são iguais em todo o lado, têm regulação uniforme e contam com produtos maduros com décadas de investimento por trás.
O teste prático é a cobertura. Se um produto existente cobre cerca de 80 por cento do fluxo de trabalho, compre. Os restantes 20 por cento resolvem-se com processo, com uma pequena camada à medida na periferia ou aceitando que uma parte fica menos elegante. Há três sinais que o confirmam: o processo é regulado e igual para todos, por isso a conformidade fica com o fornecedor; precisa disto a funcionar em semanas, e um produto configurável já está em uso enquanto uma construção ainda está na descoberta; e o processo não diferencia o negócio, por isso ser diferente não traz retorno.
Quando é que construir compensa?
Quando o fluxo de trabalho é a razão pela qual os clientes escolhem a empresa, ou quando nenhum produto serve.
Há uma terceira opção?
Há, e na prática é a mais comum: comprar o núcleo e construir à volta. O padrão habitual é adotar um produto para o núcleo do processo, que trata da conformidade e da manutenção, e depois construir a camada que diferencia, ou seja, integrações com sistemas internos, interfaces para quem o usa todos os dias e automatismos que o produto não prevê.
Isto exige uma condição inegociável, verificada antes de assinar: o produto tem de ter uma API documentada e permitir exportar os seus dados. Sem isso, a camada à medida assenta em algo que pode mudar sem aviso, e a estratégia deixa de ser híbrida para passar a ser dependência.
O que mudou a IA na decisão entre construir ou comprar software?
Menos do que os fornecedores sugerem, e mais do que parece. Do lado da construção, as ferramentas de assistência aceleram parte do trabalho, com 54 por cento dos programadores a usá-las já no seu fluxo de trabalho habitual, o que reduz o custo em certos tipos de código repetitivo. Do lado da compra, quase todos os produtos acrescentaram funcionalidades de IA e quase todos as cobram à parte, e a integração de IA pode acrescentar até 30 por cento ao custo de um projeto de desenvolvimento, o que sugere que também não é gratuita desse lado.
O que não mudou foi a estrutura da decisão. Construir continua a ser caro no início e barato de manter. Comprar continua a ser barato no início e a crescer. A IA desloca ligeiramente as duas curvas e não muda a pergunta sobre qual delas serve o seu caso.
Como decidir entre construir ou comprar software sem folha de cálculo?
Quatro perguntas resolvem a maioria das decisões entre construir ou comprar software, feitas por esta ordem. A primeira que tiver uma resposta clara decide.
-
1Este processo é a razão pela qual os clientes nos escolhem? Se sim, construa. A discussão de custos é secundária face a apagar uma diferença competitiva.
-
2Algum produto cobre cerca de 80 por cento disto? Se sim, compre e resolva o resto com processo. Se cobrir 50 por cento, não é a ferramenta certa, é uma ferramenta parecida.
-
3A subscrição no quinto ano, com o crescimento esperado, continua aceitável? Se o número assustar, faça a comparação completa com construção mais manutenção. Pode já ter passado o ponto de cruzamento.
-
4Se o fornecedor desaparecer ou triplicar o preço, o que acontece? Se a resposta for "temos um problema sério", isso é risco a ter em conta no preço, não uma nota de rodapé.
O que deve ficar registado numa decisão entre construir ou comprar software?
Escreva a decisão, mesmo quando parece óbvia. Daqui a três anos alguém vai perguntar porque é que a empresa construiu ou comprou. As pessoas que decidiram podem já não estar lá para responder.
Uma página chega. Deve identificar o processo em causa, os produtos avaliados e que parte do fluxo de trabalho cada um cobria. Deve mostrar o custo a cinco anos das duas opções, o custo de saída do produto escolhido ou rejeitado e os pressupostos por trás dos números de crescimento. Guarde os orçamentos dos fornecedores em anexo, com as respetivas datas.
Deve também nomear um responsável e uma data de revisão. Uma decisão entre construir ou comprar software é certa para as condições que existiam quando foi tomada. Quando a base de utilizadores duplica, um produto lança a funcionalidade que faltava ou o fornecedor muda os preços, a data de revisão é o momento em que alguém verifica se a resposta continua válida.
O registo demora uma hora a escrever. Sem ele, a equipa seguinte repete a avaliação do zero ou, pior, assume que o raciocínio original ainda se aplica quando já ninguém sabe dizer qual era.
Perguntas frequentes
Custo ao longo do tempo
É mais barato comprar software ou desenvolvê-lo à medida?
Qual é o custo total de posse de uma solução de prateleira?
Quanto custa manter software à medida depois de construído?
Tomar a decisão
O que é a regra dos 80 por cento?
Quando é que vale a pena construir software à medida?
Posso combinar as duas abordagens?
