# MVP ou produto completo? Comece pela decisão que precisa de evidência.

> MVP ou produto completo: por onde começar?

Como separar protótipo, primeira versão operacional e produto ampliado para validar o risco certo sem publicar uma solução irresponsável.

Canonical HTML: [https://yuriqueiroz.com.br/artigos/mvp-ou-produto-completo](https://yuriqueiroz.com.br/artigos/mvp-ou-produto-completo)

Comece pela menor jornada completa capaz de testar a hipótese mais arriscada. **Isso pode ser um protótipo sem uso público ou um MVP operacional para poucos usuários; “produto completo” só deve entrar quando funções adicionais já tiverem uma razão verificável.**

O erro comum é tratar MVP como sinônimo de qualquer entrega rápida. O recorte certo depende de quem vai usar, de que risco está sendo testado e das consequências de uma falha.

## Critérios para decidir

### Qual pergunta a primeira entrega precisa responder?

Uma primeira versão útil tem uma pergunta central. Por exemplo:

- as pessoas entendem a proposta e concluem a jornada principal;
- a integração decisiva é tecnicamente viável;
- o processo reduz trabalho manual sem criar nova fila;
- existe disposição real para usar ou pagar;
- a operação consegue atender, corrigir e aprender com os primeiros usuários.

Se a equipe não consegue escrever a pergunta, a lista de funcionalidades ainda não é um escopo. É apenas um inventário de ideias.

### Protótipo, MVP operacional e produto ampliado são coisas diferentes

Um **protótipo** testa entendimento, fluxo ou viabilidade. Pode usar dados controlados, simulações e código descartável. Não deve ser apresentado como serviço pronto para o público quando ainda não trata riscos de uso real.

Um **MVP operacional** executa uma jornada completa para um público e um contexto delimitados. Precisa ter o mínimo proporcional de autenticação, persistência, tratamento de falhas, privacidade, suporte, implantação e observação necessário para esse uso.

Um **produto ampliado** adiciona jornadas, perfis, automações, escala e refinamentos porque evidências anteriores justificaram o investimento — não porque todas as ideias precisavam entrar no lançamento.

Chamar de “mínimo operacional” o que pode ser publicado com responsabilidade é uma **inferência editorial** a partir da distinção do GOV.UK entre alpha e beta. A fonte define alpha como experimentação não pública e beta como construção para uso progressivo por pessoas reais; ela não oferece uma definição universal de MVP.

### O que não pode ser adiado?

“Depois a gente corrige” só é aceitável para itens reversíveis e de baixo impacto. Não trate como opcional uma proteção necessária para o contexto, como:

- autorização para dados sensíveis;
- consistência de pagamento ou registro financeiro;
- recuperação de uma operação que pode ser repetida;
- consentimento e privacidade;
- backup de dados que não podem ser reconstruídos;
- suporte para usuários reais bloqueados no fluxo.

O mínimo é definido pelo risco, não apenas pela quantidade de telas.

### Como saber se é hora de ampliar?

Antes da primeira entrega, defina sinais que apoiam a próxima decisão: conclusão da jornada, erro que impede uso, abandono em uma etapa, demanda recorrente por uma função e capacidade de suporte.

Evite uma métrica de vaidade isolada. Aumento de cadastro não compensa um fluxo que ninguém conclui. Interesse declarado não substitui comportamento quando o objetivo é validar uso real.

## Riscos e limites

Um MVP grande demais demora a produzir aprendizado e mistura hipóteses. Quando o resultado é ruim, ninguém sabe se falharam proposta, canal, usabilidade, tecnologia ou operação.

Um MVP pequeno de forma irresponsável gera o problema oposto: coloca pessoas reais diante de falhas previsíveis e chama ausência de qualidade de “validação”. Protótipo descartável, versão privada e serviço público precisam de critérios diferentes.

Também existe um limite de linguagem. “Produto completo” não é um estado permanente: software continua mudando. O termo só ajuda quando significa que o recorte necessário para uma operação definida foi atendido e aceito.

## O que a prova relacionada sustenta — e o que não sustenta

O portfólio público descreve a Entrevista Mapeada como um produto B2C com checkout e processamento assíncrono, além de validações e caminhos de falha. Esse recorte ajuda a mostrar por que uma jornada real exige mais que a interface principal.

O case **não prova** que outro produto precisa da mesma arquitetura, do mesmo conjunto de controles ou da mesma ordem de entrega. Também não promete validação de mercado, aprovação de usuários ou resultado comercial para uma nova ideia.

## Decisão prática

Escreva o primeiro recorte em cinco linhas:

1. público inicial;
2. problema e jornada completa;
3. hipótese mais arriscada;
4. proteções mínimas exigidas pelo uso;
5. evidência que autoriza ampliar, corrigir ou interromper.

Se a dúvida ainda é de proposta ou usabilidade, comece com protótipo e pesquisa, sem publicar. Se pessoas reais precisam executar o fluxo, planeje um MVP operacional com limite explícito. Amplie somente depois de observar o que aconteceu.

## Fontes oficiais para aprofundar

- [How the alpha phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works) — GOV.UK Service Manual. A fase alpha experimenta soluções e constrói apenas o necessário para testar as hipóteses mais arriscadas, sem disponibilizar o serviço ao público.
- [How the beta phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-beta-phase-works) — GOV.UK Service Manual. A fase beta leva a melhor ideia adiante, começa com uso limitado, coleta evidência com usuários reais e itera antes de ampliar.

## Resumo

Comece pelo menor caminho que testa o risco certo. Use protótipo para aprender sem exposição pública; use MVP operacional quando houver usuários reais e trate as proteções exigidas pelo contexto como parte do mínimo. O restante entra quando a evidência pedir.

## Conteúdo relacionado

- Serviço: [Desenvolvimento de SaaS e MVP](https://yuriqueiroz.com.br/servicos/desenvolvimento-saas-mvp)
- Case: [Entrevista Mapeada](https://yuriqueiroz.com.br/projetos/entrevista-mapeada)
- Artigo: [Quanto custa um sistema web sob medida?](https://yuriqueiroz.com.br/artigos/quanto-custa-desenvolver-sistema-web-sob-medida-2026)

## Próximo passo

Definir o recorte do primeiro produto. [Entrar em contato](https://yuriqueiroz.com.br/contato).