Maestro at Scale: Architecting a Deterministic Mobile Test Platform
Article Summary
Emre Erkek from Getir reveals how they turned Maestro from a simple testing tool into a deterministic platform that runs thousands of tests daily. Most teams fail at E2E testing scale—here's the architecture that actually works.
Getir's engineering team built a production-grade mobile automation platform using Maestro as the foundation. This isn't a tutorial—it's a detailed blueprint for solving the three core problems that break mobile testing at scale: data volatility, architectural complexity across multiple business domains, and operational divergence between local and CI environments.
Key Takeaways
- Mock-first architecture using Mockoon proxy eliminates staging dependencies and flaky tests
- Domain-aligned monorepo structure mirrors org chart, balancing team autonomy with shared utilities
- Four-tier flow hierarchy (Suites → Scenarios → Subflows → Components) enforces maintainability
- Runner contract abstraction enables infrastructure-agnostic execution across CI and device farms
- Three-tier observability strategy minimizes time-to-debug with video, network logs, and flakiness detection
Getir transformed Maestro into a scalable platform by treating automation as an internal product, systematically engineering out data volatility, complexity, and operational friction through architectural discipline.
About This Article
Getir's super-app covers multiple business areas like Market, Food, and Water. With hundreds of test flows, the codebase became messy. Setup logic mixed into test scenarios, and teams kept duplicating the same implementations. Login flows appeared five times across tests. The select-address flow had ten different versions.
Emre Erkek's team created a strict four-tier taxonomy for flows: Suites, Scenarios, Subflows, and Components. They used platform-specific file extensions like .android.yaml and .ios.yaml. GitHub CODEOWNERS enforced governance rules to catch accidental regressions while letting teams work independently.
The modular structure cut down maintenance work by centralizing UI component changes into single files. When the Add to Cart button changed from text to an icon, one update fixed every test across the super-app. Without this, they would have needed 50 separate fixes.