Qaynaq STUDIO ’26 / BAKU
Journal ENGINEERING

Astro vs Next.js — which website framework for a small business?

Astro vs Next.js — the honest decision criteria for two frameworks. Why this site uses Astro, and why that isn't the answer for every project.

The Astro vs Next.js question gets asked weekly. Both are excellent frameworks, both are mature, both have credible deployment stories in 2026, and both are over-recommended outside their natural use cases. For a small business website framework choice — and especially a small business in Baku — the honest decision isn't "which one is better." It's "which one fits this specific site." This is the practical answer.

The frameworks, in one paragraph each

Astro is a content-first static site generator built around the idea that most web pages don't need JavaScript and shouldn't ship any. Pages render to HTML at build time. Interactive components are opt-in "islands" that hydrate independently. The framework is agnostic about React vs Svelte vs Solid vs Vue — you can use any of them, or none. It launched in 2021 and is now at v6.

Next.js is a React framework built around the idea that web apps need server-rendered React components, with route-based code splitting, image optimisation, server actions, and an opinionated full-stack architecture. Pages render on the server, hydrate on the client, and run as part of a Node.js (or edge) runtime. It's the most-used React framework in production.

Same category — "modern web frameworks" — but they're answering different questions.

When Astro is the right call

Astro fits when the site is:

  • Editorial or marketing. Content is the substance. Pages don't have lots of stateful interactivity.
  • Static-ish. Content changes weekly or monthly, not minute-by-minute. New pages get added by a developer or by an editor with a CMS, but the page structure is stable.
  • Performance-sensitive. You care about LCP, INP, page weight. You want pages to ship under 30 KB of JavaScript by default.
  • SEO-heavy. Multi-language, structured data, hreflang, canonical, JSON-LD all matter.
  • Owned long-term. You want to be able to audit every line of HTML the user receives.

Examples of sites that fit this profile: studio portfolios, marketing sites, news sites, documentation, single-product launches, restaurant sites, hotel sites, consulting practices, mid-size editorial publications.

Most small business sites in Baku — services, restaurants, clinics, agencies, retail brands without complex e-commerce — fit here.

When Next.js is the right call

Next.js fits when the site is:

  • App-shaped. Authenticated users, dashboards, forms with complex validation, real-time data, role-based access.
  • Heavily stateful. The page IS the application; the application IS the page. SaaS, e-commerce with complex cart logic, customer portals, admin tools.
  • Server-functional. You want server actions, server-side data mutations, API routes co-located with pages.
  • React-team-staffed. Your team already builds React; the additional Next.js abstractions are familiar.
  • Deployed on Vercel. The framework is increasingly co-evolved with Vercel's platform. On other hosts you give up some of the seamless features.

Examples that fit: SaaS dashboards, customer portals, full-featured e-commerce stores (Shopify Hydrogen excluded), real-time apps, internal tools.

The overlap, where both could work

There's a real middle. Some sites genuinely could be either framework, and the choice comes down to team preference:

  • A small e-commerce store with 50–500 products, a basic cart, no complex configuration logic.
  • A SaaS marketing site (the marketing part, not the app part) — Next.js works because the team uses it for the app; Astro works because the marketing is editorial.
  • A medium-sized blog or publication with 100+ posts and a few interactive elements.

For these, the "right" choice is the one the team can actually maintain in two years.

The performance comparison, honestly

Astro out of the box ships zero JavaScript for static pages. Next.js out of the box ships the React runtime, the hydration code, and the App Router payload. The difference is real:

  • A typical Astro marketing page: 15–35 KB of JS total.
  • The same page on Next.js App Router: 80–140 KB of JS minimum, often more.

For a marketing site on a Baku mobile connection (which is often 4G with variable latency), this difference is between LCP under 2 seconds and LCP over 3 seconds. That's measurable and matters for ranking.

However: a competently-built Next.js site can ship close to the same numbers with discipline. Static export, minimal client components, careful third-party loading. It's harder to do well in Next.js than in Astro because the framework's defaults pull toward more JavaScript, not less. But it's possible.

The developer experience comparison

For a small business website where the dev team is small or external, this matters as much as runtime performance.

Astro:

  • Lower mental overhead for marketing-site work. The framework gets out of the way.
  • Content Collections with Zod for typed frontmatter — excellent for editorial sites.
  • Smaller ecosystem of integrations and templates than Next.js, but growing fast.
  • Fewer "what does this magic do" moments. The HTML output mostly matches the source.

Next.js:

  • Massive ecosystem, every UI library has a Next.js example, every CMS has a Next.js adapter.
  • App Router with React Server Components is genuinely powerful but has a steep mental model.
  • Lots of conventions; lots of opportunities to do things the "wrong" way that work but waste bytes.
  • The hiring pool is much larger — finding a Next.js developer in Baku is easier than finding an Astro developer.

The hosting comparison

Astro static output deploys anywhere — Cloudflare Pages, Netlify, Vercel, AWS S3, even a $5 VPS or ANS Hosting if you wanted. No runtime required.

Next.js officially supports static export but works best with a Node runtime (or Vercel edge functions). Static export disables some features. Deploying Next.js outside Vercel works but you trade some integration polish.

For a Baku business that wants to keep hosting cheap and portable, Astro has the edge by default.

The recommendation, for most Baku small businesses

If you're building a marketing site, editorial site, restaurant site, clinic site, agency site, or studio site — pick Astro. The framework is designed for what you actually need. The performance is better by default. The hosting is cheaper. The output is auditable.

If you're building a SaaS product, a customer portal, a dashboard, or anything where authenticated users do non-trivial work in the browser — pick Next.js. The framework's primitives match the problem.

If you're somewhere in between — small e-commerce, mid-complexity site with some interactivity — pick the framework your team can actually maintain. Both work. Neither is wrong.

The React vs Astro side question

"Should I use React?" is not the same question as "Should I use Next.js?" Astro can use React components as islands. You can write your interactive bits in React and have them ship inside an otherwise-static Astro site. This is the common pattern: most of the site is static HTML, the few interactive components are React (or Svelte, or Solid — whichever the team prefers).

So "React vs Astro" is a false dichotomy. The real question is whether the page needs to be React-rendered (Next.js) or HTML-rendered with React sprinkled in for interactivity (Astro).

At Qaynaq, this site runs on Astro 6 because it's the right call for an editorial studio site. Our client work uses whichever framework genuinely fits the project. If you're weighing the website framework choice for a specific build, write to salam@qaynaq.com with a one-paragraph description of what the site needs to do.