Toda sexta, às 16h, mostramos pro cliente o que mudou no sistema durante a semana. Às vezes é uma tela inteira nova. Às vezes é um ajuste de validação que ninguém vai notar de cara. A regra é a mesma nos dois casos: a demo acontece.
O problema que isso resolve
Projeto de software sem checkpoint frequente tem um padrão previsível: as primeiras semanas parecem produtivas, e só lá pela sétima ou oitava semana alguém percebe que o time construiu a coisa errada — porque ninguém olhou de perto durante um mês e meio.
Demo semanal mata esse risco antes dele crescer. Se o rumo está errado, você descobre em uma semana, não em um mês.
Por que sexta, e não só quando "tem algo pronto"
Esperar ter "algo bonito" pra mostrar é a armadilha. Vira uma desculpa pra adiar o feedback justamente nas semanas em que ele é mais necessário — quando o trabalho está mais confuso, mais no meio do caminho.
Mostrar o feio também é parte do trato: uma tela sem estilo, uma regra que ainda não trata todos os casos. O cliente vê o processo de verdade, não uma versão editada dele.
O que isso exige do lado do cliente
Funciona só se tem alguém do outro lado prestando atenção — não é uma call de 30 minutos pra bater o olho e sumir. As perguntas que aparecem na demo geralmente valem mais que o código da semana em si, porque são elas que evitam retrabalho.
Na prática: projeto sem demo semanal não é necessariamente pior — mas é maior risco de descobrir tarde. A gente prefere a chatice de mostrar pouco toda semana à surpresa de mostrar muito depois de errado.
A demo semanal é a outra metade de entregar um MVP em seis semanas — e é parte fixa de todo projeto de desenvolvimento que tocamos.