Back end

If the front end is the shop floor, the back end is the stockroom and the office. It usually combines a server, a database and code written in a language such as PHP, JavaScript or Python. When you submit a contact form, check a booking or log in to a dashboard, the back end does the work.

People sometimes say "the back end" when they mean the admin area of their CMS, the screens where they edit content. That admin area is part of the back end, but the back end also includes everything the visitor never sees, such as emails being sent, payments being confirmed and data being saved.

How it works

A request arrives at the server, for example "show me tours in June" or "save this enquiry". A web server receives it and passes it to the application code. That code checks the request is valid and allowed, reads or writes data in the database, applies the business rules and sends a response back, either a finished page or data the front end will display.

Around that core sit the jobs nobody sees: sending confirmation emails, resizing uploaded images, running scheduled tasks overnight, talking to payment providers and other services through their APIs, and writing logs that record what happened. Many of these run on a timer or in a queue rather than while the visitor waits.

The back end is also where security lives. Passwords, customer records, prices and payment confirmations must be checked and stored on the server, because anything sent to the browser can be seen and changed by the visitor. A price that is only checked in the browser can be edited before the order is submitted.

Example

A cleaning company adds online booking. The front end shows a calendar. The back end checks which slots are still free, saves the booking, emails a confirmation to the customer, alerts the office and blocks the slot so nobody else can take it.

None of that is visible, but each step can fail. If two customers press book on the same slot at the same moment, the back end has to accept one and politely refuse the other; if the email service is down, it should retry rather than lose the confirmation. Handling those edge cases is most of the effort in a reliable booking system.

Why it matters for your business

A back end is what lets a site do work for you: take bookings, manage stock, collect and route leads. It also brings ongoing costs, because servers, databases and code need hosting, security updates and backups for as long as the site runs. If your site only needs to present information, a static site with no custom back end can be cheaper and safer. If it does need one, ask who will update it after launch, how backups are tested and how long a restore would take. A back end that nobody maintains does not stay still: the software around it keeps changing, and unpatched server code is a common way small sites get compromised.

Common mistakes

• Checking form input only in the browser, which anyone can bypass, instead of also on the server.
• Building a custom back end for features that a reliable existing service already handles.
• Leaving server software and plugins un-updated for years after launch.
• Having no tested backups of the database, so one failure wipes out every enquiry and booking.

Questions people ask

Does every website need a back end?

No. A static site that only shows information can run with no custom back end at all. You need one when the site must store or process data, such as bookings, accounts, orders or forms that save to a database rather than just sending an email.

Which language is best for a back end?

There is no single best one. PHP, JavaScript with Node.js, Python and others all power large sites. What matters more is that your hosting supports it, that developers are easy to find and that the code is maintained. Familiar, widely used choices are cheaper to support.

Is the back end the same as the CMS admin panel?

Not quite. The admin panel where you edit pages is one part of the back end. The back end also covers the server code, the database, emails, integrations and security checks that run whether or not anyone is logged in.