Astro has quietly become the default for content-led websites that need to be fast, and “fast” here isn’t a vibe, it’s a ranking factor. But the framework only pays off in hands that understand why it’s fast. Here’s how to hire someone who does.
Why Astro, in one paragraph
Astro renders your pages to plain HTML at build time and ships zero JavaScript by default. You opt into interactivity component by component (“islands”), so a visitor downloads a menu’s worth of JS instead of a whole framework’s. For a marketing site, blog, or documentation, that means near-perfect Core Web Vitals without heroic optimization , which is exactly why we build on it, including this very site. If your project is a content site first and an app second, Astro is usually the right call.
What a good Astro developer actually knows
Anyone can npm create astro. The difference between a template-filler and a real Astro
developer shows up in five places:
- The islands mental model. They know that a
client:loadon the wrong component drags a framework runtime onto every page and quietly kills the performance you came for. They reach forclient:visibleorclient:idle, or no hydration at all, by default. - Content collections. They structure your blog and case studies as typed content collections with a schema, not a folder of loose files. This is what makes a growing site maintainable, adding an article becomes one markdown file, and the types catch mistakes.
- Image handling. They serve responsive WebP/AVIF with explicit dimensions so images don’t
cause layout shift. If they hand you
<img src>with no width and height, keep looking. - Partial hydration vs. a framework habit. Developers coming from Next.js often rebuild
everything in React and hydrate it, defeating the purpose. A real Astro dev writes
.astrocomponents for the static 90% and reserves React/Vue/Svelte for the genuinely interactive 10%. - The build and deploy story. Static output that deploys anywhere for a few dollars a month : Hostinger, Vercel, Netlify, a CDN. They should be able to explain your hosting bill.
Questions that separate the real ones
- “When would you NOT use Astro?”, A good answer names app-heavy projects (dashboards, real-time, heavy client state) where Next.js or a SPA fits better. Someone who says “always Astro” is selling a hammer.
- “How do you keep JavaScript off the page?”, They should talk about hydration directives and measuring the JS bundle, not just “Astro does it automatically.”
- “How will my team edit content?”, Markdown collections for technical teams; a headless CMS (Sanity, Storyblok, Keystatic) wired in for non-technical editors. The answer should depend on your team, not their preference.
When Astro is the wrong choice
Honesty first: Astro is not the answer to everything. If your product is the website, a SaaS app with accounts, dashboards, and live data, you want Next.js or a full framework, not Astro with islands bolted on. Astro shines for the marketing site in front of that app. Plenty of companies run both: an Astro marketing site and a Next.js product. That’s a feature, not a compromise.
The short version
Hire someone who treats Astro’s speed as a discipline, not a default they can coast on, who structures content properly, keeps JavaScript off the page on purpose, and can tell you when to use something else. That’s the person whose site still loads instantly after you’ve added a hundred blog posts.
Building a content site and weighing your options? Tell us what you’re making , we’ll give you a straight answer on whether Astro fits, even if it doesn’t.
Choosing the right platform and building on it properly is the core of our web development service.
