MVP: o que é, quanto custa e o erro de construir demais

Este artigo é um guia completo: o que um MVP é (e o que ele não é), por que quase todo fundador constrói demais, quanto custa, como decidir o que entra na primeira versão e quando lançar. A espinha dorsal vem de um livro que recomendamos a todo cliente que chega com uma ideia debaixo do braço: Apaixone-se pelo problema, não pela solução, de Uri Levine — cofundador do Waze, o app de navegação com mais de 700 milhões de usuários que o Google comprou em 2013 por US$ 1,15 bilhão. Levine construiu dois unicórnios repetindo um mesmo princípio, que dá título ao livro e resume tudo que você precisa saber antes de gastar um real com desenvolvimento.

O que é (e o que NÃO é) um MVP?

O termo vem do movimento Lean Startup, de Eric Ries: o MVP existe para "começar o processo de aprendizado o mais rápido possível". Leia de novo, porque é aqui que o mercado inteiro erra: o MVP é um instrumento de aprendizado, não um produto pequeno. Ele existe para responder uma pergunta — "alguém tem esse problema de verdade e usaria isso para resolvê-lo?" — pelo menor custo possível.

O que um MVP não é:

• Não é a versão capada do sonho. "Vamos fazer tudo, só que mais simples" não é MVP — é o produto inteiro com acabamento pior. MVP é escolher uma hipótese e testá-la.
• Não é protótipo. Protótipo é simulação: telas navegáveis, sem sistema por trás, para validar entendimento antes de construir. MVP é produto de verdade, em produção, na mão de usuário real. O protótipo responde "é isso que você quer?"; o MVP responde "alguém usa e paga?".
• Não é desculpa para entregar porcaria. Mínimo se refere ao escopo, não à qualidade. Um MVP com três funções que funcionam vale mais que um produto com trinta que quebram. O "V" de viável é tão obrigatório quanto o "M" de mínimo.
• Não é a versão final. Se o MVP validar a hipótese, ele evolui — e boa parte dele será reescrita com o que se aprendeu. Isso não é desperdício: é o objetivo.

Por que todo mundo constrói demais?

Porque fundador se apaixona pela solução. É o padrão que Uri Levine passa 400 páginas desmontando: a ideia vira um filho, cada feature imaginada parece "essencial", e questionar o escopo soa como questionar o sonho. A prescrição do livro está no título — apaixone-se pelo problema, não pela solução. O problema é o que o mercado tem; a solução é só o seu palpite atual de como resolvê-lo. Quem ama o problema corta features sem dor, porque o compromisso é resolver, não construir. Quem ama a solução defende cada tela como se fosse cláusula pétrea.

O custo desse apego tem estatística. O levantamento clássico da CB Insights sobre por que startups morrem aponta a falta de encaixe entre produto e mercado como a causa central: na análise mais recente, com 431 startups que fecharam, 43% falharam por product-market fit ruim — e cerca de dois terços dessas nunca chegaram a encontrar um mercado. Traduzindo: quase metade das startups morre construindo, com capricho, algo que ninguém precisava. Elas não falharam por construir de menos. Falharam por construir demais na direção errada — e descobrir tarde.

Há ainda um terceiro motor do excesso, mais mundano: medo de lançar simples. A resposta canônica é a frase de Reid Hoffman, fundador do LinkedIn, que ele mesmo transformou em ensaio:

"Se você não tem vergonha da primeira versão do seu produto, você lançou tarde demais."

Reid Hoffman — cofundador do LinkedIn

A vergonha da primeira versão não é um acidente do processo — é o sinal de que você priorizou aprender rápido em vez de parecer pronto. O Waze do lançamento, conta Levine, tinha mapas ruins a ponto de motorista desistir no meio do trajeto. Lançaram assim mesmo, porque só usuário real dirigindo gerava os dados que consertavam o mapa. A primeira versão vergonhosa era, literalmente, o único caminho até a versão excelente.

Quanto custa um MVP no Brasil em 2026?

A faixa de referência da Rhodium, baseada em mais de 100 projetos entregues desde 2016: R$ 25 mil a R$ 80 mil, em 4 a 8 semanas, para um MVP de escopo fechado desenvolvido por equipe sênior — incluindo arquitetura, desenvolvimento, testes, deploy em produção e documentação. O que move o número dentro da faixa não é a quantidade de telas: é o número de integrações, os perfis de usuário e as exigências de produção (pagamento, nota fiscal, operação 24/7). Detalhamos a composição do preço, os custos escondidos e os modelos de contratação no artigo quanto custa desenvolver um aplicativo — vale ler junto com este.

Dois avisos de quem está do lado de dentro:

• Abaixo de R$ 25 mil, você geralmente está comprando template adaptado, projeto sem responsável pela operação depois da entrega, ou um escopo tão cortado que nem testa a hipótese — o que transforma o MVP em desperdício mínimo viável.
• Acima de R$ 80 mil "de MVP", desconfie do escopo, não do fornecedor: quase sempre há um produto completo se escondendo atrás da sigla. MVP de R$ 200 mil é oxímoro — se custa isso, ou o projeto tem hardware/integrações pesadas (e aí é outra categoria), ou alguém não cortou o que devia.

E a matemática que justifica tudo: se o MVP de R$ 40 mil provar que o mercado não quer o produto, ele acabou de economizar os R$ 300 mil da versão grande — mais os dois anos de vida que iriam junto. Levine chama isso de falhar rápido: o custo do MVP não se compara ao custo do produto; se compara ao custo de estar errado sem saber.

Como decidir o que entra na primeira versão?

O método que usamos nas sessões de diagnóstico, em três passos:

1. Escreva a hipótese — uma só

Complete a frase: "Acredito que [público] tem o problema [X] e pagaria por [solução] para resolvê-lo." Se a frase tem dois "e" demais, você tem duas hipóteses — e dois MVPs disputando o mesmo orçamento. Escolha a mais arriscada: a que, se estiver errada, derruba o negócio inteiro. É ela que o MVP precisa testar primeiro.

2. Ache o menor teste possível

Para cada funcionalidade imaginada, a pergunta não é "seria útil?" (tudo parece útil) — é "o teste da hipótese falha sem isso?". Se não falha, corta. Na prática, os cortes se repetem de projeto em projeto:

• Login social, recuperação de senha elaborada, onboarding animado → e-mail e senha resolvem. Ninguém deixa de validar uma hipótese por falta de "entrar com Google".
• Painel administrativo completo → uma planilha e acesso ao banco resolvem os primeiros meses. O painel entra quando houver operação que o justifique.
• App nativo nas duas lojas → um web app responsivo testa a mesma hipótese sem o custo e o prazo das lojas. Nativo entra quando o produto precisar de algo que só o nativo dá.
• Integração automática com tudo → nos primeiros 50 clientes, uma pessoa fazendo o processo manualmente atrás da cortina custa menos que a integração — e ainda ensina o que a automação precisa fazer. (Quando chegar a hora de automatizar de verdade, só se automatiza o que se conhece.)
• Configurações, temas, preferências → decida você. Produto mínimo tem opinião; quem oferece 15 opções está terceirizando o design pro usuário.

3. Defina o que vai medir antes de construir

MVP sem métrica é opinião com deploy. Antes da primeira linha de código, escreva o que confirma a hipótese: "X% dos que testarem voltam na semana seguinte", "Y de cada 10 aceitam pagar R$ Z". Sem isso, o lançamento vira teste de vaidade — e vaidade sempre passa.

Bônus: às vezes o menor teste nem é software

Antes de gastar R$ 25 mil no MVP, pergunte se a hipótese não pode ser testada por ainda menos. Três formatos que usamos antes de recomendar qualquer desenvolvimento:

• Venda antes de construir. Uma página descrevendo o produto, um botão de compra (ou lista de espera com sinal pago) e tráfego apontado pra ela. Se ninguém clica em pagar por algo que ainda não existe, o MVP inteiro acabou de custar o preço de uma landing page. Cuidado só com a régua: cadastro de e-mail é curiosidade; cartão na mesa é demanda.
• Concierge. Entregue o serviço manualmente para os primeiros clientes, como se o sistema existisse — você por trás da cortina, fazendo o que o software faria. Além de validar a demanda, é o melhor levantamento de requisitos que existe: depois de atender 20 clientes na mão, você sabe exatamente o que automatizar (e o que era invenção).
• Piloto com planilha e WhatsApp. Boa parte dos "apps" que nos chegam pode ter a primeira versão operada com ferramentas que o cliente já tem. Se o processo funciona no improviso e a demanda aparece, o software entra pra escalar o que já se provou — a ordem certa.

Se a hipótese sobreviver a um desses testes, aí sim o MVP de software deixa de ser aposta e vira o próximo passo lógico — construído sobre demanda demonstrada, não sobre palpite. É a forma mais barata de ficar fora da estatística de quem constrói primeiro e procura o mercado depois.

Um padrão que vemos com frequência nas nossas sessões de diagnóstico: o fundador chega com dezenas de telas desenhadas — e, depois de passar cada uma pelo filtro da hipótese, sai com meia dúzia. As outras não morreram: foram para a fila do "depois que validar". A diferença é que agora o projeto cabe no orçamento, no prazo e no risco que a fase do negócio comporta. Esse corte, aliás, é o trabalho mais valioso da sessão — mais que qualquer decisão de tecnologia.

Quando o MVP está pronto para lançar?

Antes do que seu estômago aceita. Os critérios objetivos são três:

• Ele testa a hipótese de ponta a ponta — o usuário consegue percorrer o fluxo central e extrair o valor prometido, mesmo que sem polimento.
• Ele mede — os eventos que confirmam ou derrubam a hipótese estão instrumentados.
• Ele aguenta ser usado — não precisa escalar para 100 mil usuários; precisa não perder os dados dos primeiros 100.

Se os três estão de pé e você ainda quer "só mais uma featurezinha" antes de mostrar pro mundo, releia o Hoffman. O tempo entre "poderia lançar" e "lancei" é desperdício puro: são semanas em que usuários reais já poderiam estar te ensinando — e não estão.

O que acontece depois do MVP?

Três destinos, todos bons se chegarem rápido:

• A hipótese confirmou → o MVP vira produto: as features da fila voltam (agora filtradas por uso real, não por palpite), a arquitetura evolui para escala e entra operação séria — monitoramento, suporte, evolução contínua.
• A hipótese quase confirmou → pivô. O Waze mesmo nasceu de ajustes sucessivos sobre o mesmo problema (fugir do trânsito). Pivotar não é recomeçar do zero: é reaproveitar o aprendizado — e boa parte do código — apontando para a variação da hipótese que os dados sugeriram.
• A hipótese falhou → parabéns, sério. Você descobriu com R$ 40 mil o que a maioria descobre com R$ 400 mil e três anos. Levine é taxativo: falhar rápido é parte do método, não acidente de percurso. O aprendizado fica; o próximo tiro sai mais calibrado.

O que não pode acontecer depois do MVP é o mais comum: ele ficar no ar, sem métrica olhada, sem decisão tomada, enquanto o fundador já desenha a "versão 2". MVP é experimento — experimento tem prazo pra ler o resultado.

Perguntas frequentes