
Como lancei meu primeiro produto próprio — e o que aprendi no processo
Em 2022 comecei o MEXP como produto paralelo. Não era só código — era entender o que é vender software, não só construir. Os dois são completamente diferentes.
Em 2022 comecei a construir o MEXP como produto próprio.
Não como freelance — como produto. A diferença é fundamental: freelance você entrega projeto para cliente, recebe, acabou. Produto você constrói, mantém, vende recorrentemente, e o código que você escreveu em março ainda está rodando em novembro com clientes dependendo dele.
Tinha construído software para clientes nos três anos anteriores. Construir produto próprio era diferente de formas que não antecipei.
O primeiro choque: cliente de produto não é cliente de projeto.
Em projeto, o cliente sabe o que quer (mais ou menos). Você constrói. Entrega. Ele aceitou ou não aceita.
Em produto, o cliente não sabe o que quer — sabe o problema que tem. Você tem que descobrir o problema, construir a solução, e descobrir se a solução resolve o problema de forma que o cliente pague por ela.
São três coisas diferentes. Erro comum é pular para a terceira sem passar pela primeira e segunda.
O que aprendi sobre validação de mercado antes de construir:
Não tem jeito de validar completamente antes de lançar. Mas tem jeito de reduzir o risco de construir a coisa errada.
O que eu fiz: falei com cinco donos de concessionárias antes de escrever linha de código. Perguntei: "quais são os três maiores problemas no seu processo de vendas hoje?"
Não falei sobre software. Não falei sobre IA. Só ouvi.
Dois dos cinco falaram do mesmo problema sem que eu sugerisse: leads que chegam pelo WhatsApp e pelo site ao mesmo tempo, e o time perde track de qual foi atendido, qual está aguardando, qual já comprou.
Esse foi o problema que o MEXP resolveu primeiro.
O segundo choque: construir é a parte mais fácil.
Escrevi o MVP em três semanas. Deployei. Rodava.
Fazer as pessoas usarem levou três meses.
Não porque o produto era ruim. Porque usar software novo exige confiança. Confiança exige que o dev (eu) apareça para suporte, para treinamento, para "pode me ajudar a configurar isso?", para ajustar quando o workflow deles era diferente do que eu tinha imaginado.
O produto não é só o código. É o suporte, o onboarding, a confiança de que quando der problema alguém vai aparecer.
O que mudou na minha carreira depois do MEXP:
Parei de pensar só em "como construir" e comecei a pensar em "quem vai usar, como vai usar, e por que vai pagar".
Todo sistema que construo hoje — para clientes, para o time, para mim mesmo — passa pela pergunta: "quem é o usuário, qual problema ele tem, e essa solução resolve de forma que ele prefira ao que faz hoje?"
Essa pergunta transforma como você projeta software. E não aprendi isso em livro — aprendi tentando vender produto que ninguém usava até entender por que não usavam.