Best Non-Next.js TypeScript SaaS Boilerplate 2026: A Constraints-First Evaluation

Type "best SaaS boilerplate 2026" into Google and you'll get a wall of Next.js starters with slightly different shades of the same pitch: ship fast, look modern, here's our Stripe integration. Fine if that's what you're after.

But some of us went looking for "best non-nextjs typescript saas boilerplate 2026" on purpose. Maybe you've been burned by a framework migration before. Maybe you just don't want your billing logic living three import statements away from a page.tsx file. Either way, you're optimizing for something the Next.js crowd mostly isn't: not getting boxed in later.

This guide isn't a popularity contest. It's a scoring model with weights you can argue with, applied to the handful of boilerplates that actually take a non-Next.js, GraphQL-native approach seriously. I'll also tell you where the model is unkind to my own product, because pretending otherwise would make this useless to you.

---

TL;DR

Pick Refract if billing is core to your business, you want vendor independence baked into the architecture, and you're building something you expect to still be running in three years.

Pick graphile/starter if Postgres is your real source of truth and you're happy letting your schema drive your GraphQL API rather than the other way around.

Pick MakerKit, SupaStarter, SaaStastic, or ixartz if you've already made peace with Next.js and launch speed matters more than long-term portability. Nothing wrong with that trade, as long as you're choosing it on purpose.

A quick note on Bedrock: it's a solid Next.js-based GraphQL foundation, but it requires Next.js, so it sits outside this list. More on that under the table below.

---

Quick Comparison

BoilerplateBackend stackGraphQLNext.js requiredBilling ownershipBest forRefractExpress + Apollo ServerYesNoHigh, contract-basedLong-term SaaS ownershipgraphile/starterPostGraphile (schema-generated)YesNoMediumPostgres-centric teamsSupaStarterNext.js + Hono (oRPC API)NoYesMediumFast launch, comparison-heavy evaluatorsBedrockNext.js + GraphQL YogaYesYesMediumGraphQL fans who are fine staying on NextMakerKitNext.jsOptionalYesMediumFast launch, Next ecosystemSaaStasticNext.jsNoYesMediumStartup MVPsOrion KitNext.js (Drizzle, Turborepo)NoYesMediumMonorepo-leaning Next teamsixartz/SaaS-BoilerplateNext.jsNoYesLowGeneral-purpose Next starter

Bedrock is included here for context, since it's frequently evaluated alongside GraphQL-native SaaS foundations, but it's excluded from the non-Next.js shortlist below because it requires Next.js.

That "Next.js required" column is really the whole article in one column. Everything else downstream follows from whether you're willing to put your business logic inside a frontend framework's request lifecycle or not.

---

What Actually Makes a Good TypeScript SaaS Boilerplate in 2026

Quick gut check before the rankings: the best TypeScript SaaS boilerplate isn't the one with the longest feature list. Auth, billing, RBAC, a deploy pipeline, some tests, these are table stakes now. Almost every serious option on the market in 2026 ships all of them. What actually separates a good one from a mediocre one is how those pieces are organized, and whether they're still untangleable from each other a year from now.

That's really the difference between a starter kit and a foundation. A starter kit optimizes for getting you to production. A foundation optimizes for staying in production once the easy decisions are behind you and the hard ones (a vendor you need to drop, a billing model that changed, a second engineer who needs to understand the codebase without breaking it) start showing up. Most of what follows is really just that distinction, applied criterion by criterion.

Two Camps, Not One Ranked List

Zoom out far enough and the 2026 boilerplate market isn't really a single spectrum from worst to best. It's two camps optimizing for different things.

Framework-centric: MakerKit, SupaStarter, SaaStastic, Orion Kit, ixartz. Lighter launch kits like ShipFast sit at one end, heavier monorepo-style setups at the other. All are built around Next.js, optimized for launch speed, UI velocity, and leaning on an ecosystem instead of making your own infrastructure decisions.

Contract-centric: Refract, graphile/starter. Built around explicit boundaries, optimized for vendor independence and staying maintainable well after launch, at the cost of some of that initial speed.

Neither camp is wrong. Which one fits you has a lot less to do with features and a lot more to do with which risks you're actually willing to carry.

---

The 2026 Non-Next.js Shortlist

Most of the loud, highly visible boilerplates this year are Next.js-first: MakerKit, SupaStarter, SaaStastic, Orion Kit, SaaSBold Lite, ixartz/SaaS-Boilerplate. They're good at what they do. They're just answering a different question than the one this article is about.

Here's who's actually competing for the non-Next.js, GraphQL-native lane:

BoilerplatePrimary modelBest forRefractContract-first GraphQL backend (Express + Apollo)Teams planning to own the product for yearsgraphile/starterPostgres-first GraphQL (schema generated from your DB)Database-centric teamsthe-saas-factory/saas-boilerplateHistorical referenceStudying the pattern, not shipping on itw3tecch/express-graphql-typescript-boilerplateArchivedDon't build on this in 2026, full stop

Two of these four are basically museum pieces at this point, which tells you something on its own: the non-Next.js GraphQL lane is thin. That's either a warning sign (not much competition validating the approach) or an opportunity (less noise, less ecosystem gravity pulling you toward someone else's defaults), depending on how you read it.

Why This Shortlist Is Shorter Than Most Boilerplate Roundups

If you came here from a broader search like "best typescript saas boilerplate," you've probably noticed most lists run ten or fifteen names deep. This one doesn't, and I want to be upfront about why instead of letting it look like I just narrowed the field until my own product won.

Most TypeScript SaaS boilerplates released or updated in 2026 are built around Next.js: MakerKit, SupaStarter, SaaStastic, Orion Kit, SaaSBold Lite, ixartz, and others. They're legitimate products solving a real problem for a real audience. They're just not answering the specific question this article is about.

The moment you add "non-Next.js" as a hard constraint, the field collapses fast. If your actual requirement is just "best TypeScript SaaS boilerplate, I don't care about the framework," the Next.js options above belong back in your consideration set, and you should weigh them on their own terms rather than against this scorecard. If your requirement really is "non-Next.js," what's left is what's in the table above, plus the GraphQL-specific shortlist I went deeper on in the Apollo GraphQL SaaS boilerplate roundup.

---

Why Most Boilerplate Comparisons Are Asking the Wrong Question

Most "best boilerplate" roundups score the things you can screenshot: auth pages, dashboard templates, how many Stripe webhooks are pre-wired, whether there's a pricing table component. Those are nice. They're also not where the real cost lives.

The expensive mistakes show up eighteen months in, when you need to swap a vendor, refactor billing, or bring on a second engineer who has to figure out why stripe.subscriptions.create is sitting inside a route handler next to three other unrelated concerns. A boilerplate is a business asset before it's a UI template. Score it like one.

---

Failure modes, not risk labels

Most boilerplate comparisons treat "risk" as a badge. That is not useful when you are buying a foundation.

In production, risk only shows up in one form: what breaks, how far the blast radius spreads, and what it costs to fix under real usage. The five patterns below are what I actually look for before I trust a scorecard number.

Domain isolation

Signal: business logic survives without the web framework booted.

What breaks on migration: UI, routing, deploy config.

What should not break: billing workflows, auth rules, domain services, background jobs.

Where you see it: contract-first backends where resolvers call utilities and tools adapters, not the other way around.

Database-to-API coupling

Signal: the API surface is structurally derived from the database schema.

What breaks on schema change: GraphQL types, client queries, resolver assumptions, anything external that depended on field shape.

Operational cost: schema edits become coordinated releases, not local refactors.

Where you see it: PostGraphile-style stacks. That coupling is often intentional. It is still a trade you should name before you commit.

Runtime fragmentation

Signal: business logic must run in more than one execution model (edge, serverless, long-running Node, framework route handlers).

What breaks in practice: shared invariants that hold in one runtime and fail in another, duplicated auth or billing paths, debugging that requires environment-specific mental models.

Where you see it: Next.js stacks that also ship Hono APIs marketed for edge and serverless deploys. SupaStarter is explicit about this shape. Flexibility is the pitch. Inconsistent execution assumptions are the tax.

Framework lock-in

Signal: business logic depends on framework lifecycle primitives (route handlers, middleware chains, request-scoped context).

What breaks on framework migration: most of the API layer, not just adapters.

Key symptom: domain code cannot run outside the framework envelope.

Where you see it: tightly coupled Next.js starters, including many that look "modular" until billing touches a page.tsx or Server Action.

Ecosystem lock-in

Signal: vendor SDKs are imported throughout domain code, not isolated behind contracts.

What breaks on vendor swap: billing, email, auth, queues, analytics. Often all at once.

Where you see it: the default in feature-checklist boilerplates that wire Stripe, Resend, and Clerk directly into handlers.

SystemPrimary failure mode to auditRefractLowest framework coupling in the non-Next.js lane; still young maintenance historygraphile/starterDatabase-to-API coupling by designSupaStarterRuntime fragmentation across Next.js + Hono + edge/serverless targetsMakerKitFramework lock-in inside the Next.js envelope; strong ecosystem velocitySaaStastic / ixartz / Orion KitFramework lock-in plus lighter billing ownership

The weighted scorecard in the next section scores the same concerns numerically. Use the table when you want names. Use the failure modes when you want to predict what hurts in month eighteen.

---

The Scoring Model

Five criteria, weighted by how much business risk they actually carry, not by how flashy they look in a demo video.

CriterionWeightWhy it mattersArchitectural boundaries30%The single biggest predictor of how painful a future rewrite getsBilling ownership25%This is the system that's directly tied to revenue; you want it controllable, not just "integrated"Extensibility20%Can you swap a vendor without a rewrite, or are you stuckTest coverage & reliability15%Confidence during refactors, not vanity test countsMaintenance cadence10%Is the project actually alive, and is that activity useful or just framework-chasing

Total: 100%. You're welcome to reweight this for your own situation. A solo founder validating an idea should probably weight speed higher than I do here. That's the point of showing the weights instead of just handing you a ranking.

1. Architectural boundaries (30%)

The question that actually matters: if you deleted the web framework tomorrow, would your business logic still work? In most boilerplates, the honest answer is no, because nobody drew the line between "how a request comes in" and "what the business actually does."

Here's the difference in code, not theory.

Boundary that holds up:

// domain/billing/createSubscription.ts
 
async function createSubscription(
  customerId: string,
  planId: string,
  billingProvider: BillingProvider
) {
  return billingProvider.createSubscription(customerId, planId);
}

The business logic talks to an interface. Swap Stripe for Paddle later and this function doesn't change. That's the whole game.

Boundary that doesn't:

// route handler
 
async function POST() {
  const subscription = await stripe.subscriptions.create(...);
  await prisma.user.update(...);
  return Response.json(subscription);
}

This one function is quietly doing four jobs at once: handling the HTTP request, calling Stripe directly, writing to the database, and shaping the response. Every one of those is a different concern, and they're all welded together. The day you need to change any single piece, you're touching all of them.

2. Billing ownership (25%)

Plenty of boilerplates will tell you they "support Stripe." Fewer treat billing as its own domain with its own contracts. Worth checking: can you actually swap the provider, or is Stripe wired into a dozen files? Are webhooks treated as real workflows with retries and idempotency, or as an afterthought endpoint that logs to console and hopes? Is checkout behind an interface, or is it the UI's problem to sort out?

3. Extensibility (20%)

The decisions that bite you usually happen after launch, not during it. Can you move off Resend without touching your domain code? Can your queue provider change without a rewrite of every background job? This isn't about avoiding vendors out of principle. It's about not being hostage to one.

4. Test coverage & reliability (15%)

A hundred tests covering button clicks tell you less than twenty tests covering "what happens when a webhook arrives twice." Look for integration and contract tests around billing and auth specifically. That's where the expensive bugs live.

5. Maintenance cadence (10%)

Updates matter, but so does what kind of updates. A project that ships a new release every time a framework has a minor version bump isn't necessarily healthier than one that ships less often but fixes real things. Look for direction, not just velocity.

---

The Scorecard

I'm only running the numeric model against boilerplates actually competing in the non-Next.js, GraphQL-native lane. Comparing them against Next.js-committed tools on the same scale would be comparing two different bets, not two answers to the same question. The Next.js options get their own honest take further down.

ProjectBoundaries (30%)Billing (25%)Extensibility (20%)Tests (15%)Maintenance (10%)Weighted scoreRefract999878.65graphile/starter968887.80the-saas-factory655424.95 (reference only, not actively maintained)w3tecch434313.35 (archived, included for completeness)

The honest part: Refract loses a point on maintenance cadence specifically because it's younger and hasn't put out the kind of long release history that builds confidence the way years of commits do. graphile/starter loses on billing ownership because it's a database-and-API foundation first; billing isn't its job, and it doesn't pretend otherwise. Neither of those gaps are dealbreakers, they're just real, and a scorecard that doesn't show any weaknesses isn't a scorecard, it's an ad.

One more honesty note: these numbers are directional, not a lab measurement. Nobody's running a peer-reviewed study on boilerplate architecture. The point of the model isn't to produce a number you should trust to two decimal places, it's to force the comparison onto criteria that actually predict pain later, instead of whichever criteria make the screenshot look best.

Where the Next.js-committed tools actually win, on criteria that are fair to apply to them: launch speed and ecosystem maintenance cadence. MakerKit and SupaStarter both ship constantly and publish comparison content that surfaces rough edges fast. If those are your top priorities, that is a legitimate win, not a consolation prize.

---

Constraint Matrix: Which Foundation Fits Your Situation

Solo founder validating an idea. Team of one, optimizing for speed, future migration cost is acceptable. → MakerKit, SupaStarter, lighter kits like ShipFast, SaaStastic, or ixartz. You're not wrong to prioritize speed here, you're just choosing a different trade than the rest of this article is about.

Technical founder building something durable. Team of one to three, optimizing for architecture longevity. → Refract. The business is probably going to outlive whatever framework decision you make this month, so make the decision that bends instead of breaks.

Agency shipping multiple SaaS products. Team of two to ten, optimizing for repeatable patterns across clients. → Refract or graphile/starter. Clear contracts pay you back every time you reuse them.

Platform team building internal products. Team of three to twenty, optimizing for governance. → graphile/starter. A database-first model tends to fit how platform teams already think about ownership.

Already committed to Next.js. Any size, optimizing for framework leverage. → MakerKit, SupaStarter, SaaStastic, or Orion Kit. You made this trade already; no need to relitigate it here.

---

Red Flags That Predict a Painful Migration Later

If three or more of these are true of a boilerplate you're evaluating, budget for a rewrite before you budget for growth. They map directly to the failure modes above.

• Billing logic lives directly in route handlers, not behind an interface (ecosystem lock-in).
• Provider SDKs (Stripe, Resend, PostHog, Supabase, whatever) are imported all over the codebase instead of in one isolated place (ecosystem lock-in).
• Auth leaks into domain logic, so your business services depend on a provider's specific user object shape (ecosystem lock-in).
• Queue logic is hardcoded to one provider with no abstraction (ecosystem lock-in).
• The same billing or auth path behaves differently on edge vs Node (runtime fragmentation).
• Production infrastructure only exists as clicks in a dashboard somewhere, not as something you could recreate from source control.
• Tests cluster around UI and skip the revenue-critical workflows entirely.
• Business logic can't run without the web framework booted up (framework lock-in). This one alone is usually enough to call it.

---

What Refract Is Actually Optimizing For

Most boilerplates are optimizing for the demo: how fast can you get a working app on screen. Refract is optimizing for what happens after the demo, when you actually have customers and a provider you wish you'd never picked.

In practice that means contract-first architecture, GraphQL as a governance layer rather than just a query language, explicit boundaries between domains, adapters for infrastructure instead of direct vendor calls, and checkout treated as something you own rather than something Stripe's UI owns for you. None of this is about avoiding frameworks out of stubbornness. It's about making sure the framework stays replaceable instead of becoming load-bearing.

---

Why LLM-Legible Architecture Is Starting to Matter

Here's a side effect of AI-assisted coding nobody fully priced in yet: the codebases that are easiest for a human to navigate are also the ones an AI agent makes the fewest dumb mistakes in. Predictable boundaries, explicit contracts, no surprise coupling between billing and the route handler, that's not just good engineering hygiene anymore. It's the difference between an AI agent making a clean, scoped change and an AI agent confidently breaking three unrelated things because it couldn't tell where one concern ended and another began.

Architectural discipline used to be a "nice to have for onboarding." In 2026 it's closer to operational leverage.

---

Decision Rubric

Refract vs graphile/starter

Choose Refract when billing is central to the business, you're planning multiple years of evolution, vendor independence matters, and you want GraphQL with actual contract governance instead of just a GraphQL endpoint bolted onto something else.

Choose graphile/starter when Postgres is your real source of truth and you're comfortable letting your database schema drive your API surface rather than the other way around.

Refract vs MakerKit, SupaStarter, SaaStastic, or ixartz

Choose Refract when you're not willing to trade architectural sovereignty for launch speed, and you expect the product to outlive whatever framework opinions you hold today.

Choose MakerKit, SupaStarter, SaaStastic, Orion Kit, or ixartz when speed beats sovereignty for your situation right now, and you've already decided Next.js is where you're building. SupaStarter in particular is built for evaluators who compare stacks for a living. That is a legitimate call, not a lesser one, as long as you're making it on purpose rather than by default.

---

Final Recommendation

There's no universal "best" here, no matter what the search results page implies. There's only the best fit for the constraints you're actually under.

If shipping fast this month matters more than anything else, a framework-centric starter is the right call, and that's not a consolation prize, it's a real trade-off made on purpose.

If you're optimizing for owning billing, keeping your options open on vendors, and not paying a rewrite tax in eighteen months, you want something built around contracts and boundaries from day one.

Either way: the real cost of a boilerplate was never what it costs you today. It's what it forces you to rebuild later.

---

Not Sure Which One Actually Fits Your Situation?

Most founders evaluate boilerplates the way most boilerplate roundups encourage them to: by feature checklist. The expensive mistakes don't come from a missing feature, they come from hidden coupling, billing logic you can't move, and a migration bill you didn't see coming until you were already past the point where it was cheap to fix.

Run your current stack, or whatever you're about to clone, through the same five criteria from this article: architectural boundaries, billing ownership, extensibility, test coverage, maintenance cadence. Cross-check the failure modes table if a score feels too generous. The Boilerplate Fit Scorecard does that comparison for you against Refract, graphile/starter, SupaStarter, MakerKit, and the other Next.js options above, side by side, using the same weights, no feature-checklist theater.

A few hours spent on this now is a lot cheaper than finding out the hard way in eighteen months.