Imagens de Play Store no vibe coding: 5 prints do celular, não da LLM

Quem faz o app em vibe coding ainda precisa das imagens de Play Store. Martin pediu essas imagens a uma LLM, recusou o que voltou e ficou com 5 prints tirados no celular, o mesmo aparelho em que o Fumava já estava instalado pelo link da loja.

A mesma live já tinha segurado o clique no RevenueCat para o AAB subir sem compras nativas. Nesta cena ele configura as páginas da Play Store com a tela que o testador já vê. Vale ver como isso terminou em vibe coding para enviar app para revisao na play store.

Tentei gerar as imagens de Play Store numa LLM

Martin descreveu o trabalho assim:

Configurando aqui as páginas que aparecem aqui na Play Store. Isso aqui, ó, essas páginas aqui. Então, agora uma parte mais de design, vamos dizer assim, né? Tentei fazer aqui numa LLM para gerar as imagens, mas ficou uma merda.

Ele não nomeou a LLM e não mostrou o prompt. O método seguinte já era outro:

Já começamos aqui. Botei um fundinho. Vai ser esses cinco prints aqui. Agora só tem que tirar print no celular e preencher aqui.

Ele manteve o fundinho e passou a preencher a ficha com print da tela do app. Já tinha uma versão funcional no teste fechado e o aplicativo no celular pelo link da Play Store, então a captura saía desse fluxo. Isso aparece também em supabase edge functions.

5 prints do celular e um fundinho

Nesta sessão ele subiu 5 prints. Falou "cinco prints" quando ainda ia capturar e, mais tarde, confirmou o lote:

Estamos com cinco print aqui.

Depois de confirmar os 5, compartilhou o lote no Drive. A live cita esses 5 arquivos e para aí, sem resolução do print do celular.

Martin constrói o Fumava em vibe coding e pediu à mesma LLM as imagens de Play Store. O pedido falhou na primeira tentativa, e o print já estava ao alcance porque o teste fechado já estava no ar. Isso aparece também em supabase auth. O mesmo problema apareceu em como sacar dinheiro da play store. Vale ver como isso terminou em vibe coding para lgpd.

Em vibe coding o gráfico 1024 por 500 também entra

Na ficha ele ainda pediu uns 1000 caracteres de descrição, com o limite da loja em 4000. Depois dos 5 prints restavam 2 arquivos: o recurso gráfico de 1024 por 500 pixels e o ícone do aplicativo. Os 5 prints são captura da tela. O recurso e o ícone são peças gráficas, e essas 2 saíram iguais. Vale ver como isso terminou em vibe coding para classificar app de habito na play store.

Agora falta aqueles dois arquivos que você tinha dito, um que era 1024 por 500 pixels e tal e propriamente dito o ícone do aplicativo, né? Mas, pô, ficou os dois igual, né? Será que isso é problema? Eu vou mandar print dos dois, um lado a lado.

Ele mandou os 2 lado a lado e perguntou o lugar do gráfico na loja:

onde que aparece o recurso gráfico que o Google Play pede de 1024 por 500 pixels? Onde que ele aparece quando tu tá vendendo o aplicativo?

A transcrição do agente nessa hora é ruim: "É, nesse caso aqui não Tem". Ele queria o canto do arquivo de 1024 por 500 na página pública, o lugar em que o gráfico aparece quando alguém está vendendo o aplicativo. Quem quiser a regra oficial precisa olhar o console, porque a live só grava a pergunta.

Martin fechou a conversa com a frase que a live gravou:

Bom, tem que botar igual, então.

O pacote da cena ficou com 5 prints do celular e os 2 arquivos gráficos no mesmo desenho. A live para antes da aprovação das imagens e mostra Martin seguir com esse conjunto.

Preencha a ficha com a tela que o testador já vê

Se o app já está no celular, abra as 5 telas que você quer mostrar, tire o print no aparelho e suba. O gráfico de 1024 por 500 e o ícone podem sair iguais nesta etapa. A pergunta que Martin fez, onde o gráfico aparece quando você está vendendo o app, se responde no próprio console.

Quem ainda está antes do teste fechado encontra o relógio dos testadores em como publicar um app na Play Store.

Dá para assistir à live e ouvir ele recusar a imagem da LLM e preencher os 5 prints.