Engineering
1 min

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.

Ramesh KannanFounder & Engineering

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.

ts
// 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.

Next.jsWebPerformance

Published May 28, 2026 · 1 min read

Notes from the workshop.

Occasional writing on shipping mobile AI — architecture decisions, privacy engineering and what we got wrong. No cadence promises, no filler.

Keep reading.

All posts