A hosted builder or a static site generator

What a static generator does

It takes content files and templates and produces finished pages ahead of time. Those pages are then served directly, with no database and nothing running when somebody visits.

The result is genuinely fast and hard to attack, and a crawler or an answer engine gets the finished page with nothing to run. For sites that do not need to change per visitor, it is technically the cleanest approach available.

Our own site is built this way, which is why we can say honestly that it is excellent and that it is not what we would hand to most small business owners.

What it demands in return

Comfort with a repository, a build step, and editing content in a text format. Those are ordinary for a developer and a genuine barrier for somebody who runs a business.

Changing a price becomes an edit, a commit and a deploy. That is fine when a developer is available and it is a real obstacle when the owner wants to fix a typo on a Sunday.

There is no editing interface unless somebody builds or configures one, and the options that exist add back much of the complexity the approach was meant to avoid.

It also concentrates the knowledge in one person. When the only person who can deploy the site leaves, a business with no repository experience is stuck until it hires somebody who has it.

Where it genuinely wins

Documentation, publications and large content sites maintained by technical people. Version control of content is a real advantage when several people are working on the same material.

Sites with unusual build requirements, or where content comes from data rather than from typing. Generating hundreds of pages from a structured source is what this approach is best at.

And anywhere security is a priority. No database and no application means most of the common attack routes simply do not exist.

Who should and should not use one

The list below is the honest split. It is not about site size or budget; it is about who will be making changes and what they are comfortable with.

• Suits a team with developers who work in repositories
• Suits content generated from structured data
• Suits sites where several people edit the same material
• Does not suit an owner who wants to edit a page directly
• Does not suit anybody without a deploy process
• Does not suit frequent small changes by non-technical staff
• Does not suit a business with no technical help available

The maintenance question

Static sites need less routine maintenance than a self-hosted application, because there is nothing to patch. That is a real and lasting advantage.

The dependencies still age. Build tools, plugins and the generator itself move on, and a site untouched for three years frequently will not build when somebody finally needs to change it.

So the maintenance is smaller and lumpier. Very little month to month, and occasionally a day of work to get a build running again.

Keep a written note of how to build and deploy it. That single file is what makes the site recoverable by somebody who did not build it, and it is almost never written.

Speed, and whether it decides anything

Static output is fast, and a well-built hosted site is also fast. The difference is real and rarely decisive for a small business site with a handful of pages.

What usually decides real-world speed is images, scripts and third-party embeds, all of which you can get wrong in any approach. Our page on page speed covers the order.

So speed is a reason to prefer this approach and not a reason to accept an editing workflow nobody in the business can use.

The practical answer for most businesses

If nobody in the business uses a repository, this is the wrong tool however good it is. A site the owner cannot edit becomes a site that never gets updated.

Our page on keeping content current covers why that matters. Stale prices and old hours cost more than any performance difference gains.

Where a developer is genuinely available and committed, it is an excellent choice. The question is not the technology; it is who will be there in two years.