A marketing site that stays fast: Next.js static export in practice
Why this site is a fully static export, what that rules out, and the workarounds we use for the things a server would normally handle.
This site builds with Next.js configured for static export. There is no server rendering at request time, no API routes and no image optimisation service. Every route is a file. That constraint is deliberate.
Why static
- Our product pages double as Play Store policy URLs. They must be available, permanently, with no runtime that can fail.
- A marketing site has no per-request personalisation, so server rendering buys nothing.
- Static hosting removes an entire category of outage and an entire category of cost.
What you give up
No API routes means no server-side form handling, so contact submissions go through a mail client or a third-party endpoint. No incremental regeneration means content updates require a rebuild. No middleware means redirects belong to the host, not the application.
// next.config.ts
const nextConfig: NextConfig = {
output: 'export',
reactCompiler: true,
reactStrictMode: true,
};Blog content without an MDX toolchain
Posts are typed data — an array of content blocks — rendered by a single typography component. The compiler catches a malformed post, every article is styled identically, and there is no markdown parser in the bundle. The trade-off is that writing happens in TypeScript rather than in a CMS, which is the right call at our volume and the wrong one at ten times it.
The rule we follow
Reach for a server when something genuinely cannot be decided at build time. Most of a marketing site can.
Published May 28, 2026 · 1 min read