Guides / How websites & apps work

Guide · Web

What You're Buying When You Pay for a Website or App

01Why ten minutes on this is worth it

You don't need to know how an engine works to buy a car — but you'd want to know whether you're being quoted for a hatchback or an SUV. Websites are the same. When one quote says £600 and another says £6,000, the difference usually isn't cheek; it's that they're quoting for different machines. This guide gives you just enough of the mechanics to tell which is which.

02The big picture

Here's the whole thing on one diagram. Don't worry about the labels yet — we'll walk through each part below.

03The frontend — what people see

The frontend is everything that appears on your customer's screen: the layout, the colours, the text, the buttons, the things that move. It's delivered to their phone or laptop and runs right there in their browser.

A "static" website — a brochure site with your services, photos and a contact form — can be almost entirely frontend. That's not a lesser product; it's the right tool for the job of being found, looking professional and getting enquiries. It's fast, very cheap to run, and there's very little to go wrong or maintain.

04The backend — the engine room

The moment your site needs to do something — take bookings, let customers log in, process payments, show different things to different people — you need a backend. This is a program running on a server that receives requests from the frontend, applies your business rules ("is that time slot free?", "is this discount code valid?") and sends back answers.

The backend is usually where most of the build cost in an app quote lives, because it's where your business logic gets translated into software. It's also what separates "a website" from "a web app" — the words get used loosely, but the engine room is the real dividing line.

05The database — the filing cabinet

If the backend is the engine room, the database is the filing cabinet beside it: the organised store of everything that needs remembering — customers, bookings, orders, invoices, stock. The backend is the only thing that reads or writes it; your customers never touch it directly.

When a developer mentions PostgreSQL, MySQL or SQL Server, this is the part they're talking about. The names matter less than the questions: what's stored in it, is it backed up, and where does it live? — that last one matters for GDPR if it holds personal data.

06Domains, hosting and the padlock

Three more pieces complete the picture, and they're easiest as an analogy:

• The domain (yourbusiness.co.uk) is your address — rented annually, typically £10–20 a year. Make sure it's registered in your name, not your developer's. It's the single most important thing on this page.
• Hosting is the premises — a computer you rent that holds your frontend files and runs your backend. A brochure site shares a server for a few pounds a month; a busy app might need something bigger.
• SSL/HTTPS is the lock on the door — the padlock in the browser bar that encrypts everything in transit. It's normally included with hosting these days; nobody should be charging you much for it.

07Why one quote is £600 and another is £6,000

Now the diagram pays off. A £600 quote is usually the first two boxes: frontend plus basic hosting — a well-made brochure site. A £6,000 quote is usually all four boxes: custom backend logic, a database designed around your business, user accounts, integrations, testing. Neither price is wrong — they're different machines.

The expensive mistake isn't picking either one; it's paying SUV money for a hatchback, or expecting a hatchback to do an SUV's job. Asking "which boxes am I buying?" cuts straight through it.

08Questions to ask whoever builds yours

Take these to any quote conversation (including one with us — we'll happily answer all six):

1. Is the domain registered in my name, and do I have the login for it?
2. Which parts am I getting — frontend only, or backend and database too?
3. What are the monthly running costs once it's live, and what are they for?
4. Where is it hosted, and where is customer data stored?
5. Is there a backup, and has restoring from it ever been tested?
6. If we part ways, what do I walk away with — files, code, database, logins?

A good developer will answer these without flinching. Hesitation on questions 1 or 6 is your cue to walk away.