Front and back

Buy a train ticket on SNCF Connect and three kinds of computers work for you. Your browser runs the front end: the page, the seat map you click, the form that warns you when your email address is missing. SNCF's servers run the back end: they search the timetable, check that the seat is still free, save the booking and issue the ticket. Outside services do specialised jobs: a payment company handles your card, an email service sends the confirmation, an analytics tool counts your visit.

Whatever happens on the servers, what reaches your browser is always the same three kinds of files: HTML for the structure, CSS for the look and JavaScript for the behaviour. The browser runs them on your computer, with your processor and your connection.

Placing each feature in one of these three zones is the first move whenever you read a quote, judge a plan an AI wrote or try to understand a bug. It tells you who builds that feature, who pays for it and who can change it.

A grocery site lets you pick a delivery slot. Full slots are greyed out, and the page adds up your basket. Both are handy, and both run in the customer's browser, on their own computer. With the developer tools, anyone can switch a greyed-out button back on or change a number in the page. They can even skip the page and send an order straight to the server, with whatever slot and price they like. Nobody needs to hack the server for that.

Checks in the page are there for comfort: they give honest customers instant feedback. The rule itself has to be checked again on the server, which must never trust what the browser sends. The server looks up the slot in its own calendar and refuses it if it's full. It works out the price from its own catalogue, and uses the order only to know which products were chosen. Anything the page contains, such as a list of valid promo codes, the visitor can read too.

Apps built in a hurry, including many built by AI agents, get this wrong. For every rule that costs money when broken, ask whether the server checks it.

Your cousin runs a yoga studio. Her site is a few pages hosted for free on GitHub Pages, and she'd like class sign-ups plus a members' page with recorded sessions. A friend offers to "just add it" over a weekend.

Today her site is static: files prepared in advance and served as they are. Nothing runs on a server and nothing is stored, which is why it's free and almost never breaks. Sign-ups need somewhere to keep data: either a ready-made service (a booking tool, a form service) or a database of her own on a service such as Firebase or Supabase. The members' page needs accounts with a login, and rules on a server that send the videos only to members. An unlisted page, or a password check in the page's JavaScript, keeps nobody out, because the page and its code reach every visitor.

Once it's live, she holds personal data with GDPR duties, has accounts to manage, faces limits and bills that grow with use, and needs someone to own it all when the friend moves on. A ready-made service usually leaves the least to look after.

Agency proposals often name a tool and stop there. "We'll build it with React" sounds complete, yet React only builds the interface that runs in the browser. It says nothing about a server, a database, accounts, hosting, or how your team will edit the text.

WordPress covers much more. It builds pages on a server, keeps the content in a database and gives you an admin screen to edit it, so it needs hosting with a database and regular updates. Webflow puts a design tool, hosting and content editing into one monthly subscription, with little room for custom server code, and moving away from it later is hard. Firebase and Supabase rent you a back end: a database, logins and file storage, with access rules you write yourself.

So read a stack like a map. For each tool, mark which zones it covers: the browser, the servers, the data, the hosting. Every zone left blank is a question to send before you sign. And a tool's name says nothing about the quality of the work: good and bad sites are built with all of them.

These questions work with any team: an agency, a freelancer, or a colleague with an AI agent.

For every rule that costs money or exposes data when it's broken (a price, a limit, who sees what), ask "Is this checked on the server?" and expect a clear yes. When a proposal names tools, ask which parts of the map each one covers and who provides the rest: hosting, database, logins, outside services. Ask whether your own team will be able to change texts and images without calling anyone, because the answer changes what gets built.

Then ask about life after delivery: who updates the site, who answers when it breaks, and what it costs each month. If you might change agency one day, ask whether you can take the site and its data with you.