Why I Switched from Backend to Fullstack

I used to look down on frontend

Honest confession: there was a time I dismissed frontend work. "How is fiddling with CSS even real development?" It's a bias quietly shared among backend developers, and I had it too.

For three years, I only touched Spring Boot and PostgreSQL. I thought designing APIs, optimizing queries, and deliberating over server architecture was "real development." (Looking back, it's kind of embarrassing.)

The trigger was money

Let's be honest. The biggest reason I started learning frontend was money. In late 2024, I was scouting the job market and found that fullstack positions averaged about 7 million KRW (roughly $5,200) more in annual salary than backend-only roles. It varies by company, but that's what I saw across 47 job listings.

And fullstack positions simply had more openings than backend-specialist ones. The smaller the company, the stronger the "we want one person who does everything" demand.

The first 3 months were hell

When I first touched React, state management stopped me cold. In backend work, a request comes in, you process it, send a response, done. You rarely need to track ongoing state. But in frontend, state is everything. Click this button and that component changes, which affects another component.

CSS nearly drove me insane. Why is centering something so hard? There was a period where I didn't know display: flex existed and was struggling with margin: auto. (I spent 3 days laying out a single modal. Three days.)

Then I discovered Tailwind CSS

My first reaction to Tailwind was "how is this different from inline styles in HTML?" But after a week, it clicked. Not having to jump between CSS files was a massive win for someone coming from backend.

Tailwind killed most of my frontend resistance. I still have zero design sense, but at least I can build screens now. On projects with a design system, it's not really an issue.

What changed after becoming fullstack

The biggest shift was how I approach API design. When I was backend-only, it was "I'll structure the data like this and send it down." Now I start with "how will the frontend actually use this data?" Designing APIs around screen needs reduces overfetching, and the frontend code ends up cleaner.

Team communication changed too. Before, when a frontend dev said "can you send it in this format?" I'd volley back with "handle that on the frontend." Now I understand both sides, so I can immediately judge whether it's better to process data server-side or client-side.

I do have some regrets though

I feel like my backend depth has gotten shallower. Covering both sides means I spend less time on system design and database tuning. I used to spend half a day analyzing query execution plans. Now with frontend work waiting, I sometimes slip into "it works, move on" mode.

I feel the depth vs. breadth tradeoff every single day. Anyone who claims they can master both... I honestly don't buy it. (Or maybe I'm just not good enough.)

But I don't want to go back

I have no desire to return to backend-only work. Being able to build a service from start to finish on your own is a serious advantage, whether for side projects or job hunting.

But I've also learned that the "fullstack developer" title isn't a silver bullet. When deep backend questions come up in interviews, my answers wobble a bit more than they did three years ago. That stings a little.

No regrets though. Tomorrow I'll be writing APIs in the morning and building components in the afternoon.