Static site generation for small teams

Most teams know this matters. Fewer have decided who owns it. Most advice about static site generation assumes a team that does not exist at your size. Here is the version that does not.

The question is rarely whether something can be built, but what it costs to keep running afterwards. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What to keep

Static files are the fastest and cheapest thing to serve. This is the sort of thing that compounds, quietly, in both directions. If it only works because one person remembers to do something, it does not work yet.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. This is the sort of thing that compounds, quietly, in both directions.

How to approach it

Rebuilds can be automated on every content change. That sounds obvious written down. It is still the thing most often skipped. Check it against what you would want a competitor's site to get wrong.

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about static site generation before you move on:

• Someone can say what the current setup is without going to look
• No server means dramatically less to attack or patch — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.