Journey Rewards — Stepping In Mid-Flight

The Engagement

Journey Rewards is a loyalty and rewards platform with native Android and iOS apps built on a shared Kotlin Multiplatform Mobile layer. When the previous external team completed their engagement, the company needed someone to pick up the work without losing momentum.

My team came in as the replacement: seven contractors in total, including two engineers who stayed on from the previous team — one on each platform — alongside four new engineers from my side. I stepped in as Head of Mobile.

The mandate was clear: don’t break what’s working, fix what’s not, and keep shipping.

Taking Ownership Without a Rewrite

The first thing we did was read the code — all of it.

In situations like this, the temptation is to arrive with opinions before you’ve earned them. We didn’t. We spent the first stretch of the engagement understanding what the previous team had built before making any changes to it.

The honest verdict: it was good work. The shared KMM layer was well-structured, with clean platform boundaries, thoughtful use of shared coroutines for reactive state, and expect/actual declarations limited to the surfaces that genuinely required them — date handling, serialisation, auth, push notifications. The architecture didn’t need to be rethought. Our job was to understand it well enough to extend it safely.

That decision — to inherit rather than rewrite — turned out to matter more than any individual technical contribution. The two retained engineers were invaluable here. They carried institutional knowledge that no amount of reading could fully replace, and the overlap between teams made the transition far smoother than a clean break would have.

Building Management From Scratch

The bigger challenge wasn’t the code. It was the structure around it.

Prior to our engagement, mobile development had been managed externally — processes, prioritisation, communication with the product side all ran through outsourced layers. When we came in, that infrastructure came with us. We were building internal mobile management for the first time, not inheriting it.

Early on, everything flowed through me. Engineers had questions, decisions needed to be made, blockers needed clearing — and I was the junction point for all of it. That’s fine as a starting position, but it’s not where you want to end up.

The shift happened gradually, and you could feel it when it did. Engineers started going directly to the people who could unblock them. They’d built enough context about the company — and enough confidence — to navigate it themselves. They stopped needing me in the middle.

That’s the thing you’re actually trying to build in an engagement like this: a team that doesn’t depend on you to function. By the time the PM came on board mid-engagement, I was able to move progressively from coordination to execution, contributing directly to both the Android and iOS codebases.

Delivery

Feature work ran across both platforms throughout the engagement. On Android, we worked within a Jetpack Compose UI layer consuming the shared domain directly. On iOS, I was involved in feature work and code reviews alongside the iOS engineers.

The KMM architecture held up well under this. Shared business logic — written once in commonMain — propagated cleanly to both platforms. The boundary between shared and platform-specific code stayed intact.

The 4 Months

The engagement ran July through October 2025. The process improvements were the most visible win — fewer blockers, clearer ownership, a delivery cadence that matched the product team’s pace. The technical foundation was already strong; our job was to build the human layer on top of it.

The company later chose to move away from the KMM architecture entirely, opting to rebuild in React Native. That project has yet to ship. The two native apps — Android and iOS, sharing a single Kotlin domain layer — remained the more durable foundation.

What I’d Carry Forward

Audit before you touch anything. Inheriting a codebase with goodwill and curiosity, rather than assumptions, is what let us move quickly once we understood what we had.

And build toward your own redundancy. An engagement that ends with engineers routing everything through you has produced a dependency, not a team. The goal is to be unnecessary by the time you leave.