Next.js for applications: why we use it for software and Astro for websites
Two frameworks, two jobs. Why content sites get Astro, logged-in software gets Next.js, and what each choice buys you.
The short answer
A website and an application look similar in a browser and are different things underneath. A website is mostly content, read by anonymous visitors, where speed, search visibility and low cost matter most. An application is mostly state, changed by logged-in users, where sessions, data, permissions and rich interaction matter most. We use Astro for the first and Next.js for the second. Astro turns content into static files with almost no JavaScript, which is why our websites are fast, cheap and secure by default. Next.js gives applications server-side logic, authentication, data fetching and interactive interfaces. Both are TypeScript, both deploy to the same platform, and a business gets a fast public site and a capable application without two teams or two ways of working.
Two jobs, two tools
| Website (Astro) | Application (Next.js) | |
|---|---|---|
| Typical content | Pages, articles, products, landing pages | Dashboards, forms, workflows, records |
| Visitors | Anonymous, from search and campaigns | Logged-in users with roles |
| What matters most | Speed, search visibility, cost, security surface | Sessions, data, permissions, interaction |
| Output | Static files on a network, functions for the dynamic edges | Server-rendered and client-rendered pages with server logic |
| JavaScript shipped | Almost none by default; islands where needed | As much as the interface needs |
| Hosting cost | Very low, flat | Scales with use |
| Security surface | Small: no public admin, no per-visit server code | Larger, managed with authentication, permissions and the usual discipline |
Where the line falls
- Public pages, content, products, campaigns: Astro. Static, fast, cheap.
- A few interactive pieces on those pages: Astro islands plus serverless functions.
- A logged-in area with real state, data and roles: Next.js, on a path or subdomain of the same site.
- Shared look: tokens and components mirrored across both, so the visitor never sees a seam.
- Shared platform: one hosting account, one deploy pipeline pattern, one language.
What the business gets
A public site that scores well on speed without effort, costs little to host and has almost nothing to attack. An application that can grow into real software: authentication, permissions, integrations, background jobs, rich interfaces. One team, one language, one platform, one design system across both. And a clear rule for the next project: is it content or is it state?
What this means for you
Your public website and your business software are different jobs and deserve different tools. Astro for content, Next.js for applications, both TypeScript, both on the same platform, sharing a look. That is how a business gets the fastest possible site and genuinely capable software from one team, and why we do not use one framework for everything.
Frequently asked questions
Why not use one framework for everything?
Because a framework built for applications carries machinery a content site does not need, and pays for it in weight and complexity, while a framework built for content lacks what an application needs for sessions, data and interaction. Using each for its job gives the fastest website and the most capable application, with shared language, tooling and hosting.
Can the website and the application share a look?
Yes. Design tokens and components are shared or mirrored, the domain is shared with the application on a path or subdomain, and the visitor moves from public pages to the logged-in area without noticing a boundary. What differs is the machinery underneath, which the visitor never sees.
What if our site needs some application features, like a booking flow?
Astro handles that with islands: small interactive components on otherwise static pages, plus serverless functions for the dynamic parts. A booking widget, a configurator or a form with logic fits comfortably. When the whole product is logged-in state, dashboards and workflows, it has become an application and Next.js is the better home.
Sources
- Next.js documentation (accessed 2026-09-12)
- Astro documentation (accessed 2026-09-12)