People sometimes ask whether I'm a frontend or a backend developer.
My honest answer is: whichever one the bug is in.
That sounds like a joke, but it is the best definition of full-stack I have. It isn't a list of technologies on a CV. It is a refusal to stop working when the problem crosses a boundary.
The definition people use
Ask around and "full-stack" usually means a set of tools. React plus Node. Next.js. A frontend framework and a backend framework.
That definition has a flaw: it changes every two years. Someone who was full-stack in one set of tools isn't automatically full-stack in the next. The tools are the least stable part.
The one I use
Full-stack means you can take an idea all the way to someone using it, and you understand each place it can break on the way.
Each layer asks a different question:
- The interface: what does the person see and touch?
- The backend: what are the rules, and who is allowed to do what?
- The data: what has to be remembered, and how are those things related?
- The infrastructure: where does this run, and what happens when it stops?
Notice that none of those questions mention a specific tool. You can answer all four with different technologies and still be doing the same job.
Why the boundaries matter
Most hard bugs don't live inside a layer. They live between two of them.
The page looks broken, but the real problem is an API returning the wrong shape. The API looks broken, but the real problem is a proxy mangling the headers. The proxy looks fine, but DNS is pointing somewhere else.
If you only know one layer, you can prove it is innocent and then you are stuck. If you can move across the boundaries, you can follow the problem to where it actually is.
For someone hiring me, that is the practical difference. Fewer handoffs means fewer places for things to fall between people. One person who understands the whole path can say what will break before it does.
What it doesn't mean
It doesn't mean equal skill everywhere. I'm strongest in TypeScript, Node, and getting things deployed and running. There are layers where I'm competent and layers where I'm still learning, and I'd rather say that than pretend.
It also doesn't mean you never need a specialist. A serious security audit, a complex data model at scale, or a heavily animated interface might all deserve someone who has spent years on exactly that.
The healthy shape is deep in one place and honest everywhere else. Know one layer well enough to be trusted with it, and the others well enough not to be surprised by them.
Where breadth goes wrong
Breadth without depth is a real trap. You can end up with a thin layer of knowledge across everything, which is enough to build a demo and not enough to run it when it breaks at 2am.
The fix is to keep going down. When something works, ask why it works. When something breaks, don't stop at the fix, find out what it was actually doing. Every time you do that, one more layer stops being a black box.
That habit is how I ended up building a cloud platform. I didn't set out to be an infrastructure person. I just kept asking what was underneath.
So, frontend or backend?
Whichever one the bug is in.