Answer first: the frontend is everything your visitor sees and interacts with in the browser. The backend is everything that happens on the server – data storage, business rules, authentication, integrations. A slow-loading page is usually a frontend problem. A form that submits but never emails anyone is a backend problem. Knowing which side a problem lives on is the difference between a productive conversation with your developer and a frustrating one.
The frontend: what the user touches
Frontend development builds the interface. It takes the design and turns it into working, responsive, accessible screens that behave correctly on a 6-inch Android phone and a 27-inch monitor.
Built with: HTML, CSS and JavaScript, usually through a framework such as React, Next.js, Angular or Vue.
Frontend owns: layout and responsiveness, page load speed as experienced by the user, animations and interactions, form validation before submission, accessibility, and how the site renders across browsers and devices.
Problems that live in the frontend
- The site looks broken on mobile, or a menu will not close
- Pages feel slow to appear even though the server responds quickly
- Text is unreadable on small screens; buttons are too small to tap
- Layout shifts while the page loads and you tap the wrong thing
- It works in Chrome but not in Safari
The backend: what the user never sees
Backend development builds the machinery. When someone submits a form, logs in, checks availability or completes a payment, the backend is what receives that request, applies your business rules, talks to the database and other systems, and sends back a response.
Built with: Node.js, PHP or Laravel, Python or Django, and a database such as MySQL or PostgreSQL – plus the APIs connecting to everything else.
Backend owns: data storage and integrity, user accounts and permissions, business logic and rules, third-party integrations, email and notifications, security, and how the system behaves under load.
Problems that live in the backend
- The enquiry form submits successfully but nobody receives the email
- Two customers book the same slot
- Data is missing, duplicated or inconsistent between systems
- The site is fine with ten visitors and collapses with a thousand
- A user can reach a page or record they should not have access to
- Payment succeeds but the order does not appear
A worked example: the enquiry form
One form, both halves, and a useful illustration of how to diagnose.
- Frontend: renders the fields, checks the email address looks valid, disables the button while submitting, shows a success message
- Backend: receives the data, validates it again (because frontend validation can be bypassed), guards against spam and injection, writes it to the database, sends the notification email, pushes it to the CRM
So when someone says “the contact form is broken”, the diagnostic question is simple: does a success message appear? If yes, the frontend did its job and the problem is on the backend – most often email deliverability or a failed integration. If the form does not respond at all, start with the frontend.
What full stack means, and when you need one
A full stack developer works competently on both sides. For a small business website, one capable full stack developer is often the right and most economical answer – the surface area is small enough for one person to hold in their head.
For anything with real complexity – a portal, a booking platform, a system with meaningful data – specialists produce better results. A frontend specialist builds interfaces that hold up on real devices; a backend specialist designs data structures that do not need rebuilding when you add a second product line. Asking one person to do both at that scale usually means one half is weaker, and it is normally the half you cannot see.
Why this matters when you are buying
Three practical consequences.
- Vague briefs get vague quotes
“The website is slow” could mean images are too heavy (frontend), or that every page load runs an unindexed database query (backend). These cost very different amounts to fix. Describing the symptom precisely – what you did, what you saw, on what device – gets you a real answer instead of an estimate.
- Designagencies often only do half
Plenty of firms selling “website design and development” deliver excellent frontend work and subcontract the backend, or avoid backend requirements entirely. That is fine if your site is genuinely informational. It is a problem the moment you need a login, a booking or an integration. Ask directly which half is in-house.
- Maintenance differs on each side
Frontend work ages visually and through browser changes. Backend work ages through security vulnerabilities, and that ageing is dangerous rather than merely unattractive. An unpatched backend is how business websites get compromised. If a maintenance quote only covers “design updates”, it is not covering the risk that matters.
What to ask a development team
- Which parts of frontend and backend are handled in-house versus subcontracted?
- Which frameworks do you use, and why those for my project specifically?
- Who maintains the backend after launch, and how quickly are security patches applied?
- If I need to move to another developer in two years, how hard is that?
The last question is the most revealing one on the list, and the one least often asked.
