Quando você já foi o cliente, você programa diferente. O que a Lumethros me deu que nenhum tutorial ensina — e como isso mudou a forma como penso sobre software.
Em 2024, fundei uma agência de marketing digital. Em 2026, estou construindo CRMs, plataformas de gamificação e sistemas de indicação de leads como engenheiro.
Não é uma história de pivô. As duas coisas me formaram — e eu não seria o engenheiro que sou hoje sem ter sido o founder que fui antes.
Esse post não é sobre marketing. É sobre o que acontece com a sua forma de pensar software quando você já esteve do outro lado da mesa.
A Lumethros
A Lumethros nasceu de uma observação simples: a maioria das agências de marketing entrega relatórios bonitos mas não consegue conectar o trabalho delas ao resultado financeiro do cliente. Eu queria fazer diferente — marketing que aparece no faturamento, não só no alcance.
Atendi clientes reais: Portal Gouveia, Axxos Tecnologia, Drika Papelaria, Buski, entre outros. Cuidei de tudo — captação, proposta, entrega, cobrança, retenção. Fiz tráfego pago, branding, identidade visual, estratégia de conteúdo.
E, como não poderia deixar de ser, construí toda a infraestrutura técnica da agência eu mesmo. O site, o portal de conteúdo, as automações internas.
Quando a Axxos me trouxe para dentro como engenheiro, eu já era cliente deles. Já tinha dependido de um sistema de vendas para operar meu negócio. Já sabia o que dói quando o sistema não funciona.
Lição 1 — O sistema existe para o usuário, não para o engenheiro
Quando você é founder, você usa o sistema que alguém construiu para você. E você percebe, na prática, que a experiência de uso importa mais do que a elegância técnica por baixo.
Na Lumethros, usei dezenas de ferramentas. CRMs, plataformas de automação, dashboards de tráfego. Algumas eram tecnicamente impressionantes e completamente inúteis na prática — lentas demais, confusas demais, cheias de funcionalidades que ninguém pedia e sem a única coisa que eu precisava.
Quando fui construir o Axxos CRM, essa memória muscular estava lá.
Antes de escrever uma linha de código, passei tempo com o time comercial entendendo o fluxo real deles. Não o fluxo ideal, não o fluxo descrito no documento de requisitos — o fluxo real, com os atalhos, os workarounds, as planilhas paralelas que existiam porque o sistema anterior não dava conta.
O pipeline estilo Kanban que implementei não foi uma decisão técnica. Foi uma decisão de uso — o time conseguia enxergar o funil inteiro numa tela só, sem navegar entre menus. A decisão técnica veio depois, para suportar essa necessidade.
O que mudou no meu código: eu faço perguntas antes de arquitetar. "Quem vai usar isso?" e "em que contexto?" são perguntas de produto, não de engenharia — mas a resposta delas define a arquitetura.
Lição 2 — Métrica que não muda decisão não é métrica
Como founder, aprendi a diferença entre vanity metrics e métricas que importam. Alcance no Instagram não paga boleto. O que importa é CAC, LTV, taxa de conversão, ciclo de venda.
Essa mentalidade mudou como eu construo dashboards e relatórios.
Quando fui projetar os relatórios do Axxos CRM, a primeira pergunta que fiz foi: "que decisão esse número vai ajudar a tomar?" Se a resposta fosse "nenhuma", o número não entrava no dashboard principal.
A maioria dos dashboards que já vi tem o problema oposto: muita informação, pouca clareza. Gráficos que existem porque são bonitos, não porque guiam ação.
No CRM, os relatórios principais são três: taxa de conversão por etapa (onde os leads morrem?), tempo médio por etapa (onde eles ficam presos?) e origem dos leads (de onde vêm os melhores clientes?). Tudo o mais é secundário, acessível mas fora da tela principal.
Esse recorte não veio de um framework de produto. Veio de ter operado um negócio e saber o que o gestor olha toda manhã.
O que mudou no meu código: quando alguém me pede um relatório, eu pergunto o que vai mudar com base nele. Às vezes a resposta revela que o relatório pedido não é o que a pessoa precisa.
Lição 3 — Velocidade de entrega é uma feature
Quando você tem uma agência, o cliente não quer saber da sua arquitetura. Ele quer o resultado. Rápido. Ontem.
Aprendi a separar o que precisa ser perfeito do que precisa ser funcional. Aprendi que um sistema que entrega 80% do valor em uma semana é, na maioria dos casos, mais valioso do que um sistema que entrega 100% em dois meses — porque em dois meses o contexto mudou, a prioridade mudou, o mercado mudou.
Isso não significa entregar código ruim. Significa fazer escolhas deliberadas sobre onde investir qualidade e onde aceitar imperfeição temporária.
No Stone Destino Chile, a campanha tinha uma data de início. Não havia margem para arquitetura perfeita. Fiz escolhas que me permitiram entregar o core funcional — motor de ranking, autenticação, painel de importação — e planejei a evolução para fases seguintes. A Fase 1 foi para produção no prazo. A Fase 2 continua sendo construída com mais calma.
Um sistema em produção que resolve 80% do problema é infinitamente mais valioso do que um sistema perfeito que existe só no Notion.
O que mudou no meu código: planejo em fases desde o início. O que vai para produção primeiro? O que pode esperar? Essa pergunta não é de engenharia — é de negócio. E eu sei responder porque já estive do lado do negócio.
Lição 4 — O problema que o cliente descreve raramente é o problema real
Na Lumethros, aprendi a ouvir o que o cliente não fala.
Cliente diz: "quero mais seguidores no Instagram." Problema real: as vendas estão caindo e ele não sabe por quê.
Cliente diz: "quero um site novo." Problema real: o site atual não converte e ele atribui isso ao design, mas o problema é o texto.
Essa habilidade de ir além do pedido explícito para entender a dor real é uma das mais valiosas que um founder desenvolve — e é diretamente transferível para engenharia.
Quando o time da Axxos descreveu o problema do Axxos Indica, o pedido inicial era "uma plataforma para parceiros cadastrarem indicações." Mas o problema real era diferente: indicações aconteciam, mas ninguém sabia quantas, quem tinha indicado, qual tinha convertido, e o parceiro não tinha visibilidade nenhuma — então parava de indicar.
O sistema que construí resolveu o problema real: rastreamento completo, visibilidade para o parceiro em tempo real, gamificação para manter o engajamento. Se eu tivesse construído só "um formulário de cadastro de indicações", teria resolvido o pedido e ignorado o problema.
O que mudou no meu código: quando recebo um requisito, minha primeira pergunta é "por quê?" — não para questionar a decisão, mas para entender o problema por trás dela. A solução técnica que emerge dessa conversa é quase sempre diferente — e melhor — do que a solução que o pedido inicial sugeria.
Lição 5 — Você é responsável pelo resultado, não pela entrega
Essa foi a mais difícil de aprender e a que mais mudou como eu penso sobre o meu trabalho.
Quando você é founder, não há como separar "fiz minha parte" do resultado final. Se a campanha não converteu, não importa que o criativo estava impecável — o resultado não veio. Você é responsável pelo todo, não pela sua parcela.
A maioria dos engenheiros opera de forma diferente: "entreguei o que foi especificado, funcionou conforme o requisito." E tecnicamente isso é correto. Mas é uma postura que deixa dinheiro na mesa — e oportunidades de crescimento também.
Quando construí o CRM da Axxos, eu acompanhei os números depois do deploy. Taxa de conversão subiu? O time comercial estava usando o sistema? Onde estava travando? Essa postura de acompanhar o impacto real do que foi construído não era uma obrigação do meu cargo — era um hábito que trouxe da Lumethros.
E foi exatamente esse acompanhamento que me permitiu iterar o sistema de forma que realmente importava, não baseado em suposições, mas em comportamento real do time usando a ferramenta.
O que mudou no meu código: o deploy não é o fim. É o começo da parte mais importante — entender se o sistema está resolvendo o problema que foi desenhado para resolver.
O que fundar não substitui
Seria desonesto não dizer: a experiência de founder tem limites.
Ela não substitui profundidade técnica. Não substitui entender de algoritmos, de modelagem de dados, de segurança, de performance. O atalho cognitivo de "pensar como o usuário" não resolve um problema de N+1 queries ou uma race condition em produção.
O que ela faz é contextualizar. Ela me dá clareza sobre o porquê de cada sistema que construo. E quando você sabe o porquê de verdade — não o porquê do requisito, mas o porquê do negócio — você toma decisões técnicas melhores.
Um engenheiro que entende o negócio consegue questionar um requisito ruim antes de implementá-lo. Consegue propor uma solução mais simples que resolve o mesmo problema. Consegue priorizar o que importa quando o prazo aperta.
Essas não são habilidades técnicas. São habilidades de contexto. E contexto vem de estar do outro lado da mesa pelo menos uma vez.
Para quem está pensando em empreender antes de se especializar
Não é uma recomendação, é uma observação: as duas coisas se alimentam.
Empreender me fez um engenheiro melhor. Engenharia me teria feito um founder melhor se eu tivesse mais dela antes de começar. Não é uma sequência — é um ciclo.
Se você está no começo da carreira e tem a oportunidade de operar um negócio, mesmo que pequeno, mesmo que como freelancer com dois clientes — faça isso. Não pelo dinheiro, não pelo título. Pela perspectiva que você não consegue de outra forma.
E se você já é engenheiro e nunca esteve do lado do cliente: vá conversar com um. Não para coletar requisitos. Para entender como ele usa o sistema que você construiu, o que trava, o que ele resolve na mão porque o sistema não dá conta, o que ele ama mas nunca comentou.
Essa conversa vai mudar como você escreve código na semana seguinte.