TanStack Ship vs Makerkit: B2B Multi-Tenant vs Edge-Native Solo SaaS

Written by Huifer, solo developer and maintainer of TanStack Ship. I evaluated Makerkit’s B2B features during a three-day trial. Its organization, role, and multi-tenant foundations are genuinely more mature than what TanStack Ship ships today. If I were serving several enterprise accounts with complicated workspace permissions, that would be a decisive reason to choose Makerkit. For a solo or small-team subscription product, I found TanStack Ship’s growth and edge tooling more directly aligned.

Verified sources: TanStack Ship GitHub · Makerkit documentation · TanStack Start documentation Updated: 2026-07-20 · Changelog

TL;DR: Pick Makerkit when multi-tenant B2B structure, team roles, and an enterprise-oriented application model are your hardest day-one requirements. Pick TanStack Ship when a solo or small team wants TanStack Start on Cloudflare Workers plus built-in attribution, campaigns, referrals, and revenue operations. Neither is universally better. The costly mistake is buying for a long feature list instead of the hardest invariant in your product.

The real split is tenancy versus operations

Both products reduce the repeated work around authentication, billing, application shells, and deployment. They diverge in what they optimize after that baseline. Makerkit’s public documentation emphasizes SaaS applications organized around accounts, teams, memberships, and permissions. TanStack Ship emphasizes an edge-native TanStack architecture and the operational loop from acquisition through revenue analysis.

That distinction matters more than a row-by-row feature contest. A multi-tenant B2B product can fail if workspace boundaries are weak, even when its campaign dashboard is excellent. A founder-led subscription product can ship sound role checks and still operate blind if attribution, offers, referral credits, and MRR reporting live in disconnected spreadsheets.

My rule is simple: choose the starter that already models the risk you cannot afford to model badly. The full feature catalog is useful only after you have named that risk.

A short recommendation table

This is not advice to buy Makerkit at an arbitrary customer count. The “five-plus enterprise customers” in my brief is a practical warning that permission and account complexity arrives early, not a scientific threshold.

Architecture and deployment model

TanStack Ship uses TanStack Start and TanStack Router, targets Cloudflare Workers, and integrates D1, R2, KV, and Queues where the product needs them. The design favors typed routes, Server Functions, edge-compatible dependencies, and one operational platform. If your team already wants that stack, the coherence removes integration choices.

Makerkit’s documented stacks target the React SaaS ecosystem with database-backed account and team patterns. Its B2B strength comes from treating tenancy as a first-class application concept rather than an optional organization_id column. Consult its current docs before purchasing because supported frameworks, providers, and package boundaries can change.

Why framework fit is a business decision

Framework familiarity affects delivery risk. A Next.js-oriented team may move faster with Makerkit even if a Cloudflare architecture appears cheaper on paper. A team already using TanStack Router can lose time translating route ownership and data-loading conventions into a different framework. Neither learning curve is free.

I compare dependency boundaries, not logos. Can the chosen runtime execute every SDK? Where do sessions live? Which database owns tenant isolation? How are background jobs retried? Can one engineer trace signup, checkout, and entitlement updates without crossing three deployment systems? Those questions predict month-six operability better than a generic “edge versus serverless” slogan.

For TanStack-specific trade-offs, the comparison hub provides the broader context. Makerkit remains a reasonable answer when B2B account depth outweighs stack consolidation.

Test data ownership before UI polish

The fastest way to expose a starter’s assumptions is to draw ownership for five records: user, workspace, subscription, invoice, and project. Ask whether a user may belong to several workspaces, whether a subscription belongs to a person or an account, and what happens to shared resources when the last owner leaves. Then enforce those answers in a route and a database query.

For a B2B product, I also test invitation reuse, removal of an administrator, cross-workspace URL guessing, and a billing event arriving after the workspace was archived. These are not exotic edge cases; they reveal whether tenancy is foundational or decorative. Makerkit’s model starts closer to those questions.

For a solo subscription product, I run a different test: preserve campaign identity from the first anonymous request through signup and checkout, then show the attributed order in an admin report. That slice reveals whether growth data is a connected domain or a collection of integrations. TanStack Ship starts closer to this workflow.

Do both tests before styling a dashboard. A polished template can hide a mismatched ownership model for weeks, while a small authorization or attribution test makes the mismatch obvious in an afternoon. Keep the resulting test even after selection; it becomes an executable statement of why the architecture was chosen.

Where Makerkit is stronger

Multi-tenant account modeling

Makerkit’s primary advantage is not simply “has roles.” It gives B2B founders a stronger starting vocabulary for personal accounts, team accounts, memberships, invitations, and permissions. Those concepts become the spine of billing and authorization. Reconstructing them after launch is risky because every table, route, and background job may already assume a different ownership model.

TanStack Ship has authentication, user administration, and role-based access, but I do not claim parity with a mature nested organization system. If your roadmap requires multiple workspaces per user, per-workspace billing, delegated administration, and carefully scoped data access, Makerkit deserves the first prototype.

Fit for enterprise-shaped work

Enterprise buyers ask about auditability, account lifecycle, permission changes, and onboarding controls before they care about a referral engine. Makerkit’s orientation makes those conversations easier to map to application concepts. A starter cannot grant compliance by itself, and buyers still need policies, infrastructure evidence, and legal work, but the underlying model can reduce rework.

This is the point where a biased comparison would hide Makerkit’s advantage. I would rather send the wrong-fit reader to Makerkit than sell a TanStack Ship license that begins with a tenancy rewrite.

Where TanStack Ship is stronger

Growth operations are part of the product

TanStack Ship connects SSR-compatible UTM capture, cross-session attribution, campaign offers, short links, referral credits, email campaigns, and revenue dashboards. The value is in the connections. A campaign can influence checkout, the resulting order can retain attribution, and the admin surface can compare channels without a separate analytics glue project.

Makerkit provides the stronger B2B application base, but founders should verify whether their required acquisition-to-revenue workflow exists or must be assembled. “Stripe included” does not mean campaign attribution or operational reporting is included. See the alternatives directory for other starter shapes if neither emphasis fits.

Edge-native TanStack ownership

TanStack Ship is designed around Cloudflare Workers rather than treating the runtime as a secondary deployment target. That affects dependency selection, request context, storage, asynchronous work, and observability. The benefit is architectural predictability for teams committed to Cloudflare, not a guarantee that every request is faster.

I will not publish a universal latency winner. Geography, database placement, cache state, plan, and route code dominate results. Run the same user journey against production-like deployments instead.

#!/usr/bin/env bash
set -euo pipefail

for base in "$MAKERKIT_PREVIEW_URL" "$TANSTACK_SHIP_PREVIEW_URL"; do
  echo "Testing $base"
  for path in / /sign-in /dashboard; do
    curl --silent --output /dev/null \
      --write-out "$path status=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n" \
      "$base$path"
  done
done

Run warm and cold samples from regions that resemble your customers, retain raw output, and compare equivalent routes. Do not reuse someone else’s homepage Lighthouse score as proof of authenticated dashboard performance.

Compare implementation work, not checkbox count

Before evaluating either starter, I turn requirements into weighted, testable statements. A weight reflects business harm if the requirement is missing; the score reflects what the prototype proves, not what a landing page implies.

type Requirement = {
  name: string
  weight: 1 | 2 | 3 | 4 | 5
  makerkit: 0 | 1 | 2
  tanstackShip: 0 | 1 | 2
}

const requirements: Requirement[] = [
  { name: 'workspace isolation', weight: 5, makerkit: 2, tanstackShip: 1 },
  { name: 'UTM revenue attribution', weight: 4, makerkit: 0, tanstackShip: 2 },
  { name: 'Cloudflare-native jobs', weight: 3, makerkit: 0, tanstackShip: 2 },
]

const total = (key: 'makerkit' | 'tanstackShip') =>
  requirements.reduce((sum, item) => sum + item.weight * item[key], 0)

console.table({ makerkit: total('makerkit'), tanstackShip: total('tanstackShip') })

Replace these example requirements and provisional scores with your own evidence. Add migration effort, provider constraints, license terms, support expectations, and the features you must delete. Deletion matters: unused enterprise abstractions can slow a solo product just as missing tenancy can endanger B2B data.

Prototype one vertical slice

Build signup, account creation, invitation, billing, and one protected resource in each candidate. Then add the operation you will perform weekly: perhaps changing a member role for B2B, or tracing a paid campaign to revenue for a consumer subscription. Record setup friction, code touched, failed tests, and unanswered questions.

Three days gave me enough evidence to understand Makerkit’s model, not enough to certify every production scenario. Readers should treat this article as a decision framework and use current vendor documentation as the authority.

Honest limitations and ongoing cost

TanStack Ship’s weaker multi-tenant depth is a present limitation. Do not buy it on the assumption that roadmap items already exist. It also asks teams to understand TanStack Start and Cloudflare primitives. That learning has value only if the resulting architecture matches the product.

Makerkit may include B2B depth you do not need, and your operational growth stack may still require custom work. Its framework and provider choices should be evaluated against your team, not described as lock-in merely because they differ from mine. Pricing and license terms are volatile, so I intentionally do not freeze a price table here; verify both TanStack Ship pricing and Makerkit’s current purchase page on decision day.

Support quality is similarly hard to reduce to a badge. Submit one real technical question during evaluation and judge the answer. A starter’s long-term value includes updates, migration notes, and how clearly maintainers disclose breaking changes.

Decision tree

Choose Makerkit when the account hierarchy is the product’s hardest invariant; multiple users collaborate inside customer workspaces; per-account roles and billing are immediate requirements; your team prefers its documented stack; or enterprise-shaped onboarding matters more than built-in acquisition tooling.

Choose TanStack Ship when you are solo or a small technical team; TanStack Start and Cloudflare Workers are deliberate choices; the product is primarily subscription-led rather than organization-led; and attribution, campaigns, referrals, credits, email, and revenue operations would otherwise consume your next development cycle.

Choose neither yet when the business model is still unclear. A small framework-native prototype may reveal that you need a marketplace, usage billing, on-premise deployment, or another constraint that neither starter owns deeply.

Final recommendation

Makerkit is the better B2B multi-tenant starting point in this comparison. TanStack Ship is the better fit for the edge-native solo or small-team subscription SaaS it was built to serve. That conclusion respects both products because it is tied to audience and system risk, not a claim that one codebase wins every row.

Write your five non-negotiable requirements, prototype the riskiest vertical slice, and price the missing work at your own engineering rate. The cheaper license can be the expensive choice if it omits your core invariant; the deeper package can be waste if its depth points in the wrong direction.

If the second profile matches your product, start with TanStack Ship’s free tier, inspect the features, and validate the architecture before choosing a paid package on pricing.