Astro

What it is

Astro is a framework for building static websites. You write components in a familiar HTML-like syntax, Astro compiles them down to plain HTML, CSS, and (only if you ask for it) JavaScript. The output is a folder of static files that can be deployed to any CDN, no Node server, no database, no runtime.

The category is "static site generators." You may have heard of Next.js (the React-flavored one), Hugo (the very fast Go one), or Eleventy (the minimalist one). Astro is the newer entrant that learned from all three: component-author experience as good as React, output as lean as Hugo, philosophy as boring as Eleventy.

How we use it

Reached for only when a CMS would be overhead

Most of our projects ship as WordPress because clients need to edit pages themselves. Astro is for the inverse case: a single landing page, a campaign microsite, a portfolio for someone who'll never touch a CMS, a concept piece. When the editing surface is one or two people who can edit Markdown in git, Astro is dramatically lighter than WordPress and dramatically faster to load.

Zero JavaScript by default

Astro renders to static HTML at build time. No React, no Vue, no client-side framework runtime shipped to the visitor. If a specific component needs interactivity (a slider, an animation, a chat widget), you opt that one component into hydration. Everything else stays as inert HTML. The result is page weights an order of magnitude smaller than a typical Next.js or Gatsby build.

Bespoke design per project, shared engineering underneath

The visual language for an Astro build is tuned to the client's brand, not forced into our house style. A medspa landing page, a fintech microsite, and a portfolio for a hardware brand all look completely different from each other and from this WordPress site. What does port cleanly across stacks is the architecture: component conventions, CSS token discipline, naming, the deploy pipeline. .astro components map onto the same shape as our .php ones, so the work of shifting a project between stacks is wiring, not rewriting.

Deploys to Cloudflare Workers Static Assets

Build runs in GitHub Actions, output uploads to Cloudflare's edge network. The site is served from 300+ data centers worldwide, with no origin server to keep alive. Hosting cost rounds to $0/month under the free tier and scales linearly with bandwidth on the paid tier. The whole pipeline is identical in shape to our WordPress GitHub Actions deploy, just pointed at a different target.

Content lives next to the code

Posts, pages, and structured content are Markdown files in the repo, not rows in a database. Editing means a pull request, not a wp-admin login. That's the right tradeoff for a marketing site or a portfolio. It's the wrong tradeoff for anything a non-technical client needs to edit weekly — which is why we don't push Astro on every project.

What you get

• Pages that load in under 100ms from any continent. No "slow on mobile" complaints, no Lighthouse score under 95.
• Hosting cost that rounds to zero. Free tier on Cloudflare or Netlify covers most marketing sites entirely.
• No CMS to learn, log into, or keep updated. No WordPress core updates, no plugin updates, no admin attack surface.
• Design tuned to your brand, not forced into our house style. Astro is a build tool, not a visual identity.
• Identical deploy story to our WordPress sites: push to staging, see staging update, promote to production. Same muscle memory, different target.

Where we don't use it

If a client needs to edit content themselves (blog posts, page copy, new service entries), Astro is the wrong answer. Pushing them to git is a non-starter for most non-developers, and the cost of a CMS layer on top of Astro (Sanity, Contentful, Storyblok) is usually higher than just shipping WordPress and being done.

For e-commerce, we don't ship Astro. WooCommerce on WordPress, or Shopify, handles checkout, inventory, taxes, and shipping with a maturity that headless-commerce-on-Astro just hasn't matched at our project scale.

For sites with frequently-changing dynamic content (job boards, real estate listings, event calendars), the rebuild-on-every-change story gets painful. WordPress (or a true database-backed app) is the right tool.