Estudo de caso · projeto autoral
App para cidadãos denunciarem problemas ambientais na Paraíba — que nasceu como trabalho de disciplina e virou produto.
01 /
O EcoHub nasceu como projeto de disciplina no Unipê e deixou de ser exercício: está inscrito no Prêmio de Inovação CSED 2026 e em fase de piloto com um escritório de advocacia.
O cidadão fotografa o problema — lixo, queimada, buraco, enchente, esgoto, falta de iluminação —, marca no mapa e acompanha o status oficial. Do outro lado, a autoridade verifica, encaminha e resolve.
02 /
Mapa de ocorrências
Denúncias sobre o mapa de João Pessoa, com filtro por status.
Nova denúncia
Até 3 fotos, vídeo de 30 s, categoria e localização.
Panorama da cidade
Tipos mais reportados e bairros mais afetados.
Fila de verificação
A autoridade confirma as denúncias, da mais antiga para a mais nova.
Painel da autoridade
Funil de triagem, tempos médios e relatório em PDF.
03 /
Um app de denúncia lida com gente que pode sofrer retaliação. Por isso a privacidade não ficou para depois: ela está nas regras do banco, no tratamento das fotos e nos testes.
O documento público da denúncia anônima não guarda o UID de quem denunciou — e um teste de regra garante isso.
Os metadados saem da imagem para que a localização e o aparelho gravados nela não reidentifiquem o denunciante.
A pessoa apaga a conta e os dados; o consentimento vai junto.
As regras do Firestore validam toda escrita, com negação por padrão. Denunciar exige e-mail verificado, e o App Check barra scripts.
Ocultar conteúdo e mudar o status oficial são ações exclusivas da autoridade, e usuário comum não consegue se dar esse papel.
Cada ação da autoridade entra numa linha do tempo que não aceita edição nem exclusão.
04 /
Os testes unitários cobrem models, services, utils, widgets e controllers. As regras do Firestore são testadas contra o emulador, com testes que tentam burlá-las: forjar o autor, se dar papel de autoridade, vazar o UID numa denúncia anônima.
Análise e testes
Regras de segurança do Firestore
Build Android (APK)
roda depois de “Análise e testes”
alguns dos testes em test/firestore_rules/firestore.rules.test.js
05 /
Diante de uma proposta de migrar para Supabase e Postgres, com meta declarada de 30 mil usuários, registrei a decisão num ADR (docs/adr/0001): o app continua no Firebase, com Cloud Functions em TypeScript como a camada de servidor que ainda falta.
Ganho
O caso de uso é fotografar descarte irregular na rua, às vezes sem sinal. O Firestore já entrega fila de escrita e cache offline sem código extra.
No Supabase, recuperar isso exigiria PowerSync ou ElectricSQL — custo e complexidade novos para algo que já funciona.
Ganho
Ficar evita reescrever as 694 linhas de regras como RLS, além de serviços, repositórios, login e testes.
Perco PostGIS (busca por raio sai de graça) e JOIN nos relatórios. Contornos aceitos: geohash no mapa e export para o BigQuery no analítico.
| Item | Firebase Blaze | Supabase Pro | Backend próprio |
|---|---|---|---|
| Backend / compute | Functions Gen2 ~$10 | Pro $25 + compute | 2 servidores $60–80 |
| Banco | Firestore ~$20 | incluso (8 GB) | Postgres gerenciado $60–120 |
| Auth | $0 até 50 mil MAU | incluso | próprio ou Clerk |
| Crash / analytics | Crashlytics $0 | Sentry ~$26 | ~$26 |
| Total por mês | ~$65–90 | ~$70–150 | ~$200–400 |
Estimativa do ADR para 30 mil usuários (~10 mil ativos por dia). No piloto de 500 usuários, o Firebase fica em ~$9/mês — só as lojas — contra ~$34/mês do Supabase, que cobra o plano mesmo sem uso.
