[build] · projects
0+
Jamstack sites shipped
[build] command = "pnpm build" publish = "dist" shipped = 120
Stack Innovations
Start a project
Stack Innovations
Start a project
Each stat is a fragment of the netlify.toml/vercel.json configs that ship every Jamstack project we run. Hover any to see the section. Counters scrub with scroll.
[build] command = "pnpm build" publish = "dist" shipped = 120
[edge] cdn = "global" regions = 330 cache = "tagged"
[metrics.ttfb] p50 = 38 p95 = 92 budget = 200
[origin] servers = 0 vms = 0 pagers = "silent"
Click an entry on the left — the active capability opens in the deploy dashboard. Each pane is a working pattern we've shipped.
Marketing, content, and catalogue routes are prerendered at build. Long-tail and frequently-edited routes use ISR / on-demand revalidation. Dynamic data still works — we just don't make every request render from scratch on the origin.
We pick the CMS for the editor first, the developer second. Sanity for schema-driven structured content, Contentful for enterprise multi-channel, Strapi for self-hosted control, Ghost for editorial. Webhook on publish → build → deploy.
The bits that have to be dynamic — auth checks, A/B routing, geo-redirects, rate limiting, CSRF, request rewriting, lightweight personalization — live as edge functions. Cold starts under 10ms, no provisioning, billed per request. The rest of the site stays static.
Native form submissions land directly with the host (Netlify Forms, Cloudflare Pages Functions). Auth via Auth.js / Clerk / Supabase / your IdP. Identity, sessions, and CSRF handled with HTTP-only cookies. No app server to operate, no auth library half-rolled.
Every push gets a deploy preview at a URL. Every merge atomically swaps production. Every previous deploy is one click to roll back. Lighthouse, Pa11y, link-check, visual-diff run in CI — the build fails before bad code reaches the CDN.
Every response has a cache tag tied to the content type that produced it. When an editor publishes, only the affected tags revalidate — a homepage edit doesn't blow away the whole catalogue. SWR for catalogue routes, immutable for static assets, no caching for auth-shaped responses.
There's no single "Jamstack" framework — there's a shape: a generator, a content source, a host, and the add-ons that make it real. Pick one of each below; the architecture diagram, the metric estimates (TTFB, build time, monthly cost, Lighthouse), and the recipe name all rebuild live. Each option links into the dedicated service page if we have one for it.
Same architecture, two very different ways it ends up shipping. Eight criteria your team will actually feel — in plain English, with the receipts.
"It's static, so it's fast" — until 800 KB of unused JS hydrates the marketing page.
Lighthouse 100s as a starting line. CI fails the build on any regression.
Everyone in the world hits one box in one region. SLA is whatever that box can manage.
Static at the edge, dynamic at edge functions, dynamic-dynamic on origin only when there's no choice.
Editors ship through devs. Publish-day Slack threads, manual cache busts, frequent "did it go live?" questions.
Headless CMS publish triggers an on-demand revalidate. Affected pages refresh; the rest stay cached.
Bolted on as a follow-up engagement. The "we'll get to it" version of SEO.
Sitemaps, structured data, hreflang, Open Graph images — live on day one.
"Don't deploy on Friday" is in the runbook. Rollbacks need a meeting.
Every PR has a preview URL. Every merge is atomic. Every previous deploy is one click to revert.
You move the content yourself. URLs break, search rankings drop, editors hate you.
Source connector, content port, redirect map, dry-run, cutover. SEO continuity holds.
"Good luck with the admin." Editors learn by trial and error in production.
Editors leave training feeling fluent. First publish goes through without a Slack ping.
Hand-off, then silence. Six months later your stack is two majors behind.
Monthly version bumps, perf monitoring, real Slack channel. Features, not tickets.
Pick a project shape on the left — the exact stack we'd reach for shows on the right, with links into the dedicated service page for each piece. These aren't theoretical: they're the four recipes we ship most often, with the trade-offs that pushed us toward each.
Inventory routes + content shape. Pick the SSG, the headless CMS, the host, the add-ons. Lighthouse + TTFB baseline.
Model the content with the editor. Scaffold the SSG + adapter, wire CMS, layouts, design tokens, baseline meta.
Pages, layouts, components, ISR routes, edge functions for auth/geo/AB. Forms wired to the host's native handler.
Image pipeline, prefetch tuning, JSON-LD, sitemap, OG images. Cache tags wired, edge regions pinned.
Content migration, redirect map. Build against the target host, dry-run on staging, atomic deploy, DNS cutover.
Stack upgrades, perf monitoring, route-level Lighthouse, tag-purge audit, monthly review.