My frontend engineer career path didn’t start as a plan. It started as a growing sense that I was spreading myself too thin. There’s a question I’ve been asked in almost every job interview since I made the switch. It usually comes after the hiring manager spots that I’ve been shipping full-stack systems — Node.js, PostgreSQL, AWS, the works — for nearly a decade. The question sounds polite, but it’s really a test:
“So… why just frontend now?”
The word just does a lot of work in that sentence. It implies I’ve narrowed myself, opted for the shallow end, and retreated to buttons and colour palettes somewhere along the way.
I want to set that record straight. Not to reassure nervous hiring managers, but because the honest answer is more interesting than the polished one. This is the post I wish someone had written when I was two years into my full-stack career and starting to feel what I’d later call a clarity problem.
The Full-Stack Reality Nobody Puts in Job Descriptions
Full-stack development in a small team sounds like a superpower. You can ship end-to-end, understand the whole system, and be the person everyone turns to when something breaks in production at 11pm.
For several years, that felt good. I was working across a React + Node.js + PostgreSQL stack, building cross-platform apps in React Native, managing Nx monorepos, and wiring up CI/CD pipelines. I was genuinely good at all of it.
But “good at all of it” turns out to be a trap.
Here’s what the full-stack reality looks like from the inside: you are constantly switching between completely different mental models. One hour you’re thinking about database index strategies. The next you’re debugging a CSS layout regression on mobile Safari. Then a security review, a Core Web Vitals audit, then back to a backend API contract.
None of these get your full attention. Each one gets enough attention. And for a long time, I told myself that was fine — that the breadth was the point.
It wasn’t fine. I was producing competent work across the stack, but I wasn’t producing great work anywhere in it.
The Gradual Realisation: Choosing a Frontend Engineer Career Path
There wasn’t a single moment. Instead, it was a series of smaller ones that quietly added up.
I noticed I was most engaged when the problem was on the frontend — not just visual, but structural. Structuring a component library that scales across a monorepo. Getting a React Native codebase to share 90% of its logic with the web version without lying about what “shared” actually means. Cutting 22% off initial page load in Next.js without breaking an SEO strategy we’d spent months building.
These weren’t trivial problems. They were hard in the way I wanted my work to be hard — with real trade-offs, real user impact, and real architectural thinking required.
In contrast, I noticed where I was least engaged: infrastructure ticketing, database migration scripts, and debugging race conditions in backend microservices. I could do these things, and I did do them. However, they felt like maintenance on someone else’s vision rather than construction of my own.
The backend work was genuinely important, and I don’t regret doing it. But it simply wasn’t where my attention naturally went when I had the freedom to choose.
Why Frontend Is Not The Shallow End
Let me address the assumption that frontend specialisation is a step down in technical complexity.
It isn’t. Not in 2026.
A serious frontend engineer career path today means deep TypeScript. Not just types — but generics, utility types, strict mode, and type-safe API boundaries. React Server Components are part of the picture too. Understanding why the rendering model matters, not just how to use it. Performance profiling goes beyond Lighthouse scores into bundle analysis, code-splitting, and edge runtime decisions. Accessibility is a design constraint, not a checkbox.
Beyond that, it increasingly means building the tooling the rest of the team depends on — Webpack configs, design systems, monorepo component strategies. These are hard platform problems that happen to live on the frontend.
The companies I want to work for understand this distinction. The ones still using “React Developer” as a job title — as if React is the skill rather than the baseline — are simply not the companies I’m targeting.
What My Backend Years Added to My Frontend Career Path
Here’s the part I genuinely believe, and it’s not reassurance for sceptical interviewers — it’s just true:
Nine years of full-stack work made me a more effective frontend engineer than I would have been if I’d specialised from day one.
Knowing what happens on the other side of the API changes how you write frontend code. When I design a data-fetching layer in React Query, I’m not guessing at payload shapes — I know how the backend is built and where the bottlenecks live. When I choose between SSR, CSR, and ISR in Next.js, I’m thinking about database query patterns and infrastructure cost, not just SEO scores.
I also understand Docker, CI/CD, and deployment pipelines well enough to own the frontend side without waiting to be unblocked. Reading backend code fluently makes cross-team work much faster.
This depth doesn’t make me want to go back. Instead, it makes me more useful precisely because I’m staying on the frontend.
The Real Reason
Beyond all of this — the burnout logic, the market signals, the architectural complexity argument — there is a simpler reason I chose frontend.
I care where this goes.
The frontend is where code meets humans. It’s the layer where technical decisions become visible, felt, and judged in real time by real people. It’s also the layer closest to the things I’m genuinely excited about: 3D on the web, motion and animation, immersive experiences, and eventually the intersection with games and interactive storytelling.
Those aren’t hobbies I’m keeping separate from my career. Rather, they’re the direction my career is pointed. This career choice isn’t a retreat from ambition. It’s the specific path toward the work I actually want to be doing in five years.
The “just frontend” framing assumes the goal is maximum technical breadth. Mine isn’t. My goal is to go deep in the direction that matters to me, and build something worth building.
What This Means for Who Hires Me
For hiring managers reading this: yes, I have backend depth, and no, I’m not going to pretend it’s irrelevant to a frontend role. But I’m not angling to become your next full-stack hire. I’m a Senior Frontend Engineer with unusually broad context — and I’ll use that context entirely in service of the frontend work.
For developers in a similar position — full-stack experience, starting to feel the clarity problem I described — here’s what I wish someone had said earlier: specialisation isn’t a limitation. It’s a decision about where to be excellent.
Being good at everything is a perfectly fine career. Being great at something is a better one.
I’m currently open to Senior Frontend Engineer roles — remote, React/Next.js/TypeScript focused. You can find my work at slawa-warda.me or connect with me on LinkedIn.
