Construir ou comprar: quando a solução de prateleira sai mais cara
Prateleira é mais barato até você contar configuração, integração e os processos que entorta para caber. Um teste para decidir de que lado fica cada caso.
A resposta padrão é comprar, e para a maioria das capacidades o padrão está certo. Você não deveria construir autenticação, folha de pagamento, entrega de e-mail ou um livro-razão contábil. São problemas resolvidos, em que a versão de outra pessoa é melhor do que a sua será.
O padrão fica errado numa situação específica e previsível: quando a capacidade é aquilo que diferencia o seu negócio dos concorrentes.
O teste
Uma pergunta separa a maioria dos casos:
Se isso funcionasse exatamente como funciona no seu concorrente mais próximo, você perderia alguma coisa?
Se a resposta é não, compre. Reembolso de despesas, integração de pessoal, chamados e armazenamento de documentos passam nesse teste com folga.
Se a resposta é sim, você está olhando para aquilo pelo que o cliente de fato paga, e um produto feito para a média do seu setor vai deixar você médio nisso.
| Tipo de capacidade | Padrão | Exceção |
|---|---|---|
| Retaguarda comum | Comprar | Quase nunca construir |
| Fluxo padrão do setor | Comprar e configurar | Construir só se configurar custar mais que construir |
| Integração entre sistemas comprados | Construir fino | Comprar um iPaaS tudo bem; comprar uma caixa preta não |
| Aquilo em que você compete | Construir | Comprar só para validar demanda, com saída planejada |
| Registro regulado de verdade | Depende | Compre o motor, construa o fluxo em volta |
Os custos que tornam "comprar" mais caro do que parece
Custo de licença é o número da comparação. Raramente é o maior número do total.
Configuração é desenvolvimento sem engenheiros. Uma plataforma configurada em 200 telas por consultores é uma base de código. Não tem controle de versão em que você confie, nem suíte de testes, nem revisão de código, e quem entende dela cobra por hora. Costuma ser mais difícil de mudar do que o código sob medida equivalente.
A integração é sua de qualquer jeito. Comprar não elimina o trabalho de integração; realoca. E agora você integra contra o modelo de outra pessoa, no cronograma de release dela, com os limites de taxa dela.
Mudança de processo é custo real sem nota fiscal. Adotar um produto significa adotar o processo que ele codifica. Quando esse processo é melhor que o seu, isso é benefício. Quando é apenas diferente, você paga em treinamento, exceções e planilhas paralelas que crescem em volta das partes que não encaixam.
O custo de sair cresce em silêncio. Cada ano de dado acumulando num modelo proprietário aumenta o custo de partir. Pergunte o que uma exportação contém antes de assinar, não quando quiser sair.
O híbrido que costuma vencer
A maioria das boas respostas não é construir nem comprar. É comprar o motor e construir a borda.
Outra pessoa opera o núcleo difícil e não diferenciador: o processador de pagamento, o provedor de identidade, o data warehouse, a API de modelo. Você constrói o fluxo, as regras de domínio e a interface que tornam aquilo especificamente seu.
Isso mantém a construção pequena e a diferenciação nas suas mãos. Tem um requisito: o componente comprado precisa expor uma API de verdade. Se não expõe, você comprou um sistema sobre o qual não dá para construir, e toda extensão vira automação de tela ou chamado de suporte.
Reversibilidade decide os casos apertados
Quando a análise fica genuinamente equilibrada, escolha a opção mais barata de desfazer.
Comprar costuma ser mais barato de reverter cedo e muito mais caro de reverter tarde, conforme dado e processo se acumulam. Construir é caro no começo e permanece mais ou menos tão reversível quanto começou, desde que você tenha mantido as fronteiras limpas.
Essa assimetria favorece comprar para validar uma necessidade da qual você não tem certeza, com um ponto de decisão explícito em um ano, e construir quando a necessidade estiver provada e os requisitos tiverem parado de se mover.
Acertando a estimativa do lado de construir
Se você cair no construir, o número depende de muito mais do que a lista de funcionalidades. Os fatores que realmente movem estão em como dimensionar o custo de software sob medida, e se você está substituindo um sistema que precisa continuar rodando, o sequenciamento é uma migração em fatias.
Fazemos essa análise no início da maior parte dos projetos de engenharia, e já recomendamos comprar vezes suficientes para isso ser um desfecho normal, e não uma gentileza. Como trabalhamos e o que protegemos está nas práticas de segurança.