MVP em 30 dias: o que cortar e quanto custa

A maior armadilha de quem está começando um produto é querer lançar completo. O resultado é quase sempre o mesmo: meses de desenvolvimento, dinheiro queimado, e um produto que ninguém usa do jeito que você imaginou.

O MVP existe pra resolver isso. Ele não é uma versão capenga do produto final. É a menor coisa que prova, ou derruba, a sua hipótese principal.

Este texto é o método que a gente usa: como escolher a hipótese, como cortar, o que sobra, quanto custa e como são as quatro semanas na prática.

A resposta curta

MVP é a menor coisa que prova, ou derruba, uma hipótese escrita em uma frase. Fica: o fluxo central, login simples, um canal de feedback, medição, e cobrança se a hipótese for sobre pagar. Sai: painel completo, relatório, configuração, integração de pouco uso e aplicativo nativo nas lojas.

O mercado publica entre R$ 30.000 e R$ 90.000 para MVP, com prazo de dois a quatro meses. Trinta dias é possível quando o escopo é cortado de verdade e existe alguém do lado do cliente disponível pra decidir no mesmo dia.

Primeiro: qual é a hipótese?

Antes de listar funcionalidade, escreva uma frase. Uma só, e ela precisa ser falsificável.

Ruim: "as pessoas querem organizar melhor as finanças". Ninguém discorda disso, e por isso ela não testa nada.

Boa: "autônomo que fatura entre cinco e quinze mil por mês paga R$ 29 mensais por uma ferramenta que separa o dinheiro da empresa do dinheiro pessoal automaticamente".

A segunda frase pode dar errado. É por isso que ela presta. Ela também já te diz quem é o usuário, qual é o valor e qual é o teste, tudo de uma vez.

Tudo daqui pra frente se organiza em volta dessa frase. Inclusive, e principalmente, o que vai ser cortado.

O corte

Liste tudo que você imaginou. Tudo mesmo, sem editar. Agora passe item por item com uma pergunta:

Se isso não existir, ainda dá pra provar a frase?

Se a resposta for sim, sai. Não morre: vai pra uma lista chamada "depois", que você olha de novo quando tiver dado.

A maior parte da lista cai nessa pergunta. É desconfortável e é exatamente aí que está o serviço. Todo mundo consegue adicionar; cortar é a parte difícil.

O que quase sempre fica

• O fluxo central. O caminho único que entrega o valor principal. Se o seu app é de finanças, é registrar um gasto e ver pra onde o dinheiro foi. Tudo gira em torno disso.
• Login simples. E-mail e senha, ou login social. Nada de SSO corporativo no dia um.
• Uma forma de ouvir o usuário. Um botão de feedback, um WhatsApp, um formulário. Sem isso você lança e fica no escuro.
• Medição. Quantos entram, quantos completam o fluxo, onde travam. Subir sem medir é lançar no escuro e chamar de validação.
• Cobrança, se a hipótese for sobre pagar. Intenção de pagar não é pagamento. Se a frase que você quer provar tem preço dentro, o cartão precisa passar.

O que quase sempre sai

• Painel de administração completo. No começo dá pra operar direto no banco, e isso é normal.
• Relatório avançado, exportação, gráfico configurável.
• Configuração infinita e personalização.
• Integração que só 5% vão usar.
• Modo escuro, gamificação, medalha, a não ser que sejam o produto.
• Aplicativo nativo nas lojas. Web no celular resolve a validação e vai ao ar muito antes da fila de revisão da Apple.

Três cortes de verdade

Teoria de corte é fácil. Na prática, o corte dói. Três exemplos do que sobra quando a régua é aplicada de verdade.

App de organização financeira. A ideia tinha importação de extrato bancário, categorização automática, metas, relatório mensal e comparação com outros usuários. O que sobrou: registrar um gasto em três toques e ver pra onde o dinheiro foi no mês. Importação de banco é integração cara e demorada, e não era ela que provava se a pessoa mantinha o hábito.

Marketplace de prestador de serviço. A ideia tinha cadastro dos dois lados, busca com filtro, chat interno, pagamento na plataforma, avaliação e agenda. O que sobrou: um lado só, o que é mais escasso. Se não existir prestador, o cliente não tem o que buscar, e o resto do produto é enfeite.

SaaS B2B de gestão. A ideia tinha módulo financeiro, de estoque, de vendas e de relatório. O que sobrou: um módulo, escolhido pela dor que fez o primeiro cliente aceitar conversar. Vender um módulo que resolve muito é mais fácil que vender quatro que resolvem pouco.

O padrão é sempre o mesmo. O que sobra é a coisa que a pessoa faria mesmo se o resto não existisse.

Antes de construir, tente não construir

Metade dos MVPs que a gente ajuda a cortar poderia ter sido testado antes com muito menos. Vale gastar uma semana nisso.

Uma landing com botão de "quero usar" mede interesse. Um protótipo clicável mostrado pra dez pessoas do público mostra onde elas travam. Uma pré-venda responde a pergunta mais dura de todas. E o modo concierge, em que você entrega o resultado na mão sem automatizar nada, ensina o fluxo real antes de qualquer linha de código.

A gente detalhou esses testes em validar antes de codar. Se algum deles derrubar a hipótese, parabéns: você acabou de economizar o orçamento inteiro.

As quatro semanas

Trinta dias não é slogan, é restrição de projeto. Restrição é o que força a decisão.

Semana 1: hipótese e corte. A frase, a lista, o corte, e o desenho do fluxo central. No fim da semana existe protótipo navegável. Você já pode mostrar pra usuário e pra investidor.

Semana 2: o esqueleto. Login, banco, a primeira tela do fluxo funcionando de verdade. Feio ainda, mas real, e num endereço que você acessa.

Semana 3: o fluxo inteiro. O caminho completo de ponta a ponta, com o acabamento visual entrando junto. É a semana em que dá vontade de adicionar coisa. Não adicione.

Semana 4: o mundo real. Cobrança se for o caso, medição ligada, teste com gente de fora, domínio, e o lançamento pra um grupo pequeno.

O que não cabe nessas quatro semanas provavelmente não precisava caber.

Quanto custa

Duas software houses brasileiras publicam faixa aberta pra MVP. Vale olhar antes de conversar com qualquer fornecedor.

Repare na distância entre a tabela de mercado da nFactory e o preço que ela mesma anuncia. Isso não é pegadinha, é a prova de que faixa publicada descreve um projeto imaginário. O que decide o seu número é o seu escopo.

Na Mutagex o piso é R$ 5.000 pra qualquer projeto, e um sistema sob medida completo começa em R$ 30.000, com 8 a 16 semanas. O MVP mora entre os dois, porque ele é justamente esse sistema com o escopo cortado até sobrar o fluxo que prova a hipótese. O valor depende muito mais de quantas telas o fluxo central precisa do que de quão ambiciosa é a ideia inteira, e o diagnóstico é gratuito e sai com o escopo já cortado e faixa por escrito.

A conta que importa, aliás, não é o preço do MVP. É quanto custaria descobrir a mesma coisa construindo o produto completo. Essa diferença costuma ser de um zero.

O dia 31

A parte que ninguém planeja é a que vem depois do lançamento. Sem isso, o mês vira demonstração e não validação.

Marque uma conversa pra duas semanas depois do ar, com três números na mesa: quantas pessoas entraram, quantas completaram o fluxo central, e quantas voltaram. O terceiro é o mais duro e o mais honesto.

De lá saem três caminhos possíveis, e todos são resultados legítimos.

Seguir. Os números confirmam a hipótese. Agora dá pra investir na segunda camada, com a lista do "depois" na mão e o dado pra priorizar ela.

Ajustar. As pessoas entram e param no mesmo lugar. Isso não invalida a ideia, invalida uma parte dela, e costuma ser barato de consertar porque o produto ainda é pequeno.

Parar. Ninguém completa, ninguém volta, ninguém paga. Você gastou uma fração e tem a resposta. É o resultado mais barato que você vai comprar no ano.

Os erros que a gente mais vê

Chamar de MVP o produto inteiro com prazo apertado. Isso não é MVP, é projeto grande feito às pressas. Sai pior nas duas pontas.

Cortar qualidade em vez de escopo. MVP tem escopo pequeno e acabamento honesto. Software instável não valida nada, porque a pessoa desiste antes de chegar no que você queria medir.

Não ligar a medição. Sem número, a conversa de fechamento vira opinião, e opinião você já tinha antes de gastar.

Lançar sem plano de tráfego. Ninguém entra sozinho. Se não houver gente chegando, o MVP não valida nem invalida nada, e o mês foi jogado fora.

Tratar validação negativa como fracasso. É o oposto: é o produto fazendo o trabalho dele. Você gastou uma fração e não passou um ano construindo a coisa errada.

Quem faz o quê nessas quatro semanas

MVP de trinta dias não é o fornecedor sumindo por um mês e voltando com uma surpresa. Do seu lado precisa existir uma pessoa que decide, disponível de verdade.

Ela responde dúvida no mesmo dia, aprova o que precisa ser aprovado e diz não quando alguém sugere adicionar coisa. Sem ela o cronograma escorrega na primeira pergunta que fica sem resposta, e a culpa costuma cair no lugar errado.

Do nosso lado, o combinado é entrega acessível o tempo todo, uma conversa curta por semana e nenhum item novo entrando sem sair outro. Restrição só funciona se as duas partes respeitarem ela.

A pergunta que decide tudo

Pra cada funcionalidade: se isso não existir, ainda dá pra provar a hipótese?

Velocidade em MVP não é pressa. É foco em provar uma coisa de cada vez.

Tem uma ideia pra validar? Fala com a gente ou veja como funciona o MVP de startup na Mutagex.