Early in my career, I had a quiet conviction that backend was the serious side of engineering. The frontend was where you made things pretty. The backend was where you made things work.
I was wrong, of course. But it took years of crossing back and forth across the stack to understand exactly how wrong, and why that journey turned out to be the most valuable thing I did for my engineering career.
Starting on the backend
My first real engineering work was backend-heavy. PHP with Symfony, building REST APIs, designing database schemas, wiring up business logic for custom ERPs and web applications. I loved the clarity of it: request comes in, logic runs, response goes out. Clean inputs, clean outputs, predictable behavior.
Backend work taught me to think in systems. How data flows. Where bottlenecks form. Why you normalize your schema now so you don't regret it in six months. How to design an API contract that your future self won't curse.
I felt at home there. The backend was where the real engineering happened, or so I believed.
The frontend pull
The first time I had to build a complex frontend, I treated it like a necessary inconvenience. Just render the data the API sends. How hard could it be?
Very hard, it turns out.
The frontend humbled me. Suddenly I was dealing with state that lived in the browser, not the database. User interactions that couldn't be predicted or controlled. Layout systems that behaved differently across devices, browsers, and screen sizes. Performance constraints that had nothing to do with query optimization and everything to do with rendering cycles and bundle sizes.
But more than the technical challenge, the frontend changed how I thought about the user. On the backend, the "user" was an abstract concept: a request with headers and a payload. On the frontend, the user was a person clicking buttons, waiting for responses, getting confused by bad labels, abandoning flows that took too long.
That shift in perspective, from system-first to human-first, was transformative.
Going deep on frontend
I spent over two years as a Lead Frontend Developer, building the entire dashboard for a cloud infrastructure platform. This wasn't "make it pretty" work. It was building complex state management for real-time infrastructure monitoring, designing component architectures that could scale across dozens of views, and making deeply technical information accessible to engineers who had no patience for bad UX.
Then came React: building a full management interface for a services company in Madrid. And Flutter for the mobile app. Each new frontend technology forced me to rethink assumptions I'd carried from the backend world.
What I learned in those years:
State management is its own discipline. Backend developers think of state as "whatever's in the database." Frontend developers know that state is everywhere: URL params, local storage, component state, global stores, server cache, optimistic updates. Managing it well is as intellectually demanding as designing a good database schema.
Component architecture is system design. The best frontend codebases I've worked on had the same qualities as the best backend systems: clear boundaries, single responsibilities, composability, and explicit contracts between modules. The patterns are different, but the thinking is the same.
Performance is a feature, not a metric. On the backend, performance means response times and throughput. On the frontend, performance means the user doesn't feel friction. These are related but not identical. A 200ms API response feels slow if the UI doesn't show a loading state. A 2-second page load feels fast if the above-the-fold content renders immediately.
The return trip
After years of deep frontend work, I found myself pulled back toward the backend, but I was a different engineer now.
For the services company in Madrid, I designed and built the entire stack: Symfony/API Platform backend, React frontend, Flutter mobile app, even an NFC-based offline timekeeping system. Having spent years on the frontend, I now designed APIs differently. I thought about the data the client actually needs, not the data the database happens to have. I structured error responses for the UI, not for the log file. I made pagination and filtering decisions based on how lists would be rendered, not just how queries would perform.
The roundtrip gave me something that staying on one side never could: empathy for the other end of the wire.
What fullstack actually means
I've come to believe that "fullstack" is one of the most misunderstood terms in engineering.
It doesn't mean you can write a React component and a SQL query in the same afternoon. That's just syntax.
Real fullstack thinking means:
-
You understand the constraints of both sides. You know why the frontend developer is asking for a different API shape. You know why the backend developer pushes back on real-time WebSocket connections. You can mediate because you've lived both realities.
-
You design across boundaries. When you think about a feature, you think about the data model, the API contract, the state management, the UI interaction, and the error handling, as one connected system, not separate layers thrown over a wall.
-
You make better trade-offs. Should this logic live on the client or the server? Should this data be computed on read or write? Should this validation happen in the form, the API, or both? These aren't religious questions. They're engineering decisions, and making them well requires understanding both environments.
Why the journey matters more than the label
I don't introduce myself as a "fullstack developer" anymore. The title has been diluted to the point where it can mean anything from "I did a bootcamp that covered HTML and Node" to "I've architected distributed systems and built design systems."
What matters isn't the label. It's the journey: the willingness to cross into uncomfortable territory, to be a beginner again, to discover that the problems you dismissed as simple are actually deep and fascinating.
Going from backend to frontend taught me humility. Going from frontend back to backend taught me empathy. The combination taught me that the best engineers aren't the ones who go deepest on one thing, they're the ones who can hold the full picture in their head and make decisions that serve the whole system.
That's the real value of a fullstack journey. Not that you can do everything. But that you understand enough of everything to lead well.
If you've made a similar journey, or you're considering crossing to the other side of the stack, I'd be curious to hear what surprised you most. The lessons from the roundtrip are always different for everyone.