Perfeito. Vou consolidar as duas revisões (a do Claude + a minha crítica) em uma análise final estratégica, com foco claro em:

  • Controle agressivo de custos
  • Redução deliberada de autonomia do usuário free
  • Preservação de UX para usuário premium
  • Caminho realista de migração de plataforma (se/when fizer sentido)

Vou tratar isso como um documento de decisão de arquitetura e produto, não só técnico.

📊 Análise Final de Custos & Estratégia de Escala

Vanguru Mobile — Janeiro/2026

🎯 Objetivo Estratégico

Garantir que:

  1. Usuários Free nunca consigam se comportar como Heavy Users
  2. Usuários Premium tenham experiência fluida, previsível e sem atrito
  3. O custo cresça de forma controlada e intencional
  4. Exista um plano de escape do Firebase antes que ele vire gargalo financeiro

🧠 Princípio Central (Muito Importante)

Custo em cloud não é problema técnico — é problema de autonomia do usuário.

Portanto:

  • Free = autonomia reduzida
  • Premium = autonomia expandida
  • Arquitetura serve para impor limites, não só escalar

🧩 EIXO 1 — Redução de Autonomia do Usuário (Controle de Heavy Users)

1️⃣ Classificação Operacional de Usuários

Não basta Free vs Premium. Internamente, você precisa de tiers operacionais:

Tier Tipo Objetivo
Free Usuário exploratório Testar valor
Free+ Usuário ativo mas limitado Converter
Premium Usuário profissional Retenção
Premium Pro (futuro) Heavy user real Margem

📌 Heavy user nunca deve existir no Free.

2️⃣ Estratégias Agressivas para Usuário Free 🚫

🔒 Limitações Estruturais (não negociáveis)

Rotas

  • Máx. 3–5 rotas ativas
  • Máx. 1 rota por dia
  • Máx. X execuções/mês

➡️ Impacto direto:

  • Redução de chamadas à Directions API
  • Redução de writes de execução

Execução de Rota

  • Atualização de posição:

  • Tempo: mínimo 60–90s

  • Distância: mínimo 150–200m
  • Sem execução em background ilimitada
  • Kill da rota se app ficar > X minutos em background

➡️ Heavy user perde viabilidade operacional no Free.

Passageiros

  • Máx. 5–10 passageiros
  • Sem histórico longo
  • Dados antigos truncados (ex: últimos 7 dias)

Histórico

  • Execuções:

  • Free: 7 dias

  • Premium: 90–180 dias

  • Eventos antigos são:

  • Agregados

  • Ou deletados via TTL

Mapas

  • Maps SDK:

  • Lazy loading mais agressivo

  • Directions:

  • Forçar uso de rota cacheada

  • Bloquear recálculo manual frequente

3️⃣ Fricção Intencional no Free ⚠️

Fricção não é bug, é ferramenta de produto.

Exemplos:

  • Delay artificial (2–3s) ao iniciar rota
  • Avisos recorrentes:

“Atualizações em tempo real são limitadas no plano Free” * Confirmações extras para ações custosas

➡️ Isso reduz uso compulsivo e empurra conversão.

4️⃣ Usuário Premium: Leniente, Fluido, Previsível ✅

Características do Premium

  • Atualização de posição:

  • 30s ou dinâmica por distância

  • Execução contínua (foreground/background)
  • Cache mais agressivo a favor do usuário
  • Sem delays artificiais
  • Histórico longo
  • Reexecução rápida de rotas

📌 Premium paga para não pensar em limites.

🧩 EIXO 2 — Estratégia Técnica de Redução de Custos (Firebase)

1️⃣ Firestore: Limitar Writes é Prioridade #1

Medidas Concretas

A. Throttling inteligente

  • Escrita apenas se:

  • distance > X

  • OU time > Y
  • Free: X alto / Y alto
  • Premium: X baixo / Y baixo

B. Escritas condicionais

if (hasMeaningfulChange) {
  write();
}

➡️ Evita duplicação silenciosa.

C. TTL agressivo

  • Free:

  • Execuções > 7 dias → delete

  • Premium:

  • Execuções > 90/180 dias → delete ou archive

2️⃣ Google Maps: Tornar Directions um Recurso Premium

Estratégia-chave 🎯

  • Recalcular rota manualmente = Premium

  • Free:

  • Usa rota sugerida inicial

  • Cache forçado

  • Premium:

  • Recalcular quando quiser

➡️ Isso protege seu maior driver de custo.

3️⃣ Realtime Database (Uso Cirúrgico)

Não migrar tudo — usar apenas para telemetria volátil.

Boa aplicação:

  • Posição atual do veículo
  • Status “em rota”
  • Último ping

Não usar para:

  • Histórico
  • Contratos
  • Dados relacionais

📌 Isso reduz writes em Firestore sem explodir tráfego.

🧩 EIXO 3 — Estratégia de Migração de Plataforma (Quando Firebase Não Bastar)

1️⃣ Quando Firebase deixa de fazer sentido?

Sinais claros:

  • 5k usuários ativos mensais

  • 1k heavy users premium

  • Directions API virando >50% do custo
  • Firestore writes >1–2M/mês

2️⃣ Opção A — Firebase → Google Cloud “Puro”

Arquitetura alvo:

Firebase GCP
Auth Identity Platform
Firestore Firestore (mantém) ou Cloud SQL
Functions Cloud Run
Hosting Cloud Run / CDN
RTDB Pub/Sub ou Memorystore

Vantagens:

  • Mais controle de custo
  • Melhor observabilidade
  • Escala previsível

Desvantagens:

  • Mais DevOps
  • Menos velocidade de iteração

📌 Caminho natural, não ruptura.

3️⃣ Opção B — Backend Próprio (Cloud Run + DB)

Stack típica:

  • Cloud Run (API)
  • PostgreSQL
  • Redis
  • Worker para GPS ingest

Quando vale a pena:

  • Heavy users dominam a base
  • Modelo B2B ou contratos fixos
  • SLA e previsibilidade > velocidade

📌 Só faz sentido com Premium forte.

🧩 EIXO 4 — Estratégia de Produto: Free x Premium

Comparação Direta

Feature Free Premium
Rotas Limitadas Ilimitadas
Execuções Limitadas Ilimitadas
Atualização GPS Lenta Rápida
Histórico Curto Longo
Recalcular rota ❌ ✅
Background Restrito Livre
Ads Sim Não
Suporte Básico Prioritário

📌 Conclusão Estratégica

O que está certo:

  • Firebase é perfeito até ~1–2k usuários
  • Custo atual é baixo e controlável
  • Arquitetura já nasce defensiva

O que é obrigatório:

  1. Heavy user só pode existir no Premium
  2. Free precisa ter limites claros e sentíveis
  3. Directions API deve ser tratada como recurso premium
  4. TTL e throttling não são opcionais

Decisão-chave:

Você não escala controlando cloud — você escala controlando usuário.

Se quiser, no próximo passo posso:

  • Transformar isso em roadmap técnico (épicos GitHub)
  • Criar matriz de decisão: Firebase vs GCP vs Backend próprio
  • Simular break-even Premium x custo cloud

Esse material já está em nível de CTO / investidor.