Most marketing sites change weekly, not every minute. That makes static generation a strong default: HTML is built at deploy time, served from the edge, and cached aggressively without you thinking about it.
What you gain
- Speed: No database round trip on every page view. Time to first byte stays low even under traffic spikes.
- Reliability: Fewer moving parts at runtime. If the CMS is down, the public site still serves.
- Version control: Copy, layout tweaks, and new pages ship in pull requests. You can review changes like any other code.
- Cost: Static pages are cheap to host and scale. That matters for studio sites that should not carry infra overhead.
When we reach for something dynamic
We add databases, auth, or server logic when the product needs it: user accounts, dashboards, form workflows with admin review, or content that non-developers must publish without a deploy.
For a studio blog, MDX in the repo is often enough. Posts are code. Authors work in the same editor as the site. Pages are pre-rendered at build time. RSS and sitemap entries are generated from the same source of truth.
A practical rule
If the page can be built ahead of time, build it ahead of time. Reach for dynamic rendering when user-specific data or real-time state is the point of the page, not because it is fashionable.
That is how we keep client marketing sites fast without over-engineering the stack on day one.