Y

Maybe that was the right call. Maybe it wasn't. The problem is you made the decision without knowing what any of those terms actually mean — which means you also don't know what your new hire can and can't build, where they'll be slow, or what gaps they'll leave.

Frontend vs backend is one of the most basic distinctions in software engineering. It's also one of the most consistently misunderstood by the people signing the cheques. Here's a clear breakdown — not a tutorial, just enough to make better hiring decisions and stop nodding through technical conversations.

Frontend: what users see and touch

Frontend is everything that runs in the user's browser or on their phone. The buttons, the forms, the screens, the animations. When a user taps "checkout," the frontend is what registers that tap, shows a loading spinner, and displays the confirmation screen.

Frontend engineers write code that runs on the user's device, not on your servers. Their work is visual and interactive by nature. They think about layout, responsiveness, accessibility, loading speed, and how things feel to use.

Common tools: React, Vue, Next.js, Swift (for iOS), Kotlin (for Android). The language most frontend web developers work in is JavaScript or TypeScript.

What frontend engineers are not responsible for: where the data comes from, how it's stored, whether it's secure at rest, or what happens to an order after the user taps submit. That's the backend's job.

A red flag worth knowing: if your frontend engineer is also defining business rules — like how discounts are calculated or how permissions work — something has gone wrong architecturally. Business logic belongs in the backend. When it leaks into the frontend, you end up with rules duplicated in two places, which means bugs when they get out of sync.

Backend: where the actual work happens

Backend is everything that runs on your servers and never touches the user's screen directly. The database, the business logic, the API layer, the authentication system, the email queue. When a user taps "checkout," the backend is what checks inventory, processes the payment, updates the order record, triggers the confirmation email, and notifies the warehouse.

Backend engineers write code that runs on infrastructure you own or rent — not on the user's device. Their work is less visible but more consequential for reliability and scale. They think about data integrity, performance under load, security, and what happens when things fail.

Common tools: , Node.js, Python, Ruby, Java. Databases like , MySQL, MongoDB, Redis.

The backend is where your actual business logic lives. Pricing rules, user permissions, transaction flows, fraud checks — all of it is backend. If your backend goes down, your product is down, regardless of how good the frontend looks.

One thing that surprises founders: backend engineers often have no idea how their work looks to users. They're thinking in terms of API responses and database queries, not pixel alignment. That's correct. It's specialisation working as intended.

Full-stack: genuinely useful, genuinely limited

A full-stack engineer can work across both frontend and backend. They're not two engineers in one body — they're a generalist who can contribute to both sides without needing to hand off every task.

At the early stage of a startup, a strong full-stack engineer is often the right first hire. You can move fast, ship features end-to-end, and avoid the coordination overhead of splitting work between specialists.

The honest limitation: full-stack engineers are rarely as deep as specialists on either side. A full-stack engineer who's strong on the frontend tends to be weaker on the backend, and vice versa. That's fine at 3 engineers. It becomes a problem at 15, when backend performance actually matters and you need someone who thinks about query optimisation and connection pooling for a living.

The mistake founders make is hiring full-stack engineers indefinitely, then wondering why backend reliability starts deteriorating as traffic grows. At some point, you need people who specialise. The right time is earlier than you'd expect — usually around the point where one part of the system is clearly under more stress than the other.

The part most founders get wrong

Thinking full-stack means "can do everything, equally well, forever."

It doesn't. Full-stack is a spectrum. Some engineers are genuinely strong on both sides. Most are stronger on one. When you're interviewing, ask directly: which side do you spend most of your time on? Which problems do you find more interesting? Where have you hit the limits of your knowledge?

The answers will tell you a lot more than the job title.

A second mistake: assuming frontend work is simpler or cheaper than backend work. It isn't. A poorly built frontend creates slow load times, broken mobile experiences, and accessibility failures that lose you users and damage SEO. The work is different, not easier. Underpaying for frontend engineers because they "just make things look nice" is a choice you'll pay for in user drop-off and app store reviews.

Real-world example: the wrong hire at the wrong time

A B2B SaaS startup, six months post-launch, 200 paying customers. The founder hired two full-stack engineers at launch — correct decision. Fast, flexible, got to market.

At 200 customers, the product started slowing down. API response times were creeping up. Some queries were taking three seconds. Users were complaining.

The founder hired another full-stack engineer. The performance problem didn't improve. Because the problem wasn't headcount — it was that nobody on the team had experience diagnosing database performance issues at scale. They needed a backend specialist who knew how to read query execution plans and add the right indexes.

The underlying issue was architectural: the database schema had been designed for simplicity at launch, not for the query patterns that emerged at scale. A generalist can ship features. A specialist can find and fix the thing that's quietly making everything slower.

FAQ

Q: Should my first engineering hire be frontend, backend, or full-stack?

A: Full-stack almost always, unless your product is obviously one-sided — a purely data-processing tool with no user interface, or a purely visual tool with no complex logic. Full-stack gets you moving faster with fewer people.

Q: When should I hire specialists instead of full-stack engineers?

A: When one side of your system is clearly under more stress. Consistent backend performance issues = hire a backend specialist. Consistent UI/UX complaints and frontend bugs = hire a frontend specialist. Don't add another generalist and hope the problem averages out.

Q: What's a "frontend engineer" vs a "UI/UX designer"?

A: A designer defines how something should look and feel — wireframes, prototypes, visual design. A frontend engineer builds it in code. They're different skills. Sometimes one person does both; more often they're separate roles. At early stage, a frontend engineer who has decent design instincts is more practical than two separate hires.

Q: Is it a red flag if my engineer says they can do everything?

A: Not automatically. Some engineers genuinely can. But probe it. Ask for specific examples of production backend systems they've optimised and specific frontend performance issues they've debugged. Vague answers to specific questions are a signal.

Q: Does it matter which side my CTO came from?

A: More than most founders expect. A CTO with a strong backend background will build robust systems and may underinvest in frontend quality. The reverse is also true. Neither is disqualifying — but it's worth knowing which direction their instincts run so you can ask the right questions about the other side.

Knowing the difference between frontend, backend, and full-stack won't make you an engineer. It will make you a better client, a sharper interviewer, and someone who understands when a problem is a headcount issue versus a specialisation gap.

Next: what an API actually is — and why your whole product depends on one.