Na edição #126 do Guru Talks, que foi ao ar no dia 26/03/2026, o CEO da Guru, André Cruz, revela por que o Custo Total de Propriedade (TCO) deve ser a métrica número um de qualquer empresário maduro que busca escala e previsibilidade. Descubra por que internalizar tecnologia de suporte pode ser um “suicídio operacional” e como a orquestração via camada de serviços protege sua margem e sua liberdade.
- 1. O que é TCO no SaaS e por que ele importa
- 2. O mito do património tecnológico
- 3. Software próprio: ativo ou passivo de manutenção?
- 4. O custo oculto de internalizar operações
- 5. A analogia da padaria: foco no core business
- 6. O imposto da pessoa-chave e o risco operacional
- 7. Obsolescência, distração e atraso competitivo
- 8. A falácia de que fazer internamente é mais barato
- 9. O perigo do controlo total e da infraestrutura própria
- 10. Lock-in reverso: quando a empresa fica presa ao que criou
- 11. Como decidir o que internalizar e o que contratar fora
- 12. Conclusão: seja dono do resultado, não do software
O que é TCO no SaaS e por que ele importa
[01:13] André introduziu o tema a partir de um erro comum entre empresários e gestores: decidir com base no curto prazo e ignorar o impacto estrutural da decisão no longo prazo. Nesse contexto, ele recuperou o conceito de TCO (Total Cost of Ownership), ou custo total de propriedade, para mostrar que o problema não estava apenas no preço da ferramenta, mas em tudo o que vinha junto com a sua posse.
[02:08] A principal provocação foi direta: TCO não era uma questão de planilha, mas de sobrevivência empresarial. Ao longo da conversa, André sustentou que tentar absorver tudo para dentro da operação poderia parecer inteligente no início, mas, na prática, transformava-se numa estratégia cara, lenta e arriscada.
O mito do património tecnológico
[03:35] André chamou esse erro de mito do património tecnológico. Na visão de muitos empreendedores — sobretudo os mais novos ou os que ainda não desenvolveram maturidade de gestão — construir software próprio parecia um sinal de solidez, controlo e valorização do negócio.
No entanto, essa leitura revelava-se incompleta. O empresário acreditava estar a criar um ativo, quando muitas vezes estava apenas a assumir um compromisso permanente com manutenção, suporte, segurança, atualização e risco. Em vez de ganho estratégico, surgia uma nova camada de complexidade.
Software próprio: ativo ou passivo de manutenção?
[04:04] André foi enfático ao desmontar a lógica do “software próprio como património”. Segundo ele, o software interno raramente funcionava como um ativo imobilizado. Na maior parte dos casos, ele tornava-se um passivo de manutenção.
Isso acontecia porque o custo não terminava na entrega do projeto. Pelo contrário: ele começava ali.
O custo real começa quando “dá certo”
[04:35] André trouxe uma ideia importante: se desse certo, dava errado. A provocação fazia sentido porque, quando um sistema começava a funcionar de verdade e a ganhar escala, ele passava a atrair novos riscos e exigências.
Entre eles:
- tentativas de fraude e invasão;
- pressão por estabilidade e performance;
- necessidade de segurança reforçada;
- exigências de integrações com terceiros;
- dependência de equipa técnica qualificada;
- evolução contínua do produto.
[05:04] Ao citar o volume de requisições maliciosas e tentativas de fraude, André mostrou que operar tecnologia crítica não era apenas “colocar algo no ar”. Era também sustentar uma estrutura preparada para responder a riscos reais de mercado.
O custo oculto de internalizar operações
[06:03] Um dos pontos mais fortes da conversa foi a comparação entre contratar um SaaS e fazer internamente. André resumiu isso com clareza: quando a empresa contratava um SaaS, o problema passava a ser do fornecedor.
Se uma integração mudasse, se uma API quebrasse ou se uma atualização inesperada impactasse o fluxo, o cliente continuava a exigir resultado — e a responsabilidade operacional recaía sobre o fornecedor.
Quando tudo era feito internamente, o cenário mudava por completo.
A empresa tornava-se responsável por tudo
[06:33] Ao internalizar, a empresa passava a ser:
- suporte;
- segurança;
- engenharia;
- manutenção;
- gestão de crise;
- gestão de continuidade.
Ou seja, além do seu negócio principal, ela ainda precisava operar uma estrutura paralela de tecnologia e sustentação. Isso aumentava o custo, o ruído interno e a pressão sobre a liderança.
A analogia da padaria: foco no core business
[07:31] André utilizou uma analogia simples e eficaz: uma padaria deveria preocupar-se em vender pão, não em fabricar forno. A lógica por trás disso era central para qualquer empresa SaaS ou digital.
Negócios saudáveis concentraram energia naquilo que gerava valor direto para o cliente e receita para a empresa. Já as empresas que tentaram construir tudo internamente passaram a investir tempo e capital em componentes de suporte, sem retorno proporcional.
O que faz sentido internalizar
[07:59] Ao citar o caso do Brasil Paralelo, André mostrou que não fazia sentido essa empresa absorver internamente toda a complexidade de recorrência, automações e infraestrutura que já era resolvida por uma plataforma especializada.
A pergunta estratégica era simples:
isto faz parte do core business ou apenas dá suporte à operação?
O imposto da pessoa-chave e o risco operacional
[08:57] André trouxe um conceito relevante para a gestão: o imposto da pessoa-chave. Trata-se do custo invisível gerado quando uma operação depende excessivamente de pessoas específicas que concentram conhecimento crítico.
Essa dependência tornava-se ainda mais perigosa em equipas de desenvolvimento interno.
Quando o conhecimento fica preso numa pessoa
[09:27] Se um profissional central saísse da empresa, o impacto podia incluir:
- atraso em entregas;
- perda de contexto técnico;
- aumento de custo para retenção ou substituição;
- risco operacional elevado;
- queda de produtividade da equipa.
Obsolescência, distração e atraso competitivo
[10:23] Outro ponto crítico foi a obsolescência programada da operação tecnológica. André lembrou que sistemas envelheciam rapidamente porque o ambiente em volta mudava o tempo todo: navegadores, sistemas operativos, legislação, requisitos de segurança, APIs e integrações.
O custo de estar sempre a correr atrás
[10:53] Esse fenómeno criava um efeito acumulado. A empresa montava o seu pipeline, planeava uma rota de evolução e, de repente, precisava interromper tudo para responder a algo urgente que não estava no radar.
Esse tipo de interrupção drenava foco, orçamento e capacidade de execução.
O custo da distração
[12:22] André também destacou o custo da distração. Cada reunião dedicada a bugs, manutenção interna, correções ou melhorias burocráticas era uma reunião a menos para vender, inovar ou evoluir aquilo que realmente gerava receita.
Essa reflexão é especialmente relevante no SaaS, onde velocidade de adaptação e foco em produto são determinantes. Quanto mais energia a empresa dispersou em sistemas acessórios, menos energia sobrou para criar vantagem competitiva.
[13:53] Ele ainda relatou um caso interno em que uma funcionalidade simples ganhou uma complexidade desnecessária porque a equipa se empolgou tecnicamente. O resultado foi clássico: um pedido pequeno transformou-se num projeto grande, difícil de encaixar e lento para entregar.
A falácia de que fazer internamente é mais barato
[17:44] André também enfrentou uma das justificações mais recorrentes do mercado: a ideia de que fazer em casa seria “mais barato” do que pagar mensalidade a um fornecedor SaaS.
Na superfície, a conta parecia simples. Mas ela ignorava quase tudo o que realmente compunha o TCO.
O que normalmente fica fora da conta
[18:13] Entre os custos frequentemente ignorados estavam:
- encargos trabalhistas;
- férias e benefícios;
- hardware e infraestrutura;
- gestão de risco;
- turnover;
- custo de liderança;
- tempo de manutenção;
- perda de foco estratégico;
- custo de oportunidade.
Por isso, comparar mensalidade com salário era uma conta incompleta. O custo não estava apenas no valor pago ao programador ou à equipa. Estava em toda a estrutura necessária para sustentar aquela operação ao longo do tempo.
Diferenciação irrelevante não gera receita
[19:06] André chamou atenção para outro erro: construir sistemas exclusivos que não faziam o cliente comprar mais. Nesse caso, a empresa criava uma sensação de diferenciação interna, mas sem impacto real na geração de receita.
Era, nas palavras dele, uma vaidade operacional.
O perigo do controlo total e da infraestrutura própria
[20:02] André defendeu a simplicidade como estratégia de gestão. Ao mencionar a relação da Guru com a Google Cloud, ele mostrou uma visão pragmática: manter consistência tecnológica e reduzir a tentação de trocar stack, fornecedor ou infraestrutura a todo momento.
Essa escolha tinha um objetivo claro: proteger a empresa da dispersão e proteger a equipa da síndrome da reinvenção constante.
O erro do “my precious”
[21:54] A crítica seguinte foi à obsessão pelo controlo total. Para muitos empresários, possuir datacenter, servidor próprio ou stack totalmente interna parecia sinónimo de robustez. André desmontou essa lógica ao mostrar que segurança, redundância, compliance e infraestrutura séria exigiram investimento muito acima do que a maioria das empresas imaginava.
[23:20] Ele relatou inclusive um caso grave de armazenamento inadequado de cartões de crédito numa base de dados, reforçando que ter infraestrutura própria sem maturidade de segurança podia transformar-se num enorme passivo jurídico, operacional e financeiro.
Lock-in reverso: quando a empresa fica presa ao que criou
[27:12] Um dos conceitos mais interessantes apresentados por André foi o lock-in reverso. Muitas empresas internalizaram processos para “não ficar presas a fornecedor”. Só que, ao fazer isso, acabaram presas a algo ainda pior: uma tecnologia própria, pouco documentada, difícil de manter e sem mercado de suporte.
Como decidir o que internalizar e o que contratar fora
[29:01] Depois de expor os riscos, André chegou ao ponto mais prático da conversa: como decidir o que deve ficar dentro de casa e o que deve ser contratado fora.
A resposta foi objetiva e estratégica.
Regra 1: internalizar o que gera dinheiro
[31:01] Se determinada capacidade gerava receita diretamente, diferenciava a empresa e fazia parte do seu core business, então fazia sentido investir internamente.
Exemplos:
- produção de conteúdo em empresas cujo negócio depende disso;
- produto principal de uma empresa SaaS;
- elementos que afetam diretamente a proposta de valor percebida pelo cliente.
Regra 2: externalizar o que apenas suporta a operação
[33:00] Se determinada estrutura apenas ajudava a operação a funcionar, mas não era o motor da geração de riqueza, então a compra externa costumava fazer mais sentido.
Exemplos:
- sistemas acessórios;
- infraestrutura comoditizada;
- ferramentas operacionais de suporte;
- processos que não aumentavam valor percebido pelo cliente final.
Regra 3: considerar o time to market
[33:56] André também acrescentou uma variável decisiva: quanto custa esperar. Não bastava calcular o investimento para construir algo. Era preciso considerar quanto valeria ter a solução pronta amanhã, versus seis meses, um ano ou dois anos depois.
Esse raciocínio incluía:
- custo de desenvolvimento;
- custo de manutenção;
- custo de atraso;
- custo de oportunidade;
- impacto competitivo no mercado.
Conclusão: seja dono do resultado, não do software
[35:23] A conclusão de André resumiu todo o argumento com precisão: a empresa não deveria querer ser dona do software; deveria querer ser dona do resultado.
O mercado não premiou quem tinha a infraestrutura mais bonita, o sistema mais exclusivo ou o maior controlo técnico. O mercado premiou quem entregou valor mais rápido, com mais consistência e com melhor foco no cliente.
[36:21] Quando a empresa investiu tempo, dinheiro e atenção em estruturas burocráticas que não aumentavam valor percebido, ela perdeu margem e velocidade. Por outro lado, quando concentrou recursos naquilo que realmente movia receita, fortaleceu a operação e preservou a capacidade de crescer.
