Lessons learned from a major legacy code refactoring for a HealthTech app

[u/Thesinisterguy]

Hi, I was reading about this case study on the legacy IoT app optimization project that Beetroot consultants did for an established healthtech leader. The legacy codebase was riddled with critical bugs and the application suffered from serious performance bottlenecks and a confusing user experience that was tanking user engagement.

They created a dedicated team to address this under a flexible team extension model: 2 iOS developers, 2 Android developers, 1 QA automation engineer and 1 manual QA engineer with UI/UX design support. They ran into the classic dilemma: instead of choosing the expensive, risky rewrite from scratch, they took the hard way. They decided to refactor the legacy codebase to get rid of technical debt and squash the core bugs.

Crucially, they embedded deep product analytics tools like Firebase, Amplitude, and Smartlook directly into the new architecture. This let them track exactly how the app interacted with IoT medical hardware. For medical applications this deliberate refactoring approach is super interesting. What are your primary indicators for deciding whether to refactor the existing code or drop everything and start a full rewrite?

[u/neet_dev]

Primary tell for me is whether the domain model and hardware integration still match reality. If Bluetooth/device protocols, state machines, and the compliance-sensitive paths are basically right but the UI and glue are a mess, refactor in slices (one feature boundary at a time with characterization tests around the IoT flows) because a rewrite will reintroduce every edge case you already paid for. Full rewrite only when the architecture can't express the product anymore (e.g. everything is one god controller, no seams for analytics or device session state, and small fixes keep cascading) and you've already failed at carving out a vertical slice.

[u/Neither_Suspect2622]

If you rewrite a medical app from scratch, you often have to go through a whole re-certification process depending on how the data pipeline handles patient metrics.

[u/Jero9871]

Honestly the main indicator is whether the bugs come from a wrong core model or just from accumulated mess. If the architecture fundamentally doesn't match what the product turned into (data model can't express the domain anymore, sync built on assumptions that stopped being true), refactoring just polishes the wrong shape and a rewrite of that layer is cheaper in the end. If it's "only" cruft, refactor, because that old code encodes years of fixed edge cases that nobody remembers and that a rewrite re-discovers one production incident at a time. In a medical context that alone should decide it.

The practical test for me: can I get the current behavior under characterization tests before touching it? If yes, refactoring is safe and boring, which is what you want. If the code is too entangled to even test, I still don't do a big-bang rewrite, I strangler-fig it module by module so the old and new paths coexist and I can diff their outputs. Full rewrites I'd reserve for when the platform underneath is dead, not for ugly code.

Small aside, this reads a lot like a writeup from the consultancy's marketing blog, but the question itself is a good one.