No começo de 2025, eu lancei meu primeiro produto ao público. Não era projeto de cliente, nem um protótipo que vivia no meu notebook: era um produto nosso, construído do zero, com gente de verdade se cadastrando. No fim do mesmo ano, a gente engavetou.
Não foi um produto malfeito, nem um time que se desfez, nem uma ideia em que ninguém acreditava. A gente tinha quase tudo que dizem que importa. Mesmo assim, não andou. Este post é uma tentativa de explicar por quê, do jeito mais honesto que eu consigo, do ponto de vista de quem era responsável por construir.
O que a gente tinha
O produto era uma plataforma web e mobile para nutricionistas e personal trainers: um lugar para prescrever planos alimentares e treinos, acompanhar o progresso de cada cliente e gerenciar consultas, tudo num app só.
A gente era um bom grupo de sócios, cada um com a sua função bem definida. Eu era o "CTO", entre aspas, porque o título é generoso para uma empresa daquele tamanho. A gente tinha contatos dentro do mercado que estava atacando. Construímos do zero, lançamos e fizemos as reuniões que vêm depois de um lançamento. Chegamos a sentar com investidores: conversas e negociação, nenhum dinheiro no fim, mas interesse de verdade no que a gente tinha construído.
Se você me mostrasse essa lista antes de começar, eu diria que era uma boa posição. Produto, time, rede de contatos, lançamento, interesse de investidor. A maioria dos projetos que eu já tinha visto morrer não tinha metade disso.
Onde eu achava que estava o risco
Como quem estava construindo, eu achava que o risco era principalmente técnico. O app vai ser estável? O pagamento vai funcionar? Vai aguentar quando as pessoas usarem de verdade? Essas eram as perguntas em que eu gastava a maior parte da minha energia, e eram as que eu sabia responder.
Olhando para trás, esse era o lugar mais confortável para colocar o risco. Era a parte que eu controlava. Se o problema fosse técnico, dava para resolver com mais trabalho. Eu não tinha um plano para o caso em que o produto funcionasse e as pessoas mesmo assim não viessem.
Onde travou
Algumas pessoas vieram. Alguns profissionais usaram a plataforma com os próprios clientes dentro dela. Então não é verdade que o produto não funcionou para ninguém. Ele só nunca chegou no ponto de crescer sozinho.
A gente tentou os canais de sempre: Meta Ads, Google e contato direto com gente do nicho. O problema não foi escolher o canal errado. Foi o que o cliente encontrava do outro lado de cada canal: um mercado com concorrentes estabelecidos, que se sobressaíam mais do que a gente.
E quando as pessoas testavam, a gente esbarrava em duas coisas que eu subestimei. A primeira foi suporte. Um profissional que roda parte do negócio dele no seu app precisa de resposta rápida, e a gente pecava nisso. A segunda foram features que simplesmente não tinham passado pela nossa cabeça: os edge cases do uso real, as coisas que só aparecem quando a rotina de verdade de alguém encontra o seu produto. Cada uma era pequena. Juntas, eram a diferença entre testar o produto e ficar nele.
Nada disso é problema de código. Eu poderia ter escrito um código melhor e nada dessa lista teria mudado.
Como acabou
Não teve um dia em que ele morreu. O produto foi morrendo aos poucos, e em algum momento uma conversa entre os sócios oficializou o que já era verdade. No fim de 2025, a gente engavetou.
Ser o "CTO" de algo que claramente deu errado é uma sensação estranha. A parte pela qual você era responsável se sustentou. A empresa não. E você começa a perceber que a linha entre essas duas coisas nunca foi tão clara quanto você achava.
O que eu faria hoje
Se eu começasse hoje, sei por onde começaria, e não seria pelo código.
- Validar a tese antes de construir. Não se as pessoas gostam da ideia, mas se o mercado precisa mesmo desse produto, vindo da gente, a ponto de trocar o que já usa.
- Distribuição desde o primeiro dia. Não como uma fase que começa depois que o produto está pronto, mas como parte do produto. Quem vai ficar sabendo disso, e por que acreditaria na gente?
- Posicionamento. Num mercado com concorrentes estabelecidos, "a gente também faz isso" não é motivo para trocar. Saber exatamente para quem é, e por que é melhor para essa pessoa, é um trabalho que precisa acontecer antes do primeiro anúncio.
- Build in public. Mostrar o trabalho enquanto ele está sendo feito, para as pessoas verem que é bom. A confiança num produto muitas vezes começa como confiança em quem está construindo, e essa confiança demora mais para construir do que qualquer feature.
- Suporte como parte do produto. Para quem roda o próprio trabalho na sua plataforma, a velocidade da sua resposta faz parte do que essa pessoa está pagando.
O que eu levei disso
No meu último post eu escrevi que, em algum momento, escrever código deixa de ser a parte difícil. Foi aqui que eu aprendi isso do jeito caro. A gente construiu o produto. O que a gente não construiu foi um motivo para alguém escolher ele.
Eu ainda levo isso para o jeito como trabalho em produtos hoje. Não como "engenheiro tem que fazer marketing", mas como perguntas que eu faço bem mais cedo do que fazia: para quem é isso, como essas pessoas vão encontrar, e por que confiariam? Código responde muita pergunta. Essas não estão entre elas.
A gente construiu o produto. A distribuição era o produto.