“Modern web app” became shorthand for moving the application into the browser. That can be the right choice for dense, long-lived interactions. It is not automatically the right choice for a public-facing site.
Static server-side rendering starts with a useful response: real headings, links, forms, and content. Navigation can still feel fluid. Individual components can still become interactive. The difference is that the page does not depend on a large client runtime before it can communicate.
Spend interactivity deliberately
A contact form needs validation and a trustworthy submission path. A systems explorer may benefit from client-side state. A capability page probably does not need to become an application merely because it contains cards.
Make the default resilient
HTML-first pages preserve core journeys through slow devices, blocked scripts, transient network failures, assistive technology, crawlers, and unusual browser configurations. Progressive enhancement makes the reliable path the default path.
Keep the server boundary useful
Server rendering also gives sensitive operations—email delivery, attribution storage, content administration—a natural home. Secrets remain server-side, form protections stay centralized, and the public surface remains small.
Architecture should fit the work. For content-led experiences with a handful of meaningful interactions, static SSR is not a retreat. It is restraint applied as an engineering advantage.