Going full-stack after ten years on the frontend
What actually changed when I moved from frontend specialist to full-stack, and the lessons from a decade and 80+ projects that carried over.
I spent most of the last decade on the frontend. Agency sites in WordPress and Laravel, bilingual builds with right-to-left layouts, then years leading the UI on insurtech products in Vue. Somewhere north of eighty projects. For a long time I thought of the backend as someone else’s half of the app.
Recently that changed. In my current role I still lead the frontend, but I also write resolvers, migrations, and integrations against a FastAPI and GraphQL API on PostgreSQL. Here is what actually shifted, and what a decade of shipping frontends prepared me for better than I expected.
The frontend was quietly teaching me backend the whole time
Every messy API I ever consumed taught me something about the API I now design. Ten years of wiring UIs to REST endpoints, waiting on payloads that were almost but not quite the right shape, over-fetching because the endpoint gave me no choice, turns out to be great training for the other side of the wire.
GraphQL clicked immediately for exactly that reason. When you have felt the pain of under- and over-fetching from the consumer’s seat, designing a schema around what the client genuinely needs stops being abstract. The frontend gave me the empathy; the backend gave me the tools.
Migrations are about increments and people, not frameworks
The single most valuable thing I did on the frontend was lead a Vue 2 to Vue 3 migration. The framework diff was the easy part. The real work was doing it without freezing feature delivery, keeping the team moving, and shipping the migration in slices small enough that nothing was ever broken for long.
That lesson transferred directly. Whether it is a framework upgrade or a new backend service, the winning move is the same: make it incremental, keep it shippable at every step, and treat “we can pause and still be fine” as a requirement, not a nice-to-have.
A design system is leverage, not decoration
I now spend real time architecting a React design system: tokens, accessible components, Storybook, versioned with Changesets. It is tempting to file that under polish. It is not. A good design system is the reason a small team can run several apps, a dashboard, an embeddable booking widget, a marketing site, and have them feel like one product.
The payoff is not prettier buttons. It is that a new feature reuses decisions already made, and consistency becomes the default instead of a code-review argument. That is leverage, and it compounds.
Types end-to-end kill whole categories of bugs
The habit I would least want to give up is types all the way through. TypeScript on the frontend, Zod at the boundaries, a typed GraphQL schema connecting to the API. When the contract is enforced in code rather than in a doc, an entire class of “the shape changed and nobody noticed” bugs simply stops happening.
Going full-stack made this concrete. When I change a resolver and the frontend fails to type-check before I even run it, that is not friction. That is the system catching a mistake at the cheapest possible moment.
Test what you will actually keep
I have settled on a small, boring testing setup I will genuinely maintain: unit tests with Vitest, end-to-end coverage with Playwright, and enough of each to trust a deploy without babysitting it. The trap is not too few tests. It is an ambitious suite nobody keeps green. A test you will actually run beats a perfect one you will eventually delete.
Still frontend at heart
None of this made me stop being a frontend developer. It made me a more useful one. I can now follow a feature from a database migration to the last pixel, and the parts I used to hand off no longer feel like a black box.
If you are a frontend engineer wondering whether to step into the backend: the skills you think you are missing matter less than the ones you already have. Ship something small end-to-end. You will be surprised how much of it you already know.