The medication adherence app was my first real project. It already existed in one system; my job, paired with a developer who'd started the same week I had, was to retrofit it into a second. I was new enough to still want to figure everything out myself before asking for help. That didn't last: partway through, the other developer left, and his half of the work became mine.
The same app, a different system, every time
Medication adherence is mostly standalone. It owns its API, and that API is what every host system talks to; the patient portal on the host system conforms to it rather than getting its own version of the logic. So "retrofit into a new system" mostly meant reworking that API to speak the new host's schema and redoing the encryption setup it required: keys, connection strings, the parts of the script that assume a specific security configuration. It runs in about four client systems now, with more planned. The four aren't framework migrations, they're four different client systems, each one different.
What made it interesting was what it surfaced. Every move exposed something quietly broken in the old system. Account reset on the patient portal never worked. Live messaging between providers didn't either. There was a block of dead code for an abandoned Zoom-style video chat feature, crossed out and left in the file. Moving the app was an audit of everything nobody had finished the first time.
Inheriting debt you didn't create
By the second integration, some of the debt was mine, from parts of the first iteration I'd built before I understood the codebase, and some was my former coworker's. Clients caught the gaps before I did. I'd get a ticket, open the module, and have to understand code I hadn't written, in a system I'd only recently learned, well enough to fix it for someone using it. That's the part of inheriting a legacy system early-career that nobody warns you about: you're responsible for context you never got to build firsthand, reverse-engineering someone else's decisions under a support ticket.
More room, the third time
The third integration folded a legacy application process from an older system into a newer one, tied into medication adherence rather than being it. This time I had real say over the UI, working alongside the lead developer of that system and the original medication adherence SME I'd been learning from since the first iteration. Same shape of work, but for the first time I was making some of the decisions instead of only absorbing them.
Where it sits now
The current integration, a leaner retrofit into another system with a smaller feature set, isn't mine to build; a senior developer with more bandwidth is doing it faster than I could. But I'm the SME on the module: the one he checks with when something doesn't add up, and the one in client meetings as backup when the lead developer isn't available. My work on it now is bug fixes, retrofits, new features, fixing features that were broken before I got there, and writing reversible "undo" deployment scripts that can cleanly pull the entire module back out of a system if a rollout goes wrong. The work moved from building the thing to being the person who remembers why it's built the way it is. Somewhere across these systems, I learned to ask questions and say what I was thinking instead of carrying all of it myself. That took longer than any of the technical parts.