Pitch: Construí 10 apps Flutter sozinho pra aprender ASO na prática — decisões técnicas e o que eu erraria diferente · PhantomTecnologia1

Sou dev full stack, trabalho principalmente com Laravel/PHP no dia a dia. Nos últimos meses resolvi aprender Flutter construindo algo real em vez de só seguir curso, e o resultado foi uma suíte de 10 apps Android no mesmo nicho (frases/mensagens prontas pra WhatsApp), cada um separado por categoria (bom dia, frases de amor, versículo do dia, motivação, status, humor, frases tristes, indiretas, rap e aniversário).

Não vim aqui pra vender app de frase pra ninguém — o público daqui nem é o público final desses apps. Vim compartilhar as decisões técnicas por trás e ouvir crítica de quem já passou por algo parecido, porque sei que aqui a régua é alta.

Por que 10 apps pequenos em vez de 1 grande

Essa foi a decisão mais discutível do projeto. Argumentos a favor que usei:

Cada app compete por keywords de cauda mais longa e específica na Play Store, em vez de um app genérico competindo com apps gigantes de "frases".
Dá pra medir performance isolada por nicho (instalação, retenção, eCPM de anúncio) sem um nicho ruim "esconder" um nicho bom nas métricas agregadas.
UX mais direta — quem quer só versículo do dia não navega por menu de humor e indireta.

Contra, que só descobri lendo depois (e o pessoal aqui provavelmente já sabia): o Google Play tem política de "minimum functionality" e pode marcar contas com muitos apps parecidos como spam/duplicidade, mesmo com propósito de nicho genuíno. Ainda não fui penalizado, mas é risco real que eu deveria ter pesquisado antes de publicar o primeiro, não depois.

Arquitetura: tudo offline, de propósito

Todo o conteúdo (frases, versículos, categorias) fica embarcado localmente no app — nada de API/backend pra servir texto estático. Isso resolve dois problemas ao mesmo tempo: custo de infra fica em ~zero (sem servidor pra manter rodando pra 10 apps) e a experiência funciona sem internet, o que é relevante pro público-alvo (uso cotidiano de celular, muitas vezes com conexão instável).

O trade-off óbvio: atualizar conteúdo significa nova versão do app, não um simples PUT numa API. Pra esse tipo de conteúdo (frases não mudam com urgência) o trade-off valeu a pena, mas seria diferente se o conteúdo precisasse de atualização frequente.

Monetização

AdMob + compra única pra remover anúncio, sem assinatura. Decisão consciente: pra esse tipo de app, assinatura recorrente pareceria abusiva pro usuário (ninguém quer pagar mensalidade por "frase pronta"), então preferi um modelo que o usuário entende e aceita.

O que eu faria diferente
Pesquisar a política de conta/minimum functionality do Google Play antes de publicar 10 apps parecidos, não durante.
Validar com 1-2 apps antes de escalar pra 10 — construí os 10 baseado em intuição de nicho, sem validar o primeiro com dados reais antes de replicar o modelo.
Definir métricas de sucesso por app desde o início (hoje comparo de forma meio informal).

Queria muito ouvir de quem já publicou apps em escala parecida (ou maior): vale a pena esse modelo de "muitos apps de nicho" ou é melhor consolidar em menos produtos com mais profundidade? E alguém já foi penalizado por minimum functionality nesse tipo de cenário?

Pra quem quiser ver o resultado prático (sem call to action, só referência do que foi descrito acima):