Do fim de 2025 em diante, houve uma virada de chave que a gente ainda vai contar história sobre por muito tempo. Os modelos de LLM deram o grande salto que habilitou tudo que estamos vivendo desde então, com intervalos entre melhorias encurtando a cada ciclo. Os resultados são observáveis na prática: o que era gargalo técnico há seis meses hoje é considerado trivial. Mas por que estamos voltando neste tema que está tão batido? É porque foi exatamente nesse período que passamos a ver várias ferramentas SaaS começarem a ser tratadas como "com os dias contados", múltiplos de mercado de SaaS sob pressão, e diversas vozes fomentando que a parte difícil de construir aplicações semelhantes não seria um big challenge dali em diante.
Esses eventos mudaram a matemática de decisão de qualquer empresa que compra software recorrente. Não porque construir ficou fácil, e sim porque passou a existir a possibilidade de ficar mais barato, o que é diferente. E essa conta passou a ser questionada de forma natural pela liderança em rodas de priorização e etc.
A armadilha do "dá pra construir, então construa"
Só que tem um erro comum escondido nessa lógica: tratar "ficou mais fácil construir" como "então vale a pena construir tudo". A maioria dos softwares de mercado não nasceu como uma solução completa. Nasceu como uma funcionalidade, e foi empilhando camada sobre camada por anos, tentando servir todo tipo de cliente, de maturidade baixa a maturidade alta, tudo dentro do mesmo produto.
O problema é que grande parte das empresas (para não dizer todas) não usa o produto inteiro. Cada empresa usa uma fração. O time de produto quer uma visão, o time de operações quer outra, o time de engenharia quer uma terceira, e a ferramenta genérica, pensada pra atender todo mundo um pouco, no fim não atende bem as particularidades do seu negócio, da maturidade do seu time, da velocidade e forma como seus times precisam consumir. O resultado prático de quem já passou por isso é claro: times acabam usando duas, três ferramentas em paralelo pra cobrir o que uma única, mal ajustada ao seu fluxo real, nunca entregou sozinha. Você paga licença cheia por um produto e paga de novo, em tempo e atrito, pela lacuna que ele deixa.
Isso não é exclusividade de empresas mais recentes, é estrutural em qualquer uma que cresce rápido e tenta encaixar processo real dentro de produto genérico.
O que a Lerian realmente precisava
Na Lerian esse problema ficou claro rápido, e de um jeito bem concreto. A gente precisava de visibilidade de entregáveis pra empresa inteira, não um dashboard isolado de um time, mas um lugar único onde qualquer área acompanha o que está sendo construído, sem depender de status manual em reunião ou de print de tela colado no Slack.
E precisava se ao mesmo tempo de gestão de atividades por área, cada time com seu nível de detalhe e sua forma própria de organizar trabalho.
Porém, existia um pré-requisito: tudo isso ser integrado num mesmo substrato de dados. Não por elegância arquitetural gratuita, e sim por necessidade real de como operamos o dia a dia: nossos fluxos automáticos com IA precisam ler e escrever informações automaticamente durante o fluxo do desenvolvimento, e nosso AI team member, Gandalf, precisava estar dentro da própria ferramenta, via chat, pra responder dúvida direto sobre o quê e o porquê o time está trabalhando naquilo, mantendo o contexto da pergunta combinado com o contexto do negócio.
Ao mesmo tempo, essas consultas também precisam funcionar de forma nativa via Slack, porque é ali que boa parte do time vive o dia inteiro, e permitir esse movimento natural passa a ser um catalisador de adesão dos dados salvos na ferramenta como única fonte da verdade. Ou seja, estamos falando de uma ferramenta que tem que ser acessível por múltiplas portas: UI, API, chat, Slack, mantendo a linguagem e os retornos que a empresa inteira entenda. Nenhuma ferramenta de mercado nasceu pensando nesse conjunto de requisitos. Elas nascem pra resolver "gestão de projeto" ou "roadmap" de forma genérica, e depois você tenta forçar o seu caso de uso lá dentro, torcendo pra API não ser a parte esquecida do produto.
A conta que não fechou pro "continuar comprando"
A gente vivia meio dentro de uma plataforma de mercado, meio fora dela: parte em ferramenta comprada, parte em planilha, parte em automação improvisada com plugins criados pela comunidade. O clássico remendo que qualquer empresa em crescimento reconhece na hora, porque já passou por ele.
E então, em linha com nossa cultura de inconformismo, decidimos fazer a conta de verdade. De um lado: custo de licença recorrente, mais o esforço constante de contornar as limitações, mais o tempo perdido reconciliando dado entre ferramenta A e ferramenta B, porque nenhuma das duas falava com a outra do jeito que a gente precisava. Do outro lado: o custo de construir algo sob medida, e o custo, esse sim real e que ninguém deveria ignorar, de manter esse algo vivo depois de construído.
A conta não fechou pro "continuar comprando e continuar remendando", ela fechou para o "construir uma vez, do jeito certo, com a flexibilidade de evoluir depois conforme a empresa muda". E é importante marcar essa diferença: não fechou porque "construir é grátis agora". Ainda existe o custo de desenho e priorização do software, o custo dos tokens gastos para implementação e manutenção, o custo do treinamento no novo ferramental. Mas fechou porque o custo total de propriedade da alternativa comprada, incluindo o remendo que ela exigia, era mais alto do que parecia no contrato de licenciamento.
Construir como produto, não como gambiarra
Aqui está o ponto que talvez seja o mais importante da história inteira: o Lerian Map não nasceu como ferramenta interna descartável. Nasceu passando pelo mesmo processo que qualquer entrega nossa passa quando vai para cliente.
Teve escuta de time de verdade: cada área com um requisito diferente, nem sempre óbvio, às vezes contraditório com o requisito da área vizinha, e alguém teve que arbitrar isso com critério, não com "vamos colocar tudo". Teve arquitetura pensada pra durar, não pra resolver o problema de hoje e virar dívida técnica em seis meses. Teve o mesmo padrão de segurança que a gente exige de qualquer sistema que toca dado sensível da empresa, porque roadmap e atividade de time carregam informação estratégica, e tratar isso como "é só ferramenta interna, relaxa" seria hipocrisia dado o que a gente vende pra fora. E teve API como cidadã de primeira classe desde o dia um, não como afterthought, porque sem API bem desenhada e com camadas de autenticação, o resto do plano (IA lendo e escrevendo nesse dado, agente operando em cima dele) simplesmente não sustenta.
E isso só foi possível porque o time Lerian possui um perfil técnico e ousado, que gosta de topar esse tipo de trabalho. Na prática, isso significa gente de infraestrutura e produto tratando "ferramenta interna" com o mesmo rigor que trata produto vendido pra cliente, o que é raro, porque a tentação natural em qualquer empresa é tratar internal tooling como trabalho de segunda categoria, feito nas sobras de tempo, sem dono de verdade e sem revisão séria.
O resultado prático, hoje: economizamos dezenas de milhares de reais por mês em licenciamento e no esforço de contornar limitação de ferramenta de terceiro. Mas o número de economia, sozinho, conta só metade da história. A outra metade é que ganhamos uma ferramenta que fala a nossa língua.
A pergunta que fica
Dá pra generalizar essa história além da Lerian, e vale a pena fazer isso com cuidado. Ferramenta interna virar produto vendável pro mercado é caminho conhecido, e legítimo: várias empresas de tecnologia começaram exatamente assim, resolvendo o próprio problema antes de perceber que outras empresas tinham o mesmo problema. Mas o ponto real da história não é "construa tudo internamente porque ficou fácil". Isso é raciocínio raso, e é o mesmo raciocínio raso que levou tanta gente a comprar ferramenta genérica demais no passado, só que na direção contrária.
O ponto real é que build versus buy deixou de ser uma decisão de procurement (aquela conversa rápida entre "qual plano custa menos") e virou uma decisão estratégica de longo prazo, que precisa ser revisitada com a mesma seriedade que qualquer investimento estrutural da empresa. Isso significa pesar custo de criação inicial, custo de manutenção contínua ao longo dos anos (que quase sempre é maior do que a estimativa inicial), e o que você realmente ganha em flexibilidade de evolução quando o dado e a arquitetura são seus. E significa fazer tudo isso sem abrir mão de segurança e de arquitetura sólida no caminho, porque um time empolgado em construir sem esse rigor não está economizando: está trocando custo visível de licença por passivo técnico invisível, que aparece na fatura mais tarde, geralmente na hora mais inconveniente.
Time interno tecnicamente afiado e disposto a construir é um ativo real. Mas ativo só rende quando tem disciplina por trás. A diferença entre o Lerian Map dar certo e virar mais um script que ninguém quer manter foi exatamente essa: tratamos a decisão de construir com o mesmo peso que trataríamos a decisão de vender, reflexo de uma cultura que preza por resolver de fato os desafios, tratando soluções como algo para o longo prazo.