Backend Is Not Enough

TL;DR: Backend depth is essential, but insufficient for engineers who want to influence product outcomes. The best engineers think about the full product, not just one layer.

What to expect:

Why dismissing frontend is a costly mistake

The product engineering mindset

Why architectural quality alone doesn't guarantee product success

What to actually focus on as an engineer

My Side of the Story

When I started my journey as a Software Engineer, I was fascinated by frontend. I just like it when people enjoy the experience of interacting with something that I built.

Often, I saw people who took the opposite path, focusing on backend, and mocking those who chose differently:

"I hate CSS"
"Frontend doesn't matter"
"I don't care about learning CSS, we have Material UI, why should I bother?"

Those are only some of the things I saw people saying in the past. Today, the talk is different:

"Frontend is dead, AIs can do everything on frontend, why should I care?"

In a way, I agree that frontend today is much easier than 3 years ago, when you had to do things by hand. But, for me, it's far from being easy or dead.

Before we dive in, here's a quick example. This is my website. Same content, same buttons, same information. The only difference is the frontend. Hit "Beautify" below and tell me — which version makes you want to click around?

giovanes.dev

Giovane Saes

Product & AI Engineer

Who are you?

I am an engineerI am a recruiterI am a wanderer

Let's talk about why that matters.

"But AI Can Build Frontends Now"

Yes, it can. And it's genuinely impressive. You can describe what you want and get a working UI in seconds. But here's the thing: most AI-generated frontends converge toward the same patterns and aesthetics unless guided intentionally. Same component libraries, same layouts, same spacing, same vibe. It's functional, but it's generic.

The question isn't "can AI build a frontend?" It's "do you want your product to look like everyone else's?" Technically complete, but lifeless. Nobody's bookmarking that.

AI is a fantastic accelerator, but it doesn't replace taste, craft, or the ability to make something feel right. The engineers who treat frontend as a commodity will ship commodity products. The ones who care will stand out. And so will their work.

Why Frontend Matters As Much As Backend

Think about a common backend concern: "I can't let a payment go through twice. I need to add idempotency and a lot of logic to mitigate that, otherwise users will never buy on my website again!"

That's a completely valid concern. Double payments cause trust damage, regulatory headaches, support tickets, and angry users. Preventing that is critical work.

But what if your users have such a bad experience browsing your product listings that they don't even bother clicking to buy?

The double-charging scenario at least implies a user who made it to checkout. If your UI is so bad that people bounce before they even browse your products, you don't get the chance to have backend problems. You just have no users.

And yes, there are domains where backend complexity genuinely dominates: financial infrastructure, distributed databases, real-time trading systems. I'm not pretending those aren't hard. But even those products have users who interact through a UI, and if that UI is confusing or broken, the engineering behind it doesn't matter to them.

That's why, for me, it's not about "which is more important." It's about balance. Both a double-charging app and an e-commerce with a terrible UI lead to the same outcome: people stop using your product. They're just different failure modes.

The Product Mindset

Now, let's make something clear: I'm not saying learning backend, DevOps, and security aren't important. I'm just saying — why learn only one of those?

In my first job, as an entry-level frontend engineer, I often needed a new API endpoint, a new filter, or some processing on the backend. So I asked the backend team: "hey, can you please add that to the API?" But guess what? That takes time. Sometimes, that dependency turned a 5-minute task into a 2-hour wait, because I was blocked by someone else's work.

This isn't unique to my team. It's a structural consequence of how most organizations split engineering responsibilities. Specialization creates handoffs, and handoffs create bottlenecks.

That's why, from that moment on, I decided to become a full-stack engineer.

After that, I got promoted to a mid-level full-stack engineer. Things were way easier. I could finish tasks faster, without blockers, without needing to wait for a simple API endpoint. And that was beautiful.

Until I needed a caching layer to avoid overloading the database.

Now, I had another issue: infrastructure. Same story: waiting for someone to set everything up so I could use it. From that moment, I decided to develop enough depth across the stack to unblock myself and make informed decisions at every layer.

That's what people call Product Engineering — the practice of aligning technical decisions with user-perceived value and business outcomes, owning the full path from infrastructure to interaction. And I think that's what every engineer should care about.

Your Product Is What Users See

Products only exist because they solve someone's problem:

Microwaves exist because people need to heat their food
Instagram exists because people like to connect and post photos
Cars exist because people don't want to walk long distances

They're all products, and they all have users.

It doesn't matter if you can handle millions of HTTP requests per second. Most of your users will never know that's a thing. They just click a button to update their profile picture, and that's it. They don't know about compression, CDNs, blob storage, presigned URLs, or any of those technical things.

For them, what matters is what they see.

Imagine a user trying to upload their profile picture, and your backend takes 3 minutes to process it. If you stick them in a 3-minute loading state, their patience erodes with each attempt. Maybe not the first time, but eventually they stop coming back. I guarantee it, because I am one of them.

Then, you might think: "there's nothing we can do, that's the time we take to upload the file." That might be true, but you're completely ignoring something: the issue is the loading state.

We can easily solve that by saving the file into a local variable, making an optimistic update (showing the local image instead of waiting for the remote one), and updating in the background. If it fails, we notify the user to try again. If not, the next time we just use the file from the blob storage.

That's probably a 30-minute change on the frontend, without touching the backend, and it changes the user experience to an instant profile update.

Here's another one: imagine a search feature. Your backend returns results in 200ms, lightning fast. But the frontend has no debouncing, no loading skeleton, and the results jump around as images load in. The backend did its job perfectly, but the experience feels broken. No backend optimization in the world can fix that — it's a frontend problem.

Backend work is easier to measure and defend in code review. "We reduced latency by 40%" fits in a spreadsheet. UX improvements like "the checkout flow feels smoother" are harder to quantify. Engineers naturally optimize what they can measure, which is why the frontend often gets neglected.

A product doesn't feel fast because of its architecture alone. It feels fast because someone deliberately optimized the perceived experience.

The False Hierarchy

There's a structural reason backend work carries more prestige in most organizations. Backend deals with data, security, and scale. Things that sound important in meetings and are easy to quantify. Frontend work gets reduced to "making things pretty," which undersells the actual complexity involved.

But it goes deeper than perception. The industry actively reinforces this hierarchy:

Interviews reward system design over product thinking. You'll spend 45 minutes designing a URL shortener, but nobody asks how the user will interact with it.
Team structures often split into "core engineering" (backend) and "UI team" (frontend), implicitly ranking one over the other.
Promotion ladders reward measurable impact, and backend metrics are easier to quantify. Reducing latency by 40% gets you promoted, while improving onboarding flow gets you a "nice to have."
Hiring processes filter for algorithms and system design, which maps directly to backend thinking. Product sense rarely shows up in interview rubrics.

I've seen teams spend months optimizing latency while ignoring onboarding friction that was costing them significant activation. The backend was fast, the infrastructure was solid, but users were dropping off before they ever experienced any of it.

Frontend has its own hard problems: rendering performance, complex state management, accessibility, cross-browser compatibility. And those problems directly affect whether your users stay or leave.

What To Focus On?

Engineers often misdiagnose problems because they optimize what they're comfortable with, not what the product actually needs. You need to focus on what matters at a given time.

Struggling with deployment? If you can't figure out how Docker containers work, or how to deploy safely without compatibility issues, study infrastructure and Docker.
Users aren't sticking around? If you have a really strong backend, but can't hook users or make them enjoy your app, study frontend and how to improve UI/UX.
Slow performance? If users love the experience on your website, but your dashboard takes 30s to load, study how to optimize your backend and reduce that load time.

Your product's weakest layer is the one holding it back. Not the one that sounds the least impressive on a resume — the one that's actually losing you users right now. That's where your time should go.

You don't need to be an expert in everything. But you need enough understanding across the stack to spot where the real problem is and unblock yourself. That's the product mindset again: not "what's my specialty?" but "what does this product need from me right now?"

It's not about setting up infrastructure, building a tremendously scalable and reliable backend, or building the most beautiful UI in the world. It's about building products that make sense and focusing on what matters.

Conclusion

Go back up and toggle the comparison one more time. Same content, same features, same backend — completely different product. That's the gap between "it works" and "people want to use it," and no amount of infrastructure can close it.

The best engineers don't pick a side. They ship the full experience. The engineers who have the most impact are the ones who stop optimizing for a single layer and start optimizing for the product.

The layer you optimize doesn't matter. The outcome does.

If this resonated with you, give it a like and share it with someone who needs to read it.

Farewell!