I have never been interested in stopping at a single layer of the stack.
The interesting problems usually happen at the boundaries:
- the mobile app is correct but the API contract is weak,
- the backend works but deployment is fragile,
- the model performs well in isolation but not in a real pipeline,
- the hardware behaves differently once real users are involved.
That is why I keep building across frontend, backend, DevOps, and sometimes even firmware or computer vision.
What this changes in practice
Working across the stack makes me faster at debugging and better at product thinking.
If an issue appears in production, I do not need to wait for the problem to be translated across four teams before I can reason about it. I can usually trace the failure from UI to API to infrastructure and reduce the unknowns quickly.
The tradeoff
The downside is obvious: there is always more to learn.
But for the kind of products I want to build, that tradeoff is worth it. I would rather be the engineer who can connect the system than the one who only understands one slice of it.