O que é MVP e como construir um produto mínimo viável de verdade

Um MVP bem feito costuma ter menos código do que você imagina. Às vezes, nenhum. A ideia de “produto mínimo viável” não é lançar uma versão capenga do sistema dos sonhos; é descobrir, com o menor esforço possível, se a hipótese por trás do produto se sustenta. Quem entende isso economiza meses. Quem não entende passa um ano construindo o “mínimo” e lança algo que ninguém pediu.

O termo ganhou força com Eric Ries e o movimento Lean Startup. Nos princípios do Lean Startup, o MVP aparece como peça do ciclo construir, medir, aprender: a versão que permite completar esse ciclo uma vez, com o mínimo de esforço. A definição de MVP da Agile Alliance reforça o ponto: o objetivo é aprendizado validado, não entrega de funcionalidades.

Este verbete integra o glossário de programação do buildbase. Como a resposta para “como construir um MVP” muda muito conforme quem pergunta, o texto está dividido por situação. Encontre a sua.

MVP para quem tem uma ideia e nenhum código ainda

Imagine uma pessoa que quer criar um app para conectar donos de pet a passeadores no bairro. A tentação é abrir o Android Studio. A pergunta que importa antes disso: donos de pet pagariam por isso?

Formas de testar sem programar o app:

• Página de espera. Uma landing page explicando o serviço, com botão “quero agendar”. Quantas pessoas clicam e deixam e-mail?
• MVP concierge. Você mesmo faz o serviço manualmente: recebe pedidos por WhatsApp, combina com dois passeadores conhecidos e cobra por Pix. O cliente recebe o valor; você aprende como é a operação.
• MVP “Mágico de Oz”. Parece automatizado para o usuário, mas por trás há uma pessoa fazendo tudo à mão.

O exemplo clássico é o do Dropbox: antes do produto funcionar para o público, os fundadores publicaram um vídeo mostrando como ele funcionaria e mediram o interesse pela lista de espera. Esse tipo de teste responde à pergunta de negócio sem uma linha de código de produção.

MVP para o dev júnior que recebeu a tarefa no trabalho

Situação comum: o gestor diz “faz um MVP do módulo de agendamento”. Aqui o MVP não é validação de mercado, é uma primeira versão enxuta de uma funcionalidade para ver se os usuários internos ou clientes vão usá-la.

Antes de abrir o editor, faça três perguntas ao gestor:

1. Qual é a hipótese? (“Achamos que clientes vão agendar sozinhos em vez de ligar.”)
2. Como vamos saber se deu certo? (Número de agendamentos pelo sistema em 30 dias, por exemplo.)
3. O que fica de fora com certeza? (Remarcação, lembrete por SMS, integração com Google Agenda.)

Com essas respostas, o escopo se desenha sozinho: tela de horários disponíveis, formulário de agendamento, lista para a recepção. Sem as respostas, cada reunião acrescenta um “já que estamos fazendo”.

MVP para quem vai empreender com um SaaS

Aqui o produto é o software, então em algum momento haverá código. O ponto é quanto e qual.

Um SaaS de emissão de orçamentos para eletricistas, por exemplo, pode começar como:

A coluna da direita não é “nunca”. É “quando os dados disserem que vale a pena”. Ferramentas no-code e low-code, ou um framework produtivo como Django ou Laravel, encurtam bastante esse caminho. Antes de escrever qualquer linha, vale a leitura sobre como validar uma startup antes de construir tudo.

MVP para quem já tem um sistema e quer lançar algo novo dentro dele

Empresas com produto rodando também fazem MVPs, só que de funcionalidades. Pense num aplicativo de delivery que quer testar assinatura mensal com frete grátis. Construir todo o sistema de planos, cobrança recorrente e regras de desconto leva semanas.

A versão mínima pode ser bem mais simples:

• Um banner oferecendo o plano para 5% dos usuários, controlado por feature flag.
• Quem clica cai num formulário de interesse, ou paga por um link de cobrança avulso.
• O frete grátis é aplicado por uma lista de IDs mantida manualmente pela equipe.

É feio por dentro? É. Mas em duas semanas a empresa sabe quantas pessoas querem o plano e se o pedido médio sobe. Se os números forem bons, aí sim se constrói a versão robusta, agora com dados para justificar o investimento. O cuidado aqui é tratar esse código como descartável de verdade: documentar que ele é temporário e removê-lo quando a versão definitiva entrar, para o experimento não virar parte permanente do sistema.

MVP, protótipo e prova de conceito são a mesma coisa?

Não. A prova de conceito responde a uma dúvida técnica (“dá para integrar com a API do banco?”) e normalmente nunca chega ao usuário. O protótipo mostra como o produto vai parecer ou funcionar, muitas vezes sem funcionar de fato (telas no Figma, por exemplo). O MVP vai para as mãos de usuários reais e mede comportamento real. Uma ideia pode passar pelos três, nessa ordem, ou pular direto para o MVP quando não há dúvida técnica relevante.

MVP para quem estuda e quer um projeto de portfólio

Para o estudante, o raciocínio de MVP resolve outro problema: o projeto pessoal que nunca termina. Aquele clone do Netflix com 14 funcionalidades planejadas e três pela metade.

Aplique a mesma lógica. Qual é a menor versão que mostra o que você quer provar? Se o objetivo é mostrar que você sabe consumir API e lidar com estado no front-end, uma lista de filmes com busca e página de detalhe já prova isso. Publicada, com README explicando as decisões, ela vale mais no portfólio do que um projeto gigante que só roda na sua máquina.

Os erros que transformam um MVP em projeto eterno

Valem para todos os perfis acima:

Medir nada

Lançar sem definir o que conta como sucesso transforma qualquer resultado em “vamos dar mais um tempo”. Escolha uma métrica antes: cadastros, uso semanal, pagamentos.

Polir o que ninguém validou

Animação de transição, tema escuro e testes de carga para 100 mil usuários num produto com 12 usuários. O “M” de mínimo foi esquecido no caminho.

Confundir mínimo com malfeito

Mínimo é pouco escopo, não pouca qualidade. Um MVP com bug no fluxo principal não valida a ideia; valida que o app trava. O que entra precisa funcionar direito, com tratamento de erro básico e dados salvos com segurança, porque usuário que perde informação no primeiro uso não volta para o segundo.

Nunca jogar fora

Às vezes o aprendizado do MVP é “a ideia não serve”. Isso é um resultado, não um fracasso. Continuar investindo porque “já gastamos muito” é o erro mais caro da lista.

O passo que vem depois de ler isso

Escreva, em uma frase, a hipótese que o seu produto ou funcionalidade precisa provar. Depois liste tudo o que você planejava construir e risque o que não ajuda a provar aquela frase. O que sobrar é o seu MVP. Se a lista ainda estiver longa, risque de novo.