MVP em 90 Dias com Orçamento Fechado: o que é possível

Toda a semana aparecem founders com a mesma proposta: "quero construir um MVP em 3 meses com €10.000". A pergunta que se segue define se o projeto vai resultar ou não: MVP de quê, exactamente?

90 dias e €10.000 é um orçamento real para um MVP real — mas a palavra "MVP" está tão desgastada que perdeu significado. Este artigo define o que é possível construir, o que não é, e o que muda quando o âmbito é definido com rigor desde o início.

O que é um MVP — e o que não é

MVP significa Produto Mínimo Viável. Viável não é sinónimo de funcional — é um produto que permite validar a hipótese central do negócio com utilizadores reais.

A confusão entre os três é a principal razão pela qual MVPs falham. Um protótipo não valida nada com utilizadores reais. Um produto completo leva 12-18 meses a construir, não 90 dias.

O que pode ser construído em 90 dias com €5k–15k

Com uma equipa competente e âmbito bem definido, 90 dias permitem entregar:

• Uma aplicação web com autenticação, um fluxo principal de utilizador e base de dados funcional.
• Um marketplace simples com dois perfis de utilizador (comprador e vendedor) sem sistema de pagamento complexo.
• Uma ferramenta SaaS B2B com dashboard, gestão de utilizadores e a funcionalidade core que justifica a proposta de valor.
• Uma aplicação móvel com um único fluxo, integração com uma API externa e sistema de notificações básico.
• Um sistema de gestão interno para substituir processos manuais, com formulários, listagens e exportação de dados.

O que não entra em 90 dias com esse orçamento: sistema de pagamentos complexo, integrações com múltiplos sistemas externos, app móvel e web em simultâneo, múltiplos idiomas, ou painel de administração completo. Estas são funcionalidades de fase 2.

Porque a maioria dos MVPs falha antes de ser lançada

Scope creep não gerido

O âmbito inicial parece razoável. Depois surgem pedidos de funcionalidades adicionais ao longo do desenvolvimento — cada um aparentemente pequeno, cada um com justificação legítima. No final do trimestre, o MVP tem 3x mais funcionalidades do que o previsto e ainda não está terminado. Nem o orçamento chega, nem o prazo se cumpre.

A solução não é dizer "não" a tudo — é ter um processo formal de gestão de âmbito onde cada pedido de alteração é avaliado explicitamente contra o prazo e o orçamento.

Sem validação prévia da hipótese

Construir um MVP sem ter validado a hipótese central com utilizadores reais é construir para o vazio. Não é necessário ter o produto para validar — uma landing page, um formulário de interesse, conversas com 10 potenciais clientes. Se ninguém quer o produto antes de existir, construir o produto não vai mudar isso.

Stack técnica excessivamente ambiciosa

Escolher tecnologias complexas para um MVP que ainda não validou nada é um erro comum. Um MVP não precisa de microserviços, de Kubernetes, de machine learning. Precisa de funcionar, de estar disponível e de permitir a validação da hipótese de negócio. A arquitectura pode ser simplificada sem comprometer o resultado.

Como o Framework 3R muda o resultado

O Framework 3R é a metodologia que a BeC usa para definir o âmbito de um MVP antes de começar o desenvolvimento. Cada funcionalidade é avaliada segundo três critérios:

O resultado típico desta análise é um corte de 40–60% das funcionalidades inicialmente previstas. Não porque essas funcionalidades não tenham valor — têm — mas porque não são necessárias para validar a hipótese central do negócio.

A BeC System aplica o Framework 3R na fase de escopo de todos os projetos de desenvolvimento de software a preço fixo. É o que permite garantir prazo e orçamento fechados desde o início.