MVP (Minimum Viable Product, ou produto mínimo viável) é a menor versão de um produto capaz de ser usada por clientes reais e gerar aprendizado sobre o negócio. Não é um rascunho nem uma promessa: é software funcionando, colocado na mão de quem tem o problema que você quer resolver. O objetivo não é lançar rápido por lançar — é descobrir, com o menor investimento possível, se a sua hipótese de produto se sustenta antes de comprometer meses de desenvolvimento e um orçamento inteiro.
O termo nasceu na cultura lean e virou jargão. No caminho, perdeu precisão: hoje chamam de MVP qualquer coisa, de apresentação de slides a produto completo lançado com pressa e sem teste. Este artigo devolve o corte original ao conceito e mostra como aplicá-lo em software de verdade — com escopo definido, métricas simples, estimativas de prazo e custo, e um caminho de evolução que não exige jogar o código fora depois.
O que um MVP não é
O erro mais comum é confundir MVP com protótipo descartável. Protótipo é um artefato de design: telas navegáveis, sem código de verdade por trás, feitas para testar entendimento e fluxo. Ele tem valor — mas ninguém opera um negócio em cima de um protótipo. MVP é produto: tem banco de dados, autenticação, deploy, usuário logando de manhã e reclamando quando algo quebra. Se ninguém consegue usar de verdade, não é mínimo viável; é só mínimo.
O segundo erro é o oposto: tratar o MVP como um produto completo capado na última hora. A equipe planeja a plataforma inteira, o orçamento aperta, e o corte acontece por conveniência — some o que dava trabalho, fica o que estava pronto. O resultado é um produto incoerente, que não resolve nenhum problema por inteiro. O corte do MVP não é sobre fazer menos: é sobre escolher qual problema único será resolvido por completo, e adiar todo o resto de forma deliberada.
Também não é sinônimo de baixa qualidade. Um MVP pode (e deve) ter escopo pequeno, mas o que entra precisa funcionar bem: cadastro que não perde dados, pagamento que não falha, tela que carrega rápido. O usuário não sabe que aquilo é um MVP — ele só sabe se o produto resolveu ou não o problema dele.
Como definir o corte de escopo do produto mínimo viável
O escopo de um MVP se define de trás para frente: primeiro a hipótese, depois as funcionalidades. Escreva em uma frase o que você precisa provar — por exemplo, “clínicas pequenas pagariam por agendamento online com cobrança automática”. Tudo que não ajuda a provar essa frase fica fora, por melhor que pareça. Um roteiro prático:
- Formule a hipótese central em uma frase testável, com público e problema explícitos.
- Mapeie a jornada mínima que prova a hipótese: do primeiro acesso até o momento de valor (o agendamento feito, o pedido entregue, o relatório gerado).
- Corte tudo que não está nessa jornada: painéis administrativos completos, personalização, integrações secundárias, apps nativos quando a web resolve.
- Substitua por processo manual o que puder ser manual no início — onboarding feito por WhatsApp e conciliação em planilha são aceitáveis num MVP.
- Defina o critério de sucesso antes de lançar: quantos usuários, fazendo o quê, em quanto tempo, para a hipótese ser considerada validada.
Como validar um MVP com usuários reais
Validação não é opinião de amigo nem elogio em demonstração. É comportamento observado: gente de fora do seu círculo usando o produto sem você do lado. Dez a trinta usuários do perfil certo dizem mais do que mil downloads de curiosos. E as métricas de um MVP devem ser poucas e honestas:
- Ativação: dos que se cadastraram, quantos chegaram ao momento de valor pelo menos uma vez?
- Retenção: quantos voltaram na semana seguinte sem você pedir? Retorno espontâneo é o sinal mais forte de problema real.
- Disposição a pagar: quantos aceitaram pagar, deixar cartão ou assinar um pré-contrato?
- Feedback qualitativo: cinco conversas de vinte minutos com usuários ativos valem mais que qualquer formulário de satisfação.
Se a hipótese envolve dinheiro, teste dinheiro. Cobrar desde o início — mesmo um valor simbólico — é o filtro mais barato que existe: separa quem tem o problema de quem só achou a ideia simpática. Um MVP gratuito valida interesse; um MVP pago valida negócio.
Quanto custa um MVP e quanto tempo faz sentido investir
Como estimativa de mercado — não orçamento —, um MVP de software web bem recortado costuma ficar entre R$ 40 mil e R$ 150 mil no Brasil, com 6 a 12 semanas de desenvolvimento. Abaixo disso, em geral o que se compra é um protótipo ou um template adaptado; muito acima, provavelmente o escopo deixou de ser mínimo. Os fatores que mais movem esse número são integrações (pagamento, sistemas externos), necessidade de app nativo e requisitos de conformidade. Detalhamos essas variáveis em quanto custa desenvolver um software.
A regra de bolso mais útil é temporal: se o plano do MVP passa de três a quatro meses, o corte está errado. Cada mês a mais de desenvolvimento é um mês a menos de aprendizado — e aprendizado é o único produto que um MVP entrega de verdade. Melhor lançar em oito semanas e descobrir que a hipótese precisa de ajuste do que lançar em oito meses a versão perfeita da ideia errada.
Do MVP à v1 sem reescrever tudo: arquitetura evolutiva
O medo clássico — “vamos ter que jogar tudo fora depois” — só se concretiza quando o MVP é construído sem nenhuma decisão de engenharia. A alternativa não é arquitetura corporativa no dia um; é arquitetura evolutiva: um monólito modular com fronteiras de domínio claras, banco relacional bem modelado e deploy automatizado desde o primeiro commit. Custa quase nada a mais no início e muda tudo depois: quando a validação vier, você escala partes do sistema em vez de recomeçar do zero.
É assim que trabalhamos em desenvolvimento de software sob medida: React e Next.js no front, NestJS e PostgreSQL no back, Docker e deploy contínuo via Coolify. Uma stack estável e sem exotismo, em que o mesmo código do MVP evolui para a v1 — adicionando módulos, não reescrevendo fundações. Em mais de 40 produtos e integrações colocados em produção ao longo de 8+ anos, o padrão se repete: quem modela bem os dados no começo raramente precisa de reescrita; quem improvisa o banco paga o preço na primeira escalada.
Exemplos de MVP por setor: agendamento, saúde e varejo
Alguns recortes típicos ajudam a visualizar o tamanho certo de um primeiro produto. São exemplos genéricos de estrutura, não fórmulas prontas:
- Agendamento e serviços: agenda online, confirmação automática e cobrança no ato da reserva. Fora do corte: multiunidade, programa de fidelidade, app nativo.
- Saúde: registro estruturado de atendimentos e um painel simples para a equipe, com controle de acesso rigoroso. Fora do corte: integrações com sistemas hospitalares e telemedicina.
- Varejo: catálogo com estoque, pedido e pagamento online para uma única loja. Fora do corte: marketplace, logística própria, recomendação personalizada.
Repare no padrão: em todos os casos, o MVP resolve um fluxo inteiro para um público específico — e ignora os outros dez fluxos que a versão completa terá. Gigantes de tecnologia que hoje parecem inevitáveis começaram exatamente assim, com uma fração do produto atual servindo bem a um grupo pequeno. Se o seu MVP tende a virar um produto de assinatura, o passo seguinte natural está em como criar um SaaS.
Por onde começar
Comece pela hipótese, não pelo software: uma frase testável, uma jornada mínima, um critério de sucesso com prazo. Com isso definido, o desenvolvimento vira execução — semanas, não meses. Sem isso, nenhuma tecnologia salva o projeto.
Se quiser ajuda para transformar a ideia em um escopo de MVP com estimativa honesta de prazo e investimento, fale com a engenharia. A primeira conversa é um discovery curto: saímos dela com a hipótese clara, o corte proposto e um caminho de execução — antes de qualquer linha de código.