GPAC
App móvil y pipeline de entrega
3+
años en su arquitectura y CI/CD
Contexto
GPAC es una plataforma de reclutamiento de EE. UU. Sus reclutadores trabajaban desde la web, y con un lema como «work from everywhere» hacía falta una app móvil. Entré para construirla desde cero, por mi experiencia con apps publicadas y con CI/CD, y la arquitectura la diseñamos junto con UX y Producto.
Decisión
Investigué opciones de manejo de estado y de arquitectura, y me quedé con MVVM con servicios, una estructura feature-first y Riverpod. Como no sabíamos qué tan grande iba a ser la app, feature-first nos dejó crecer con orden. También hicimos una sola pantalla de detalle para todas las entidades y componentes reutilizables, y eso nos ahorra rehacer lo que ya teníamos y acorta las entregas. El CI/CD corre en Azure DevOps y Bitrise, y la app trae analytics, Remote Config, feature flags, notificaciones push y A/B testing para lanzar cambios poco a poco y decidir con datos.
Descripción en texto: En el círculo de quintas, cada tonalidad comparte casi todas sus notas con la de al lado, por eso avanzar por él suena estable y natural. Así funciona el pipeline de GPAC. Cada cambio arranca en una pull request (C) y avanza siempre en el mismo orden por el análisis (G), las pruebas (D), los builds de Android e iOS (A) y la publicación (E). Es una versión simplificada del pipeline real.
Lo que hice yo
Decidí la arquitectura, las buenas prácticas y que tuviéramos un design system, algo que no existía ni en web ni en móvil. Construí el CI/CD, el detalle compartido de entidades y la integración de Remote Config, feature flags y analytics. Hoy llevo la documentación técnica, de procesos y de tickets, y el uso supervisado de agentes de IA como Codex y Kiro, para los que definí sus skills, lo que no pueden tocar en el repo y los comandos que pueden correr.
Qué haría distinto
Desde el inicio ya tomaba las decisiones técnicas, como la arquitectura, el state management y cómo implementar cada feature. Lo que cambiaría es tomar la iniciativa desde el día uno también en los procesos, que es donde empezó mi camino hacia tech lead, preguntando por qué se eligió cada feature y armándolos desde el inicio en vez de irlos agregando con la app ya andando. El proyecto también me cambió la forma de pensar, porque empecé muy metido en lo técnico y hoy pienso primero en el usuario y en qué le estamos entregando.