There are dozens of options for a marketing-site stack. We chose Astro for three reasons:
- It’s static by default. Every page in the site is pre-rendered at build time. That keeps hosting cheap, makes the site fast for search engines, and means there’s no server to keep alive.
- It plays well with content. Markdown, MDX, and content collections are first-class — you don’t fight the framework to model a blog, a help centre, and an API reference in the same project.
- It stays out of the way. Need a React component? Drop one in. Don’t? Don’t. The framework doesn’t impose a runtime on every page.
When you’d choose something else
Astro isn’t the right fit for highly interactive apps. If your marketing site is mostly a thin wrapper around a complex dashboard, a single-framework setup (Next.js, SvelteKit) might serve you better. The starter assumes your dashboard lives in a separate repo and this site links out to it.
How the starter uses Astro
A few patterns are worth knowing about as you adapt the starter for your own project:
- Content collections in
src/content/are the source of truth for blog posts, help articles, pages, and API endpoints. - Image components (
<Image>fromastro:assets) handle responsive images, lazy loading, and format conversion automatically. - Build-time scripts in
scripts/regenerate API docs and image thumbnails — they run vianpm run gen:*.
Read the Astro docs if you want to go deeper. Otherwise, the starter is structured so most edits don’t require touching framework internals.