Astro

Astro is built for marketing sites, blogs, docs and other sites where content matters more than app-like interactivity. By default it prerenders the whole site to static HTML at build time. Individual routes can opt into on-demand rendering on a server through an adapter, so a site can be mostly static with a few dynamic pages.

Its core idea is islands. The page is plain HTML, and only the components that need interactivity, such as a pricing calculator or a demo widget, load JavaScript. Directives like client:load and client:visible decide when each island hydrates. Islands can be written in React, Preact, Svelte, Vue or Solid, and content can live in typed content collections or come from any headless CMS. Astro is MIT-licensed. In January 2026 the company behind it joined Cloudflare, and the team says Astro stays open source and keeps supporting other hosts.

Why it matters for a SaaS website

Astro removes most of the JavaScript a marketing site never needed, which helps loading speed and Core Web Vitals on the pages paid traffic lands on. Because the site is plain files in a git repo, there is no per-seat editor fee, no platform lock-in, and every change can be reviewed like code. That last point matters more now: AI coding agents can edit an Astro site directly and open a change for review, which is harder on a closed visual builder.

The trade-off is ownership. Someone has to own hosting, builds and dependency updates, and the first build takes longer than in Framer.

How DesignMe handles it

Our own website is built in Astro and edited with Claude: we ask for pages and fixes, review the change, and approve it. We recommend Astro to teams that already run on agents, to fintech companies that want a fast, mostly static site with a small attack surface, and to healthtech teams that need few third-party scripts and an easy accessibility audit. When editors need a visual tool, we pair it with a headless CMS. When designers or marketers want to build pages themselves, we usually recommend Framer instead.

Example

Say an AI infrastructure company has a marketing site, a changelog and 40 integration pages. In Astro, integrations and changelog entries are content collections with a schema, so a missing logo or date fails the build instead of reaching production. The pricing calculator is a React island set to client:visible, so its JavaScript loads only when a visitor scrolls to it. Everything else ships as HTML.

Common mistakes

• Hydrating everything. Putting client:load on every component rebuilds the heavy single-page app Astro was meant to avoid.
• Choosing it with no code owner. If nobody will maintain the repo, a visual builder is the safer choice.
• Using it for the product. A logged-in app with complex state is usually better served by Next.js or a dedicated app framework.
• Skipping a content schema. Unvalidated Markdown drifts. Define fields once and let the build enforce them.