GPAC
Mobile app and delivery pipeline
3+
years on its architecture and CI/CD
Context
GPAC is a US recruitment platform. Its recruiters worked from the web app, and with a motto like “work from everywhere”, the company needed a mobile app. I joined to build it from scratch, thanks to my experience with published apps and CI/CD, and we designed the architecture together with UX and Product.
Decision
I looked into state management and architecture options and went with MVVM plus services, a feature-first structure and Riverpod. We didn’t know how big the app would get, and feature-first let it grow in an orderly way. We also built one detail screen shared by every entity, plus reusable components, which saves us from rebuilding what we already had and shortens delivery. CI/CD runs on Azure DevOps and Bitrise, and the app comes with analytics, Remote Config, feature flags, push notifications and A/B testing, so we can roll changes out gradually and decide with data.
Text description: On the circle of fifths, each key shares almost all its notes with the one next to it, which is why moving around it sounds stable and natural. GPAC’s pipeline works the same way. Every change starts as a pull request (C) and always moves in the same order through checks (G), tests (D), the Android and iOS builds (A) and release (E). It’s a simplified version of the real pipeline.
What I did
I decided on the architecture, the engineering practices and on having a design system, which didn’t exist on web or mobile. I built the CI/CD, the shared entity detail and the Remote Config, feature flag and analytics integration. Today I lead the technical, process and ticket documentation, and the supervised use of AI agents like Codex and Kiro, for which I defined their skills, what they can’t touch in the repo and which commands they can run.
What I’d do differently
I already made the technical calls from the start, like the architecture, state management and how each feature was implemented. What I’d change is taking the initiative from day one on processes too, which is where my path toward tech lead began, asking why each feature was chosen and setting them up from the start instead of adding them once the app was already running. The project also changed how I think, because I started deep in the technical side and now I think first about the user and what we’re actually giving them.