Toda semana recebo mensagens de fundadores que querem "só um appzinho simples" — e quando abrem o escopo, tem autenticação OAuth com 5 providers, dashboard com 20 gráficos, integração com 3 ERPs, app mobile, e notificações push. "Dá pra fazer em um mês?"
A resposta honesta: não, isso não é um MVP. Isso é um produto de 6 meses. Mas sim, dá pra fazer um MVP de verdade em 4 semanas. A questão é saber o que cortar.
O que é um MVP (de verdade)
MVP não é "versão ruim do produto final". MVP é a menor versão do produto que entrega valor real pra um usuário real e gera dados reais sobre se vale a pena continuar investindo.
A palavra-chave é "menor". Não "mínima qualidade" — mínimo escopo. O que está no MVP precisa funcionar bem. Só tem menos coisas.
Eric Ries popularizou o conceito, mas muita gente entendeu errado. MVP não é um protótipo descartável. É a primeira versão de um produto que vai crescer. A arquitetura precisa suportar crescimento, o código precisa ser limpo, a UX precisa ser funcional. Só não precisa ter tudo.
O framework de decisão: MVP Filter
Pra cada feature que alguém sugere pro MVP, passo por 3 perguntas:
- O usuário consegue resolver o problema central sem essa feature? Se sim, fica pra v2.
- Existe uma alternativa manual ou simplificada? Se sim, use a alternativa no MVP.
- Essa feature gera dados que validam a hipótese de negócio? Se não, não é prioridade.
Esse filtro elimina 60-70% das features que parecem essenciais. E o melhor: ninguém reclama, porque o que sobra funciona bem.
O que sempre fica no MVP
Depois de construir mais de 20 MVPs nos últimos anos, identifiquei o core que quase todo SaaS precisa ter desde o dia 1:
Autenticação básica: login com email e senha. Só. Nada de OAuth com Google, GitHub, Apple. Isso pode entrar na semana 5.
Uma ação central: o produto precisa fazer UMA coisa bem. Se é um SaaS de propostas, o usuário precisa conseguir criar e enviar uma proposta. O resto é contexto.
Feedback visual: o usuário precisa saber que a ação funcionou. Loading states, confirmações, mensagens de erro claras. Isso não é "nice to have" — é funcionalidade básica.
Responsividade: funcionar em celular. Não precisa ser perfeito, mas precisa ser usável. 60% do tráfego vem de mobile.
Deploy em produção: URL real, HTTPS, domínio próprio. Nada de "vou te mandar o link do localhost". Isso parece óbvio mas muitos protótipos nunca saem da máquina do dev.
O que sempre corto do MVP
Essas são as features que mais geram discussão — e que quase nunca fazem diferença no MVP:
Dashboard com múltiplos gráficos: no MVP, um contador simples ("você tem 15 propostas ativas") resolve. Gráficos complexos ficam pra quando tiver dados suficientes pra eles fazerem sentido.
Sistema de permissões elaborado: no MVP, tem admin e tem usuário. Roles granulares (editor, viewer, manager, billing) ficam pra quando tiver clientes pedindo.
Notificações push/email elaboradas: no MVP, um email simples de confirmação basta. Sequências de onboarding, digest semanal, alertas configuráveis — tudo pra v2.
Integração com múltiplos serviços: no MVP, integre com UM serviço que é essencial. Os outros podem ser importação manual via CSV ou entrada manual.
App mobile nativo: no MVP, o site responsivo é o "app". Se precisar presença mobile, PWA (Progressive Web App) resolve sem o custo de desenvolver em Swift e Kotlin.
Personalização visual: no MVP, uma cor, um layout. Temas, customização de logo, white-label — tudo pra depois.
Busca avançada com filtros: no MVP, busca simples por texto. Filtros por data, categoria, tags, status — pode entrar conforme os dados crescem.
Cronograma real de 4 semanas
Aqui está como divido o tempo em um MVP típico:
Semana 1 — Fundação
Dia 1-2: discovery e definição de escopo (com o fundador). Saímos com um documento de 1-2 páginas listando exatamente o que entra.
Dia 3-5: setup do projeto (Next.js + TypeScript + PostgreSQL + Tailwind), modelo de dados, autenticação, deploy do esqueleto em produção.
Entregável: o fundador acessa a URL real, consegue criar conta e logar. Ainda não faz nada, mas já está no ar.
Semana 2 — Core Feature
A funcionalidade central do produto. Todo o foco aqui. Se é um SaaS de propostas, nessa semana o usuário consegue criar, editar, visualizar e enviar uma proposta.
Entregável: demo ao vivo pro fundador. Ele usa o produto de verdade pela primeira vez.
Semana 3 — Valor + Pagamentos
Completar o fluxo de valor. Se precisa de pagamentos, integro Stripe (checkout + webhook). Se precisa de dashboard, monto a versão simplificada.
Entregável: o produto funciona end-to-end. Alguém poderia pagar e usar.
Semana 4 — Polish + Launch
Testes manuais, correções de UX, ajustes de responsividade, SEO básico, configuração de analytics (Vercel Analytics ou Plausible), documentação mínima.
Entregável: produto em produção, pronto pra receber os primeiros usuários reais.
Erros comuns que atrasam o MVP
Tentar agradar todo mundo: o MVP não é pra todos os possíveis usuários. É pra um segmento específico. Se você está tentando atender pequenas empresas E corporações E freelancers, seu MVP vai servir pra ninguém.
Refatorar antes de validar: vi fundadores quererem reescrever o código na semana 2 porque "não ficou do jeito ideal". O código do MVP não precisa ser perfeito — precisa funcionar e ser extensível. Refatoração vem depois da validação.
Comparar com produtos maduros: o Notion levou 4 anos pra chegar onde está. O Slack foi reescrito 3 vezes. Seu MVP não precisa competir com eles na v1.
Não definir métricas de sucesso: antes de lançar, defina o que significa "deu certo". 10 usuários ativos? 3 clientes pagantes? 100 cadastros? Sem meta, você nunca sabe se o MVP validou ou não.
O que acontece depois do MVP
Se o MVP validou (pessoas usam e/ou pagam), o próximo passo é iterar baseado em dados:
Mês 2: adicionar as 2-3 features mais pedidas pelos primeiros usuários.
Mês 3: otimizar onboarding e retenção. Onde as pessoas travam? Onde desistem?
Mês 4-6: escalar. Mais integrações, mais features, mais marketing.
Se o MVP não validou, o custo foi baixo o suficiente pra pivotar ou tentar outra ideia. Esse é o ponto: MVP não é sobre construir barato — é sobre aprender rápido.
Quer construir seu MVP em 4 semanas?
Se você tem uma ideia que quer validar rápido, podemos conversar. Em 15 minutos, analiso seu caso, sugiro o que entra no MVP e o que fica pra depois, e te passo uma estimativa de prazo e custo. Agende em andersdev.com.br — sem compromisso.