Five mistakes teams make with static site generation

This is cheap to get right at the start and expensive to retrofit. These are the ones we run into repeatedly when we audit static site generation.

Most development decisions are really maintenance decisions wearing a different hat. If two people in the business would answer this differently, that gap is the actual problem.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Static files are the fastest and cheapest thing to serve
• No server means dramatically less to attack or patch
• Never checking whether the fix actually worked

Rebuilds can be automated on every content change. It is worth being explicit about, because assumptions differ quietly. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to do next

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
• Static files are the fastest and cheapest thing to serve — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.