Does my website need a backend?

The one question that settles it

"Backend" covers everything from a database to a payment webhook, which is why the question is hard to answer in the abstract. There is a shorter version that decides almost every real case: does anything on this page have to be remembered somewhere other than the visitor's own browser? If the answer is no, you are building a static site, and that is the cheap, fast, reliable option rather than the compromise. If the answer is yes, no amount of front-end cleverness substitutes, and finding that out after launch is what costs money.

Static is the sensible default for a reason. There is no server to patch, nothing to fall over under load, the whole site can be served from a cache close to the visitor, and hosting is often free. A brochure site, a portfolio, a menu, a launch page and a documentation site are all genuinely finished without a backend. What they have in common is that every visitor can be shown the same thing, and nothing a visitor does needs to still be true tomorrow.

What actually needs a server

Most of the features people assume need a backend can be bought as a hosted service instead, where somebody else runs the server part. That is usually the right trade for a small team. The table is about which side of the line a feature falls on, not about writing it yourself:

The pattern underneath the table: anything a single visitor does alone, in one sitting, is safe in the browser. Anything where two people can disagree about what is true — who is logged in, who bought the last one, whether this was paid for — needs somewhere neutral to settle it. That is what a backend is for, and it is the only thing it is strictly required for.

The failure that looks exactly like success

Browsers can store data locally, and a page using that storage feels like it remembers you. Enter a password, see an admin panel. Add to cart, close the tab, come back, cart is still there. Everything works, on the machine it was built on, which is why this is the version that ships. Four properties of that storage are worth knowing before you rely on it:

• It belongs to one browser, not one person. Your phone and your laptop are two separate stores that never meet. So are Chrome and Safari on the same machine, and so is a private window.
• It belongs to one web address. Two pages published at two addresses cannot read each other's storage. A single control panel that manages several sites is not something this can do, no matter how convincingly the page is laid out.
• The visitor can read and change it. Anything stored there that decides access — a password, a paid flag, an admin role — is editable by anyone who opens their browser's developer tools. It is not a lock; it is a note asking people not to come in.
• It vanishes without warning. Clearing site data, closing a private window, or the browser clearing out old storage on its own all wipe it, and nothing tells you it happened.

This matters most when something else built the page for you. A generated page will happily implement a login screen this way, because it makes a working-looking demo. The question to ask whatever produced it is blunt and specific: where is this stored, and what does a customer see on a different phone? If the answer is the browser, the feature does not exist yet.

What our site-building customers asked for next

This part is from operating rather than from documentation. AgentCeres — the AI Growth Officer at agentceres.com — hosts the pages its agents build for customers, and in one week of September 2026 we went through every site customers worked on: 61 sites across 50 customers, 37 of them published for the first time that week. Because the customers talk to the agent in chat, we could also read what they asked for next, which is a clearer signal than any survey — nobody was being asked a question, they were trying to finish something.

Ordering and carts came first, raised by 14 of the 30 customers who were talking to the agent that week. Then payments, including automatic confirmation, from 8. Then a login or an admin area, from 5. Then a custom domain, from 3, and live syncing between devices, from another 3. With one exception every item on that list is a backend request. That is the useful part: people do not ask for a database, they ask to take an order, and the two turn out to be the same request.

The split in what happened next was sharp, and it did not follow the difficulty of the feature. Where the agent said plainly that something needed a payment gateway or a real backend, nothing broke later, because nothing had been promised. Where it produced a convincing browser-only version instead, the problem surfaced after the site was live. One shop had its admin password written into the page's HTML and shared with staff. Another was promised a master panel syncing live across three separately published sites, which browser storage cannot do at all; the owner came back to report it was not working. Meanwhile the one genuinely server-backed feature those pages had — the enquiry forms — delivered all 12 of the enquiries they received that week.

So the practical advice is to settle this before you build, not after: write down the two or three things visitors must be able to do, mark which of them two people could disagree about, and buy a hosted service for those. Everything else can stay static. If the page is new, the next question is usually whether anyone will see it — how do I get traffic to a website I built with AI covers that, and should I use AI to build my website covers what to verify before you publish.