← todos os posts

"Por que 8 horas não bastam: o que acontece com um protótipo nas 3 semanas depois de publicado"

O link está no ar e é real. O que vem depois são três semanas que se repetem em qualquer protótipo que passa a ser usado — e têm uma medida.

"Acreditávamos que fazer o SaaS seria o menor dos nossos problemas. Ledo engano."

É de quem não programa, num fórum brasileiro, depois de duas semanas tentando montar um sistema com IA em sociedade. E tem a versão com desdém, de programador, no mesmo tipo de fórum:

"Qualquer um consegue colocar um mvp no ar..."

As duas frases estão certas e são a mesma frase. Qualquer um consegue colocar no ar. E colocar no ar era o menor dos problemas. O que este post faz é contar o que acontece entre as duas: as três semanas depois de publicar, na ordem em que elas chegam, e uma medida pra você saber onde o seu protótipo está hoje.

Primeiro: o que você fez é real

Eu quero começar por aqui porque a conversa costuma pular esta parte e ir direto pro "mas".

Se você tem um link no ar, que salva dado, que continua lá depois do F5, que outra pessoa abre e consegue se cadastrar — isso é real. Você fez, num sábado ou em uma semana de noites, o que a maioria das pessoas que assiste vídeo de IA nunca faz. Não é pouco. Ninguém aqui vai tratar como pouco.

Eu construo software há quinze anos e fiz o mesmo exercício: um projeto de referência, do zero ao link, em oito horas. Ficou no ar. E, respondendo com honestidade o checklist que eu uso pra separar protótipo de produto, ele saiu com sete "não" em dez perguntas. Guarde esse número. Ele não é a nota do meu sábado; é o tamanho do que um sábado consegue fazer, e ele é o mesmo pra quem está começando e pra quem faz isso há quinze anos.

Agora, o que acontece com esse link nas três semanas seguintes. Não é com você — é com qualquer protótipo que passa a ser útil. Já vi em sistema de empresa grande e em app de fim de semana, e a sequência é sempre a mesma.

Semana um: alguém usa de verdade

Uma pessoa do time começa a usar. Cadastra um cliente com nome, telefone, às vezes CPF. Esse dado entra numa tabela que a plataforma criou sozinha, com a regra de acesso que ela achou boa.

Em abril de 2026, um profissional brasileiro publicou no próprio blog a auditoria de um sistema feito no Lovable "em horas": mais de 40 erros críticos, entre eles "tabelas sem regras de Row-Level Security", dado passando de um usuário pra outro sem filtro, endereços expostos. É o relato de um caso, no blog de quem auditou — não é estatística sobre o seu app nem sobre a ferramenta. Mas a forma é a que eu vejo toda vez: a IA entrega o fluxo funcionando e a proteção fica fora do que ela gerou, porque ninguém pediu diferente.

O que torna a semana um traiçoeira é que ela não dói. O app funciona. Ninguém reclama. A falha que separa o cliente A do cliente B não dá sintoma nenhum — e o dado agora não é mais só seu.

Semana dois: alguém pede uma mudança

"Coloca um campo de observação no orçamento." Pedido pequeno. Você manda pra IA.

Ela coloca o campo e, no mesmo pedido, altera o cálculo do total. Você só descobre quando o cliente reclama do valor. Aí pede pra consertar o total, e o conserto quebra o login. Cada tentativa gasta crédito e gera outro erro, e você não consegue voltar pra ontem, porque não marcou onde era ontem.

Um engenheiro civil, não programador, escreveu num fórum brasileiro em agosto de 2025 a frase que resume a semana dois:

"O Manus se perdia, dava bug, gastava créditos a toa, para não realizar nada e no fim ainda continuo sem meu projeto real."

Mais de cinco mil créditos, ele contou, "para que no fim eu só me frustrasse". É um relato, de uma pessoa, com uma ferramenta. O padrão não é da ferramenta. É de pedir mudança sem ponto de retorno e pagar pra IA consertar o que ela mesma quebrou.

Semana três: a fatura, e a pergunta de quem é

Você olha a mensalidade da plataforma. O sistema que o seu time usa todo dia mora numa assinatura. Se a plataforma dobra o preço, muda a regra ou sai do ar, o sistema vai junto.

"Mas eu tenho o código." Tem. O botão de exportar existe em quase todas. Só que exportar e fazer rodar fora de lá é exatamente onde a maioria trava — e o banco de dados, o login dos usuários, as chaves, o domínio, nada disso vem no zip. Ter o código não é ser dono. Na semana três aparece a pergunta que ninguém fez na semana zero: de quem são os dados?

A medida: dez perguntas e o seu número

Repare que as três semanas são a soma de um checklist. Eu uso ele antes de dizer que qualquer app está pronto, e você pode responder agora, no seu, em cinco minutos. Uma regra só: "não sei" conta como não. Não porque você é culpado por não saber, mas porque, pro cliente, não saber e não ter dá no mesmo.

  1. O código é seu? Está numa cópia que você controla, fora da conta da plataforma?
  2. O banco é seu? A conta onde moram os dados está no seu nome, e você consegue baixar uma cópia deles hoje?
  3. Você volta pra ontem? Se a próxima mudança quebrar tudo, existe um ponto marcado pra onde voltar — que inclua os dados, não só o código?
  4. Ambiente de teste e de cliente são separados? Ou você testa a mudança em cima do dado real?
  5. Você prova que a regra funciona sem clicar em tudo? O cálculo, o desconto, o prazo: existe um teste que dá verde ou vermelho?
  6. O login protege, ou só aparece? Você fez o teste dos dois usuários e a conta B não viu o dado da A?
  7. Outra pessoa usa sem você do lado? Alguém de fora já entrou, se cadastrou e usou, sem você explicando por WhatsApp?
  8. Você sabe quanto custa por mês? Em real, com câmbio, separando construir de manter?
  9. Existe backup, e ele já foi restaurado uma vez? Backup que nunca voltou é esperança.
  10. Você sabe o que fazer quando quebra? Está escrito em algum lugar — não na sua memória — em que ordem religar tudo?

Some os "não". Esse é o seu número.

Quem chega a esse checklist depois de um sábado de construção costuma ficar entre seis e nove. Eu fiquei em sete. Não é sinal de que o sábado foi mal feito; é sinal de que o sábado compra um protótipo, e protótipo é isto: um app com esse número maior que zero. Produto é o mesmo app com o número zerado.

O que fazer hoje com o número

Não tente zerar tudo esta semana. Faça o movimento que interrompe cada semana antes dela chegar:

  • Contra a semana um: o teste dos dois usuários. Cinco minutos, só o navegador. Se a conta B abrir o pedido da A, esse é o primeiro "não" a virar "sim", antes de qualquer outro.
  • Contra a semana dois: antes do próximo pedido de mudança, marque o ponto que funciona e tire a foto do antes. E leia na documentação da sua plataforma se restaurar versão restaura o banco — na maioria, não.
  • Contra a semana três: preencha o inventário de onde cada coisa mora e em nome de quem. Quinze minutos. Não migra nada; só deixa de ser surpresa.

Três movimentos, nenhum exige programar, e os três derrubam de dois a três "não" do seu número. Isso é o que dá pra fazer sozinho, hoje, com o que está publicado neste blog.

O que oito horas não compram

A distância entre o seu número e zero não é grande em conhecimento. Cada uma das dez perguntas tem resposta que cabe num post, e várias já estão aqui.

Ela é grande em ordem. Ligar a regra de acesso antes de separar teste de produção faz você testar segurança em cima de dado de cliente. Migrar o banco antes de ter ponto de retorno faz a primeira migração ser irreversível. Publicar no domínio antes de saber quem é dono do domínio faz a semana três chegar com a conta no nome errado. Sem a sequência, a pessoa passa dois fins de semana num erro de deploy e conclui que "código de verdade não é pra mim". Já vi gente muito capaz concluir isso, e a conclusão estava errada. Faltou a sequência e alguém do lado.

A sequência tem três fases, e cada uma tem um portão: Construa (o código na sua máquina, o banco no seu nome, teste separado de produção, um ponto de retorno — só isso zera três ou quatro "não"), Estruture (o modelo de dados desenhado por você, as regras testadas, o login que protege de verdade), Opere (no ar no seu domínio, custo conhecido, gente de fora usando, e o que fazer quando quebra). Ninguém passa pro portão seguinte com item da fase anterior em aberto. É o contrário de curso, onde a aula 7 vem depois da 6 independentemente do que aconteceu com o seu projeto.

O que eu faço com quem quer zerar o número — no app da pessoa, na ordem, com portão em cada fase e alguém conferindo — chama Mentoria Dono do App, e é a única coisa que este blog vende. Ela ainda não tem aluno pra citar, e eu não vou inventar um. O que ela tem é o checklist acima como contrato: você entra com o seu número e sai com zero, no mesmo papel, respondido de novo.

Mas o número você já tem, e os três movimentos também. Comece por eles. O sábado foi real; o que vem depois também precisa ser.

Fontes