Why "Full-Stack" Stopped Being Optional

A few years ago, "full-stack" was a nice-to-have on a resume. Today, almost every serious hiring post I see — including ones from our own team — asks for it as a baseline, not a bonus.

Here's why that shifted.

Why It Changed

Startups and small teams can't afford to hire a frontend specialist, a backend specialist, a DevOps person, and a PM separately for every project. One person who can go from a React screen to a FastAPI endpoint to a deployed container is simply cheaper and faster to coordinate.

AI coding tools closed a lot of the "I don't know this language" gap. The barrier was never really talent — it was time to learn syntax. That barrier dropped hard in the last two years.

What "Full-Stack" Actually Means Now

It's not "I can write some HTML and some Python."

It's: I can take a feature from idea → UI → API → database → deployed → monitored, and I understand enough of each layer to not need a translator between teams.

The Risk

Full-stack without depth anywhere is dangerous. I've seen "full-stack" developers who can wire up a CRUD app but have never debugged a production incident at 2 AM. Breadth without at least one area of real depth just means you're mediocre everywhere.

My take: pick one area to go deep — for me it's DevOps/infra — and build enough full-stack range around it that you're never blocked waiting for someone else.