Apollo GraphQL SaaS Boilerplate 2026: The Actual Shortlist

TL;DR

• I spent real time in early 2026 auditing what people actually get when they insist on Apollo GraphQL + TypeScript + SaaS outside the Next.js monoculture. Most names on lists are not built for that spine.
• Boilerplate value amortizes as maintenance. Stale repos look free until week six, when toolchains rot and your Stripe path does not survive a replayed webhook.
• Refract Boilerplate is Refract — the TypeScript SaaS boilerplate at userefract.io. I ship it as Express + Apollo Server backend, Vite + Apollo Client portal, contracts and tooling seams documented on docs.userefract.io.
• Companion argument for why this shape exists: draft Why I Did Not Build Refract Boilerplate on Next.js in apps/marketing/playbook/posts/. Evergreen constraints framing (no year in the slug intent): apollo-graphql-saas-decision-framework.md in the same folder.

Two weeks ago I was up late again with someone’s shortlist. Every roundup page led to the same silhouette: Next.js, Tailwind, hosted auth, Stripe demo in an afternoon. Fair shape if your product is landing pages and dashboards and you want one deployable.

Their problem was different. They wanted Apollo on the server, a typed client boundary, and room for webhooks and workers without turning route handlers into a second backend. The articles they found did not lie. They just answered a different question.

This note is what I tell that person after I have actually opened repos, read lockfiles, and watched which projects still move with Node LTS and React 19. I am not asking you to pick Refract. I am asking you to stop mistaking list placement for architecture fit.

What the list actually contains

If you follow the links people paste in Discord, the active mass is Next-first. ixartz/SaaS-Boilerplate is a serious maintenance object. Commercial kits like SaaStastic and MakerKit’s React SaaS boilerplate market hard on “2026 ready.” They are not stupid products. They are optimized for a buyer who wants speed in the default lane.

The lane I care about is thinner. Apollo-native TypeScript SaaS starters that treat the graph as the product API, not a bolt-on, are scarce. Old Express + GraphQL tutorials point at repositories that stopped or forked into noise. graphile/starter still matters for GraphQL + Postgres seriousness. Read its stack cards before you map it to “GraphQL SaaS” in your head. It is not the same shape as a hand-rolled Apollo + Express monorepo.

That scarcity is the whole point of the year in the title. 2026 is not branding. It is a reminder that boilerplates age in public. A beautiful README and a 2022 lockfile diverge while you pitch investors.

The maintenance sniff test (before you fork)

Skip README theater. Three checks survive contact with reality:

1. Commits and releases versus toolchain reality. Do they track React 18 and 19 boundaries, Apollo Client major shifts, ESLint migrations, or did the last meaningful pass predate habits you already take for granted?
2. Where Stripe actually lives. Checkout UI is theatrics. Subscription state transitions, webhook interleaving, and replay safety are the product. Silence there is not minimalism. It is debt.
3. Contract discipline. One schema truth, generated operation types in CI, resolvers thin enough that policy does not sprawl. If handwritten DTO mirrors drift from the schema, you will nurse that diff forever.

Stars reward marketing. Forks reward hope. Neither measures risk-adjusted onboarding cost.

Who should insist on Apollo + TypeScript explicitly

Rough cut. You belong here if the product API drives roadmap within months: billing mutations, entitlement checks, reconciliation, integrations, eventual mobile or partner consumers. GraphQL as the contract surface is a forcing function: the server declares what exists; clients stay consumers.

If your edge is funnel polish and you will live inside one framework’s blessed path, a Next-first kit is rational. Scroll away without shame.

Teams can bolt Apollo Server beside Next route handlers. Technically fine. Organizationally the gravity still pulls domain work into colocated pockets. Conway’s law does not care that separation is possible. It cares what your repo rewards on a Friday night. A dedicated backend process plus a portal client is not a benchmark win. It is a message to the next five hires: contracts originate on the server. UI is a client. That is architecture politics. I still pay for it on purpose.

One clean split: Next-first default versus Apollo-native split

If you optimize for…	Next-first typical	Express + Apollo Server backend, portal client
Contract authority	Emerges unless you enforce discipline	GraphQL boundary + codegen as default
Webhook and worker lifecycle	Drifts into scripts and side doors	Queue and worker idioms fit without apology
Tutorial gravity and hiring shorthand	High	You explain one more sentence
UI velocity as first-class story	Strong	Strong if you like Vite and a separate design system

Not dunking Next. Drawing the trade space so you do not buy the wrong package.

Where Refract Boilerplate sits

Refract Boilerplate is the commercial monorepo I ship at userefract.io. GraphQL-forward by construction:

• Backend: Express, Apollo Server, PostgreSQL. Orientation: architecture overview.
• Portal: React, Vite, Apollo Client, MUI. How the graph maps to client work: GraphQL.
• Mail, queue, Stripe, and related tools behind interfaces: tooling system.
• Marketing split from authenticated bundles so SEO stays honest.

w3tecch/express-graphql-typescript-boilerplate still lands on curated lists; it lives in archive now. Treat that trajectory as evidence, not vibes. Lists age faster than forks.

Red flags when you evaluate any starter, ours included:

• Duplicate webhook handlers or unclear ownership when the same event arrives twice during a deploy.
• “Stripe-ready” without an idempotency story you can point to in prose and code.
• Interfaces that read clean until you find vendor SDK literals inside supposed core modules.
• Silent REST shadows that bypass codegen and rot the contract.

If answers evaporate under those questions, you are not debating architecture. You are debating landing copy.

Is Apollo overkill compared to tRPC?

Not categorically. Different boundary expectations.

tRPC tightens type flow across one TypeScript organism. It shines when UI and server move as a unit and external consumers are a future rumor.

Apollo elevates a published schema strangers can reason about including agents, partners, generated clients across repositories.

Pick tRPC when the monolith envelope is stable and your pain is ergonomics inside it. Pick Apollo when the pain is multi-client longevity and explicit contract negotiation. Migrating either direction costs calendar time. Budget that line item if you hedge.

Do you need federation on day one?

Rarely.

Federation buys graph governance across teams already fighting over boundaries in production. Buying it upfront without that pain mostly buys coordination overhead and failure modes you do not need yet.

Defer until Conway’s lines in your org match the subgraph lines you dream about.

What about PostGraphile or Hasura?

Valid forks of the problem. Database-introspection GraphQL stacks trade explicit resolver work for coupling depth different from Express-first hand authoring.

Refract aligns with programmatic resolvers because I want stale business logic visible in ordinary TypeScript, not inferred from DDL drift alone. That is preference backed by billing scars, not a moral law. Compare migration tax if you ever outgrow auto-generated schema assumptions.

Billing and webhooks: the seriousness filter

Apollo does not solve money. Ownership does.

When you read “Stripe integrated,” ask plain questions:

• Which module owns subscription transitions when invoice.paid, customer.subscription.updated, and checkout completion race?
• What stops duplicate entitlement writes under retries?
• How are checkout-driven upgrades partitioned from lifecycle fan-out so two paths do not execute the same side effect?

Refract documents those boundaries at a layer you can reconcile with an auditor’s mindset. Start at billing, then tie back to overview. Silence from a vendor when money moves is a hard no.

How I score contenders when I disagree with myself later

Weighted rubric beats vibes when you revisit the decision at month nine. Adapt the weights. Mine default roughly like this:

• 0.24 Maintainer cadence versus Node/LTS churn
• 0.24 Billing and webhook seriousness
• 0.21 Contract discipline along the typed edge
• 0.18 Adapter seams you can swap without rewriting features
• 0.13 Structure legible enough that onboarding and tooling do not start from archaeology

Normalize each pillar 0–1 after a real audit week. Multiply weights. Sum. Write down assumptions with a date stamp so future you cannot pretend the spreadsheet was prophecy.

Pin exact dependency versions from the repos you shortlisted and rerun quarterly. Boilerplate evaluations rot faster than prose.

Concrete homework that cuts through dashboards: measure hours to first passing webhook replay test. If “tomorrow maybe” is the answer, downgrade the starter.

When Refract Boilerplate loses

Honesty clause. Pick elsewhere when:

• You only need SEO surfaces and shallow SaaS, and a lighter funnel kit finishes the job without lying about depth.
• Your team rejects resolver discipline unless lint and review babysit GraphQL entropy. Boring REST can be smarter than pretend schema elegance.
• You need plug-and-play visual cohesion from someone else’s component religion and Refract tokens feel like rework.

If two options tie after the rubric, run the webhook replay test on Tuesday and Thursday. Flaky locks hide in calm demos.

How to escape a Next-first prototype without a rewrite fantasy

Teams sprint in route handlers because the tutorial did. Weeks later Stripe, roles, and flags braid through layers that resist extraction.

Mitigation without heroics:

• Early: Carve webhook ingestion into a worker-shaped process even if types duplicate briefly.
• Mid: Freeze new domain logic in React server paths. Route additions through central modules you can later hang resolvers on.
• Late: Strangler pattern. Expose parity operations through Apollo resolvers that call shared utilities you retrofit incrementally. Big-bang freezes are how billing incidents meet vacation schedules.

GraphQL orientation from graphql.org/learn still helps if fundamentals rusted.

Closing

Consensus lists converge because distribution incentives reward sameness.

If your roadmap front-loads webhooks, entitlements, adapter swaps, and contracts that survive clients you have not invented yet, overweight those constraints in evaluation. Ignore the headline framework fetish unless it serves that spine.

Refract stays on this architecture on purpose.

If constraint framing helps more than a year stamped title, read apollo-graphql-saas-decision-framework.md in this playbook beside this piece.

If the architecture argument landed, these are the docs that show it in code rather than prose: architecture overview, GraphQL, authentication plus RBAC, billing.