O reflexo esquecido
No fim dos anos 2000 ainda era normal empresas construírem suas próprias ferramentas internas: o sistema de pedidos, o de despacho, a calculadora de comissões, a base de conhecimento interna. Com a ascensão do SaaS, esse reflexo desapareceu. "Por que construir se dá pra comprar pronto?" virou resposta padrão em toda reunião de arquitetura.
Essa resposta foi certa por um tempo. Hoje, muitas vezes não é mais. Um número crescente de empresas está construindo ferramentas de backoffice por conta própria de novo – e não por nostalgia, mas porque a economia virou.
O que não fecha mais com Enterprise SaaS
Três problemas se acumulam quanto mais tempo uma empresa roda em Enterprise SaaS:
Preço escala pelo fator errado. Licenças por usuário, módulos add-on para cada segunda função, taxas por conector em integrações. O que começa como solução padrão barata custa, depois de três anos com 200 usuários e seis módulos, seis dígitos por ano – sem que a ferramenta tenha ficado perceptivelmente melhor.
A largura de features é vasta e rasa. Enterprise SaaS precisa cobrir todos os setores, todos os tamanhos de empresa e todos os casos de uso. O resultado são ferramentas com centenas de features, a maioria irrelevante, e as poucas realmente necessárias costumam ser genéricas demais para representar o processo real. Workarounds, muletas de Excel e soluções "a gente faz assim mesmo" são o resultado.
Velocidade de adaptação despenca. Precisa de um ajuste no workflow? Espere o próximo release trimestral do fornecedor – ou pague um consultor para dobrar a plataforma SaaS até caber. Os dois são lentos, os dois são caros, os dois geram frustração na equipe que usa a ferramenta todo dia.
O que agora é tecnicamente possível
Construir ferramentas internas era pesadelo por três razões: caro demais, lento demais, manutenção alta demais. As três caíram.
Construir ficou barato. Uma equipe de desenvolvimento assistida por IA constrói um sistema interno de pedidos com fluxo de aprovação, relatórios e integração Slack em duas a quatro semanas. Cinco anos atrás eram três a seis meses. Os custos hoje muitas vezes são menores do que um ano de licença da alternativa SaaS.
Componentes vêm como Lego. Autenticação do Auth0 ou Clerk, bancos do Supabase ou Neon, componentes UI do shadcn, motores de workflow do Temporal, relatórios do Metabase. Desses blocos dá pra montar uma ferramenta produtiva sem que a equipe reinvente autenticação, modelagem de dados ou relatórios do zero.
Manutenção é gerenciável. O que era "alguém precisa cuidar disso" hoje costuma ser tão pequeno e focado que um único desenvolvedor cuida por fora. Em cima disso: revisões de código por IA, refatoração automatizada e geração de testes derrubaram drasticamente o esforço de manutenção.
O que mudou em termos de valor
Dez anos atrás, Enterprise SaaS entregava um valor que ferramenta interna não alcançava: anos de desenvolvimento de produto, lista ampla de features, boas práticas de milhares de implementações. Essa proposta de valor erodiu.
Boas práticas hoje são públicas. Como um processo de pedidos deve ser estruturado, como uma visualização de pipeline deve parecer, como funciona um workflow de aprovação – tudo documentado em blogs, em projetos open-source, na cabeça de qualquer desenvolvedor que já trabalhou em empresa de médio porte. IA amplifica isso: puxa boas práticas para dentro de cada sugestão de código.
Listas amplas de features são um peso. O que era vendido como força – "1.200 features prontas" – hoje é frequentemente a fraqueza. Funcionários não encontram as funções que precisam ou não entendem os conceitos. Ferramentas internas têm a vantagem de conter exatamente o que se precisa, e nada além.
Processos próprios não precisam ser dobrados. Esse é o verdadeiro motor. Uma ferramenta interna que espelha exatamente o workflow economiza cinco a quinze minutos por funcionário por dia em cliques e cópias. Com 50 funcionários, são vários dias-pessoa por semana voltando ao trabalho de verdade.
Onde ferramentas internas são a resposta certa
Nem toda área serve. Ferramentas internas mostram sua força onde três condições convergem:
O processo é específico da empresa. Quem tem um workflow que se distingue do da maioria das outras empresas – por motivos históricos, regulatórios ou estratégicos – sofre especialmente com ferramentas SaaS genéricas. Uma ferramenta interna se paga aqui com mais força.
O grupo de usuários é claramente delimitado. Ferramentas internas funcionam melhor para equipes internas com caso de uso claro: despacho, contabilidade, operações de vendas, RH. Onde entra público externo ou alto número de usuários, a relação custo-benefício fica mais difícil.
Integração com o próprio modelo de dados é valiosa. Uma ferramenta que acessa dados internos sem dança de exportação e importação vence qualquer SaaS que ofereça só interfaces padrão. Quanto mais profunda precisa ser a integração, mais forte o argumento por construir.
Onde Enterprise SaaS ainda vence
Três áreas continuam território SaaS:
Processos padrão altamente regulados. Folha de pagamento, contabilidade, impostos. Aqui um bom fornecedor entrega conformidade regulatória como serviço. Manter isso internamente é arriscado e caro.
Colaboração com externos. E-mail, videoconferência, documentos compartilhados. Aqui vence a plataforma que todos usam, porque efeitos de rede contam. Ninguém quer rodar seu próprio Zoom.
Verticais especializadas com profundidade real. Software setorial high-end – ensaios clínicos, atuária, segmentos logísticos específicos – traz décadas de conhecimento de domínio acumulado, que não se reconstrói em duas semanas.
Nessas áreas, fornecedores SaaS não vão a lugar nenhum. Fora delas, a vantagem fica cada vez mais fina.
Como a transição aparece na prática
Empresas que fazem esse movimento com sucesso costumam seguir um padrão parecido:
Primeiro uma dor, depois uma estratégia. Raramente começa com o propósito de "construir mais por conta própria". Começa com uma ferramenta específica sendo particularmente irritante, um substituto interno sendo construído, e todo mundo percebe: foi mais rápido do que esperado e encaixa melhor. O caso individual vira padrão, o padrão vira estratégia.
Pensamento de plataforma, não de ferramenta. Quem constrói ferramentas internas sistematicamente termina, depois de três a cinco ferramentas, com uma plataforma interna própria: auth compartilhada, modelos de dados compartilhados, biblioteca UI compartilhada. Essa plataforma deixa a próxima ferramenta ainda mais barata e rápida.
Ownership claro. Ferramentas próprias precisam de um dono responsável – alguém que entenda tanto a tecnologia quanto o processo. Sem ownership, ferramentas internas viram órfãs.
Na nh labs, acompanhamos exatamente essa transição em muitos projetos. Costuma começar com a comparação honesta do TCO de uma ferramenta SaaS existente com o esforço estimado de desenvolvimento próprio – e a conta sai bem diferente do que a maioria dos participantes esperava.
Conclusão
Ferramentas internas voltaram. Não como solução de contingência para empresas que não podem pagar Enterprise SaaS, mas como escolha estratégica para empresas que querem controlar seus próprios processos, dados e velocidade. Enterprise SaaS continua útil – mas o reflexo padrão "vamos comprar algo pra isso" está perdendo justificativa. Quem construir nos próximos dois anos algumas ferramentas internas irritantes e perceber o quanto o resultado é mais barato e melhor vai olhar pra próxima renovação de licença com muito mais criticidade. Essa onda acaba de começar.