The medication adherence app was my first real project. It wasn't new — it already existed in one system — and my job, paired with another developer who'd started at the company the same week I had, was to retrofit it into a second one. I was new enough that I still wanted to figure everything out myself before asking anyone for help. That instinct didn't last long. Partway through, the other developer left the company, and his half of the work became mine.
The same app, a different system, every time
Medication adherence is mostly standalone. It owns its own API, and that API is what every host system actually talks to — the patient portal on whatever system it's being integrated into doesn't get its own version of the logic, it conforms to medication adherence's. So in practice, "retrofit into a new system" mostly meant reworking that API to speak whatever schema the new host expected, and redoing the encryption setup — keys, connection strings, the parts of the script that assume a specific security configuration — for whatever that system required.
None of that is exciting work on its own. What made it interesting was what it kept surfacing. Every time the app moved into new soil, something that had been quietly broken in the old one would get noticed. Account reset on the patient portal never actually worked. Live messaging between providers didn't work either. There was a chunk of dead code for what looked like an attempt at a Zoom-style video chat feature — entire blocks of it crossed out, abandoned mid-build, just sitting there in the file. Moving the app wasn't just a migration. It was an audit of everything nobody had gotten around to finishing the first time.
Inheriting debt you didn't create
By the second integration, the debt wasn't just historical — some of it was mine. I'd built parts of the first iteration without fully understanding the framework yet, and parts of it were my coworker's, the one who'd left. Clients caught the gaps before I did. I'd get a ticket about something not working, open the module, and realize I was the one who now had to understand code I hadn't written, in a system I'd only recently learned myself, well enough to actually fix it for someone using it.
That's the part nobody tells you about being early-career and inheriting a legacy system: it's not that the code is bad, necessarily. It's that you become responsible for context you never had a chance to build firsthand. You're reverse-engineering someone else's decisions from the outside, under a support ticket, instead of from inside the work as it was being made.
More room, the third time
The third integration was a different kind of project — folding a legacy application process from an older system into a newer one, tied into medication adherence rather than being medication adherence itself. This time I had real say over how the UI came together, and I was working alongside the lead developer of that system and the original medication adherence SME — someone I'd been learning from since the first iteration. The work was the same shape as before: conform the API, redo the security setup, fix whatever the move exposed. But for the first time, I wasn't just absorbing decisions made before I arrived. I was making some of them.
Where it sits now
The current integration — a leaner retrofit into yet 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 still the one he checks with when something about medication adherence doesn't add up, and I've started sitting in on client meetings as SME backup when the lead developer isn't available. The work changed. What I'm responsible for didn't go away — it just moved from building the thing to being the person who remembers why it's built the way it is.
We're still fixing things as they come up, the same as we were in that first integration. The difference isn't the app. It's that I do it faster now, and somewhere in the middle of all four of these, I learned to actually ask questions and say what I was thinking instead of trying to carry all of it myself. That took longer to learn than any of the frameworks did.