Quanto custa um MVP e o que cortar do escopo

Um MVP no Brasil costuma custar entre R$ 20 mil e R$ 80 mil e levar de 6 a 14 semanas até estar na mão de usuários reais. A conta sobe rápido não por causa da tecnologia, mas porque quase todo mundo confunde "mínimo produto viável" com "primeira versão do produto completo".

Qual é a faixa de preço de um MVP

São estimativas típicas de mercado. Um marketplace aparece na tabela porque é o caso em que o "mínimo" é estruturalmente maior: sem os dois lados, não há o que validar.

O que é, de fato, um MVP

Um MVP existe para responder uma pergunta de negócio com dados reais. Não é uma versão feia do produto final, nem um corte proporcional de todas as funcionalidades.

A pergunta precisa ser específica o suficiente para ser respondida: "corretores autônomos pagam R$ 90 por mês por uma ferramenta que gera o contrato de locação automaticamente?" é uma hipótese testável. "Vamos ver se o mercado gosta" não é.

Definida a pergunta, o critério de corte se torna mecânico: cada funcionalidade que não interfere na resposta sai da primeira versão. Sem esse critério, todo corte vira discussão de gosto.

O que quase sempre pode ser cortado

Painel administrativo. No começo, você tem dezenas de usuários. Consultar e ajustar dados direto no banco, com uma pessoa técnica de plantão, é mais barato do que construir telas de administração que ninguém mais vai usar. Uma planilha conectada ao banco resolve boa parte dos casos.

Permissões granulares. Dois perfis, usuário e administrador, cobrem quase todo MVP. Matriz de permissão por módulo é um dos itens que mais consomem tempo e um dos que menos afetam a validação.

Relatórios e dashboards. Com poucos usuários, você não tem volume de dados suficiente para um dashboard significar algo. Uma consulta rodada uma vez por semana entrega a mesma informação.

Automação de processo interno. Se, ao receber uma inscrição, alguém precisa aprovar manualmente, deixe manual. Automatizar faz sentido a partir do volume em que o manual dói. Enquanto são cinco por dia, o e-mail resolve.

Aplicativo mobile. Se a jornada funciona no navegador do celular, comece por aí. Publicar nas lojas adiciona semanas de revisão, custo de contas de desenvolvedor e um ciclo de atualização mais lento, tudo antes de você saber se alguém quer o produto.

Personalização, temas e configurações. Toda opção configurável é código, teste e superfície de bug. No MVP, decida por padrão.

Integrações opcionais. Integrar com quatro sistemas "porque o cliente pode pedir" é gastar antes de saber. Integre com um, o que o primeiro cliente realmente usa.

O que nunca deve ser cortado

Cortar demais também inviabiliza a validação. Estes itens ficam:

• A jornada principal inteira, ponta a ponta. Meia jornada não gera aprendizado, gera reclamação.
• Autenticação minimamente segura. Senha com hash, sessão que expira, dados de usuário protegidos. Não é polimento, é obrigação, inclusive legal, sob a LGPD.
• Cobrança, se a hipótese é sobre disposição a pagar. Intenção declarada não é validação. Se a pergunta é "as pessoas pagam?", o pagamento precisa acontecer de verdade, mesmo que via link de gateway em vez de checkout integrado.
• Registro do que os usuários fazem. Sem instrumentação básica, quem entrou, quem completou o fluxo, onde abandonou, você lança e não aprende nada. É barato e frequentemente esquecido.
• Backup. Perder os dados dos primeiros usuários encerra o teste.

Como saber se seu MVP está inchado

Três sinais práticos:

O prazo passou de quatro meses. Nesse ponto, o mercado já mudou e você ainda não colocou nada na rua. Corte.

Você não consegue nomear a hipótese em uma frase. Se precisa de um parágrafo, o escopo está carregando mais de um produto.

Existem funcionalidades que só serão usadas "quando crescer". Todo item justificado por escala futura é candidato imediato a corte. O problema de escala é um problema bom de se ter, e resolvê-lo antes de tê-lo é a forma mais comum de gastar dinheiro à toa.

Como o MVP afeta o custo do produto final

Existe uma preocupação legítima aqui: um MVP mal feito vira dívida técnica cara. A forma de evitar isso não é construir mais coisa, é fazer poucas escolhas estruturais com cuidado.

Vale investir tempo em: modelo de dados razoável, separação entre regra de negócio e interface, e um mecanismo de autenticação padrão de mercado. Esses três pontos são difíceis de mudar depois.

Não vale investir em: arquitetura preparada para milhões de usuários, camadas de abstração para trocar de banco, microsserviços, ou cobertura de teste exaustiva em funcionalidade que talvez seja descartada em três meses.

A pergunta que separa uma coisa da outra é: se essa decisão estiver errada, o custo de mudar depois é alto ou baixo? Decisão cara de reverter merece cuidado agora; decisão barata de reverter deve ser tomada rápido e revisitada depois, com dados.

Um MVP bem escopado não é um produto pior. É um produto que responde a pergunta certa antes de você gastar o orçamento inteiro respondendo a pergunta errada.