Static pages or a database, and how to pick

Every build decision comes down to one question: does the site need to remember anything?

Static: nothing is remembered

A static page is a file. The server hands the same bytes to every visitor, and there is no state to lose. It is fast because there is nothing to assemble, it is cheap to host because a single file needs almost nothing, and it survives neglect because there is no application to maintain.

For a business page, a menu, a portfolio, a service description, or a landing page for a campaign, this is the correct answer. The traffic pattern is “many people read, nobody writes”.

Full: something is written down

The moment a visitor submits something you want to keep, you need a place to keep it: appointments, orders, registrations, enquiries that must not be lost when an email bounces.

That means a server application, a database, and a login for whoever reads the submissions. Now there is state, and state has requirements: backups, a schema that does not corrupt, a validation path that runs on the server and not only in the browser, and someone responsible for updating the stack.

The middle ground that fools people

Most sites are static pages with one or two dynamic pieces. A contact form is the usual example. Some page builders hide a server behind a form field, and that server is now part of your site whether or not anyone told you. It will need updating, and if it breaks the form stops working while every page still looks fine. That failure is invisible from the outside, which is the worst kind.

How we decide

We count what must be stored. Nothing to store: static, and the price stays low. Anything to store: a full build, with the storage documented, backed up, and exportable in a format you can open without us. If a client cannot say where their data lives and how to get it out, the build is not finished.