From Systems Analyst to Builder: Why I Started Shipping Code

For 15 years, I sat between business teams and engineering teams. My job was to understand what the business needed, translate that into requirements, and make sure the technical team delivered something that actually solved the problem.

I was a Senior Business Systems Analyst. I worked across enterprise platforms, picked up new technologies quickly, and developed a reputation for being the person who could make sense of complex systems. I was good at it.

But something started to bother me.

The gap between knowing and doing

I could look at a system and see exactly what needed to change. I could map out the architecture, identify the bottlenecks, write the requirements document. But then I had to hand it off. Wait for prioritization. Wait for sprint planning. Wait for someone else to build the thing I already had mapped out in my head.

Sometimes what came back didn't match the vision. Sometimes it took months. Sometimes it never happened at all because priorities shifted.

I started thinking: what if I just built it myself?

The first thing I shipped

I didn't start with anything fancy. I started with a problem I personally cared about — figuring out the fastest way to pay off debt. I'd been running the numbers in spreadsheets, comparing Snowball vs Avalanche strategies manually, and I thought: this should be a tool.

So I built ByeByeBalance. A free debt payoff calculator. React at first, then I migrated it to Next.js for better SEO. Added a CI/CD pipeline with GitHub Actions. Built a clean two-page print report so people could stick their plan on the fridge.

It's live. People use it. It's not a side project sitting in a private repo — it's a product.

What systems thinking gives you as a builder

Here's what 15 years of enterprise systems work taught me that most self-taught developers don't have: I think in systems, not features.

When I build something, I'm not just thinking about making a button work. I'm thinking about the data flow. The edge cases. What happens when users do something unexpected. How the pieces connect. Where the bottlenecks will show up at scale.

That's not something you learn from a tutorial. That's something you develop from years of watching complex systems succeed and fail in production.

The transition isn't about starting over

The biggest misconception about career pivots in tech is that you're starting from zero. You're not. Every requirement you've written, every stakeholder meeting you've navigated, every system you've mapped out — that's experience that compounds when you start building.

I'm not pretending I'm a 10x developer. I'm a systems thinker who learned to code. And it turns out that combination is more valuable than either one alone.

What I'm building toward

Right now I'm focused on cloud security and DevSecOps — Kubernetes, Terraform, AWS infrastructure, security tooling. I'm doing Cyber Range coursework with Sentinel and Defender. I'm building projects that demonstrate the skills, not just list them on a resume.

The goal isn't to abandon my experience. It's to combine it with hands-on engineering skills so I can operate at the intersection of business understanding and technical execution.

If you're a systems analyst, a BA, a PM, or anyone who sits between business and tech and you've been thinking about building — just start. Pick a problem you care about. Ship something small. The gap between knowing and doing is smaller than you think.