What happens when you own the whole stack
·2 min read ·Career · Full-Stack · Architecture
I've worked as a frontend developer, a full-stack engineer, and now as a CTO who still codes. The difference between 'knows both frontend and backend' and 'thinks across the full stack' is larger than it looks.
The Frontend Developer Who Doesn't See the Backend
A frontend developer who doesn't understand the backend tends to make requests that seem simple but aren't. 'Can we just add this field to the response?' can be trivial (add a column) or expensive (requires a join across three tables for every request in a hot path).
Without backend context, you can't make good tradeoffs about what to fetch, when to fetch it, and how to structure the data contract between frontend and backend.
The Backend Developer Who Doesn't See the Frontend
A backend developer who doesn't understand the frontend tends to design APIs around data models rather than around what the UI actually needs. The result is endpoints that return everything and leave the frontend to figure out what to use, or endpoints that require three separate calls to render a single view.
Good API design requires knowing what you're building the API for.
What Full-Stack Actually Changes
When you own the full stack, you make different decisions at every layer:
- The database schema is designed with the query patterns in mind
- The API endpoints return exactly what the UI needs, shaped to avoid extra work on either side
- Frontend performance problems get solved where they're cheapest to fix—sometimes that's caching on the backend, not optimizing the render cycle
The Tradeoff
Going deep in one area is valuable. Specialists in database optimization or frontend performance know things that generalists don't. The full-stack advantage is breadth, not depth.
But for building products—especially early-stage ones where the team is small—the ability to see across the stack and make coherent decisions across layers is more valuable than deep specialization in one.