MVP em 90 dias: o que é possível construir com escopo fechado

O que é um MVP de verdade

MVP — Minimum Viable Product — é o menor produto que valida uma hipótese de negócio com usuários reais. Não é um protótipo clicável no Figma. Não é uma landing page com formulário. Não é uma versão beta cheia de bugs que você envia para os amigos testarem. É um produto que funciona, que resolve um problema real de forma mínima, e que permite coletar dados de uso genuíno.

A distinção importa porque a maioria das empresas constrói coisas erradas chamando de MVP. Um protótipo serve para validar a interface. Um MVP serve para validar o modelo de negócio.

O que é possível construir em 90 dias com €5k–15k

Com escopo bem definido, 90 dias é tempo suficiente para entregar:

• Um SaaS B2B com autenticação, painel de controle, gestão básica de usuários e uma funcionalidade core que resolve o problema principal do cliente.
• Um marketplace simples (duas pontas: oferta e demanda) com cadastro, listagem, busca básica e um fluxo de transação ou contato.
• Um app mobile com 3–5 telas que executam um fluxo de valor completo — sem gamificação, sem social features, sem integrações complexas.
• Uma ferramenta interna que automatiza um processo manual crítico para a operação.

O que não cabe em 90 dias com esse orçamento: sistema de pagamentos próprio (use Stripe ou similar), integrações com ERP legado, múltiplos idiomas, app nativo iOS e Android simultaneamente (escolha um ou use cross-platform), sistema de relatórios avançado, IA generativa integrada ao core do produto.

Por que a maioria dos MVPs falha

Não é falta de dinheiro. Não é falta de tecnologia. É escopo errado desde o início.

Os dois padrões de falha mais comuns que vejo:

Scope creep: o escopo cresce ao longo do projeto. Cada reunião de alinhamento gera uma nova funcionalidade "essencial". O que era um MVP de 90 dias vira um projeto de 18 meses. O mercado muda, o orçamento estoura, a motivação cai.

Sem validação prévia: o produto é construído com base em suposições sobre o que o usuário quer, sem nenhuma conversa real com potenciais clientes antes do desenvolvimento. Resultado: um produto tecnicamente funcional que ninguém usa porque não resolve o problema certo.

O Framework 3R e como ele muda o resultado

Na BeC, usamos o Framework 3R para validar o escopo antes de começar qualquer linha de código. Os três filtros são:

• Fricção: qual é o problema real que o usuário enfrenta hoje? Se não há fricção clara e identificável, não há produto. A pergunta não é "o que você gostaria que existisse" — é "o que te faz perder tempo ou dinheiro agora".
• Regra: existe alguma restrição — regulatória, técnica, cultural — que limita as soluções possíveis? Ignorar isso durante o planejamento gera retrabalho caro depois.
• Retorno: como o usuário ganha com a solução? E como o negócio captura valor? MVP sem modelo de monetização claro é experimento acadêmico, não produto.

Quando os três filtros estão respondidos antes do início do desenvolvimento, o escopo fecha de forma natural. O que não passa pelo filtro 3R não entra no MVP — independente de quão boa seja a ideia.

Exemplos de MVPs entregues pela BeC em 90 dias

Um app de gestão de equipes de campo para uma distribuidora regional: cadastro de promotores, rota diária, checklist de visita e dashboard de supervisor. Entregue em 78 dias com desenvolvimento com escopo fechado, preço fixo.

Uma plataforma SaaS para gestão de contratos de manutenção predial: cadastro de contratos, alertas de vencimento, relatório de histórico por ativo. Escopo fechado em 3 semanas de discovery, desenvolvimento em 85 dias.

Em ambos os casos, o que viabilizou a entrega no prazo foi o escopo definido antes do contrato, não durante. Mudança de escopo durante o desenvolvimento é o maior inimigo do prazo — e é por isso que o modelo de CTO as a Service inclui uma fase de discovery antes de qualquer proposta de desenvolvimento.

O que fazer depois dos 90 dias

O MVP entregue não é o produto final — é o início do ciclo de aprendizado. Com usuários reais usando o sistema, você tem dados para decidir o que construir a seguir com base em evidências, não em suposições. A segunda iteração costuma ser mais rápida e mais barata porque o aprendizado da primeira reduziu as incertezas.