Introduction to the Journey: 🚀 Building an MVP with Kotlin Multiplatform

Written By Bruno Manchinelli

Why We Chose KMP for Android & iOS

Every startup or indie project faces a tough decision when launching a Minimum Viable Product (MVP):

• Which platforms to support?
• How to maximize development speed while keeping future scalability in mind?
• How to balance code reusability with a native user experience?

We faced the same challenges when building our app for the Future of Work in the US. After exploring multiple cross-platform solutions, we decided to go with Kotlin Multiplatform (KMP) — a decision that aligned perfectly with our technical goals, developer experience, and long-term vision.

Why an MVP?

Before we jump into why KMP, let’s talk about the why of an MVP in the first place.

• Testing Market Fit: Launching quickly to gather real-world feedback.
• Optimizing Development Resources: Building efficiently with a small team.
• Avoiding Over-Engineering: Delivering only core features first to validate demand.

The Market Opportunity

The Future of Work in the U.S. represents a massive and growing market opportunity, as traditional employment structures give way to a dynamic gig economy. With freelancers, content creators, and gig workers now making up 34% of the U.S. workforce — projected to reach 51% by 2027 — the demand for financial solutions tailored to this evolving labor force has never been greater. However, legacy credit systems, designed for salaried employees with predictable incomes, fail to recognize the financial reality of independent workers, leaving nearly 100 million Americans classified as “thin file” or “no file” by traditional credit bureaus.

This gap in financial inclusion presents an urgent need for innovative credit solutions that leverage alternative data sources, such as multi-platform earnings and job history, to accurately assess creditworthiness. Companies that address this need stand to unlock a multi-billion-dollar opportunity, providing essential financial services to a workforce that is rapidly redefining the American economy.

Read more about our Mission: Filance.AI by Bankuish: Pioneering the Future of Creditworthiness

Evaluating Cross-Platform Solutions: Why Not Flutter or React Native?

Since our goal was to move fast while keeping flexibility for future improvements, we needed a cross-platform strategy that wouldn’t lock us into a rigid framework.

Like any pragmatic team, we evaluated the most popular alternatives:

• Flutter
• React Native
• Kotlin Multiplatform (pushed internally by the dev team’s interest)

Why We Chose Kotlin Multiplatform

These were the key reasons we committed to KMP for our MVP:

1️⃣ Code Sharing Without Compromising Native UI

• KMP enables us to share business logic, API calls, and database access while still delivering a native-like UI on each platform.
• With Jetpack Compose Multiplatform, both Android and iOS users get a Compose-based UI, ensuring a consistent yet platform-adaptive experience.

2️⃣ Single Codebase for Core Logic

• We avoid duplicating logic like authentication, data models, networking, and business rules across two separate codebases, even between our legacy Bankuish App and the new Filance AI app.
• Maintenance becomes easier because fixing a bug in shared code applies to both platforms.

3️⃣ Future Scalability and Flexibility

• Unlike Flutter or React Native, KMP doesn’t force us into a single ecosystem. If needed, we can still add fully native features per platform without workarounds.

4️⃣ Leverage Our Existing Kotlin Expertise and Bankuish App Codebase

• Since our team is already experienced in Kotlin and Android development, adopting KMP was smoother than switching to a Dart- or JavaScript-based framework. Also, we could reuse most of the Data and Domain layers and much of the UI layer.

5️⃣ Seamless Gradle and Dependency Management

• With Gradle, we could easily set up dependencies already in use by our Bankuish App: Koin for Dependency Injection, Ktor for our HTTP client, Jetpack Compose for UI rendering.
• No need to introduce a new package manager or non-native build tools.

Challenges & Tradeoffs We Considered

KMP is great, but it’s not without challenges. Here are the biggest tradeoffs we knew we’d face:

• Tooling and Debugging: While improving, KMP’s tooling is not as mature as Flutter’s hot reload. Debugging across platforms can be trickier.
• iOS Interoperability: KMP generates Kotlin/Native code for iOS, which means debugging Swift code interacting with Kotlin takes some extra effort.
• Smaller Community: Compared to Flutter and React Native, KMP has fewer libraries explicitly built for it — but JetBrains is actively improving the ecosystem.

That said, none of these were deal-breakers, and the long-term benefits far outweighed the tradeoffs.

Challenges We Anticipated

One of our biggest expected challenges is working in the macOS environment. Since our mobile team has been 100% focused on Android-native development, adapting to macOS and XCode workflows required going through an initial learning curve.

On the technical side, we expected some issues and compromises implementing Compose Multiplatform. We started all this work in April 2024, and just in May 23rd JetBrains announced Beta support for iOS. The executive decision to commit to this project was taken with skepticism. For everyone’s surprise, not a single issue was encountered when building our UI with Jetpack Compose 🥳

What to Expect in This Blog Series

This is just the beginning of our journey. Over the next posts, we’ll share how we set up KMP, structured our data layer, handled UI differences, built deep link support, and much more.

Next up: Setting Up Kotlin Multiplatform: Initial Project Configuration. Stay tuned!