Fintech app with virtual payment cards

Until this project, I’d only worked with native iOS. Joining MeguMethod’s team on a fintech app with loans and virtual payment cards meant learning Kotlin, working with code shared by iOS and Android, and finding my way around a much bigger team. It was my first professional project after finishing school.

Roughly five teams across three companies worked on the product. It was a lot to take in, and sometimes overwhelming, but also exciting.

Learning Kotlin by building something real

Transaction history was an early milestone for me: building a feature from scratch and seeing it through to release. I worked on both the shared Kotlin logic and the iOS screens, then added search, filters and pending card payments.

This was before I used AI coding tools, so there was plenty of working things out myself. Colleagues and code reviews helped, and I took a Kotlin course, watched YouTube videos and studied in my own time. I could put what I was learning straight into the feature I was building.

Learning to work across teams

The backend also served other applications, so getting the right data for our screens wasn’t always straightforward. A colleague at MeguMethod maintained the GraphQL layer between the backend and the app, and I worked with him to figure out what we needed.

For transaction history, I started with what he provided and asked for tweaks. Later, with the repayment schedule, I did the investigation myself and came to him with a proposal. I was getting more comfortable asking questions and explaining what the app needed.

Making sense of the repayment schedule

The repayment schedule was a challenge. My economics background gave me a starting point, but I still had to get my head around the product’s rules: cashback covering extra repayment months, a final repayment that could be smaller than the others, and what that should look like in the app.

I worked through those cases and talked them over with colleagues. We agreed to keep the calculations in GraphQL so changes wouldn’t need a new app release. I explained the rules to the colleague building that part, and we tested and fixed the results together.

I built the shared Kotlin logic and iOS screens for the schedule and its monthly details. By then, I was doing much more than learning the language: I was figuring out how the feature should work across the different parts of the product.

Finding my way around the existing app

I also worked on Apple Wallet settings, keeping track of whether a card was on the iPhone, a paired Apple Watch, or both. The Add to Wallet flow was already there; I built the device checks and settings around it.

The card screen took some untangling too. It handled everything from creating cards to showing Apple Pay actions, with a lot of connected behaviour to understand. I reorganised those responsibilities to make the code easier to follow and work on.

Looking back, the biggest change was how much more comfortable I became. I could work independently in Kotlin, take a feature through the shared code and iOS screens, and knew who to talk to when I needed help with another part of the product. A lot of what felt overwhelming at the start had become part of my everyday work.