TL;DR
Todo founder técnico que senta comigo chega com o mesmo medo: “lanço em semanas, mas não quero reescrever tudo daqui a três meses”. O medo é legítimo. Só que ele faz você cortar a coisa errada.
O MVP que vira lixo quase nunca virou lixo por ter sido rápido. Virou porque cortou a separação (que é barata de manter e cara de refazer) pra manter feature (que é cara de fazer e que quase ninguém vai usar). O MVP que escala faz o inverso: corta feature sem dó e mantém a separação sempre. Ele não nasce protótipo descartável. Nasce como a fase 1 de um produto, e a fase 2 cresce em cima dela quando você cortou e manteve certo.
Os números ancoram a inversão. 42% das startups que morrem morrem construindo algo que o mercado não queria. Num produto médio, 64% a 80% das features são raramente ou nunca usadas. E refazer o que saiu errado é o gasto mais silencioso: times retrabalham cerca de 26% do código antes mesmo de lançar, e a maior parte disso vem de ter entendido errado o que construir, não de ter codado rápido.
Velocidade não é o inimigo do MVP que escala. Escopo cego é.
O MVP não vira lixo por ser rápido. Vira por juntar tudo e manter a feature.
A imagem de MVP que o founder carrega na cabeça é quase sempre a errada: uma versão pequena do produto inteiro. Um pouco de cada coisa. Todas as telas, todas as features, só que meia-boca.
“MVP é pra validar rápido. Faz o mínimo de tudo, capricha depois.”
Esse “mínimo de tudo” é a armadilha. Mínimo não quer dizer raso em tudo. Quer dizer estreito: pouca coisa, inteira. Você escolhe a única coisa que o produto precisa fazer bem pra provar que tem gente querendo, e faz ela do começo ao fim. O resto não é “feito pela metade”. É cortado.
E aqui está o pulo do gato que o medo de retrabalho esconde: separar as coisas é barato, e juntá-las de novo é que custa. Feature é cara de fazer e barata de cortar. Quando você corta arquitetura pra ganhar tempo, economizou no que era barato e vai pagar caro depois. Quando você corta feature, economizou no que era caro e que provavelmente ninguém ia usar.
MVP que vira lixo cortou no lugar errado.
O que cortar sem dó
Cortar bem é uma habilidade, e dói porque tudo parece essencial no começo. Não é. Comece por aqui:
- Features que não validam a tese. Esse é o corte-mãe. Se a feature não serve pra provar que alguém quer o produto, ela não é v1. Os 42% que morrem construíram algo sem product-market fit: a evidência de que existe gente o suficiente querendo o que você faz, no preço que você cobra. Não morreram por falta de feature. Morreram de feature na direção errada.
- A segunda, a terceira e a quarta feature. Num produto médio, só 12% das features geram 80% do uso. No MVP você ainda não sabe qual é essa fatia. Mas sabe que não são as vinte. Aposta em uma, no máximo duas.
- Escala que não existe. Cache, fila, sharding, microservice pra dez usuários. Otimizar uma carga que você não tem é resolver um problema imaginário enquanto o problema real (alguém usar) segue sem resposta.
- Configurabilidade. Todo “e se o cliente quiser mudar isso?” vira um painel de settings que dobra o escopo. No MVP, deixa fixo no código. Configurável é problema de quem já tem cliente.
- Polish. Animação, dark mode, onboarding de cinco passos, tela vazia ilustrada. Tudo real, tudo fase 2.
O que sobra parece pouco. É pra parecer. Se o seu MVP não te deixa um pouco constrangido, você cortou de MENOS.
O que manter sempre (manter a separação é barato; refazê-la é que custa)
Cortar feature é a parte fácil depois que a ficha cai. Onde eu vejo o founder com pressa errar é no outro lado: o que NÃO se corta, nem no prazo mais apertado. São poucas coisas, todas baratas de deixar certas agora e caríssimas de refazer depois.
- O modelo de domínio. Os nomes das coisas e como elas se ligam. Trocar “usuário” por “conta” e “organização” no mês seis é migração de dados, refactor que cruza o sistema inteiro e bug em produção. Decidir isso na semana 1 custa uma conversa.
- As divisões entre capacidades de negócio. Onde o pagamento termina e o pedido começa. Você não precisa implementar os dois bem. Precisa saber onde fica a linha entre eles, pra depois mexer num sem desmontar o outro.
- Identidade e quem-pode-o-quê. Se o produto tem mais de um tipo de usuário, enfiar auth e permissão depois é um dos refactors mais caros que existem, porque toca toda requisição.
- Um fio de observabilidade. Log estruturado e um jeito de saber o que quebrou. Não é feature. É o que te deixa dormir.
O número que justifica a teimosia: times retrabalham perto de 26% do código antes do release, e a Carnegie Mellon aponta a mesma causa raiz há décadas. Mais da metade do retrabalho nasce de requisito mal entendido, não de código mal escrito. O retrabalho caro não vem de você ter codado rápido. Vem de ter traçado a separação no lugar errado, ou de não ter traçado nenhuma.
Como manter a separação pro que eu nem sei se vai escalar?
Você não adivinha o que vai escalar, ninguém adivinha. Mas não precisa: em vez de decidir a implementação, você decide onde ficam as costuras. Manter a costura é barato (um módulo com nome claro, o pagamento que não está enfiado no meio do pedido) e atrás dela você faz o mais simples e burro que funciona hoje. Quando a carga aparecer, se aparecer, você troca o que está atrás sem mexer em quem depende dela. A fase 2 vira troca de peça, não recomeço.
A versão dessa disciplina no nível do código (organizar por feature, front e back no mesmo repositório, decisão registrada) a gente destrinchou em seu codebase é o novo prompt, que é o que mantém um agente de IA produtivo no seu MVP seis meses depois. E o registro do porquê de cada decisão dessas mora nos ADRs. Este post é o andar de cima: o que cortar e o que manter antes de o código existir.
MVP é a fase 1, não o protótipo (a fase 2 é a prova)
Tem uma palavra que denuncia que o MVP virou lixo: reescrita. Joel Spolsky chamou reescrever do zero de “o pior erro estratégico que uma empresa de software pode cometer”, e isso foi em 2000, muito antes de a IA deixar a reescrita ainda mais tentadora e mais cara. O MVP que escala nunca passa por ela. Passa por extensões: cada fase soma em cima da anterior, porque a anterior deixou a separação no lugar.
É o que a gente faz na Nextside num Sprint: escopo fechado, time sênior, um MVP funcional em 4 semanas que já nasce com as divisões certas pra crescer por fases. A pressa fica no escopo, o rigor fica na separação. E o prazo curto não é limitação, é o mecanismo: ele força a conversa de corte que o founder adia por meses.
O MVP que escala é o que você não precisa refazer
A diferença entre o MVP que escala e o que vira lixo não está na stack, no tamanho do código nem no nome da arquitetura. Está em duas decisões que você toma antes de escrever a primeira linha: o que cortar e o que manter.
Corta a feature, a escala que não existe, o polish, o “e se”. Mantém o domínio, as divisões, a identidade. Faz pouca coisa inteira em vez de muita coisa pela metade, e a fase 2 vira uma extensão do que você já tem, não o velório do que jogou fora.
MVP que escala não é o que ficou pronto mais rápido. É o que você não vai precisar refazer.