"Semana 1, 2 e 3 de um protótipo útil: a sequência que acontece com qualquer app que passa a ser usado"
"A sequência não chega pelo calendário, chega pelo uso. O que dispara cada semana, como saber em qual você está, e a jogada de cada uma."
Quando um protótipo começa a ser usado de verdade, três coisas acontecem com ele. Sempre na mesma ordem. Eu já vi em sistema de empresa grande e em app de fim de semana, e é sempre a mesma sequência.
Mas tem um detalhe que muda tudo, e é o que este mapa faz questão de dizer antes: essas três coisas não chegam pelo calendário. Chegam pelo uso. "Semana" é só o apelido. Pode ser uma semana, pode ser três meses. O que dispara cada etapa não é o relógio — é um evento. E como o evento é previsível, dá pra se preparar pra ele antes de ele chegar.
Este é o mapa das três. Pra cada uma: o gatilho que a abre, o sinal de que você já entrou nela, e a jogada.
Semana 1 — entra o primeiro usuário
O gatilho: alguém de fora usa de verdade pela primeira vez. Cadastra um cliente com nome, telefone, às vezes CPF. O app deixa de ter só dado de teste e passa a guardar dado de gente real.
Como você sabe que entrou: existe, agora, uma informação no seu app que você não pode perder nem deixar vazar. Antes era brincadeira; agora tem consequência.
O que ninguém te conta é que o dado entrou numa tabela que a plataforma criou sozinha, com a regra de acesso que ela achou boa — que muitas vezes é nenhuma. Em maio de 2026, um estudo de segurança varreu centenas de milhares de apps feitos nessas ferramentas e achou milhares vazando dado sensível, inclusive de um banco brasileiro, porque projeto novo costuma nascer público. Não é descuido seu. É padrão de fábrica.
A jogada: o teste das duas contas, e faça ele antes do primeiro cliente real entrar, não depois. Cinco minutos: duas contas suas, um dado numa, tenta ver pela outra. Se a conta B enxerga o dado da A, você tem uma semana 1 esperando pra doer — e dá pra resolver com o app ainda vazio.
Semana 2 — entra o primeiro pedido de mudança
O gatilho: alguém pede uma alteração. "Coloca um campo de observação no orçamento." Pequeno. Você manda pra IA.
Como você sabe que entrou: a IA faz o que você pediu e, de brinde, mexe em algo que você não pediu. Ela põe o campo e altera o cálculo do total. Você só descobre quando o cliente reclama do valor. Pede pra consertar o total, e o conserto quebra o login. Cada tentativa gasta crédito e cria outro erro.
Esse é o momento em que a maioria entra em pânico, porque não dá pra voltar pra ontem — e aqui mora a armadilha que quase ninguém sabe: voltar o código pra versão de ontem não volta os dados junto. A documentação do Bolt diz isso com todas as letras — o histórico de versões restaura os arquivos do projeto, não o banco. Então "desfazer" pela metade te deixa com código de ontem e dado de hoje, um estado que ninguém testou.
A jogada: antes do próximo pedido de mudança, marque o ponto de retorno — código e banco. Com um ponto de retorno de verdade, quebrar deixa de ser tragédia e vira "volta pra ontem e tenta de novo". Sem ele, cada pedido é uma aposta.
Semana 3 — entra a conta, e a pergunta de quem é dono
O gatilho: chega a fatura da plataforma, ou alguém pergunta "e se essa ferramenta sair do ar?". O app que o seu time usa todo dia mora numa mensalidade, num terreno que não é seu.
Como você sabe que entrou: você se pega pensando "se a plataforma dobrar o preço ou mudar a regra, o que acontece com o meu sistema?". E não tem resposta.
"Mas eu tenho o código." Tem. O botão de exportar existe em quase todas. Só que o banco de dados, o login dos usuários, as chaves, o domínio — nada disso vem no arquivo que você baixa. Ter o código não é ser dono. A pergunta que ninguém fez na largada aparece aqui, cobrando: de quem é o banco?
A jogada: faça o inventário — uma folha listando onde mora cada coisa (código, banco, domínio, chaves) e em nome de quem. Quinze minutos. Você não migra nada ainda; só para de ser surpreendido. Surpresa na semana 3 custa caro; a mesma informação, sabida na semana 0, custa quinze minutos.
O que o mapa é pra você
Repare no que as três jogadas têm em comum: todas são mais baratas antes do gatilho do que depois. É essa a utilidade de saber que a sequência existe e qual é a ordem. Você não está condenado a descobrir cada uma no susto. Dá pra ligar a regra de acesso com o app vazio, marcar o ponto de retorno antes do primeiro pedido, fazer o inventário antes da fatura pesar.
A sequência também te diz uma coisa sobre o seu número no checklist. Se você respondeu as dez perguntas que separam protótipo de produto e deu seis, sete "não", esses "não" não estão espalhados ao acaso — eles são a soma destas três semanas que ainda não aconteceram com você. E a razão de por que doem tanto quando a gente deixa chegar sem preparo eu contei em por que oito horas não bastam.
Protótipo que ninguém usa fica parado e não passa por nada disso. No dia em que ele vira útil, as três semanas começam a contar. Isso não é má notícia — é sinal de que alguém está usando o que você fez. Só vale saber o que vem, pra chegar antes.
Fontes
- Bolt, "Backups, restore, and version history" e "Supabase for databases" (o histórico de versões restaura os arquivos do projeto, não o banco Supabase; voltar a uma versão anterior deixa os dados como estão): https://support.bolt.new/building/using-bolt/rollback-backup