When Astro is the right choice (and when it is not)

Astro is a great default for marketing sites because it ships less JavaScript by design. But it is not the right tool for every product.

This guide is a quick decision framework you can use before you commit to a stack.

If you want an Astro build that stays fast as you add pages, see: Astro Websites.

Astro is a strong choice when

• Your site is mostly content (service pages, landing pages, blog posts).
• You want excellent performance with minimal effort.
• You need a component system, but you do not need a heavy client app.
• You want to keep hosting simple (static output with optional server endpoints).

In these cases, shipping HTML first is usually the fastest path to a site that converts well.

Astro is not the best choice when

• Your primary experience is a complex, authenticated app.
• You have lots of client-side state that must stay in sync across views.
• You need real-time collaboration, heavy dashboards, or app-like routing.

Astro can still be used as a marketing layer around these products, but you may want a full app framework for the product itself.

A practical hybrid approach

Many teams do best with:

• Astro for marketing pages, docs, and content
• A separate app (or an isolated section) for authenticated experiences

This keeps the marketing surface fast and crawlable while allowing the product to use the tools it needs.

The non-negotiables (regardless of stack)

Even with a great framework, performance and usability can regress. Protect the basics:

• Limit third-party scripts.
• Use responsive images with width/height to avoid CLS.
• Keep headings and copy scannable (one H1, clean H2/H3).
• Test mobile interactions and keyboard navigation.

If you want a quick evaluation of your current stack and a plan to simplify, start here: Contact.