Capstone: do protótipo ao produto

Seis semanas depois

Façamos as contas. Seis semanas depois da primeira linha de prompt, a app do Tom é usada por três turmas em duas escolas. O professor de matemática pagou a versão «turma» via o Payment Link. A Lina exibe um streak de 34 dias. E o Tom recebeu esta semana quatro mensagens: duas ideias de funcionalidades, uma pergunta, um bug menor. É o momento charneira que todos os criadores conhecem: a app funciona — mas uma app que funciona ainda não é um produto. Um produto é uma app mais um ciclo: mede-se, escuta-se, decide-se, itera-se. Este capítulo instala esse ciclo, e depois envia-te para o teu próximo projeto.

Medir: números sem espiar

Primeira pergunta de um responsável de produto: «quem usa o quê, realmente?». As impressões mentem — os números, menos. Mas atenção ao reflexo «Google Analytics»: para uma pequena app, sobretudo usada por menores, queres uma ferramenta de analytics respeitadora da privacidade como o Plausible ou o Umami: sem cookies, sem perfis, sem banner de consentimento interminável, apenas contadores anónimos. A integração cabe numa linha que a IA adicionará em trinta segundos, e o painel de controlo diz-te o essencial: quantas visitas, que páginas, que dias.

A armadilha seguinte é olhar para os números errados. O número de visitas lisonjeia o ego mas não diz nada de útil: chama-se a isso uma métrica de vaidade. O Tom escolhe para si uma métrica norte — O número que diz se a app cumpre a sua missão: «quantos alunos marcam pelo menos um hábito três dias por semana?». Tudo o resto (visitas, contas criadas, páginas vistas) é apenas decoração à volta desta pergunta. Escolhe a tua com o mesmo critério: se este número subir, a tua app presta objetivamente mais serviço.

Escutar: organizar o feedback

As mensagens dispersas do Tom — um SMS, dois emails, uma palavra no recreio — são o sintoma de um produto sem canal de feedback. A solução está na própria app: um pequeno botão «uma ideia? um problema?», um mini-formulário, e cada envio arrumado numa tabela da base. Tens todas as competências para o construir — é até um excelente exercício de síntese dos capítulos 6 a 9: um formulário (entradas validadas!), uma tabela Supabase (com RLS!), um limite de envios (capítulo 9!):

Adiciona um módulo de feedback à minha app de acompanhamento de hábitos.
O que quero:
1. um pequeno botão discreto «uma ideia? um problema?» no fundo da página principal
2. ao clique: um mini-formulário com um campo de texto de 500 caracteres no máximo e uma escolha «bug / ideia / outro»
3. cada envio é registado numa tabela feedback do Supabase com o user_id, a categoria e a data — com a Row Level Security ativada
4. limites: 5 envios por utilizador e por dia, validação do conteúdo do lado do servidor, mensagem de agradecimento após o envio
5. cria também uma página /admin acessível apenas à minha conta, que lista os feedbacks do mais recente ao mais antigo com um contador por categoria
Uma etapa de cada vez, testo antes de continuar.

Com o módulo instalado, a regra de interpretação: os pedidos não são necessidades. Quando três alunos pedem «um modo escuro», a necessidade real é talvez «a app encandeia-me à noite no dormitório». Antes de adicionar o que te pedem, volta ao problema: «o que te incomoda, concretamente, em que momento?». Por vezes a boa resposta é a funcionalidade pedida; muitas vezes, é uma solução mais simples que ninguém tinha formulado.

Priorizar: a matriz do construtor a solo

Com os analytics de um lado e o feedback do outro, a tua lista «mais tarde» vai inchar depressa. A triagem faz-se com quatro perguntas, por esta ordem: quantos utilizadores são afetados? (um incómodo citado cinco vezes bate uma ideia brilhante citada uma vez), está alinhado com a tua métrica norte? (uma funcionalidade que não ajuda a missão esperará), que esforço? (pede à IA que estime: pequeno, médio, grande trabalho), e é reversível? (uma experiência que se pode retirar tenta-se mais livremente do que um compromisso definitivo).

• Muitos utilizadores + alinhado + pequeno esforço: fá-lo esta semana.
• Alinhado mas grande esforço: divide-o em mini-PRD (capítulo 3) e espalha-o no tempo.
• Poucos utilizadores afetados: deixa amadurecer — se voltar três vezes, subirá sozinho.
• Não alinhado com a missão: recusa educadamente, mesmo que seja uma boa ideia. Sobretudo se for uma boa ideia.

O último ponto é o mais duro e o mais importante: dizer não. Cada funcionalidade adicionada é uma superfície a manter, depurar e proteger para sempre. Os melhores produtos não são os que fazem mais coisas, são aqueles em que cada coisa serve a missão. O Tom recusa assim um «chat entre alunos» — excelente ideia, mau produto: a missão dele são os hábitos, não as mensagens.

Monetizar sem se trair

O Payment Link do capítulo 8 transformou a app do Tom numa atividade que rende — modestamente, mas realmente. Chegou o momento de refletir com calma. Os modelos adaptados a uma pequena app: o freemium (o coração gratuito, confortos pagos — a escolha do Tom: grátis para os alunos, versão «turma» com painel de controlo para os professores), o pagamento único (simples e honesto, adaptado às ferramentas), o donativo (viável para uma ferramenta amada por uma comunidade), e a assinatura (reservada a um valor recorrente evidente — não a imponhas a uma ferramenta que se usa duas vezes por mês).

Dois princípios no momento de fixar o preço. Primeiro, a coerência com a missão: o Tom nunca fará pagar um aluno — a missão é pedagógica, são as escolas e os professores que financiam. Depois, a simplicidade: um único plano pago, um preço redondo, uma página que o explica em três benefícios. Poderás complexificar quando tiveres cem clientes; com cinco clientes, cada hora passada na grelha tarifária é uma hora roubada ao produto.

Dar a conhecer: mostrar o problema, não a técnica

O passa-palavra trouxe três turmas ao Tom; para ir mais longe, precisa de uma verdadeira página de apresentação — aquela que um professor descobre ao clicar no link partilhado na sala dos professores. Regra de ouro do iniciante: não se vende a técnica, mostra-se o problema resolvido. Ninguém se inscreve para «uma app Supabase com RLS»; inscrevemo-nos para «ajudar os vossos alunos a manter as rotinas de trabalho». O Tom manda-a gerar com todo o seu saber-fazer de prompts:

Cria uma página de apresentação de marketing para a minha app de acompanhamento de hábitos, na rota /apresentacao.
Audiência: professores do ensino básico que descobrem a app através de um colega — não programadores.
Estrutura:
1. um título que fala do problema resolvido: ajudar os alunos a manter as rotinas de trabalho
2. três benefícios concretos em três cartões, sem nenhum jargão técnico
3. uma captura de ecrã da app ao centro, limpa, sobre fundo claro
4. um curto testemunho de professor — fornecer-te-ei o texto exato
5. dois botões: «experimentar gratuitamente» para o registo, e «versão turma» para a página de pagamento
Estilo: coerente com a app, depurado, destaque verde, tranquilizador, legível no telemóvel.
A página deve carregar depressa: sem animações pesadas, sem bibliotecas inúteis.

O ritmo duradouro: iterar sem se esgotar

Último ingrediente do produto: o ritmo. O erro clássico pós-lançamento é o sprint permanente — três funcionalidades por semana durante um mês, e depois o abandono completo. O ritmo duradouro do construtor a solo parece-se antes com isto: uma melhoria por semana, escolhida pela matriz de priorização, entregue segundo o método dos capítulos 3-4 (mini-PRD se for grande, construir-testar-commit sempre), mais um quarto de hora de higiene semanal: um olho nos analytics, a triagem dos feedbacks, uma vista de olhos às páginas de estado e ao teto de despesa de IA.

E aceita uma ideia contraintuitiva: um produto pode estar terminado. Se a métrica norte está boa, os feedbacks se esgotam e a app presta exatamente o serviço previsto, tens o direito de a deixar funcionar em modo de manutenção e de passar a outra coisa. «Terminado e útil» é um estado glorioso, não um fracasso de ambição. Nem todas as apps têm vocação para se tornarem impérios — a do Tom faz precisamente o que deve fazer, e é essa a sua maior qualidade.

O teu percurso — e o projeto seguinte

Tira um segundo para medir o caminho, porque é considerável. Em dez capítulos, aprendeste a enquadrar uma ideia (mini-PRD), escolher ferramentas, construir iterando, depurar metodicamente, implementar, autenticar utilizadores, centralizar dados em segurança, ligar serviços externos, proteger o conjunto, e pilotar um produto com números e feedback. Não são conhecimentos de «vibe coder iniciante»: é, muito exatamente, o ciclo de vida completo de um produto de software — aquele que as equipas profissionais seguem, e que agora sabes desenrolar dialogando com uma IA.

A continuação escreve-se sozinha: escolhe um segundo projeto, um degrau mais ambicioso, e redesenrola o ciclo inteiro. Irás três vezes mais depressa — não porque a IA terá progredido, mas porque tu saberás o que pedir, o que exigir, o que testar e quando dizer não. Era o objetivo secreto deste curso desde a primeira página: não ensinar-te a fazer uma app, ensinar-te a fazer tantas quantas quiseres. O Tom já tem a ideia seguinte — um caderno de leitura para o clube da biblioteca. E tu?