"What stack should we use?" is the most common question we hear from founders starting new projects. This is the decision tree we use to answer it quickly.

Question 1: What kind of site is this?

  • Content-heavy (marketing, blog, docs, brochure). Astro.
  • App-heavy (SaaS, dashboard, logged-in product). Next.js.
  • Both. Two separate codebases. Marketing on Astro, app on Next.js, shared design system.

Don't try to make one framework do both well unless you have a clear architectural reason.

Question 2: How interactive is the typical page?

  • Mostly static with light interactivity. Astro with partial hydration.
  • Form-heavy or CRUD-like. Server-rendered with progressive enhancement (Astro, Next.js App Router, Remix all work).
  • Highly interactive (Figma, Linear-like). React or Vue SPA with a clear API boundary. Don't try to server-render this.

Question 3: Where are your users?

  • Global audience. Edge hosting. Cloudflare Pages, Vercel Edge, Netlify Edge.
  • Regional audience (e.g., UK-only). Single-region origin hosting is fine. Don't over-engineer.
  • Data residency requirements. Multi-region with smart routing. AWS or a specific cloud might be required.

Question 4: What's your data layer?

  • Relational data, typical scale. Postgres. Period.
  • Document-shaped data. Postgres with jsonb. Or MongoDB if you really need it (rarely).
  • Real-time multiplayer. Postgres + Yjs / Liveblocks / PartyKit.
  • Analytics-heavy workloads. Postgres + ClickHouse for analytical reads.

Question 5: REST or GraphQL?

  • Internal API with a small number of consumers. REST. tRPC if you're shipping TypeScript end-to-end.
  • Public API or large number of frontend variants. GraphQL is worth the complexity.
  • Mobile + web with different data needs. GraphQL.
  • Default. REST. Don't reach for GraphQL by default; the complexity tax is real.

Question 6: Auth?

  • Single product, modest scale. Roll your own with a well-tested library (Lucia, Better Auth, NextAuth). Email + password + magic link is fine.
  • Enterprise B2B. Add SAML/SSO. Use Auth0, WorkOS, Clerk for SSO if you don't want to build it.
  • Consumer mass-market. Same as single product, add social login.

Question 7: How big is your team?

  • 1-3 engineers. Boring stack, opinionated framework, no microservices.
  • 10+ engineers. Modular monolith with clear domain boundaries. Still not microservices.
  • 50+ engineers. Now you can have a microservices conversation.

Most teams adopt microservices at least one team-size step too early. Stay monolithic longer than you think you should.

When to break the rules

There are reasons to deviate:

  • Existing team expertise. A Rails team should ship Rails. The "right" stack you can't operate is worse than the "wrong" stack you can.
  • Specific workloads. ML inference, real-time collab, hard real-time data — these justify specialised tools.
  • Compliance constraints. Some regulated workloads require specific stacks regardless of your preferences.

Our 2026 default stack

If you handed us a greenfield SaaS project with no constraints:

  • Next.js (App Router) for the app, Astro for the marketing site.
  • TypeScript end-to-end.
  • Postgres for the data layer.
  • Cloudflare for hosting and edge logic.
  • Tailwind + a small custom design system.
  • tRPC or REST for the API. GraphQL only if there's a real reason.
  • Better Auth or similar for auth.
  • GitHub Actions for CI.

This is boring. That's the point.