Next.js Static Export for AI-Powered Sites: Trade-offs

What Static Export Is and Isn't

Next.js's output: 'export'compiles every page to a flat HTML file at build time. No server runs at request time. The site is served as a folder of files from a CDN. The wins: free hosting at scale, excellent performance, predictable SEO, no server failure modes. The trade-off: no server runs at request time — which is exactly what AI features typically need.

For pure marketing sites, static export is the obvious choice. For pure AI apps, it's the wrong choice. For marketing-plus-AI sites — the shape most agencies, SaaS marketing sites, and content-driven AI products take — the answer is a hybrid pattern.

The AI Tension

AI features almost always require a server-side call: an API key that can't live in the browser, a long-running stream, a vector database lookup. None of that runs from a static HTML file. The naive answer is “then don't use static export.” The smarter answer is “use static export for everything that doesn't need a server, and put the small AI surface behind a separate endpoint.”

What Works Well in Static Export

• Marketing pages — landing, services, pricing, about, contact.
• Blog and content — massive SEO wins from prerendered pages.
• Documentation — fast, navigable, searchable client-side.
• Read-only product views — case studies, portfolios.
• Interactive client-side features — anything that runs in the browser without a server.

Where Static Export Hits A Wall

• Anything needing server-only secrets (API keys, DB creds).
• Streaming AI responses (model output token-by-token).
• Per-request authentication and personalization.
• Real-time data (live dashboards, presence indicators).
• Custom HTTP headers per route (Next.js static export ignores headers() in next.config).
• Image optimization on the fly (you set unoptimized: true).

The Hybrid Pattern: Static + Edge Functions

The pattern we recommend for AI-marketing sites: static export for the public surface, plus a small number of edge functions (Vercel, Cloudflare Workers, AWS Lambda) for the AI calls.

The marketing site lives at the root (flowtix.ai/*). The AI endpoints live at flowtix.ai/api/* orapi.flowtix.ai/*. The client-side JavaScript on the static pages calls those endpoints when the user invokes an AI feature. Best of both worlds.

Tooling and Patterns

A few specific patterns we use:

• Security headers — since headers() is ignored in static export, put them in vercel.json or _headers at the platform level.
• Sitemap and robots — use app/sitemap.ts and app/robots.ts with export const dynamic = 'force-static'.
• Image strategy — pre-optimize images at build time. Skip dynamic optimization.
• OG images — generate per-page at build time or pre-render in a build step.
• Form submissions — post to an edge function or a third-party endpoint, not the static site.

Decision Tree: Should You Use Static Export?

1. Is the AI surface less than 20% of the product? → Static export with hybrid endpoints.
2. Is the AI surface the product? → Server-rendered, edge runtime, or a separate app.
3. Do you need per-request auth on most pages? → Not static export.
4. Are you content-heavy (blog, docs, marketing)? → Static export.
5. Do you need to deploy SEO-critical content fast and free? → Static export.

The static-export-plus-edge-functions architecture is the modern shape of marketing-driven SaaS in 2026. You get SEO wins on the public surface and AI power where the product actually needs it — without paying for a server that's 99% idle.

See also Vercel edge functions for AI and Core Web Vitals for AI apps.

FAQ

What about ISR (Incremental Static Regeneration)? Requires a server. Defeats the static export benefit. Skip.

Can we run AI in the browser?For small models, yes. For frontier-quality output, no — latency and download size kill it.

How do we handle user accounts? Use a third-party auth provider that issues tokens; verify tokens in your edge endpoints.