KoperasiQu - From Cooperative App to Shared Finance Platform

Overview

KoperasiQu started as a member-facing finance app for a Bandung implementation of the Koperasi Merah Putih program. Members could activate their account, track savings, pay required cooperative bills, and top up through virtual accounts. The product moved fast, the timeline was tight, and the main pressure was simple: financial flows had to work clearly enough that members could trust them.

That first version shipped successfully. But a few months later the problem changed.

A new client arrived from the Baitul Maal wat Tamwil (BMT) space. BMT shared some of the same foundations as a cooperative finance app, but it also brought a different product direction: more Islamic-centered behavior, syariah-specific expectations, and a much bigger loan flow. At that point the challenge was no longer just building features. It was deciding how to keep what was shared without forcing two different products into one app shape.

---

My Role

I worked as the lead Flutter engineer across both phases of the product.

My work covered three areas:

• Building the original member-side app for auth, activation, savings, wallet visibility, and payment flows
• Owning the mobile architecture behind those finance journeys, especially where cooperative rules affected billing and member status
• Restructuring the codebase into a multi-app setup so KMP and BMT could share common foundations without collapsing into one tangled product

That meant thinking beyond screen delivery. I had to keep the shipped app stable, model finance flows clearly, and make room for a second product with overlapping foundations but different rules.

---

What KoperasiQu Does

At its core, KoperasiQu helps members handle the main finance flows they need from a cooperative app.

Users can register or sign in, activate their membership, complete verification steps, see their savings wallet, understand their primary and mandatory savings status, and make payments through virtual accounts when balance is not enough.

The app also has to reflect cooperative rules in a way that feels understandable. A member should be able to tell whether they are active, whether there are mandatory dues to settle, and what they need to do next without reading the product like an internal finance system.

Later, that base expanded into a broader platform direction. The BMT side reused a lot of the same auth, profile, saving, payment, and member foundations, but also needed a more Islamic-centered surface and a more specific loan journey that could not be treated as just another cooperative feature toggle.

---

What Changed

The first version of KoperasiQu was built under real delivery pressure. The app worked, the member flows shipped, and the product reached end users smoothly. But it was still fundamentally one app shaped around one cooperative context.

That stopped being enough when BMT entered the picture.

BMT was not only a new client. It was a related but different product family. It shared the same base needs around identity, savings, payments, and member data, but it also introduced a more syariah-centered direction and a larger loan flow with different requirements. Forcing that into the original KMP app would have turned shared code into product confusion.

So the rewrite was not about chasing cleaner architecture for its own sake. It was about creating a structure where:

• shared finance and platform features could stay shared
• KMP and BMT could own different home, navigation, and feature direction
• future client-specific growth would not require copying the whole app again

---

Key Decisions

A few decisions shaped the project.

First, I treated the finance rules as product logic, not UI convenience. Savings, activation status, billing rules, PIN confirmation, and virtual account payment flows all needed to behave predictably because this was a money product, not a demo app.

Second, I avoided forcing BMT into the original KMP codebase. The overlap was real, but so was the divergence. BMT loan flows, syariah-driven requirements, and a different app surface would have made a single-app conditional approach harder to reason about over time.

Third, I restructured the codebase into a multi-app monorepo with shared packages. Shared platform infrastructure, design system pieces, and reusable finance features were extracted into common packages, while KMP and BMT each kept their own app shell and product-specific features.

That made ownership clearer. Shared code could stay genuinely shared, and app-specific behavior no longer had to pretend it belonged everywhere.

---

Challenges

The hardest part of this project was carrying two kinds of complexity at the same time.

The first was finance complexity. Cooperative products are full of rules that are easy to describe loosely but hard to model well in software. Member activation, savings status, billing, mandatory dues, wallet state, and payment routing all need to stay coherent because errors are immediately visible to users.

The second was product divergence. Once BMT became part of the story, I had to decide where to draw the boundary between "shared platform" and "different product." The challenge was finding the right balance: avoiding unnecessary duplication without over-sharing so much that the codebase stopped reflecting either product clearly.

The codebase today reflects that tradeoff directly. The shared packages hold the common foundation, while KMP and BMT keep separate shells and product-specific slices where they actually differ.

---

Impact

KoperasiQu is meaningful because it was not just one shipped app. It became a transition from a working finance product into a platform that could support more than one direction.

The first result was practical: members could sign in, activate, manage savings-related flows, and complete payments in a production app that reached end users smoothly.

The second result was architectural: when BMT arrived, the team did not have to fork the whole app or bury product differences inside endless conditionals. Shared infrastructure and common finance features were extracted, and separate app shells made it possible to support both KMP and BMT more deliberately.

That changed the quality of future work. Bug fixes in shared flows could be applied once. Product differences became easier to localize. And the codebase moved closer to something that can support future variants without pretending every finance product is the same.

---

What I Learned

KoperasiQu changed how I think about product overlap.

Two products can share a lot of foundations and still need different architecture. The hard part is not spotting what is common. The hard part is knowing when not to force different products into the same shape just because they started from the same base.

I also learned that platform work becomes much more valuable when it is tied to a real delivery problem. The multi-app monorepo was not an abstract improvement. It was a response to a live app, a new product direction, and the need to keep moving without duplicating everything.

That made the work more than a mobile rewrite. It became a systems decision about how a finance product should keep growing.