Where data lives

You book a dentist appointment on Doctolib from your laptop, and that evening it shows up when you open Doctolib on your phone. The appointment was never stored on the laptop. It went into Doctolib's database, on its servers, under your account, and each device simply asks for it. That's the first place data lives: the company's database. It follows you wherever you log in, and it survives a lost phone.

The second place is your browser. Each site can keep a little data in the browser on your device: cookies, which go back to the server with each request, and local storage, which stays on the device. It suits small things, and it never leaves that browser on that device.

The third place is outside services. The payment company keeps your card details, the email service keeps your address to send reminders, the analytics tool keeps a record of your visit. Each holds its own copy, under its own rules, sometimes in another country.

Which place holds a piece of data decides who can see it, whether it follows the user, and what happens when someone deletes it.

Log in to Le Monde on a computer at the library, and the site greets you by name on every page you open. When you logged in, the server checked your password once, then gave the browser a session cookie: a long random code, a bit like a cloakroom ticket. From then on, the browser attaches it to every request, and the server uses it to look you up. Your password doesn't travel again. Your name, your subscription and your saved articles stay in the database: the cookie only says who you are.

Three things follow from this. On another computer you have to log in again, and then you see exactly the same things, because they come from the server. Clearing your cookies, or closing a private window, logs you out but deletes nothing from your account. And whoever gets hold of that cookie can act as you without knowing your password, which is why you log out before leaving a shared computer.

You browse a furniture shop without an account. The next day, the same laptop still shows the sofas you looked at and the language you picked. On your phone, they're gone. Nothing is broken. With no login, the site had no account to file this under, so it kept it in your laptop's browser. Your phone is another browser, with its own storage, empty for that shop, and the server has no way to know the two belong to the same person. Your IP address, the number your connection uses on the internet, can't help: it changes from one network to the next, and everyone on the same Wi-Fi shares it.

This is a product decision, and it's worth making on purpose. Things people expect to find everywhere, like favourites or progress in a course, belong on the server under an account, so the site can offer a login and move them there when the person signs in. Small preferences, like a language or a text size, can stay on each device. Either way, clearing browser data or using a private window wipes whatever was kept only in the browser.

Your company's careers page lists open positions, and HR wants to add new ones every week. The developer asks: "Shall I write the text into the code? It's quicker." That's a question about where content lives.

Text written into the code only changes when someone edits the code and publishes a new version of the site: the developer again, or someone who can use an AI agent, check the result and put it online. Text stored as data can be edited by the people who own it, through an admin screen. That screen is a CMS (content management system): WordPress, Webflow's editor, or even a shared spreadsheet the site reads.

A CMS costs setup, money and maintenance, so it's worth it for content that changes often. A legal notice that changes once a year can stay in the code. Sometimes the content already lives elsewhere, like job offers in a recruiting tool, and the site can fetch it automatically. Decide who is allowed to publish, too. And right-click → Inspect doesn't count as editing: it only changes the copy of the page on your own screen.

Questions about data are product questions, so ask them early, before anything is built.

Make a list of what the site remembers about people, and for each item ask where it's kept: in your database, only in the browser, or at an outside service. Ask what should follow a user from laptop to phone, and check that it's stored on the server under an account. Ask where the database is hosted, and in which country, since the personal data of people in Europe comes with GDPR duties. Ask which outside services receive your users' data, and what each one does with it. Ask what happens to someone's data when they delete their account.

For the content, ask who will change what after launch, and how often. The answer tells the developer where to build an admin screen, and where text in the code is good enough.