Full-stack used to mean something. It meant you could build a feature end-to-end — handle the data, write the API, ship the UI. That's a legitimate skill. But somewhere along the way, it became a resume line that means 'I have done something on both sides of the network at least once.' And employers started hiring for it as if depth doesn't matter, and developers started leaning into it as if breadth is the same thing as mastery.
What most 'full-stack developers' actually are
They're frontend developers who have touched a backend. Or backend developers who have copy-pasted some React. There's nothing wrong with that — it's useful, it gets things done, teams need people who can cross lines. But calling it full-stack implies a kind of symmetry that usually isn't there. You have a dominant side. Everyone does. Pretending otherwise mostly just makes you harder to place on a team.
The depth problem
When you optimize for being full-stack, you optimize for breadth. You learn enough of everything to be dangerous and not enough of anything to be exceptional. You can build the feature, but you can't tune the query that's killing your database. You can write the component, but you don't understand why the re-renders are making the app feel slow. At some point, the problems worth solving require depth you don't have — and you feel it.
A T-shaped developer is valuable. A pancake-shaped one isn't.
— Zaid Maraqa
What to say instead
Be honest about where your gravity is. 'I'm primarily a frontend engineer who's comfortable with Node and basic infrastructure.' That sentence is more useful than 'full-stack' to every hiring manager, team lead, and collaborator you'll ever work with. It sets expectations correctly. It tells people what they're getting. And it doesn't set you up to be the person responsible for every layer of a system because you said you could handle all of them.
When full-stack actually makes sense
Early-stage startups. Solo projects. Small teams where coverage matters more than excellence in any one area. These are real contexts where being able to touch everything is genuinely valuable. But even then, you're making a tradeoff — speed and coverage over depth. Know that you're making it. The developers who grow the most are the ones who deliberately go deep somewhere, even if they stay useful everywhere else.