From Backend to Full Stack

When I first started my career (or rather, before it officially began), my world revolved around the backend. I loved the structure and clarity of server side development. Designing Django models, writing queries, and building APIs.

The frontend? That was someone else’s world.

But like many engineers, I eventually hit a moment where “someone else’s world” became mine too. And it changed how I think about building software.

Starting Point

In my early projects, I was firmly backend focused. Sure, I made the occasional minor change to frontend code like tweaking text and adjusting layouts. But my real toolkit was all backend power moves: Django ORM, GraphQL resolvers and Integrations with services like Shopify, Avatax and Stripe.

It felt natural to “stay in my lane”. Frontend didn’t seem intimidating, it just wasn’t a major part of my role. Stylesheets, pixel perfect layouts, and browser quirks felt like a completely different species of problem solving.

The Catalyst

My first taste of real frontend work came at ESG Analytics, where our small three person team (me, a senior engineer, and the co-founder) required everyone to pitch in wherever needed. I used Recharts to visualize data: Radar, Pie, Bar, Line, and Scatter charts. But it didn’t require deep frontend architecture skills.

The real shift came at Nautical Commerce. I started working on both, the dashboard and parts of the storefront. Later, we made a big move and migrated our dashboard from Next.js to React Remix.

That migration led me to go deep into frontend workflows. I had to ensure features worked end-to-end in the new dashboard, from backend data to fully functioning UI. It wasn’t just a “nice-to-have” skill anymore, it was essential.

While I understood concepts like state management and components, I hadn’t worked with them extensively. Suddenly I was:

• Creating components
• Managing state - shifting my thinking to component states and props

After a few sprints (and later, cycles when we adopted the Shape Up process) of working in both codebases,

1. I was able to "own" a feature from database schema to user click. This helped me make better decisions at every layer. Backend changes weren't abstract and I knew exactly how they’d surface in the UI.
2. I designed APIs with the UI in mind, which let me to focus more on meaningful error handling.

Impact on my career

• I became more autonomous, able to deliver features without waiting on another team.
• I communicated better with frontend peers because I understood their challenges.
• Changed how I approach architecture decisions and project planning.

It also changed how I evaluate opportunities. I now seek roles where I can work across the stack because that’s where the fun (and growth) really happens.

I didn’t set out to become a full stack engineer, it happened because I cared about shipping complete features and not just “my part” of them.

Now, when I look at a product, I don’t see “frontend” or “backend.” I see a system and how the user experience will be. That mindset has made me a better engineer, no matter where in the stack I’m working.