GoVibee
Producto digital completo, de la idea a producción: app Android y web, panel de socios, API, infraestructura y operación. En línea en govibee.com.br, con el panel en parceiros.govibee.com.br y la landing de captación en seja.govibee.com.br. Construido en solitario de julio a octubre de 2026: ~500 commits en 6 repositorios y ~450 pruebas automatizadas.
Problema
Cada fin de semana, en Juazeiro (BA) y Petrolina (PE), alguien pregunta: "¿qué hay hoy?". La información sobre fiestas, bares y shows está dispersa en historias que desaparecen en 24 horas, grupos de WhatsApp y carteles. Los agregadores nacionales ignoran la escena local.
Solución
Una guía hiperlocal de vida nocturna y eventos que une los dos lados de este mercado:
- Quien sale descubre qué hay hoy, en el mapa, con horario, precio, clasificación por edad, lineup, ruta hasta el lugar y un chat en vivo con quienes van.
- Quien produce (bares, productores, artistas y agencias) publica gratis, llega a quien ya quiere salir y sigue números reales de interés: visualizaciones, rutas trazadas, clics en la entrada y de qué ciudades viene el público.
- Modelo de negocio B2B: suscripción de socio, impulso de eventos y destaque de artistas, con una oferta de lanzamiento para los primeros socios ("Fundador").
Rol
Concibió y construyó el producto de punta a punta: producto y UX; app, panel y API; base de datos y modelado; infraestructura, deploy y observabilidad; seguridad y LGPD (la ley brasileña de protección de datos); landing de ventas y analítica; y los precios, junto con el análisis de negocio.
Arquitectura
Polyrepo (decisión registrada en un ADR): un repositorio por componente, con versionado semántico y changelog propios.
- API: FastAPI con REST y WebSocket: reglas de negocio, autenticación, chat, notificaciones, analítica y automatizaciones.
- App: Flutter con una sola base de código, publicada como app Android y como app web (PWA).
- Panel: React y TypeScript para socios (locales, eventos, artistas, rendimiento, verificación) y para la operación (moderación, colas, socios).
- Infra: Docker Compose de producción, nginx, scripts de deploy, backup, restauración y monitoreo, y Terraform.
- Docs: contrato OpenAPI versionado, ADRs, roadmap y políticas.
- Landing: página de captación de socios, con SEO, Open Graph y medición anónima.
Decisiones técnicas
El criterio en todas fue la solución más simple que resuelve el problema de hoy, con el límite y la evolución anotados en el propio código.
- El contrato OpenAPI es la frontera entre la API y los clientes: los tipos del panel se generan a partir de él, y una prueba de contrato rompe el build si la API cambia sin actualizar la documentación.
- Latitud y longitud simples en lugar de PostGIS: suficiente para "cerca de mí" a escala regional y más barato de operar.
- OpenStreetMap en lugar de Google Maps, sin costo por solicitud.
- Máquina virtual (EC2) en lugar de ECS/Fargate: costo previsible para un MVP con una réplica.
- Programación de notificaciones y difusión del chat dentro del proceso, en lugar de cola, worker y pub/sub externos, con el camino de evolución documentado.
Funcionalidades
- Home curada, Explorar con scroll infinito en lista o mapa, filtros por ciudad, estilo, precio y gratis, y búsqueda.
- Regla de dominio "la noche cambia a las 5h": un evento del viernes a las 23h sigue siendo del viernes hasta la madrugada.
- Chat en vivo por evento con moderación: denuncia con silenciamiento automático, bloqueo, filtro de groserías, anti-flood y menores fuera de chats +18.
- Eventos privados con cola de acceso aprobada por el organizador; favoritos, reseñas, tarjeta vertical lista para historias y enlaces con vista previa.
- Push: evento nuevo cerca, evento que empieza, un local o artista favorito publicó y resumen del fin de semana.
- Para socios: informes de interés (serie de 30 días, ranking, leads por ciudad agregados y anónimos), sello Verificado con revisión humana y solicitud de impulso con cola del admin.
Ingeniería de producción
- Deploy con un comando por componente: verificaciones previas, pruebas, lint y tipado, build y publicación de la imagen, migración con backup automático antes, health check de la versión nueva y rollback automático si falla, probado en producción forzando un fallo.
- Sentry en la API y en la app (sin datos personales), UptimeRobot externo y un vigía en la propia VM cada 5 minutos, con alertas por correo.
- Backup diario cifrado (AES-256) en R2, retención de 14 días y prueba mensual automática de restauración comparada con producción.
- Runbook de recuperación ante desastres con RPO de 24 horas y RTO de 15 minutos a 3 horas, en un servidor de ~1 GB de RAM.
- gzip en nginx redujo la descarga inicial de la app web de ~11 MB a ~4 MB.
Seguridad y LGPD
- JWT de corta duración con refresh token rotativo y revocación; rate limit por IP real detrás del proxy y bloqueo de intentos de login.
- Verificación de correo para publicar, validación de CPF y CNPJ, OAuth de Google con correo verificado, uploads con verificación del tipo real y almacenamiento privado para documentos.
- Privacidad por diseño: perfil público solo con consentimiento, eliminación de cuenta en cascada (incluidos los archivos), analítica agregada y anónima y baja de correos con un clic.
Datos y automatizaciones
- Analítica propia, sin cookies ni identificadores: embudo del usuario, de la landing y del socio.
- Onboarding del socio, informe semanal de rendimiento y resumen del fin de semana por correo y push, con deduplicación, ventana en el horario local y modo de simulación en producción.
Números
- 6 repositorios y ~500 commits, de julio a octubre de 2026.
- ~450 pruebas automatizadas (API 297, app 117, panel 36) y ~91% de cobertura en la API.
- 42 migraciones de base de datos versionadas y reversibles y 6 decisiones de arquitectura registradas.
- Plataformas: Android, web (PWA), panel web y landing.
Aprendizajes
- La simplicidad con un límite anotado escala mejor que una arquitectura anticipada.
- Operar a ciegas es el mayor riesgo de un producto pequeño: monitoreo, backup probado y rollback llegaron antes que nuevas funcionalidades.
- Medir antes de vender: la analítica mostró que el cuello de botella era la oferta (eventos publicados), no la tecnología, y llevó el foco a lo comercial.
- Lo que promete el marketing tiene que coincidir con el código: la landing y la tabla de precios se auditaron contra la implementación y se corrigió cada diferencia.
Stack
- Python
- FastAPI
- PostgreSQL
- Redis
- WebSocket
- Flutter
- React
- TypeScript
- Docker
- AWS
- Terraform
- Sentry