Web App Development: Choosing the Right Stack for Your Project

“Just use React” is common advice, and often correct — but React alone is a UI library, not a full answer to how your app gets rendered, routed, and deployed. That’s where the real stack decision happens.

React is the component model; the framework decides everything else

React handles building UI out of reusable, stateful components. What it deliberately doesn’t handle — routing, data fetching, server rendering, deployment — is left to a framework built on top of it. Which framework you pick changes your app’s performance characteristics, hosting cost, and how much complexity you’re signing up for.

Next.js: the default for dynamic web apps

Next.js (built by Vercel) adds the App Router, React Server Components, and a choice of rendering strategy per page: server-side rendering (SSR) for pages that must reflect fresh, per-request data; static generation (SSG) for pages that can be built once and served from a CDN; and incremental static regeneration (ISR), a middle ground that serves a cached static page but regenerates it in the background on a schedule. It also gives you API routes in the same project, so a small backend can live alongside the frontend without standing up a separate service.

This is the right default for a SaaS dashboard, a customer portal, or any product with real per-user, per-request state — genuine web applications, not primarily content.

Astro: the better default for content and marketing sites

Astro takes the opposite default: zero client-side JavaScript unless you explicitly opt a component into it (“islands architecture”), with everything else pre-rendered at build time. For a marketing site, a blog, or a documentation site — content that’s the same for every visitor — this produces a meaningfully faster page with less to go wrong, since there’s no client-side framework runtime shipped for content that never needed it.

This site is itself built with Astro for exactly that reason: it’s a marketing site, not an application, and doesn’t benefit from Next.js’s dynamic-rendering machinery.

A simple way to decide

• Content is the same for every visitor, and there’s no login → Astro (or another static-site generator). Fast, cheap to host, minimal attack surface.
• Users log in and see personalized, changing data → Next.js. You need real server rendering and session handling.
• Both → often the right answer is two separate projects (a static marketing site plus a separate app), not one framework stretched to do both jobs. See our note on website vs. web app if you’re not sure which side of that line your project falls on.

The rest of a modern web app stack

Beyond the framework: TypeScript for type safety across a growing codebase, Tailwind CSS for styling without a separate CSS architecture to maintain, Prisma as an ORM when a relational database is involved, and a managed Postgres provider (Supabase, Neon, or a cloud provider’s managed offering) rather than self-hosting a database from scratch. Authentication is almost always better handled by a dedicated library (Auth.js) or service than built from first principles.

Elmeris builds with this exact stack — React, Next.js, TypeScript, Tailwind, Astro for static sites, Prisma, and Postgres — choosing per-project rather than defaulting to one framework regardless of fit. See our web app development services, or get in touch to talk through what your project actually needs.