Technical

the modern web stack: how we build fast, scalable websites at vanguards

10 Mar 2026  ·  by Vanguards Studio  ·  6 min read

technology choices are product decisions

The stack a digital studio chooses isn't a technical preference. It's a product decision that determines what you can build, how fast it loads, how easy it is to maintain, and how much it costs to scale.

Most clients don't think about this. They hire a studio, receive a website, and discover the consequences of those choices later — when the site is slow, when the code is unmaintainable, when a simple content update requires a developer.

At Vanguards, we're transparent about how we build and why. Not to impress with technology names, but because the choices we make directly determine the quality of what you receive.

the principles behind our stack

Performance by default. Every architectural decision we make favors speed. Not "we'll optimize it later" — fast by construction, from the first deploy.

Maintainability over cleverness. Code that solves a problem brilliantly but can't be understood six months later is a liability. We write code that other developers can read, understand, and extend.

Deploy anywhere. We build on open standards and avoid vendor lock-in wherever possible. Your website should be deployable to any modern hosting platform without rewriting it.

Content independence. For content-heavy sites, the ability to update content without touching code is non-negotiable. We separate content from presentation.

Scale without surprise. Architecture decisions that work for 1,000 visitors should work for 1,000,000. We build for the ceiling, not just the floor.

the frontend stack

react + typescript

React is our primary UI framework. Not because it's the newest or the trendiest — because it has the largest ecosystem, the most mature tooling, and the best long-term support story.

TypeScript sits on top of every project. Types catch bugs before they reach production. They make codebases easier to navigate and maintain. For projects that will be touched by more than one developer, TypeScript is not optional.

vite

Vite is our build tool. Fast dev server startup, instant hot module replacement, and production builds that are optimized without manual configuration. The developer experience it provides translates directly to faster iteration and fewer build-related headaches.

static site generation

Where possible, we build statically. A statically generated site is pre-rendered at build time — the HTML already exists before a visitor arrives. No server-side rendering on request. No database queries on page load.

The result: near-instant load times, trivial CDN deployment, and zero server costs for most traffic levels.

For the Vanguards website itself, for most marketing sites, and for content-heavy properties like blogs, static generation is the right default.

tailwind css

Tailwind is our styling system. Utility-first CSS that produces no unused styles in production, enforces a consistent design system, and keeps styling decisions close to the components they affect.

The initial learning curve is worth the consistency it produces at scale. Every project looks and feels coherent — not because a designer enforced it, but because the system enforces it.

the deployment infrastructure

cloudflare pages + workers

We deploy to Cloudflare's edge network. This means your site is served from data centers worldwide — every visitor gets the site from a server close to them, not from a single origin on another continent.

The practical difference: a site hosted on a single server in the US takes 300ms+ to reach a visitor in Southeast Asia. The same site on Cloudflare's edge takes under 50ms.

For global audiences, edge deployment isn't a luxury. It's a baseline expectation.

Cloudflare Workers extend this to server-side logic — form handlers, API endpoints, dynamic functionality — all running at the edge, without the latency of a traditional server.

cloudflare r2

Static assets — images, documents, media — live on R2. Zero egress fees, global availability, and direct integration with Workers and Pages. For asset-heavy sites, R2 eliminates a category of hosting cost that adds up quickly at scale.

the content layer

For most sites, content lives as Markdown files or TypeScript data objects in the codebase. No database, no CMS subscription, no moving parts that can fail.

Content is version-controlled alongside code. Changes are reviewed in pull requests. Deployments are deterministic.

For teams that need non-technical editors, we integrate headless CMS options — Contentlayer, Sanity, or similar — that keep the performance benefits of static generation while giving editors a friendly interface.

what this means for you as a client

Speed: Sites built on this stack routinely score 95–100 on Google Lighthouse. Not because we're chasing scores, but because the stack produces those results by default.

Reliability: No database means nothing to go down. No server means no server to maintain. Cloudflare's infrastructure has a 99.99% uptime SLA. Your site will be up.

Cost: Edge deployment at Cloudflare's free and low-cost tiers handles enormous traffic volumes without meaningful hosting cost. You don't pay more because your business grows.

Maintainability: TypeScript + clean component architecture means any competent React developer can work on your codebase. You're not locked in to us — you own the code, and other developers can maintain it.

Longevity: React, TypeScript, Vite, and Tailwind are all mature, widely adopted, and actively maintained. You're not building on a framework that will be abandoned in two years.

the honest answer about tradeoffs

No stack is perfect for every use case.

Highly dynamic applications — social platforms, real-time dashboards, complex e-commerce — need more than static generation. We layer in server-side logic via Workers, or recommend purpose-built solutions for genuinely complex backend requirements.

If your project needs a full backend, a custom API, or complex database logic, that conversation happens during scoping — not as a surprise after the build starts.

We'd rather tell you what your project actually requires than build the wrong thing efficiently.

technology in service of outcomes

The goal is never to use impressive technology. The goal is to build something that loads fast, works reliably, is easy to maintain, and serves your business for years.

Our stack is the result of that goal, tested across dozens of projects. It's not fixed — we evolve it as better tools emerge. But the principles behind it don't change.

Because ultimately, the technology is invisible to your users. What they experience is the result.