We’ve all seen it. That colleague—or maybe it was you—with three different browser tabs open, a desktop app running, and an Excel spreadsheet full of VLOOKUPs, manually copying data from one system to another.
It’s the quiet, soul-crushing part of work nobody talks about.
In my role as a Full-Stack Developer working on a massive web-based ERP system, my team and I were tasked with fixing this. Not just fixing bugs, but fixing the friction—the sticky, inefficient processes that were slowing everyone down.
Here’s how we did it.
Our setup was, to put it mildly, "fragmented."
Our e-commerce platforms didn't talk to our ERP system. When a customer placed an order, it was like shouting into the void. Someone in operations had to manually export CSVs, clean them up, and import them into the warehouse system. It was slow, tedious, and ripe for human error.
We used multiple logistics providers. That meant our shipping team had to juggle multiple logins and interfaces just to get quotes, print labels, and track packages. It was a classic "swivel chair" nightmare.
Our inventory data was rarely real-time. This caused a cascade of problems. Customer service couldn't give accurate stock levels. Worse, our warehouse team couldn't optimize. We had "slot pressure" (too much of one item in one place), but no one knew until it was too late.
You can't just "plug in" APIs and expect magic. You have to understand the workflow.
First, we tackled the order silo. I developed data transformation scripts to act as the "middleware" between our e-commerce platforms and the ERP. This created a two-way synchronization that automated the entire order lifecycle—from the moment a customer clicked "buy" to the second it was dispatched from the warehouse.
Next, the shipping chaos. We integrated the APIs of our multiple logistics providers into a single dashboard. This was the game-changer. The shipping team could now compare rates, book freight, and print labels from one screen. The result? We reduced manual processing time for logistics by 80%.
Finally, we gave the warehouse a voice. We used existing APIs to build new modules for real-time inventory tracking, stock transfer logging, and—my favorite—a slot pressure warning system. We even built an order interception module. This alone cut down the need for manual inventory checks by 30%.
This is the "down-to-earth" part. Shipping code is only half the battle. Making it stick is what matters.
In a previous internship, I was an Onsite IT Support Engineer at the National Healthcare Security Administration (NHSA). My job was to be on-site, providing technical support, monitoring system status, and helping users with data filtering, cleansing, and analysis.
I was the one who saw, firsthand, how tiny UI flaws or slow processes frustrated real users. I was the one documenting root causes and reporting them back to the development team.
That experience was invaluable. As a developer, I wasn't just building to a spec sheet; I was building for the person I used to support. I knew why we needed to identify root causes and why a solution had to be robust.
You can't have automation without trust. Our code had to be reliable. We didn't just ship it.
Technology is at its best when it's invisible. The goal of automation isn't to replace people; it's to free them from the robotic, copy-paste work and let them focus on the problems that require a human brain.
Going from Onsite Support to Full-Stack Development taught me one thing: the best systems aren't the ones with the most features. They're the ones that get out of your way. And sometimes, that starts with tackling one API at a time.