What two years of backend taught me about building interfaces

I started my career on the backend: REST APIs, database schemas, slow queries, servers and the networks between them. After two years I moved to the frontend, where I have spent the four years since leading the interfaces of enterprise and banking platforms.

At the time it felt like changing fields. Looking back, the backend years were the best preparation I could have had. These are the habits that carried over.

1. Every screen is a set of requests

When I look at a design now, I see the calls behind it before I see the layout: what loads first, what can load in parallel, what depends on what, and what happens when one of them fails. A dashboard with eight widgets that each make three sequential requests will be slow no matter how well it renders. Spotting that in the design review, and asking for an endpoint shaped for the screen, saves more time than any rendering optimisation.

2. The network is not a function call

Having debugged servers and networks, I do not assume a request succeeds, returns quickly or arrives once. Interfaces I build expect latency, show progress, retry what is safe to retry, and never submit a payment twice because someone double clicked. Timeouts, idempotency keys and optimistic updates with rollback are not backend topics; they are what users experience as "the app feels solid".

3. Data has a shape, and the shape matters

Designing schemas teaches you that data has rules: what is unique, what is required, what changes over time, what belongs to whom. On the frontend those rules become form validation, empty states, filters and permissions. When the frontend models data the same way the database does, whole categories of bugs disappear, such as forms that accept values the server will reject or lists that cannot be filtered by the field users care about.

4. Security is enforced on the server and respected on the client

Backend work makes it obvious that anything in the browser can be changed by its user. So I never rely on the frontend for security, and I also never ignore it there. The UI hides what a person cannot do, the server enforces it regardless, and the two read their rules from the same source. That same suspicion of input is how I later found a SQL injection risk in a product's database nodes during a code review.

5. Observability is part of the feature

On the backend, a feature without logs and metrics is not finished, because you cannot tell whether it works in production. I bring the same rule to the frontend: errors are reported with enough context to reproduce them, slow interactions are measured with real user data, and every error message a user sees carries an id that leads support to the matching server log.

6. Talk to the people on the other side

Most of the friction between frontend and backend teams comes from each side guessing what the other needs. Having worked on both, I can read the backend code, propose a contract change in the backend's own terms, and explain to a designer why a feature is cheap or expensive. That translation work is a large part of what makes a senior engineer useful, whatever their title says.

Would I recommend it?

Not everyone needs to work on the backend for two years. But every frontend engineer benefits from building one small service end to end: a schema, an API, a deployment and the logs to debug it. It changes how you read a design, how you review a contract and how you think about failure, and those are the skills that separate building screens from building products.