Article · 2 min
Stop fixing backend problems in the frontend
The slow screen wasn't a frontend problem. It rarely is. The fix belongs to the layer that owns the problem — and finding that layer is a skill.
When a feature underperforms, the symptom shows up in the UI. A screen is slow. A view is awkward. The data arrives in the wrong shape. And because the symptom lives in the frontend, that’s where teams instinctively fix it — a client-side cache here, an extra request there, some defensive reshaping of whatever the API returned.
Each workaround is locally reasonable. Together they mask the problem instead of solving it, and the masking compounds over time.
The pattern, three times over
The same situation found me across three different products.
At Sophos, working on a banking dashboard, endpoints sometimes didn’t return what the frontend actually needed, or the queries behind them were slow. Instead of contorting the UI around the responses, I made backend and API adjustments — reshaping what the endpoint returned to match what the consumer needed.
At SmartBeemo, performance work meant reviewing queries and trimming what the API sent to the frontend, sometimes reaching into the MongoDB data model itself. That cut page load times by about 25%.
At House Edge, the work was optimizing backend queries running over very large datasets.
Different stacks, different domains, same move every time.
The method
It’s a diagnostic habit more than a technique:
- Understand what the consumer — usually the frontend — actually needs.
- Analyze the endpoint and the query behind it.
- Find the over-fetching or the inefficiency.
- Fix it at the layer that owns it.
- Confirm the frontend still behaves.
Most of the time the problem is over-fetching: the API sends far more than the view needs, because it was built for a different consumer or built generically. The frontend can hide that with loading states and client-side filtering. Or the API can just stop over-sending.
Why full-stack is the enabling condition
Here’s the part I think is under-appreciated: you can’t fix at the right layer if you can only see one layer. A frontend-only engineer facing a slow screen has exactly one place to work, so that’s where the workarounds accumulate. Working across the stack means you can follow the problem across the boundary and fix it where it lives.
A fix in the API or data layer usually beats three workarounds in the UI. Solve where the problem actually is — everything downstream gets simpler.