← todos os posts
Dores 10 min de leitura

"Protótipo ou produto? As 10 perguntas que eu faço pra qualquer app antes de dizer que está pronto"

"Dez perguntas que separam um protótipo de um produto que aguenta cliente. Como responder cada uma em minutos e o que conta como 'não'."

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

É de um programador, num fórum brasileiro, dito com desdém pra quem construiu algo sem ele. E ele tá certo numa coisa: colocar no ar ficou fácil. MVP, pra quem nunca ouviu, é a sigla de "produto mínimo viável" — a primeira versão enxuta, só pra testar se a ideia para de pé. Fazer uma dessas e publicar, hoje, qualquer um faz num sábado.

O que ele não diz — porque não é o problema dele — é que "no ar" não é a linha de chegada. É a linha de largada. E a pergunta que fica, a que ninguém te entrega respondida, é esta: o que eu fiz é um protótipo ou já é um produto que aguenta cliente de verdade?

Este post é o jeito que eu respondo essa pergunta. São dez perguntas, cada uma com um teste que você faz em minutos, hoje, sem programar. No fim tem um cartão pra copiar. É o checklist inteiro, sem segurar nada — porque o que separa protótipo de produto não é um segredo, é uma lista que ninguém te deu.

Por que você nunca recebeu essa lista

Em time de software, "pronto" não é sensação. É um papel escrito uma vez, que toda entrega tem que passar. Você nunca recebeu o seu por um motivo simples: a ferramenta termina toda resposta com "pronto!", e não tinha nenhuma lista na mesa dizendo o que essa palavra precisa provar.

Não é burrice sua. É falta da lista.

E tem uma coisa que eu preciso dizer antes de você responder, pra tirar o peso: não espere zerar. Eu construo software há quinze anos. Fiz, de propósito, um projeto de referência do zero ao link no ar, em um sábado. Depois respondi este mesmo checklist, com honestidade, no meu projeto. Deu sete "não" em dez. Sete. Não é vergonha minha nem seria vergonha sua — é o tamanho exato do que um sábado consegue fazer, e é o mesmo pra quem começou ontem e pra quem faz isso há quinze anos. A distância entre sete e zero não é distância de conhecimento. É distância de ordem, e eu volto nisso no fim.

Uma regra pra responder: "não sei" conta como "não". Não porque você é culpado por não saber, mas porque, pro cliente que vai usar, não saber e não ter dão exatamente no mesmo.

As dez perguntas

1. O código é seu?

O código tá numa cópia que você controla, fora da conta da plataforma onde foi gerado?

Como responder: procure o botão de exportar ou de conectar ao GitHub (o site onde o código fica guardado, fora da plataforma) e veja se você consegue baixar tudo hoje, pra uma conta no seu nome.

Conta como não quando: o código só existe dentro do Lovable, do Bolt, do Replit, e sumiria junto se a sua conta sumisse.

2. O banco é seu?

Banco de dados é o arquivo de fichas do app: onde moram os cadastros, os pedidos, os pagamentos. A conta onde ele vive tá no seu nome, e você consegue baixar uma cópia dos dados agora?

Como responder: entre no painel do banco (em geral Supabase ou Firebase) e veja em nome de quem está a conta. Tente exportar uma tabela.

Conta como não quando: o banco mora numa conta da plataforma, ou você não sabe nem onde ele fica. Ter o código não é ser dono — e descobrir de quem é o banco é o "não" mais caro de deixar pra depois.

3. Você volta pra ontem?

Se a próxima mudança quebrar tudo, existe um ponto marcado pra onde voltar — que traga os dados junto, não só o código?

Como responder: é a pergunta que mais engana. Muita gente responde "sim, a plataforma guarda versão". Cuidado: a documentação do Bolt diz, com todas as letras, que o histórico de versões não restaura o banco de dados. Voltar o código pra versão de ontem deixa os dados como estão hoje — e código de ontem com dado de hoje é um estado que ninguém testou. Então o "volta pra ontem" de verdade precisa marcar os dois.

Conta como não quando: você depende de "acho que dá pra desfazer". Quatro comandos marcam e voltam, e precisa incluir o banco.

4. Teste e cliente são lugares separados?

Você tem um lugar pra testar mudança que não é o mesmo lugar onde o cliente mexe?

Como responder: quando você vai experimentar uma coisa nova, você faz isso em cima do dado real do cliente ou numa cópia? Ambiente de teste e ambiente de produção (o que o cliente usa) são dois endereços diferentes?

Conta como não quando: é tudo o mesmo lugar. Aí toda experiência sua é uma experiência no colo do cliente.

5. Você prova que a regra funciona sem clicar em tudo?

O cálculo do total, o desconto, o prazo, a trava de quem pode o quê: existe um jeito de conferir que isso está certo que não seja você clicando em tudo de novo, na mão, a cada mudança?

Como responder: pergunte à IA se existe um teste automático pra aquela regra — um programinha que roda sozinho e responde verde (passou) ou vermelho (falhou). Se não existe, a regra tá no "acho que sim". E "acho que sim" é o terceiro estado, nem verde nem vermelho.

Conta como não quando: a única prova que você tem é ter clicado e parecido certo. Isso importa porque "pareceu certo na tela" e "está certo" não são a mesma coisa — eu já passei quatro vezes por um bug que era um acento e a tela mostrava tudo lindo.

6. O login protege, ou só aparece?

Ter tela de login não quer dizer que o dado está protegido. A pergunta é se o usuário A consegue ver o dado do usuário B.

Como responder: o teste das duas contas. Abra duas contas suas, ponha um dado numa, e tente abrir esse dado pela outra. Cinco minutos, só o navegador.

Conta como não quando: a conta B viu o dado da A, ou você nunca testou. E esse é um "não" que não dá sintoma: a tela funciona igual pros dois. Não é paranoia minha — a Veracode testou geração de código ao longo de dois anos e publicou, em 2026, que mesmo com o código compilando certo em mais de 95% das vezes, só cerca de 55% passava nos testes de segurança. É medição de código gerado em laboratório, não do seu app — mas mostra que "funciona na tela" e "protege o dado" andam em velocidades bem diferentes.

7. Outra pessoa usa sem você do lado?

Alguém de fora — não você, não quem fez junto — já entrou, se cadastrou e usou de ponta a ponta, sem você explicando nada por WhatsApp?

Como responder: mande o link pra uma pessoa que não sabe nada do app e peça pra ela fazer a coisa principal. Fique calado e olhe.

Conta como não quando: só funciona quando é você mexendo, ou sempre precisa de um "ah, aqui você clica nisso". Uma pessoa de fora usando é o teste mais honesto que existe.

8. Você sabe quanto custa por mês?

Em real, com o dólar convertido, separando o que foi gasto pra construir (crédito de IA, que acaba) do que você paga pra manter no ar (mensalidade, que não acaba)?

Como responder: some a mensalidade da plataforma, do banco, do domínio, do e-mail. São seis linhas, e o número em real, com câmbio e IOF, chega maior do que o anunciado em dólar.

Conta como não quando: você não sabe o valor do mês que vem.

9. Existe backup, e ele já foi restaurado uma vez?

Backup é a cópia de segurança dos dados. A pergunta tem duas partes, e a segunda é a que importa.

Como responder: você tem uma cópia dos dados guardada fora da plataforma? E, mais importante: você já restaurou essa cópia uma vez, pra ver que ela presta?

Conta como não quando: nunca restaurou. Backup que nunca voltou não é backup, é esperança.

10. Você sabe o que fazer quando quebra?

Porque vai quebrar. A pergunta não é se, é se existe um procedimento — escrito em algum lugar, não só na sua cabeça — pra quando o cliente avisar que parou.

Como responder: existe um passo a passo de "o cadastro parou, e agora"? Está escrito?

Conta como não quando: o plano é "entrar em pânico e pedir socorro". Tem uma ordem pra isso, e ela cabe numa folha.

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

Quem responde isso depois de um sábado de construção costuma ficar entre seis e nove "não". Eu fiquei em sete. Repito pra não restar dúvida: isso não é a nota do seu trabalho. É a definição de protótipo. Protótipo é um app com esse número maior que zero. Produto é o mesmo app com o número zerado.

O cartão, pra hoje

Cole onde você anota as coisas do app:

PROTÓTIPO OU PRODUTO? (some os "não"; "não sei" = não)
[ ] 1. O código é meu, fora da conta da plataforma
[ ] 2. O banco é meu, e baixo os dados hoje
[ ] 3. Volto pra ontem — código E banco
[ ] 4. Teste separado do lugar do cliente
[ ] 5. Provo a regra sem clicar em tudo (verde/vermelho)
[ ] 6. Login protege (passei no teste das duas contas)
[ ] 7. Gente de fora usou sem mim do lado
[ ] 8. Sei o custo do mês, em real
[ ] 9. Tenho backup E já restaurei uma vez
[ ] 10. Tenho escrito o que fazer quando quebra

Era uma parede de várias, e elas têm ordem

Dá pra olhar esses dez "não" e querer zerar tudo essa semana. Não dá, e não é pra dar.

A distância entre o seu número e zero é distância de ordem. Ligar a trava de acesso antes de separar teste de produção faz você testar segurança em cima do dado do cliente. Migrar o banco antes de ter ponto de retorno faz a primeira migração ser irreversível. As dez perguntas se agrupam em três fases, e cada uma só abre depois da anterior fechar: Construa (perguntas 1 a 4 — o código e o banco seus, com volta e com teste separado), Estruture (5 e 6 — as regras provadas e o login que protege) e Opere (7 a 10 — gente de fora, custo, backup e o plano de quando quebra).

Por que isso acontece nessa ordem, semana a semana depois de alguém começar a usar, eu contei em por que oito horas não bastam. E a versão desse checklist pra cada entrega da IA — não o app inteiro, mas o pedacinho que acabou de chegar — é a definição de pronto em seis perguntas.

Mas o número você já tem. Responda as dez hoje, no seu app, e anote. Saber que são sete, e saber que sete é normal, já te tira do "será que isso presta?" e te põe no "eu sei exatamente o que falta". Que é um lugar bem melhor pra começar.

Fontes