Two ways to arrive at the same page
Every website is code by the time a browser sees it. The question is who wrote it and when.
With a page builder — Wix, Squarespace, or WordPress with a visual editor — you arrange elements in an interface and the platform generates the code, usually at the moment someone visits. The tool sits between the intent and the output.
A code-first site is written directly. The structure, styles, and content are authored as files, then assembled into finished pages. Often those pages are built once, ahead of time, and served as ready-made files. That is what “static” means in this context: not unchanging, but pre-assembled.
The distinction is not about craftsmanship. It is about where control sits and what the site is capable of becoming.
What building ahead of time changes
When pages are generated on every visit, the server does work each time: query a database, run the theme, apply the plugins, assemble the HTML. When they are built ahead of time, that work already happened.
The practical consequences:
Speed. Serving a prepared file is close to the fastest thing a server can do. Page experience is something search engines measure, so this is not purely a comfort issue.
Fewer moving parts at request time. No database call means no database to be slow, misconfigured, or compromised during a visit.
A smaller attack surface. Most website compromises exploit outdated plugins or server-side code. A site with less running has less to exploit.
Cheaper, simpler hosting. Static files can be served from almost anywhere.
What you give up
This is where honest accounts usually stop, so it is worth being direct.
Editing is less immediate. With a page builder, a client changes text in a browser and it is live. A code-first site needs a rebuild, and without a content system attached, it may need a developer. This is the real cost, and for many small businesses it is decisive.
Genuinely dynamic features need more thought. User accounts, live inventory, anything personalized per visitor — none of it is impossible, but none is free the way installing a plugin is.
There is no plugin for it. A page builder’s ecosystem means common features are usually a search away. Code-first means building it or integrating a service.
It requires a developer. Not just to build, but to change. A business that wants full independence from technical help should weigh that carefully.
The middle ground most sites actually want
The trade-off above is softer than it sounds, because the two approaches are not mutually exclusive.
Content can live in a system non-technical people edit comfortably, while the site itself is still built ahead of time and served as static files. The editor gets a familiar interface; the visitor gets a prepared page. Interactive pieces — a booking widget, a form, a search box — are added only where genuinely needed, rather than loaded everywhere by default.
That combination is what most business sites benefit from: the editing experience of a platform, without the per-visit assembly cost on every page.
When code-first is the right answer
It fits well when:
- The site is mainly content: services, information, proof, contact.
- Speed matters, which is nearly always.
- The design should follow the business rather than a template.
- The business has, or is willing to have, ongoing technical support.
- Security and low maintenance are worth real money.
It fits poorly when:
- Nobody will be available to make technical changes.
- The site depends on a specific plugin ecosystem.
- Heavy per-user functionality is central to the product.
- The budget suits a template, which is a legitimate constraint.
The question underneath
“Code-first or page builder” is rarely the useful question. The useful one is what the site has to do, for whom, and who will maintain it.
A restaurant needing hours, a menu, and a phone number is well served by a builder. A practice competing on structure, search visibility, and speed usually is not. A business with an unusual workflow may need something closer to an application.
Choosing the build before understanding the requirement is how sites end up fighting their own foundations. The approach should be an outcome of the brief, which is where our website development work starts.