Quando desenvolver software era uma vantagem competitiva
Em 2022, enquanto ainda cursava Medicina, comecei a estudar programação. Naquela época, desenvolver software ainda era uma habilidade relativamente rara. Transformar uma ideia em um produto exigia anos de estudo, equipes especializadas e uma quantidade enorme de tempo. A programação, por si só, era uma barreira de entrada. Quem dominava essa habilidade possuía uma vantagem que poucas pessoas conseguiam replicar.
Foi nesse período que conheci o universo do low-code e do no-code. Essas plataformas mostravam que era possível construir aplicações complexas utilizando componentes visuais, reduzindo drasticamente a necessidade de escrever código manualmente (fazendo um comparativo, algo semelhante ao Canva® perante o Photoshop®: não é possível criar todo tipo de edição, mas facilitou muito a criação de mídias). Pouco depois, surgiu outro conceito que aceleraria ainda mais essa transformação: o vibe coding. Diferentemente do low-code, ele utiliza modelos de inteligência artificial para gerar código a partir de linguagem natural. Em 2022, essa tecnologia ainda estava longe de produzir aplicações robustas. Os modelos cometiam erros, tinham dificuldade para manter consistência entre arquivos e funcionavam muito mais como um apoio ao desenvolvedor do que como um substituto.
Mesmo assim, a direção parecia clara. Até 2025, combinar inteligência artificial (vibe coding) com plataformas low-code já permitia criar diversos tipos de aplicações, e validar hipóteses em dias, algo que antes levaria meses para sair do papel. Pela primeira vez, tive a sensação de que o desenvolvimento deixava de ser o principal gargalo para construir uma empresa de tecnologia; não era mais necessário ter uma equipe gigante com um alto investimento financeiro.
A primeira vantagem competitiva desapareceu
Foi justamente nesse período que, junto dos meus sócios, fundamos a Chronafy. A empresa nasceu de uma pergunta simples: e se fosse possível controlar toda a sua agenda apenas conversando com uma inteligência artificial em linguagem natural? Hoje, essa ideia parece quase óbvia. Em 2025, porém, transformar essa hipótese em um produto funcional ainda exigia uma arquitetura complexa, integrações com diferentes provedores, modelos de IA pouco maduros e inúmeras limitações técnicas.
Como acontece com praticamente toda startup em estágio inicial, passamos boa parte dos primeiros meses tentando muito mais entender nosso público do que de fato construir o produto que queríamos. Precisávamos compreender profundamente a dor do cliente, como ela já era resolvida, quais eram as limitações das soluções existentes e, principalmente, onde poderia existir uma vantagem competitiva sustentável. Quem já construiu um produto sabe que, nessa fase, mudar de direção faz parte da rotina. Cada conversa com um cliente gera novas perguntas, algumas hipóteses deixam de fazer sentido e outras começam a surgir.
Essa reflexão ficou ainda mais evidente durante o Startup Summit, em Florianópolis, no mesmo ano. Mas que mais me chamou atenção lá não foi uma startup específica, e sim, uma mudança clara no mercado. Praticamente todas as empresas apresentavam algum tipo de inteligência artificial como parte central do produto. A IA deixava rapidamente de ser um diferencial competitivo para se tornar uma expectativa básica. As empresas tradicionais corriam para adaptar seus produtos, enquanto as novas já nasciam com uma cultura AI-first, construídas desde o início assumindo que a inteligência artificial faria parte da experiência do usuário.
Na época, nosso MVP ainda parecia extremamente frágil quando comparado ao poder de execução das grandes empresas de tecnologia. A pergunta que fazíamos diariamente era simples: o que impediria uma big tech de lançar algo semelhante e nos tornar irrelevantes em poucos meses?
Foi justamente nas conversas de corredor, entre fundadores, investidores e profissionais do ecossistema, que comecei a ouvir repetidamente uma frase que mudaria minha forma de enxergar tecnologia:
"Produto está virando commodity."
Naquele momento, essa afirmação fazia muito sentido. Nunca havia sido tão rápido, barato e acessível transformar uma ideia em software. Se equipes pequenas já conseguiam desenvolver produtos que antes exigiriam dezenas de engenheiros, talvez o software deixasse de ser a principal vantagem competitiva. Pela primeira vez, tive a sensação de que estávamos procurando nosso diferencial no lugar errado. Até então, toda a nossa energia estava concentrada em evoluir nosso MVP e construir um produto melhor. Mas e se, alguns meses depois, qualquer concorrente pudesse construir praticamente o mesmo produto?
A busca pelo próximo moat
Pouco tempo depois, fomos selecionados para a turma BRA6 da Antler®. Durante a residência, convivemos diariamente com dezenas de fundadores que, apesar de atuarem em mercados completamente diferentes, enfrentavam exatamente a mesma pergunta.
O que tornaria nossas empresas difíceis de serem copiadas? No universo das startups, existe um conceito bastante conhecido chamado moat, utilizado para descrever uma vantagem competitiva sustentável. Não basta ser diferente hoje; é preciso construir algo que continue sendo difícil de copiar mesmo quando seus concorrentes entendem exatamente o que você faz.
Pela primeira vez, percebi que a discussão havia mudado. Ninguém mais perguntava como construir um produto. Todos perguntavam como construir algo que continuasse sendo difícil de copiar. Se desenvolver software estava ficando cada vez mais simples, então o produto, por si só, deixava de ser um moat confiável. As discussões naturalmente mudaram de direção. Talvez a verdadeira vantagem estivesse na distribuição. Talvez na marca, na comunidade, na cultura da empresa ou na velocidade com que uma equipe conseguia aprender e evoluir o produto. Cada fundador defendia uma hipótese diferente, mas todos buscavam responder à mesma pergunta: qual vantagem continuaria existindo quando qualquer pessoa pudesse construir um bom software?
No início de 2026, porém, a tecnologia acelerou mais uma vez e tornou essa discussão ainda mais complexa. Ferramentas como o Claude Code® passaram a permitir que pessoas com pouco (ou praticamente nenhum) conhecimento técnico desenvolvessem aplicações completas apenas descrevendo, em linguagem natural, o que desejavam construir. Ao mesmo tempo, a comunidade open source evoluía em um ritmo impressionante. Projetos compartilhados no GitHub®, MCPs, agentes especializados e bibliotecas reutilizáveis começaram a encapsular problemas que, até pouco tempo antes, exigiam anos de experiência para serem resolvidos.
A sensação era de que o conhecimento técnico deixava de ser um ativo escasso. Sempre que surgia uma nova dificuldade, alguém, em algum lugar do mundo, encontrava uma solução, publicava esse conhecimento e tornava a barreira significativamente menor para todos os que viessem depois. Comecei a perceber um padrão: sempre que encontrávamos um possível moat, a tecnologia tratava de reduzir sua importância poucos meses depois.
Quando até a execução começou a virar commodity
A transformação rapidamente deixou de atingir apenas o desenvolvimento de software. Ela passou a alcançar praticamente todas as áreas de uma empresa. Quem nunca havia criado um funil de vendas passou a reproduzir modelos já validados com ajustes feitos sozinhos pela IA em cima do seu próprio produto. Campanhas de marketing começaram a ser geradas por IA. Landing pages deixaram de depender de código e ficaram disparadamente mais simples de serem criadas. Criativos passaram a ser gerados em qualidade profissional. O próprio conhecimento sobre distribuição tornou-se muito mais acessível, e os algoritmos de redes pagas, muito mais compreendidos.
Há poucos anos, lançar uma campanha de marketing exigia um designer, um copywriter, alguém para configurar anúncios, outra pessoa para analisar métricas e alguém responsável por otimizar tudo isso continuamente. Hoje, boa parte desse processo pode ser executada por agentes especializados, capazes de produzir campanhas, testar variações, interpretar resultados e propor melhorias praticamente sem intervenção humana. A execução deixou de depender exclusivamente de equipes numerosas e passou a depender muito mais de como as ferramentas são utilizadas.
Naquele momento, imaginei que o verdadeiro diferencial passaria a ser a capacidade de execução. Afinal, construir um produto era apenas o começo. O que realmente diferenciaria uma empresa seria sua velocidade para aprender, corrigir erros e evoluir. Mas essa hipótese também durou pouco. Os agentes deixaram de apenas responder a perguntas e passaram a executar ciclos completos de melhoria. Revisavam código, implementavam alterações, executavam testes, analisavam resultados e iniciavam novas iterações praticamente sem intervenção humana. Pela primeira vez, até a velocidade de execução começava a se tornar reproduzível e não era mais um moat.
O que descobrimos dentro da Chronafy
Nesse momento, parei de olhar para a tecnologia e comecei a olhar para dentro da empresa. Percebi que nossa maior vantagem talvez nunca tivesse sido tecnológica. Desde o primeiro dia, seguimos uma lógica diferente daquela que predominava em boa parte do mercado. Enquanto muitas startups defendiam lançar rapidamente, corrigir problemas em produção e evoluir conforme os erros aparecessem, nós tínhamos uma enorme dificuldade em trabalhar dessa forma.
Talvez porque a Chronafy tenha sido fundada por três médicos, e, na medicina, você aprende desde cedo que protocolos existem para impedir que o erro aconteça. Quando ele acontece, existe outro protocolo dizendo exatamente como responder. Sem perceber, levamos essa mentalidade para dentro da empresa. Antes de lançar funcionalidades, desenhávamos protocolos, criávamos redundâncias, simulávamos cenários de falha e executávamos milhares de testes, testes que, muitas vezes, nem seriam feitos pelo uso comum de um usuário. Nossa preocupação nunca foi apenas lançar mais rápido. Era construir um sistema robusto capaz de continuar funcionando quando inevitavelmente algo saísse do previsto.
Na época, sinceramente, eu não enxergava isso como uma vantagem competitiva. Para mim, era apenas a consequência natural de três médicos construindo uma empresa de tecnologia. Só mais tarde percebi que, enquanto buscávamos um moat em produto, distribuição ou execução, talvez estivéssemos construindo outro sem perceber: uma cultura baseada em responsabilidade.
O último moat
Todo sistema está suscetível a falhas. Não importa qual modelo de inteligência artificial esteja por trás dele. Não importa quantos agentes participem da operação ou quantas redundâncias existam. A falha continuará sendo uma possibilidade. Puxando para o lado médico, até mesmo os métodos contraceptivos mais eficazes têm chance de falha, e terapias que têm inúmeros estudos estão propensas a falhas. No mundo tech, a mesma coisa ocorre: sistemas governamentais acabam sendo expostos e até mesmo softwares das maiores empresas de tecnologia do mundo apresentam falhas e instabilidades.
Mas agora imagine um mercado onde dez empresas oferecem exatamente o mesmo produto. Todas utilizam modelos equivalentes, possuem recursos semelhantes, entregam desempenho parecido e evoluem praticamente na mesma velocidade. Sendo o produto uma verdadeira commodity, o que faz um cliente escolher uma delas?
Em um cenário como esse, a decisão deixa de ser tecnológica. O cliente começa a fazer perguntas diferentes. Quem está por trás desse sistema? Como essa empresa trata os dados dos clientes? Quais procedimentos ela possui quando ocorre um incidente? Existe redundância? Existe transparência? Existe alguém disposto a responder quando algo dá errado? Quem assume a responsabilidade pelas consequências?
Isso porque ninguém responsabiliza um algoritmo. Ninguém processa um workflow. Ninguém liga para um agente autônomo quando um sistema falha. Sempre existe uma empresa. Sempre existe uma equipe. Sempre existe alguém cuja assinatura responde por tudo aquilo.
Talvez seja justamente esse o último moat. À medida que tecnologia, produto, distribuição e parte da execução caminham para se tornar cada vez mais acessíveis, a vantagem competitiva deixa de estar apenas na capacidade de construir sistemas e passa a estar na capacidade de construir instituições confiáveis. A inteligência artificial pode automatizar a construção, acelerar a distribuição e até executar parte do trabalho. Mas ela ainda não automatiza quem responde quando tudo dá errado.
No fim, talvez o verdadeiro produto nunca tenha sido o software. Sempre foi a confiança. E talvez a responsabilidade seja, de fato, o último moat.