Um gestor de uma empresa em Curitiba fechou um contrato de R$ 38 mil com um freelancer para construir um MVP em quatro meses. No terceiro mês, o freelancer sumiu. Para terminar o sistema, a empresa gastou mais R$ 22 mil com outro profissional refazendo partes do que foi entregue. O custo final foi R$ 60 mil. O prazo se estendeu a onze meses. E o produto que chegou ao mercado nunca foi testado como hipótese. Foi entregue como sistema pronto, com funcionalidades que ninguém confirmou que alguém precisava.
Esse caso não é exceção. É o padrão.
O que é MVP de verdade: e o que sua software house provavelmente está chamando de MVP
Eric Ries definiu MVP como "a versão de um novo produto que permite à equipe coletar o máximo de aprendizado validado sobre clientes com o menor esforço possível." A definição tem três partes obrigatórias: aprendizado validado, clientes reais, menor esforço possível.
O caso acima mostra o padrão: 20 funcionalidades divididas em fases, sem hipótese de validação, sem critério de encerramento. Isso não tem nenhuma das três partes da definição de Ries.
Uma proposta que lista 20 funcionalidades, divide o projeto em "fase 1", "fase 2" e "fase 3", e não menciona uma única hipótese de validação não é MVP. É um projeto completo fatiado em pedaços menores para parecer mais palatável na assinatura do contrato.
A diferença prática está no critério de fracasso. Um MVP real tem condição de encerramento: se a hipótese não se confirmar após o teste com usuários reais, o projeto para, ou muda de direção completamente. Um "MVP" disfarçado de fase 1 nunca para. Ele só avança para a próxima fase.
Entre 2015 e setembro de 2024, 8.258 startups brasileiras encerraram atividades. Quase metade das 16.936 que existiam no período. A causa predominante não foi falta de dinheiro. Foi falta de product-market fit, exatamente o problema que um MVP bem executado deveria prevenir. Quando o MVP é construído como projeto completo, ele não valida nada. Só gasta dinheiro antes de gastar mais dinheiro.
Por que toda software house ama o termo MVP (e o que isso significa para o seu bolso)
O Brasil tem 41.613 empresas atuando em software e serviços. Com esse volume de fornecedores, a concorrência por clientes é brutal. O termo MVP virou ferramenta de venda porque resolve um problema comercial real para a software house: reduz a fricção na assinatura do contrato.
O cliente ouve "MVP" e pensa: menos dinheiro comprometido, decisão mais inteligente do que comprar tudo de uma vez. A software house sabe disso. É por isso que o termo está em toda proposta.
O problema está no que fica em aberto. Quando uma proposta não define hipótese de validação, não estabelece critério mensurável de sucesso e não prevê o que acontece se o produto não validar, o escopo fica aberto. E escopo aberto significa que qualquer funcionalidade nova que surgir durante o projeto pode ser adicionada sem questionamento. É o scope creep embutido no modelo contratual.
Os dados mostram o resultado: mais de 50% dos projetos de software sofrem expansão não controlada de escopo. Esse número cresceu de 43% para 52% ao longo de sete anos. O custo total pode chegar a quatro vezes o valor original. E 92% dos projetos que falham têm gestão inadequada de escopo como causa raiz.
O "MVP" sem critério de encerramento não é experimento de validação. É a fase 1 de um projeto que não tem definição de fim.
5 sinais de que o seu MVP virou projeto sem fim
O prazo foi estendido mais de uma vez com justificativa técnica. Quando o atraso é explicado com linguagem técnica ("integração mais complexa do que esperado", "refatoração necessária na arquitetura") sem correlação com mudança de escopo aprovada por você, o controle saiu das suas mãos.
Funcionalidades novas aparecem como "necessárias" sem que você tenha pedido. A software house sugere adicionar algo porque "vai facilitar no futuro" ou "já que estamos nessa parte do código". Cada adição pareceu razoável. No total, o projeto dobrou de tamanho.
Você não consegue responder, em uma frase, qual hipótese o MVP está testando. Se precisar de um minuto para pensar na resposta, a proposta provavelmente nunca definiu uma hipótese. Sem hipótese, não há como saber quando o experimento termina.
O orçamento foi revisto uma vez e você aceitou. Segundo o Standish Group, 52,7% dos projetos de software ultrapassam seus orçamentos iniciais em até 189%. Uma revisão aceita sem renegociação de escopo é o precedente que autoriza a próxima.
O time da software house já fala em "fases seguintes" como inevitáveis. Quando o fornecedor planeja as fases 2 e 3 antes de terminar a fase 1, o MVP nunca foi tratado como experimento com possibilidade de encerramento. Foi tratado como entrada de um contrato mais longo.
A única pergunta que define o que entra no MVP e o que fica fora
Antes de qualquer discussão sobre funcionalidade, uma pergunta precisa estar respondida por escrito: qual hipótese este MVP está testando, e como você vai saber se ela foi confirmada ou refutada?
A resposta define tudo. Se a hipótese é "empresas de médio porte vão pagar R$ 300 por mês por uma ferramenta que automatize o fechamento financeiro mensal", o MVP precisa apenas do que permite testar essa hipótese com usuários reais. O critério de sucesso é mensurável: número de empresas que pagaram, taxa de retenção após 60 dias, receita gerada no período.
Funcionalidade que não contribui para testar essa hipótese específica fica fora. Não porque o orçamento é limitado. Porque funcionalidade fora da hipótese não gera aprendizado. Só gera custo.
Na prática, uma boa proposta de MVP cabe em uma página. Hipótese explícita. Funcionalidades que permitem testar a hipótese. Critério de sucesso mensurável. Prazo fixo. E uma cláusula que define o que acontece se a hipótese falhar: o projeto para, o escopo muda, ou a direção é revisada.
Usando o exemplo da ferramenta de fechamento financeiro: a hipótese e os critérios já estão definidos. Falta a lista de escopo. Funcionalidades IN: importação de lançamentos bancários, geração de DRE mensal, acesso para um usuário administrador. Funcionalidades OUT: integração com ERP, controle de estoque, multi-usuário, relatórios customizáveis.
Qualquer proposta que não caiba nesse formato não é MVP. É projeto completo com outro nome.
Quando o MVP foi longe demais: como identificar um produto completo camuflado de fase 1
Uma empresa narrou publicamente que economizou R$ 1,5 milhão ao construir um MVP antes de desenvolver o sistema completo: funcionalidades foram descartadas após os testes. O caso é apresentado como vitória. Mas o relato não menciona qual hipótese foi testada, qual critério de sucesso foi usado, nem o que teria acontecido se o MVP tivesse validado negativamente.
É o padrão que você precisa aprender a reconhecer: o fornecedor usa o vocabulário de MVP para comunicar velocidade e inteligência, mas o processo por trás é o de um projeto completo com prazo aberto.
Os sinais aparecem na proposta escrita, antes de qualquer reunião:
Mais de 15 funcionalidades listadas na "fase 1". Uma hipótese de validação raramente requer tantas funcionalidades para ser testada.
Ausência de critério mensurável de sucesso. Se a proposta não diz o que significa "deu certo", o sucesso nunca pode ser declarado, e o projeto não termina.
Sem cláusula de encerramento. Uma proposta de MVP que não prevê o que acontece se o produto não validar está assumindo que o produto sempre valida. Isso não é experimento. É projeto.
Divisão em fases com escopo da fase 2 já descrito. Quando o fornecedor já sabe o que vai construir na fase 2 antes de terminar a fase 1, o MVP é a entrada de um contrato maior, não um experimento isolado.
Prazo descrito como "estimado" ou "aproximado" sem gatilho de revisão definido. Prazo sem critério de revisão é prazo sem prazo.
O que exigir da software house antes de assinar qualquer contrato de MVP
Peça por escrito, antes de assinar, quatro coisas. Uma software house que trabalha com MVP de verdade não vai ter problema em responder. Uma que usa o termo como argumento de venda vai travar.
1. A hipótese de validação. Em uma frase: o que o MVP vai testar, com qual público, e em qual prazo. Se o fornecedor não conseguir escrever isso em uma frase, o MVP não está definido.
2. O critério de sucesso e de fracasso. Dois números ou condições: o que significa que a hipótese foi confirmada, e o que significa que ela foi refutada. Sem isso, o projeto não tem condição de encerramento.
3. A cláusula de encerramento. O que acontece contratualmente se a hipótese for refutada. O projeto para? O escopo é renegociado? Você paga apenas o que foi entregue até aquele ponto? Essa cláusula protege você de continuar financiando um experimento que já deu resposta.
4. A lista negativa de escopo. Quais funcionalidades estão explicitamente fora do MVP e por quê. Uma lista negativa mostra que o fornecedor pensa em escopo como escolha deliberada, não como tudo que couber no prazo disponível.
O Standish Group mede isso há décadas. A taxa de sucesso continua em 31%. O número não melhora porque o problema de escopo não é resolvido na execução, é resolvido antes de assinar.
Se a proposta que você recebeu lista mais de 15 funcionalidades, não menciona hipótese de validação e não tem critério de encerramento, você está comprando um projeto completo com prazo aberto. Antes de assinar qualquer proposta rotulada como MVP, aplique as quatro perguntas desta seção ao documento que você recebeu. Se não conseguir responder com base no que está escrito, você tem o argumento certo para exigir revisão antes de colocar dinheiro na mesa.
Se você está com uma proposta de MVP na mão, aplique o filtro do artigo antes de assinar: tem hipótese de validação em uma frase? Tem critério de encerramento? Tem lista negativa de escopo? Se faltar qualquer um dos três, você está comprando um projeto completo com prazo aberto. Antes de enviar a proposta, confira também as 23 perguntas para contratar uma empresa de desenvolvimento. A Coffe&Code Labs analisa a proposta antes da assinatura e te diz exatamente o que falta. Fale com a gente.