Gomo PH

The Challenge: Two Jobs, One Person

The brief was ambitious: rebuild the Gomo mobile app AND establish Flutter as Stratpoint’s core mobile capability—at the same time.

This isn’t one job. It’s two jobs done in parallel.

Job 1: Mobile Project Lead for Gomo Lead a team rebuilding a mobile app for one of the Philippines’ biggest telco brands.

Job 2: Flutter Capability Lead for Stratpoint Build company-wide standards, architecture patterns, CI/CD pipelines, and mentorship systems. So future Flutter projects don’t start from scratch.

Both simultaneously. The approach: don’t do everything yourself. Build systems and standards that multiply your impact through the team.

The Approach: Set Standards, Build Teams, Deliver Product

I couldn’t do everything myself, so I had to multiply myself through the team.

Building the Flutter Capability

While the Gomo project was ongoing, I was establishing Stratpoint’s Flutter practice. This meant:

Hiring & Interviews I interviewed developers to find people who could grow into leadership roles. Not just technical skill—mindset mattered. Could they learn? Could they teach?

Standards & Architecture I created the Flutter standard for the company. Clean Architecture. BLoC/Cubit for state management. Consistent project structure. Pre-commit hooks. CI/CD pipeline configuration. Every new Flutter project would start with this foundation, not from chaos.

Documentation I documented everything. How to set up the environment. How to structure a feature. How to handle state. Why we chose these patterns. So when new people joined, they didn’t have to figure it out from first principles.

Pre-Sales & Scoping I created scoping and planning templates for Flutter projects. So when a client came in, we could estimate properly instead of guessing.

All of this while shipping Gomo.

Leading the Gomo Team

The Gomo project itself needed immediate attention.

I had around 4-5 teams working on different features, each with 1-2 Flutter developers. This meant I wasn’t managing a single team—I was coordinating multiple small teams, each with their own context and pace.

What I actually did:

• Code reviews on every pull request. Not to criticize, but to catch issues and spread patterns.
• Interviewed candidates for the mobile team
• Set up and maintained the CI/CD pipeline (Jenkins, Fastlane)
• Conducted code reviews and enforced pre-commit hooks
• Directly set up a multi-tiered mentorship system where senior devs mentored juniors, and I checked in with non-mentees to ensure their mentors were actually mentoring
• Conducted project planning and scoping
• Coordinated with the client
• Led the team as if I wasn’t a contractor from Stratpoint—with no bias, just focused on what Gomo needed

The key insight: I had to be available at every level. Junior devs needed guidance. Senior devs needed space. The client needed someone who understood both the technical reality and the business reality. I couldn’t just set standards and disappear.

The Technical Foundation

Tech Stack & Architecture

• Mobile: Flutter for iOS and Android
• State Management: BLoC and Cubit (pattern-based, not magic)
• Backend Integration: Firebase (real-time data, no waiting for API responses)
• CI/CD: Jenkins and Fastlane for automated builds and deployment
• Monitoring: Crash reporting integration to catch issues in production

Quality Enforcement

I made quality non-negotiable, but practical:

• Unit test coverage: Set to 80% minimum. Not because 80% is magic, but because it’s real coverage of real code paths.
• Pre-commit hooks: Automated linting and formatting before code ever reached CI. No “fix formatting in separate PR” discussions.
• CI checks: Every commit ran through analysis. We caught issues before they hit a branch.

These aren’t fancy—they’re boring. And boring is the goal. When quality is automated and enforced, you stop debating it and start shipping.

How Technical Leadership and Team Leadership Work Together

Here’s the key insight: technical leadership and team leadership aren’t separate things. They reinforce each other.

When you set high technical standards (80% test coverage, pre-commit enforcement), you’re not just improving code—you’re building a shared language for the team. Everyone understands why decisions matter.

When you mentor developers and conduct code reviews, you’re not just checking work—you’re embedding patterns so people make good decisions independently.

The result: A team that moves fast because they understand the why. A codebase that’s maintainable because quality is automated, not debated. A capability that lasts because it’s embedded in people and systems, not dependent on one person.

The Outcome: Capability That Lasted

The metrics show it worked:

• Crash rate: ~20% → less than 1%
• Test coverage: Established and maintained at 80%+
• Deployment: Consistent, automated, reliable
• Quality checks: Pre-commit hooks + CI enforcement preventing issues before they ship

But the bigger outcome is what you can’t measure in a spreadsheet: Flutter became a real capability at Stratpoint.

Future projects didn’t start from zero. They inherited:

• Proven architecture patterns (Clean Architecture, BLoC/Cubit)
• Ready-made CI/CD setup (Jenkins, Fastlane)
• Hiring and mentorship systems
• Documentation and scoping templates

That foundation only gets built when you’re intentional about it. And it only survives beyond one project when it’s embedded in people and systems.

Closing

Gomo taught me that leadership is about creating conditions where good work happens at scale.

I didn’t do all the work. I set standards. I mentored developers. I reviewed code. I coordinated 4-5 teams. And I did it all while shipping a product.

The best part? None of it depended on me staying. The next leader could walk in, use the standards, leverage the mentorship system, deploy via the CI/CD pipeline. Everything I built was designed to outlast me.

That’s the difference between leading a project and building a capability.

---