Procuro dev Full Stack + Mobile para apoiar o lançamento e o pós-lançamento do meu SaaS (correção de bugs, ajustes pontuais e suporte contínuo por valor mensal) e também adaptar/empacotar a aplicação para Android e iOS (Capacitor ou similar) com publicação na Play Store e App Store — essa etapa ainda não foi feita. Stack atual: monorepo pnpm; web React/Vite/pwa; api node/express; postgres; firebase auth; scrapers/pipeline (python). Preciso de code review/organização do projeto, validação de builds (web e mobile), correções de bugs, pequenos ajustes de produção se necessário, hardening básico (rate limit/segurança), observabilidade e checklist de go-live. No geral já está tudo funcionando; o principal agora é fechar a parte mobile (Capacitor + stores), revisar/estabilizar o código e depois manter suporte conforme os usuários entrarem.
Detalhes técnicos do projeto (para proposta): o “Se Liga No Ponto” está em um monorepo com pnpm workspaces. Frontend fica em apps/web (React + Vite + PWA) e existe apps/mobile preparado para empacotamento via Capacitor (Android/iOS), além de uma apps/waitlist opcional. O backend principal fica em services/api (Node/Express) e o runtime é Postgres-only (Firestore não é central/obrigatório, apesar de existir
firestore.rules no repo). Existem serviços auxiliares em services/discord-bot e componentes de captura/pipeline em Python (scrapers/pipeline em services/scraper-python, scraper-azul, scraper-latam e services/pipeline), com dados/histórico versionados em data/. Infra e deploy ficam em infra/ (stacks docker-compose para VPS, Caddy e backups, e stack via Coolify), e há guias em docs/ (deploy, runbooks e checklists).
Arquitetura em produção: o fluxo padrão é web (apps/web) autenticando via Firebase Auth, consumindo a API em /api/v2/*, persistindo em Postgres. Os scrapers/seeders rodam agendados via Cloud Scheduler (no gcp) ou cron (na vps), e há opção de bot para publicar notícias. Hoje a arquitetura recomendada no repo aponta backend (api + scrapers + pipeline) em vps via coolify, web em firebase hosting e runtime-config separado (para web e mobile) em um endpoint de
runtime-config.json — a ideia é conseguir trocar o apiBaseUrl sem rebuild do app. Há caminhos documentados tanto para ecossistema Google (Cloud Run/Cloud Scheduler/Cloud sql) quanto para vps pura (docker-compose + caddy + backup via rclone).
Local/dev: requer Node 20+ (preferência 22 LTS) e pnpm 9+. Instalação do monorepo via pnpm -r install (ou script do root). Para rodar: web em http://localhost:5173 (pnpm -C apps/web dev / pnpm dev:web) e API em http://localhost:8080 (pnpm -C services/api dev / pnpm dev:api), com healthcheck em /health. Existe um modo de testar UI sem depender de Firebase/Auth local usando query param /app?dev=1. Variáveis: o web tem .env.example com VITE_FIREBASE_* e configuração de API (em dev pode usar VITE_API_URL, mas em produção é preferível runtime-config). A API precisa obrigatoriamente de DATABASE_URL (Postgres), além de segredos para agendadores/scrapers/criação de notícias (sem expor valores no anúncio), e em produção pode usar Firebase Admin (service account json na vps ou adc no cloud run), app check e smtp se habilitado. Segredos são mantidos fora do repo (infra/vps/
.env.local gitignored para local; infra/vps/.env fora do repo em produção ou secret manager). O repo já tem
firebase.json para hosting.
Mobile (Capacitor): a parte mobile precisa ser finalizada/validada (build/teste/empacotamento + publicação). O fluxo do repo inclui preparar bundle e sincronizar (scripts tipo mobile:prepare e mobile:sync), abrir no Android Studio/Xcode (open:android/open:ios) e rodar em emulador/dispositivo. Observação importante: no mobile não se usa pwa/service worker; é sempre online e consome a api. Atualizações de ui/código do app só via loja (novo build), enquanto conteúdo (ofertas/histórico/notícias) muda em tempo real via api.
Assinaturas/pagamentos (para alinhamento): o modelo desejado é assinatura via website no paywall (sem iap/revenuecat). O repo menciona gateway como item pendente e já existe base de middleware/rota para exigir assinatura em rotas premium e uma rota manual de subscription; o que falta é integrar o provedor real (no meu caso, asaas) via api + webhooks e persistência do status de assinatura no backend.
O que ainda falta para ficar 100% online: finalizar a etapa de publicação Android/iOS (signing, ids, build pipeline e stores), confirmar/configurar Postgres em produção com DATABASE_URL, implantar/validar políticas básicas de segurança e observabilidade (rate limit em rotas sensíveis, gestão de segredos, logs/metrics), e rodar um checklist de go-live (runbooks do repo). Idealmente, o trabalho começa com uma auditoria curta (mapear débitos críticos e riscos), correções e estabilização, validação de builds (web+mobile), e segue com suporte mensal no pós-lançamento.
Prazo de Entrega: Não estabelecido