Amrify vs Next.js

This is not a framework fight. Next.js is excellent and most of the criticism aimed at it comes from people using it for something it was never meant to do. That is the actual subject here: not which framework is better, but which one matches the shape of the problem.

If your pages are known before the request arrives, you are building a content site. If they cannot be known until someone authenticates, you are building an application. Those want different tools.

The Architectural Difference

Next.js renders React. Even with static generation, the client receives the React runtime and hydrates the tree so the page becomes interactive. That cost is correct when the page is an application, because interactivity is the point.

Astro inverts the default. A page compiles to HTML and ships no JavaScript at all. When a component genuinely needs to be interactive, it becomes an island: that one component hydrates and nothing else does. A service page with a single contact form ships the form’s logic and nothing more.

	Next.js	Amrify (Astro)
Default output	React runtime plus hydrated tree	HTML, no JavaScript
Interactivity model	Whole-page hydration	Per-component islands
UI libraries	React	React, SolidJS, Vue, Svelte, Preact; Pro’s widgets are SolidJS
Content layer	Bring your own	Typed collections, schema-validated
Server needed	For SSR and API routes	None, static output
Failure mode	Runtime error reaches the browser	Build fails before deploy

That last row is worth dwelling on. Content validated at build time means a malformed field breaks the build on your machine, not the page on someone’s phone. Typed collections turn a category of production bug into a category of failed build, which is where you want it.

Where Next.js Is Simply the Right Answer

Use Next.js when:

• You have authenticated users or sessions
• Pages depend on per-request data
• You need API routes, server actions or middleware
• You are building a product, not publishing pages
• Your team’s React expertise is the main asset and the site is genuinely an app

None of that is a concession. If you are building a dashboard, the whole argument on this page is irrelevant to you.

Where the Overhead Stops Paying

Use something static when:

• Every page is known at build time
• The site is marketing, service pages, docs or a blog
• Core Web Vitals matter commercially, because you compete in search
• You would rather not run a server for pages that never change
• You are maintaining many similar sites, which is the next section

The Multi-Site Problem

This is the part that decides it for agencies, and it rarely appears in framework comparisons because it is an operations problem rather than a technical one.

Fifteen client sites built independently in Next.js usually means fifteen repositories, fifteen dependency trees, and fifteen upgrade paths that drift apart the moment nobody has time. A security advisory lands and it is fifteen pull requests. A client asks for a change to a shared pattern and it is fifteen implementations that were each slightly different to begin with.

The Amrify boilerplate is one monorepo with shared packages, and the license covers unlimited sites. Components, schema builders, layouts and config loaders live once. A fix to the contact form is one commit that every site inherits on its next build. A new-site scaffolder creates the next client directory, and a cross-site verifier checks all of them before a deploy.

We are not describing this from theory. Amrify’s own sites run this way in a single repository built to run hundreds of sites, and soon thousands, which is what makes a $249 one-time price for the whole system arithmetically possible: the engineering was written once.

Running Cost and Who Does the Work

The differences that show up on an invoice or a calendar, rather than in a benchmark:

	Next.js content site	Amrify
Ownership	Your code, on your repo	Your code, on your repo, plus the shared packages you did not have to write
Framework updates	You track React and Next.js majors per site	Pulled from the Amrify repo when you choose, free for life
Hosting	Serverless functions or a Node server for SSR; static export is possible but not the default	Static files, so Netlify, Vercel and Cloudflare Pages host it free; the bundled S3 and CloudFront deploy targets your own AWS instead
Who edits content	A developer, or a CMS you wire in	Anyone who can edit a text file, or an agent through the bundled Claude Code skills
Forms and leads	Build an API route per site	One serverless lead engine: DynamoDB, SES email, Telegram or SMS, webhook, spam defenses
Speed regression check	Whatever you set up	Lighthouse 100 on all four audits, enforced in CI

Build Times and Day-to-Day Work

Static generation gets cheaper as the framework does less. Astro is not compiling a React tree for pages that contain no React, so build times track the number of pages rather than the weight of the runtime.

The practical difference for an agency is not the seconds saved. It is that a content edit is a text file, so a non-developer can make it without touching a component, and a broken edit fails the build rather than shipping. That moves routine content work off the developer’s desk, which is usually where the real cost was hiding.

Search and Core Web Vitals

Both frameworks can rank. Next.js static generation produces crawlable HTML and Google renders JavaScript competently these days. The differences are narrower than partisans on either side suggest.

The gap that remains is Core Web Vitals under real conditions. Hydration costs main-thread time, and main-thread time on a mid-range phone on mobile data is where Interaction to Next Paint is won or lost. Shipping no runtime is a structural advantage that no amount of optimization on the other side fully closes, because the fastest JavaScript is the JavaScript you never sent.

Structured data, sitemaps, canonical URLs, metadata and an llms.txt for AI answer engines are generated from typed content here rather than assembled per page, so they stay correct as the site grows instead of drifting. The free schema generator and llms.txt generator show what both should contain for a given site.

What You Give Up

An honest comparison has to include this, because every architectural choice costs something.

You give up per-request rendering. If a page must reflect data that changed a second ago, static output is the wrong shape and you will end up bolting on client-side fetching, at which point you have reinvented the thing you avoided.

You give up the React ecosystem as a default. Islands support React, but a library that assumes it owns the whole page and mounts a global provider tree will fight the model. Component libraries designed around context providers are the usual friction point.

You give up familiarity, which is a real cost on a team. Astro’s template syntax is close to JSX but not identical, content collections are a different mental model from filesystem routing plus MDX, and the first week is slower. That is a genuine expense even though it amortizes.

And you give up server-side anything on the page. No API routes, no middleware, no server actions. For a marketing site that is a feature, because there is no server to secure or scale. For anything with accounts it is disqualifying; Amrify Pro’s optional Cognito customer accounts and its lead API are separate serverless pieces, not a server behind the pages.

Migrating an Existing Next.js Content Site

If the site is already static, the move is mostly mechanical rather than a rewrite.

Pages become content entries. MDX files carry over with frontmatter adjusted to match a typed collection schema, which is usually where the real work sits, because the schema surfaces every field that was optional in practice but assumed everywhere in the templates.

Components port in tiers. Anything purely presentational becomes an Astro component and loses its runtime entirely. Anything genuinely interactive stays React and becomes an island with an explicit hydration directive. The useful discipline is that you now have to justify each one, and most teams find the list is shorter than they assumed.

Routing maps closely, since file-based routing works the same way in both. Dynamic routes become getStaticPaths, which most Next.js content sites were already using.

The step that matters commercially is the same as any migration: every URL that changes needs a 301 to its replacement. Rankings follow URLs, and a clean architecture migration that drops the redirect map is still a traffic loss.

Try It for Nothing First

The free Amrify Starter is the zero-cost way to test the argument on this page: a pnpm and Turborepo monorepo with two demo sites and five shared packages, Astro 7, Tailwind CSS 4 and TypeScript, and no JavaScript framework at all. Complete site, typed collections, JSON-LD, generated OG images, sitemap, RSS, llms.txt, and the Lighthouse 100 gate in CI. Free for unlimited personal and commercial sites; the public repo opens at launch. Amrify Pro is built on that exact Starter and adds the trade templates, the lead engine, the local SEO engine, the SolidJS widgets, fleet tooling and the Claude Code skills, for $249 once at the founding price.

Sites You Can Inspect

No testimonials appear on this page. What we can point at is the fleet, live production sites on this architecture:

• Express Mounting, TV mounting, Atlanta
• Glass Inc, an auto and residential glass company
• Best Alpharetta Roofer, roofing
• Alexus Pressure Washing, exterior cleaning

Run any of them through the free website grader, which is Google’s Lighthouse on a simulated phone plus on-page checks, or put your own site next to two of them in the comparison tool. Or read the HTML and count the script tags. Any of those is more useful than a quote from someone you cannot verify exists.

Alex Crabinsky, a full-stack developer with more than ten years of production work, built the system and runs the fleet on it.

Common Questions

Is Next.js bad for content sites?

No, it is just more machinery than the job needs. Next.js ships the React runtime and its hydration cost on pages that are text and images. That is a reasonable trade when the page is an application and a poor one when it is a service page. Astro sends zero JavaScript unless a component actually needs it.

Can I still use React components?

Yes. Astro’s island architecture runs React, SolidJS, Vue, Svelte and Preact side by side. Amrify Pro’s own widgets are SolidJS islands; you can keep React for a booking widget or a calculator, and the rest of the page ships as static HTML with no runtime attached.

What if I need API routes, auth or a database?

Then use Next.js, honestly. If the product has user accounts, server-side sessions or per-request data, you want a framework built around that. Amrify is built for sites whose pages are known ahead of time; its lead engine and optional Cognito accounts are separate serverless pieces, not a server behind every page.

Why would an agency switch?

Per-site overhead. Fifteen Next.js client sites usually means fifteen repositories, fifteen dependency trees and fifteen upgrade paths. The Amrify boilerplate is one monorepo with shared packages and a license that covers unlimited sites, so a fix to the contact form ships to every client at once instead of fifteen times.

---

Match the tool to the shape of the problem. Read the docs, or see pricing for the founding offer on the full monorepo.