stripe.com

Stripe.com's marketing surface runs on AWS. S3 fronts the static assets, Nginx terminates the edge, and there's no Cloudflare layer in front of any of it. That's a deliberate choice for a payments company: keeping the marketing site on the same cloud the API runs on means one less vendor in the trust chain, one less DNS hop a customer can blame when checkout-redirect flows feel slow. The trade-off is they're paying for AWS egress and CDN economics that Cloudflare gives away. Stripe can afford it.

The dev-tooling layer is the more honest tell. React paired with Vite is the 2024-2026 default for teams that have moved off Webpack but aren't ready to commit to Next.js or Remix as a framework. It says Stripe's marketing-site team ships independently of the application engineering org, and they're optimizing for build speed and DX, not for the kind of file-system routing and ISR you'd want if your marketing pages were heavy on dynamic content. They aren't. Stripe pages are mostly static, heavily designed, and rebuilt on a release cadence rather than per-request.

The most revealing detail isn't what's running, it's what isn't. There's no Google Analytics, no LinkedIn Insight Tag, no Mixpanel pixel, no Segment. Compare that to Notion's stack, which loads LinkedIn ads tracking and Naver Analytics on every page. Stripe is collecting first-party telemetry through their own infrastructure and has either decided third-party marketing analytics aren't worth the privacy and performance cost, or they're handling attribution server-side via their CRM. Either reading flatters them. For a company that sells "trust me with your customer's card numbers" as its core value proposition, having a marketing site that loads zero third-party trackers is the longest possible flex.

Priority Hints and HSTS rounding out the stack are table-stakes for a perf-conscious team, but they confirm the posture: the site is tuned, not just shipped.