Porque o Lean Startup é a pedra de Rosetta da Betacode
Começámos com uma ideia, um protótipo e muitas suposições. A nossa primeira startup não se tornou um unicórnio, mas ensinou-nos a construir em incerteza, a matar más ideias depressa e a ouvir o mercado.
Pedro GorrãoCo-Founder & CEO · 10 minO que aprendemos com a Wishmood
A Wishmood era uma app de entregas on-demand para praias, eventos ao ar livre e sítios onde as apps tradicionais não chegavam: comida entregue na espreguiçadeira, no piquenique ou na tenda do festival. A ideia vinha de uma observação real. Quem estava na praia queria comida, e os restaurantes próximos não tinham um canal digital.
Construímos depressa: app, onboarding de restaurantes, logística e pagamentos. Mas percebemos que entregar não é o mesmo que aprender.
- Assumimos procura durante todo o ano, e ela era fortemente sazonal.
- Construímos funcionalidades antes de saber se os restaurantes aguentavam as horas de ponta.
- Otimizámos a app antes de provar que a economia unitária funcionava.
- Nas entrevistas, as pessoas adoravam a ideia. O uso real contava outra história.
"As pessoas querem isto" e "as pessoas pagam o suficiente para isto ser um negócio" são afirmações muito diferentes.
De fundadores a facilitadores
Em 2016 fundámos a Betacode com uma pergunta: se os métodos lean nos ajudaram a aprender mais depressa, podiam ajudar outras empresas a fazer o mesmo? Hoje isso está em tudo o que fazemos: no desenvolvimento de MVPs, na consultoria técnica centrada no que construir primeiro e na Betacode Ventures, onde investimos a nossa equipa e deixamos o mercado decidir.
O que é lean startup, na prática
- Construir: lançar a versão mais pequena que testa a suposição mais arriscada.
- Medir: recolher dados de utilizadores reais, não opiniões de reuniões.
- Aprender: decidir se persiste, pivota ou para.
Como o aplicamos
Startups: defina a suposição mais arriscada antes de programar, quase sempre "alguém vai pagar?". Lance com um fluxo principal, não com uma matriz de funcionalidades, e fale com utilizadores todas as semanas.
Empresas tecnológicas: valide novas linhas de produto com protótipos antes de comprometer uma equipa durante seis meses, e meça resultados (retenção, receita, tickets de suporte), não output.
Empresas tradicionais: comece pelo problema de negócio, não por uma lista de desejos tecnológicos. Faça um piloto num departamento e mantenha os sistemas antigos a funcionar enquanto o novo prova o seu valor.
Os erros que vemos repetidamente
- Construir às escondidas: seis meses isolados e um lançamento que ninguém pediu.
- Fábrica de funcionalidades: lançar sem parar sem ver se o uso ou a receita mudaram.
- Arquitetura perfeita: meses de infraestrutura antes de um utilizador tocar no produto.
- Especificação por comité: 50 páginas escritas por quem não vai usar o software.
- Custo afundado: continuar porque "já investimos tanto".
Porque continua a importar em 2026
A IA escreve código mais depressa e a infraestrutura cloud aparece em minutos. O custo de construir caiu. O custo de construir a coisa errada não, e talvez tenha subido, porque hoje é possível lançar más ideias mais depressa do que nunca.
Qual é a suposição mais arriscada? Qual é a coisa mais pequena que a testa? O que dizem os dados? Persistimos ou pivotamos? É esta a nossa pedra de Rosetta.