Why this site is built on Astro

This site runs on Astro 6. The decision took two weeks of deliberation, and every alternative got an honest hearing. This post is the written version of that conversation — for anyone facing the same call.

The real comparison was between three categories

“Best framework” lists are useless because frameworks aren’t alternatives to each other — each one answers a different question. For us the categories were:

1. Content-first static generators — Astro, Hugo, Eleventy, modern Jekyll
2. SaaS-shaped React frameworks — Next.js, Remix, TanStack Start
3. CMS platforms — WordPress, Webflow, Framer

Each category has real strengths. To avoid picking the wrong one, we had to answer what are we actually building first.

The site’s actual character

Qaynaq.com is neither a lead-capture funnel nor a running application. It’s:

• Editorial — case studies and journal posts are the substance.
• Static — content changes once or twice a month.
• SEO-sensitive — three languages, hreflang, JSON-LD, canonical.
• Transparent — readable code, auditable, no expensive runtime dependencies.
• On a performance budget — landing JS under 80KB, LCP under 2.0s.

Once that list is written down, Next.js and WordPress are both more than we need. Webflow and Framer are less than we need, because we want full control over MDX, custom rendering, and three-language URL structure.

Why not Next.js

Next.js is a fine framework. We use it on other projects every week. For this site, though:

• No server runtime needed. The audit form and any other actions run as edge functions, separately. Holding a Node runtime open for the whole site is overhead with no return.
• The React component budget is too high. Astro islands let us scope React (or Svelte, or Solid) to the small interactive fragments. The rest of every page ships zero JS.
• Ecosystem strength is actually a weakness here. Next.js has thousands of templates. Most are generic SaaS landing pages. I don’t want a starting point that begins with “good enough.”
• Vendor coupling. Next.js is increasingly bound to Vercel features. The site needs to stay portable.

Concrete numbers (representative, not benchmarked): most pages on this site open with 15–25KB of JS. The same site on Next.js App Router, with RSC payload, hydration runtime, and framework boilerplate, would land closer to 80–120KB at minimum.

Why not WordPress

WordPress is the right answer for plenty of projects. This isn’t one of them.

• It doesn’t fit the performance budget. Default theme plus plugin stack puts LCP into the 3–5 second range. The work to fix that exceeds the work to ship Astro from scratch.
• Larger security surface. Plugin updates, the database, the admin panel. A static site has none of those.
• Content versioning isn’t Git. Content lives in a database. Our case studies and posts are MDX files — code-reviewed, branched, iterated.
• Writing experience. Gutenberg has improved, but a writer-developer who works in a terminal is faster in MDX.

WordPress isn’t a CMS you “use” — it’s a system that comes with ownership obligations. We don’t need a CMS, because the author count is one and that author can write MDX.

Why not Webflow / Framer

Both are good tools, especially for fast design iteration. But:

• You own the code, but it’s generated. Export and you get HTML wrapped in dozens of generic-class divs.
• Hosting lock-in. A Webflow site lives on Webflow (export exists, it’s not practical).
• Writing workflow. Long journal posts in a Webflow CMS isn’t comparable to writing in MDX with version control.
• Anti-template principle. Webflow’s culture is template-first. Our standard (design-quality.md) requires the opposite.

For client work, we re-evaluate per project — sometimes Webflow is the right answer for the team that owns the site afterwards.

Tool versus position

Webflow and Framer give small teams a great experience. But the tool is one thing; the position is another. A Webflow site typically speaks the visual grammar of Webflow templates — not because of the tool itself but because of the use culture around it. Writing static HTML and CSS on Astro doesn’t make us automatically more “creative.” It just doesn’t start from a default look. Everything is built from a blank surface.

What Astro actually gave us

Practical wins:

• Zero-JS pages by default. Only components marked as islands hydrate.
• MDX as a first-class citizen — typed by the collection schema (src/content.config.ts), validated at build time.
• Content collections + Zod — frontmatter is type-checked. A misspelled topic breaks the build.
• Native i18n routing — /az/, /en/, /ru/ are supported out of the box.
• Build speed — this site builds in 3–7 seconds typically. (Again: representative, scales with project size.)
• Framework-agnostic islands — React and Solid components can coexist if needed.
• Low boilerplate — adding a page is creating a .astro or .mdx file. Routing follows the filesystem.

For an editorial surface, every one of those reduces friction. Writing the next journal post doesn’t require a special merge process — create the file, write the frontmatter, push.

Trade-offs we accepted

Astro doesn’t solve everything. Honest list:

• Out-of-the-box interactivity is thin. If you’re building a complex application surface, Astro is the wrong choice. Islands help, but full SPA experiences want Next, Remix, or TanStack Start.
• Plugin ecosystem is smaller than Next.js. For us this is a feature (anti-template), but it can be a real cost for others.
• Server-side state is young. Astro Actions and DB integrations are forming surfaces. The audit pipeline backend will live as a separate edge function, not inside Astro.
• Real-time features aren’t native. Chat, live updates, complex form state — each needs its own library.

Three questions before picking a stack

When someone asks for advice, I run these three:

1. What percentage of your pages is genuinely interactive? Under 20% — look at static generators. Over 50% — look at React frameworks.
2. Where does content come from? A single technical author? MDX. A dozen non-technical editors? A CMS (Sanity, Strapi, WordPress).
3. How strict is the performance budget? Landing under 80KB? Static-first is mandatory. 200KB acceptable? More options open up.

Those three answers fix the stack choice 80% of the way. The rest is team experience and hosting preferences.

When Astro is the wrong call

In the spirit of honesty, three cases where I wouldn’t pick Astro:

• Real-time dashboards. Live data, WebSocket, complex filter state. Next.js or Remix is the better answer.
• Authenticated SaaS. Login, role-based UI, complex forms, parallel data flows. Astro islands can do it, but the friction adds up.
• A team built around React expertise. Tooling fluency matters. Teaching a React team Astro is a short-term cost; if the long-term win is real, fine. If not, stay where the team is fluent.

This matters in advisory work. Telling a partner “this site is on Astro, yours should be too” is the wrong kind of advice. Their project may want a different answer.

What stack choice reveals

A technical pick is never just technical. Every choice answers what is this site for.

A studio on Next.js says the site is a conversion funnel. A studio on WordPress says multiple non-technical editors update content. A studio on Webflow says the designer needs to make changes directly.

A studio on Astro — in this case, Qaynaq — says the site is an editorial property, that the code is version-controlled, that the author is technical, and that performance is a requirement, not a preference.

Let your stack reflect your position. It isn’t a small thing.

For questions or discussion: salam@qaynaq.com.