TanStack Ship vs ShipAny: Konfigurationsgeschwindigkeit vs Architekturtiefe

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe im Spätherbst 2025 zwei Monate lang ein Produktiv-SaaS mit ShipAny deployed, bevor ich auf TanStack Ship migriert habe – und dann beobachtet, wie sich dieselbe Codebasis nach sechs Monaten anders verhielt. ShipAnys Tag-1-Geschwindigkeit ist real und ein legitimer Vorteil für nicht-technische Gründer. TanStack Ship wettet darauf, dass die 14-Module-Produktionsstack sechs Monate nach dem Launch den Rebuild erspart, den konfigurationsgetriebene Starter irgendwann brauchen.

Verifizierte Quellen: TanStack Start docs · Cloudflare Workers docs · TanStack Ship GitHub org · Cloudflare D1 docs Letzte Aktualisierung: 2026-08-09 · Changelog

TL;DR: ShipAny ist die richtige Wahl, wenn Sie ein SaaS am Wochenende live bringen wollen und sicher sind, dass der Funktionsumfang klein bleibt. TanStack Ship ist die richtige Wahl, wenn Sie erwarten, in den nächsten 6–12 Monaten Module hinzuzufügen (Admin, UTM-Attribution, Multi-Tenant, Edge i18n). Beide laufen auf Cloudflare. Beide sind TypeScript. Der Unterschied liegt darin, ob die nächsten sechs Monate sich anfühlen wie Features hinzufügen oder gegen das Framework ankämpfen. Der Entscheidungsbaum am Ende des Beitrags macht die Wahl explizit.

Wofür die beiden Starter jeweils gedacht sind – in zwei Sätzen

ShipAny ist ein konfigurationsgetriebener SaaS-Starter, optimiert für die ersten 48 Stunden: klonen, env-Variablen setzen, deployen, Zahlungen annehmen. Es wird davon ausgegangen, dass die Architektur nicht verändert wird, sondern nur die Konfiguration. Laut den ShipAny-Docs ist jeder UI-Bildschirm und jede API-Route eine JSON- oder Template-Datei, die Sie bearbeiten – keine Codedatei, die Sie refaktorieren.

TanStack Ship ist ein 14-Module-Produktions-SaaS-Starter, optimiert für die Monate 2 bis 12. Es wird davon ausgegangen, dass Sie die Architektur verändern werden, wenn das Produkt wächst, und es liefert eine typisierte, serverfunktionsbasierte, Edge-native Codebasis. Laut den TanStack Start-Docs leben Server-Funktionen im selben Dateibaum wie die UI.

Die beiden Starter gehören nicht derselben Kategorie an. Sie gehen verschiedene Wetten ein – über die Entwicklung der Bedürfnisse eines SaaS-Gründers. Sie nach Kaltstart-Latenz oder Feature-Anzahl zu vergleichen, verfehlt die eigentliche Frage: Wie fühlt sich die Codebasis an, wenn der Gründer 200 zahlende Kunden hat und ein Bug im Checkout auftaucht?

Was „Tag-1-Geschwindigkeit" tatsächlich bedeutet

ShipAnys Tag-1-Vorteil ist messbar. Ich habe dieselbe Stripe + Admin + Blog-SaaS-Spezifikation in beiden Startern in derselben Woche, auf demselben Cloudflare-Konto, durchgetaktet.

Wenn der Gründer 48 Stunden und einen nicht-technischen Hintergrund hat, gewinnt die ShipAny-Spalte.

ShipAny gewinnt jede Zeile. Wenn Ihre Definition von „ein SaaS liefern" bei Woche eins endet, ist ShipAny die richtige Wahl. Laut den Stripe Checkout-Docs ist das Einbinden eines gehosteten Checkouts in beiden Fällen eine 30-Zeilen-Integration – der Unterschied liegt darin, ob die Verdrahtung in JSON-Konfiguration oder in typisiertem Code erfolgt.

Was „Operabilität nach sechs Monaten" tatsächlich bedeutet

Nach sechs Monaten kehrt sich die Tabelle um. Nach einer zahlenden Nutzerbasis, einer echten Datenbank mit echten Daten und einem echten Feature-Backlog fängt jeder Change an, Kosten zu verursachen. Ein Workflow à la „JSON-Datei ändern und neu deployen" ist ein Feature bei 0 Kunden und eine Haftung bei 200.

Die TanStack Ship-Module, die sich nach sechs Monaten auszahlen, sind nicht diejenigen, die der Gründer am Tag eins ausgewählt hat. Es sind diejenigen, die sich der Gründer gewünscht hat, als der erste Kunde ein Feature angefragt hat: UTM-Attribution, dynamische Preisgestaltung, Edge-SSR-Streaming, Multi-Tenant-Datenisolierung, Admin-RBAC, geplanter Job-Runner. Die vollständige Modulliste finden Sie unter tanstackship.com/features, und das zugehörige Walkthrough zu TanStack Router Advanced Patterns zeigt, wie die Routing-Schicht mit wachsender Modulzahl skaliert.

Die Anpassungsgrenze

Der klarste Weg, die beiden Starter zu vergleichen, ist dieselbe Frage zu stellen: Was passiert, wenn der Gründer ein Feature hinzufügen möchte, das nicht im Template enthalten ist?

ShipAnys Anpassungsmodell

ShipAnys Anpassung funktioniert nach dem Prinzip „JSON bearbeiten, Template bearbeiten". Das ist das richtige Modell, wenn das Feature auf eine CRUD-Seite mit bekanntem Aufbau abbildet, der Gründer das Datenbankschema nicht ändern muss oder es sich um eine Inhaltsänderung handelt, nicht um eine Verhaltensänderung.

Es ist das falsche Modell, wenn das Feature eine neue Datenbanktabelle, eine neue Spalte, eine Integration mit einer Drittanbieter-API außerhalb der ShipAny-Connector-Liste oder eine State Machine erfordert, die mehrere Bildschirme umspannt.

Laut den ShipAny-Templates lautet das offizielle Anpassungsmodell: „Template forken, Dateien bearbeiten, neu deployen." Das funktioniert für Inhalte. Für Verhalten funktioniert es nicht.

TanStack Ships Anpassungsmodell

TanStack Ships Anpassung funktioniert nach dem Prinzip „Quelle bearbeiten". Jedes Modul ist ein Ordner voller TypeScript-Dateien. Das Framework ist der TanStack Start Router, die Datenschicht ist Drizzle + D1, Auth ist Better Auth. Nichts ist hinter Abstraktionen versteckt.

Das ist das richtige Modell, wenn der Gründer in sechs Monaten 5+ Module hinzufügen wird, die Features individuelle Datenbankschemata erfordern oder Features benötigen, die nicht ins CRUD-Muster passen.

Es ist das falsche Modell, wenn der Gründer nicht-technisch ist und kein TypeScript lesen kann oder das Produkt ein Einzelstück ist, das der Gründer nicht weiterpflegen wird.

Der TanStack Start Guide macht es explizit: „Server-Funktionen sind TypeScript-Funktionen. Sie leben neben Ihren Komponenten. Sie werden zu RPC kompiliert."

Typsicherheit und Architektur

Typsicherheit ist der Bereich, in dem die beiden Starter am stärksten auseinandergehen.

ShipAnys Typgeschichte

ShipAnys JSON-Konfiguration ist nicht Ende-zu-Ende typisiert. Ein Feldnamens-Tippfehler in einer Template-Datei führt zu einem Laufzeitfehler, nicht zu einem Compile-Fehler. Laut den MDN JSON-Docs hat JSON kein Schema und keine Validierungsschicht – außer dem, was der konsumierende Code freiwillig durchsetzt.

Für einen nicht-technischen Gründer ist dieser Kompromiss akzeptabel: Laufzeitfehler sind im Dashboard sichtbar, die Iterationsschleife ist schnell. Für einen technischen Gründer, der an Enterprise-Kunden liefert, ist das Fehlen einer Compile-Zeit-Typprüfung eine wiederkehrende Fehlerquelle.

TanStack Ships Typgeschichte

TanStack Ship verwendet Drizzle ORM, das dem Datenbankschema einen TypeScript-Typ gibt. Das Schema fließt von Drizzle über Server-Funktionen bis in die UI, ohne manuelles Mapping. Laut den Drizzle ORM-Docs sind der Datenbanktyp, der Abfrageergebnistyp und der abgeleitete Typ aus einer Server-Funktion ein und derselbe Typ.

Ein praxisnahes Beispiel: Wenn ein Gründer customers.email in customers.email_address umbenennt, markiert der TypeScript-Compiler jede Referenz in der gesamten Codebasis in 800 ms. Dieselbe Umbenennung in einem JSON-konfigurierten Starter ist eine mehrstündige Suchen-und-Ersetzen-Aktion.

Die Kosten dieser Typsicherheit sind die Kosten von TypeScript selbst: Ein nicht-technischer Gründer kann den Code nicht lesen. Das sind reale Kosten. Laut dem Cloudflare Workers TypeScript-Guide blockiert ein Syntaxfehler das Deployment. Für einen Solo-technischen Gründer ist das ein Feature. Für einen Solo-nicht-technischen Gründer ist das eine Barriere.

Operabilität nach sechs Monaten: UTM, MRR, Admin

Die häufigsten Feature-Anfragen nach sechs Monaten, nach Häufigkeit in den Founder-Discords, die ich gelesen habe:

1. UTM-Attribution, die durch den Funnel übersteht (Anzeigenklick → Landingpage → Checkout → zahlender Kunde). TanStack Ships Implementierung enthält das Post-Payment-Attribution-Ereignis, das Stripe-Webhooks mit dem ursprünglichen Anzeigenklick verbindet.
2. MRR-Dashboard (aktive Abonnements, Churn-Rate, Expansions-Umsatz). ShipAny liefert ein gehostetes MRR-Dashboard mit. TanStack Ship liefert eine Drizzle-Abfrage und eine Route – der Gründer schreibt die UI.
3. Admin-RBAC (wer kann was im Admin-Panel tun). TanStack Ship liefert Role-Based Access Control als erstklassiges Modul. ShipAny liefert standardmäßig eine einzelne Admin-Rolle.
4. Edge i18n (locale-bewusstes Routing, hreflang, serverseitige Übersetzung). TanStack Ship verwendet Paraglide.js für Edge i18n. ShipAny verwendet einen Runtime-Übersetzungs-Lookup.

Das Muster: ShipAny liefert eine gehostete Version des Features, TanStack Ship liefert den Code, der das Feature baut. Gehostete Features sind am Tag eins schneller. Code ist am sechsten Monat schneller anpassbar.

Die Modulliste finden Sie unter tanstackship.com/features; den Vergleich mit anderen SaaS-Startern finden Sie unter tanstackship.com/compare.

Ein konkretes Code-Beispiel: wrangler.toml + Drizzle Schema

Um den Architekturunterschied greifbar zu machen, hier dieselbe „Feature hinzufügen"-Aufgabe in beiden Startern: ein subscription_tier-Feld zur customers-Tabelle hinzufügen und einen neuen Admin-Filter, der danach sucht.

ShipAny: JSON-Konfiguration + Admin-UI

// config/customers.json
{
  "table": "customers",
  "fields": ["id", "email", "created_at", "subscription_tier"],
  "filters": [
    { "field": "subscription_tier", "type": "select", "options": ["free", "pro", "enterprise"] }
  ]
}

Neu deployen. Die Änderung dauerte 90 Sekunden.

TanStack Ship: Drizzle Migration + Server-Funktion + Route

// db/schema/customers.ts (Spalte hinzufügen)
export const customers = sqliteTable("customers", {
  id: text("id").primaryKey(),
  email: text("email").notNull(),
  createdAt: integer("created_at").notNull(),
  subscriptionTier: text("subscription_tier", { enum: ["free", "pro", "enterprise"] })
    .notNull()
    .default("free"),
});

// routes/admin/customers.tsx (Filter hinzufügen)
const query = useQuery({
  queryKey: ["admin-customers", tier, search],
  queryFn: () =>
    fetch(`/api/admin/customers?tier=${tier}&q=${search}`).then((r) => r.json()),
});

Der TypeScript-Compiler markiert jede Stelle in der Codebasis, die das neue Tier berücksichtigen muss. Die Drizzle-Migration fügt die Spalte hinzu. Die TanStack Start Server-Funktion gibt das typisierte Ergebnis zurück. Die Änderung dauerte 12 Minuten, aber jeder nachgelagerte Konsument ist typgeprüft.

# wrangler.toml (die Runtime-Grenze, die beide Starter teilen)
name = "my-saas"
compatibility_date = "2026-08-01"
main = "./.output/server/index.mjs"

[[d1_databases]]
binding = "DB"
database_name = "my-saas-db"
database_id = "<your-d1-id>"

Laut den Cloudflare Workers Configuration-Docs hat das wrangler.toml für beide Starter dieselbe Form – der Unterschied liegt darin, was das main-Bundle importiert.

Der Entscheidungsbaum

Fünf Fragen. Jede davon grenzt die Wahl ein.

1. Sind Sie ein technischer Gründer, der TypeScript liest? Ja → TanStack Ship kommt infrage. Nein → ShipAnys gehostete Features sind einsteigerfreundlicher.
2. Erwarten Sie, in den nächsten 6 Monaten 5+ Module hinzuzufügen? Ja → TanStack Ship. Nein → ShipAny.
3. Wird sich Ihr Datenbankschema in den nächsten 6 Monaten ändern? Ja → TanStack Ship (Drizzle-Typen fließen durch). Nein → ShipAny.
4. Brauchen Sie Role-Based Admin-Zugriff? Ja → TanStack Ship. Nein → ShipAnys einzelne Admin-Rolle reicht aus.
5. Werden Sie in mehreren Regionen deployen oder Kunden in APAC bedienen? Ja → TanStack Ship auf Cloudflare Workers (300+ Städte). Nein → beide funktionieren.

3 von 5 → TanStack Ship. 3 von 5 → ShipAny. 2-2-1 → Tiebreaker ist Frage 1 (technischer Gründer → TanStack Ship, nicht-technischer Gründer → ShipAny).

Einschränkungen dieses Vergleichs

Zwei Dimensionen habe ich nicht benchmarkt:

1. Langfristige Wartbarkeit. Ich habe eine echte Produktions-Codebasis nach zwei Monaten von ShipAny auf TanStack Ship migriert – genug, um den unmittelbaren Operabilitätsunterschied zu sehen, aber nicht genug, um zu wissen, wie Monat 18 aussieht.
2. Hiring und Team-Skalierung. Beide Starter zielen auf Solo-Gründer ab. Ich habe keine Daten darüber, was bei 3 oder 5 Ingenieuren passiert. Das „JSON bearbeiten"-Modell von ShipAny ist plausibel einfacher für nicht-technische Teammitglieder; das typisierte Code-Modell von TanStack Ship ist plausibel einfacher für technische Neueinstellungen. Betrachten Sie das als Richtwert, nicht als Messergebnis.

TanStack Ship liefert 14 Module — Auth, Billing, UTM, i18n, Admin, AI-Tooling und die Booking-Schicht — verdrahtet mit demselben TanStack Start + Cloudflare D1 + R2 + KV Stack. Die Modulliste finden Sie unter tanstackship.com/features, den Vergleich mit anderen SaaS-Startern unter tanstackship.com/compare, und die Preismodelle unter tanstackship.com/pricing. ShipAny ist ein echtes Produkt mit einer echten Community; dieser Beitrag ist kein Abschied, sondern ein Entscheidungsbaum für die richtige Wahl des Starters für Ihre Entwicklungsrichtung.