How a High-Stakes Rewrite in Our Healthcare App Drove 14× Growth and Team Velocity

A socio-technical rewrite inside Indonesia’s leading lab test service app — where Conway’s Law turned into a growth strategy, not a constraint.

Photo by Szabo Viktor on Unsplash

In mobile frontend development, performance is rarely the real bottleneck. With modern devices handling edge computations efficiently, our North Star wasn’t about shaving milliseconds off an algorithm — it was about accelerating months of delivery cycles. In large-scale apps, especially in healthcare ecosystems used by millions, the true challenge lies in how quickly teams can evolve complex features with confidence.

That reality hit us when we were tasked to overhaul the cart and payment flow — the most business-critical journey in our app, used by the largest lab test service network in Indonesia. What began as a UI refresh and backend integration update became something far deeper: a necessary architectural reset from a legacy module that no longer aligned with how our current team needed to move.

The challenge wasn’t just technical. A single massive module had to be built under a tight timeline by multiple engineers. Without the right structure, the cost wouldn’t be CPU time — it would be human coordination time.

So we made a decision: we wouldn’t just rewrite the module. We would reshape it in a way that made collaboration scale as cleanly as the code.

When Code Becomes a Social Constraint

The legacy cart and payment module had grown into a tightly coupled structure that reflected the past — built under a different architectural paradigm, by a different team, for a different pace of development. As the business evolved, the code didn’t. Over time, pain points began to surface not because the module was slow, but because it was structurally resistant to change. Dependencies were tangled, responsibilities were blurred, and extending a feature required navigating layers of undocumented assumptions. Debugging felt like tracing a maze without a map.

Yet the challenge we faced wasn’t purely technical. The new UI redesign and updated backend integration required a clean, future-proof foundation, which meant the module had to be rebuilt from scratch rather than patched. At the same time, a tight delivery timeline meant multiple engineers needed to work on this single module concurrently.

A high-stakes feature flow tied to the company’s transaction revenue now depended on several developers collaborating within a system that had no clear ownership boundaries and no safe architectural lanes to work within.

In other words, what looked like a code refactor problem quickly revealed itself to be a coordination problem. Without an intentional redesign — not only of the code, but of how collaboration would scale within it — velocity would collapse under misalignment and integration chaos. The real risk wasn’t that the new module would fail technically; it was that the team building it would fail organizationally.

That was the moment we understood: this wasn’t just about rewriting a legacy module. It was about reshaping it in a way that humans could sustainably and confidently build, extend, and own together.

Reframing the Problem: From Rewrite to Realignment

Instead of immediately opening Xcode and starting fresh, we gathered in a room armed not with code, but with whiteboards. The goal was not to debate implementation patterns, but to align how we understood the problem. We deconstructed the module as it existed in the legacy system, surfaced every hidden dependency we could remember, and mapped the flow from cart creation to transaction completion. What once felt like a monolithic black box gradually became a shared mental model. That visual clarity did more than reveal architecture — it lowered the psychological friction of contributing to something previously perceived as fragile and intimidating.

Photo by Brands&People on Unsplash

As complexity shifted from something individual engineers carried silently in their heads into something visible and shared, a subtle transformation happened: the problem started to feel solvable. We were no longer navigating a ghost of someone else’s architecture; we were collectively making sense of what needed to be rebuilt. During these conversations, it became obvious that this project could not succeed by forcefully injecting multiple developers into a single codebase without order. To meet the timeline without sacrificing code quality or burning the team out, we needed a structure that would allow parallel work without stepping on each other’s toes.

It was during these sessions that the idea of decomposition emerged — not as a purely technical refactoring approach, but as a way to create natural boundaries of responsibility, autonomy, and eventual ownership. We weren’t just drawing boxes for new submodules; we were laying the groundwork for how people would work inside them.

Decomposition as Social Architecture

With clarity of flow and pain points mapped out, we made the pivotal decision to build the cart and payment experience as a new module rather than refactoring the legacy one. But building a fresh module alone wasn’t enough; it had to be broken down into parts that could move in parallel without sacrificing cohesion. We decomposed the journey into three distinct submodules: Order Details for the items currently in the cart, Schedule for handling home service preferences and selected appointment times, and Payment for managing available payment methods and promos. On paper, this looked like a technical restructuring. In practice, it was a restructuring of collaboration.

Each submodule became a domain with clear boundaries, conceptual autonomy, and a dedicated developer acting as its primary owner. Rather than multiple engineers crowding around the same files with overlapping responsibilities, every submodule had someone who understood its logic, guided its evolution, and became accountable for its integrity. I took responsibility as the overarching module owner, not to dictate every decision, but to ensure architectural consistency and negotiate integration touchpoints between domains.

This distribution of ownership transformed the atmosphere in the team. Developers were no longer implementing features in someone else’s vague space; they were building within territories they understood deeply and could defend confidently. The architecture didn’t just express code boundaries — it expressed trust, accountability, and identity. In hindsight, it became clear that our decomposition was less about separating flows and more about shaping a collaboration model that allowed speed without chaos.

From Canvas to Codebase: Implementing with Intent

With decomposition in place and ownership clearly distributed, we transitioned from whiteboard diagrams to actual code. Before any feature work began, I established the core scaffolding of the new module — defining the foundational structure, setting shared architectural rules, and outlining contracts that governed how submodules would communicate with one another and with the backend. These boundaries were designed not just to standardize code, but to enable each developer to move independently without drifting from the collective direction.

As development progressed, each submodule evolved under its owner’s stewardship, shaped by both design requirements and domain understanding. Integration did not happen as a chaotic merge at the end, but as a continuous negotiation of interfaces, reviewed together to ensure that local decisions did not break global coherence.

When misalignments surfaced, we didn’t treat them as blockers, but as prompts to revisit the original canvas and adjust collectively before the divergence became costly.

The process felt less like assembling code fragments and more like orchestrating a shared rhythm. Although work was parallel, the psychological alignment we had built at the start meant that each developer moved with an awareness of how their choices affected the integrity of the whole. We weren’t just implementing UI flows; we were encoding an understanding of how the module should evolve in the future.

In the end, the codebase became not only modular but narratively coherent — each submodule reflecting a clear purpose, each developer’s effort converging into a system that felt intentionally designed rather than rushed into existence under deadline pressure. What began as decomposition turned into a deliberate reassembly, where the architecture guided the team and the team, in turn, preserved the architecture.

Results Beyond Delivery: Clarity, Momentum, and Collective Confidence

The new cart and payment module launched on schedule and without critical issues — but its real success wasn’t defined by a smooth rollout alone. What mattered more was what happened underneath: a legacy structure gave way to a modular one, turning architectural ambiguity into clear ownership and shifting collaboration from reactive to intentional. Instead of navigating around tightly coupled code, teams could extend capabilities without renegotiating every integration point.

That technical clarity translated into business momentum. Mobile transactions surged 1,400%, contributing to the company surpassing $140M in total revenue in 2024, as reported in its annual review. But progress wasn’t just measured in metrics — it showed up in delivery velocity. Features no longer stalled in architectural fog. Ownership became obvious. Iteration felt additive, not risky. The system didn’t just move faster — it removed cognitive drag.

The change was psychological as much as structural. This wasn’t just a refactor — it was Conway’s Law at work. As the architecture aligned into modules, the team aligned around ownership. As clarity emerged in code, confidence emerged in people. The architecture scaled — but so did belief.

In the end, the most valuable outcome wasn’t just a system built to grow — it was a team that now trusted its ability to grow it. Because great systems are not only the result of better code, but better alignment between the humans who write it.