How I got my start

I didn’t set out to become an engineer. In 2019 I was working customer service at a dropshipping company — a setup with hundreds of vendors, each with their own quirks, their own lead times, and their own definition of “in stock.” The process was a mess of context switches: pull up the order, find the vendor, check the right portal, send the right templated message, log it back somewhere else. I spent more time hunting for information than actually helping anyone.

So I started a Coursera Python course on the side. Mostly out of curiosity. I had no plan to leave the queue — I just wanted to see if I could shave a few minutes off my day.

The Flask rabbit hole

A previous intern had built a small internal tool. It was limited, brittle, and only handled a slice of what we did. But the existence of it cracked open the idea that this was a thing one could just do. So I started watching YouTube videos about Flask, working evenings, building a personal version of the tool that solved the parts of my own workflow that hurt the most.

What started as a productivity hack for me turned into something the rest of the team wanted to use. I quietly transitioned from doing customer service to maintaining the tool that the customer service team used. From there, the scope kept growing:

• Integrations with every 3rd party service we used
• Auto-generated emails for the most common vendor situations
• Vendor issue & returns management
• Order refund processing
• Inventory updates
• Eventually, a whole layer of decision logic that did the routine triage work for us

The pivotal moment was when one of those features ended up automating an entire role out of existence. Thankfully no one actually lost their job — the person whose role it had been was shifted to other work — but the moment still sat with me. Partly because of what it meant for the work they’d been doing day-to-day, but mostly because of what it suggested about what was suddenly possible with a few weeks of focused work. It was the first time I really understood the leverage that comes with being the person who can build the tool instead of the person who has to use it.

The acquisition

Then Super.com acquired the e-commerce company. Overnight I went from being a solo dev whose only review was “does this make my coworkers’ day easier” to sitting on an engineering team with real conventions, a real frontend, and real code review.

I had been writing Python. Now I needed to write React. I learned it on the fly, in production, mostly by reading other people’s PRs and asking a lot of dumb questions. It was the hardest few months of the job and the most growth I’ve ever had in a compressed window.

Eventually I ended up running engineering for the entire e-commerce vertical as it was being wound down. Owning a thing on its way out is a strange experience — you’re investing in stability you’ll never benefit from, and making decisions about what not to fix that wouldn’t survive contact with a healthy roadmap. But it taught me how to think about lifecycle: what’s worth the work when the runway is finite.

Subscription engineering

After the wind-down, I moved into building a new subscription onboarding funnel and gradually became the person teams pinged for anything subscription-shaped. Two projects from that stretch stand out:

• A replacement for a third-party SaaS reward-decisioning tool. We were paying for limits we kept hitting. I built our own decisioning + event-processing layer so the rules lived in our codebase instead of someone else’s UI.
• A custom billing engine. Integrated with our payment hub (the gateway to multiple payment processors) and our existing subscription service. The goal was to peel away from a vendor whose lock-in had been quietly setting our roadmap for too long. The transition needed to be seamless from the customer’s perspective and invisible to most of the rest of engineering. We pulled it off.

The through-line

Looking back, the consistent thread isn’t a particular technology or domain. It’s a kind of problem: the load-bearing, strange-shaped thing nobody else has time to pick up. The customer-service tool. The vertical no one wanted to babysit. The vendor we needed to escape but everyone was too busy to plan around. I keep ending up on those, and they keep teaching me more than the tidy work ever does.

Seven years in, I still don’t think of myself as someone who was always going to be an engineer. I think of it more like a discovery — the realization that the way I already enjoyed thinking happened to be useful, and that the difference between staring at a problem and solving it was usually just deciding to try.