MVP com hipótese escrita é o contrato entre produto e engenharia: o que acreditamos, como medimos, o que mata o recorte. Demo de modelo não é produto. Demo prova que a API respondeu na sala. Produto prova que alguém muda o comportamento fora da sala — com critério combinado antes do sprint.

Março enche de piloto de IA com slide. O buraco é o mesmo do MVP clássico: escopo que cresce porque a demo pediu mais um recurso. Hipótese escrita segura o cut. MVP em 60 dias fala de ritmo de entrega; o slug legado permanece. O âncora do Startup Studio é MVP em até 90 dias. Aqui o ponto é o que entra nesse prazo.

O que vai no papel antes do código

Uma página:

  • hipótese de valor (quem, tarefa, mudança de comportamento);
  • hipótese de usabilidade (consegue completar sem o fundador ao lado);
  • hipótese de viabilidade (o recorte cabe no horizonte);
  • evidência mínima e data de corte;
  • o que não entra mesmo se a demo “pedir”.

Validar demanda antes de abrir o sprint é o filtro. Sem demanda, o MVP é um protótipo caro. Discovery antes da feature de IA mata copiloto interno sem usuário; o mesmo ritual vale para produto novo.

Demo de modelo costuma validar viabilidade técnica cedo demais e valor tarde demais. Inverta: concierge ou protótipo de tarefa, depois modelo no recorte que sobreviveu.

Demo versus aceite de produto

Aceite de demo: o happy path rodou. Aceite de MVP: o segmento-alvo completou a tarefa N vezes, ou a lista de espera com e-mail corporativo passou do piso combinado, ou o concierge teve retenção mínima. Escolha um. Sem número inventado de mercado — o número é o de vocês, escrito antes.

Fundador que troca o critério depois da demo está fazendo outro produto. Isso pode ser certo (aprendizado). Tem que ser explícito: nova hipótese, novo prazo. Senão o “MVP” vira v1 infinita.

Como não hipotecar arquitetura no recorte

Hipótese escrita também protege engenharia: o recorte não precisa de plataforma universal. Monolito pequeno, um fluxo, dado mínimo. O que o modelo precisa de contexto fica listado — e o que não entra no prompt também. Diagnóstico em 48h no Studio existe para esse alinhamento, não para começar o build no escuro.

Desde 2012 a Tech Coders trata parceria do conceito ao mercado nesse ritmo: evidência, depois código. Sem case inventado. O modelo de Startup Studio é o veículo.

Como a Tech Coders faz MVP com hipótese

No Startup Studio, hipótese e critério de corte vêm no diagnóstico (48h) e no caminho de MVP em até 90 dias. Demo de modelo não entra como aceite. Entra o recorte que o usuário executou. Engenharia sob medida no recorte — sem big bang de plataforma “para quando crescer”.

Perguntas frequentes

E se o investidor quiser só a demo de IA?

Demo pode ser marco de comunicação. Aceite de produto é outro documento. Misturar os dois queima o prazo do MVP no palco.

Hipótese escrita atrasa o “ship”?

Atrasa o ship do recorte errado. O paper de uma página cabe em um dia. O atraso real é o mês extra de feature de palco.

Posso ter várias hipóteses no mesmo MVP?

Pode, se cada uma tiver teste. Cinco hipóteses sem teste é roadmap disfarçado. Prefira uma de valor e uma de usabilidade no primeiro recorte.

90 dias incluem discovery?

O caminho típico reserva discovery curto no início. Se a hipótese ainda não existe, o relógio de build não deveria ter começado. Diagnóstico de 48h deixa isso explícito.