Um Produktanforderungen herum wählen
Notiere, was das Produkt braucht, bevor du Framework-Namen vergleichst. Ein Web-Dashboard, ein Offline-Mobile-Tool und ein lang laufender Recherche-Workflow haben unterschiedliche Anforderungen. Entscheide, welche Clients du bedienst, welche Daten jedem Kunden gehören und welche Operationen weiterlaufen müssen, nachdem ein Tab geschlossen wird.
Wäge die Erfahrung deines Teams neben Feature-Listen ab. Ein vertrauter Stack mit klaren Grenzen kann leichter zu warten sein als eine neuere Kombination, die Auth, Deployment und Persistenz-Konventionen gleichzeitig lernen muss. Zähle die laufende Arbeit von Upgrades und Debugging, nicht nur die erste Installation.
- Welche Client-Oberflächen du ab Tag eins brauchst — nur Web oder auch Mobile und Desktop.
- Welche Daten jedem Kunden gehören und ob Teams Workspaces teilen.
- Welche Vorgänge einen Browser-Tab überleben müssen: eingereihte Jobs, geplante Arbeit, lang laufende Tasks.
- Wofür du abrechnen wirst — Abos, Sitze, Nutzung — und wer dafür zahlt.
- Wie viel Betriebsfläche dein Team realistisch betreiben kann: Datenbanken, Queues, Anbieter.
Die Schichten unter dem Framework bewerten
Framework-Namen beschreiben die Oberfläche. Die Schichten darunter entscheiden, ob das Produkt zusammenhält. Geh sie eine nach der anderen durch und stell jeder dieselbe Frage: Wem gehört diese Entscheidung, und wo wird sie durchgesetzt?
Behandle jede Schicht, die ein Stack leer lässt, als Arbeit, zu der du dich verpflichtest. „Bring your own auth“ ist ein legitimes Design — es bedeutet nur, dass dir Session-Semantik, Anbieter-Integrationen und jeder folgende Fehlerfall gehören. Leere Schichten sind eine Wahl; unsichtbare Schichten sind ein Risiko. Die Modul-Dokumentation des Kits ist eine nützliche Referenz dafür, wie eine eigene Schicht tatsächlich aussieht.
| Schicht | Die zu beantwortende Frage |
|---|---|
| Identität | Wer stellt Sessions aus und verifiziert sie — auf jeder Oberfläche? |
| Daten | Wie wird jeder Datensatz auf seinen besitzenden Kunden begrenzt? |
| Abrechnung | Wo wird ein Zahlungsereignis zu Zugang — und wer entzieht ihn? |
| Hintergrundarbeit | Was passiert, wenn ein Job fehlschlägt, wiederholt wird oder doppelt läuft? |
| KI und Anbieter | Wem gehören die Schlüssel, die Modellwahl und das Ausgabenlimit? |
| Betrieb | Wie laufen Geheimnisse, Logs, Backups und Upgrades tatsächlich? |
Die Übergänge zwischen Werkzeugen prüfen
Ein Stack ist eine Reihe von Integrationsentscheidungen. Identifiziere, wem Sessions gehören, wie Datensätze begrenzt werden, wo ein Zahlungsereignis zu einer Berechtigung wird und wie das UI das Ergebnis von Hintergrundarbeit abruft. Diese Verbindungen bestimmen, ob der Happy Path korrekt bleibt, wenn Anfragen fehlschlagen oder doppelt ankommen.
supastack nutzt Next.js für die Web-Oberfläche, Expo für Mobile und geteilte TypeScript-Pakete darunter. Better Auth besitzt Identität, Postgres und Drizzle persistieren Datensätze, und Trigger.dev besitzt explizites Workflow-Verhalten. Das sind Repo-Entscheidungen, keine Behauptung, dass jedes Produkt dieselben Werkzeuge nutzen sollte — der Tech-Stack-Guide hält jede Wahl und ihren Grund fest, und die Fragen übertragen sich, selbst wenn du andere Werkzeuge wählst.
Welche Werkzeuge auch immer — der Test bleibt derselbe: Nimm einen Datensatz und verfolge ihn von der Oberfläche durch die Server-Grenze in die Persistenz und zurück. Ist ein Sprung Konvention statt durchgesetzte Regel, wird ein künftiger Beitragender ihn irgendwann brechen.
Die Kosten des laufenden Betriebs mitzählen
Eine Stack-Entscheidung ist auch eine Betriebsentscheidung. Postgres braucht Backups und Migrationsdisziplin. Ein Job-Runner braucht ein Dashboard, das jemand wirklich öffnet. Jeder Anbieter-Schlüssel braucht Rotation und ein Zuhause außerhalb der Client-Bundles. Nimm diese Positionen in den Vergleich auf, bevor dich die Feature-Checkliste überzeugt.
Prüfe den Upgrade-Pfad, solange du noch Optionen hast. Ein Monorepo mit gepinnten Abhängigkeiten und einem dokumentierten Update-Prozess — das Kit pflegt dafür einen Update-Guide — altert besser als ein Stack aus Tutorials, die jeweils eine andere Version der Welt annehmen.
- Abhängigkeits- und Sicherheits-Updates: wie oft sie ankommen und wer sie einspielt.
- Anbieter-Zugangsdaten: wo sie liegen und wer sie rotieren kann.
- Daten: ein Backup-Plan, eine Restore-Übung und eine Aufbewahrungsrichtlinie.
- Observability: was laut ausfällt und was still versagt, bis ein Kunde es meldet.
Einen kleinen vertikalen Slice bauen
Bevor du dich auf einen Stack festlegst, führe einen Slice aus, der einen Nutzer anmeldet, einen eigenen Datensatz schreibt, Arbeit startet und ein Ergebnis abruft. Probiere dann absichtlich den falschen Workspace, eine abgelaufene Sitzung und einen fehlschlagenden Job. Bewerte, wie viel eigener Kleber diese gewöhnlichen Bedingungen verlangen.
Halte eine kurze Entscheidungsakte: was der Stack unterstützt, was du zurückstellst und was eine Überprüfung auslösen würde. Native Käufe, echte Anbieter-Akzeptanz und Deployment-Betrieb sollten explizite Punkte sein statt versteckter Annahmen hinter einem erfolgreichen lokalen Build. Der richtige Stack lässt dem Team genug Aufmerksamkeit für das Produkt.
Läuft der Slice gut im Repository eines Starters, lautet die Anschlussfrage, ob du ihn übernimmst — Starter-Kit oder von Grund auf geht diese Entscheidung durch.
- Anmelden und die Session nach einem Reload wiederherstellen.
- Einen auf einen Workspace begrenzten Datensatz schreiben und wieder lesen.
- Eine Hintergrundaufgabe starten und ihr Ergebnis später abrufen.
- Dieselben Aufrufe aus dem falschen Workspace und mit abgelaufener Session wiederholen.
Häufige Fragen zur Stack-Wahl
Stack-Entscheidungen ziehen viele selbstsichere Ratschläge an. Dies sind die Fragen, die du stattdessen für dein eigenes Produkt beantworten solltest.
- Soll ich den Stack nehmen, den ich schon kenne? — Meist ja, wenn er die Anforderungen des Produkts ausdrücken kann. Ein vertrauter Stack mit klaren Grenzen schlägt einen modischen, den du monatelang lernst — es sei denn, das Produkt braucht wirklich etwas, das ihm fehlt, etwa natives Mobile.
- Ist das Frontend-Framework am wichtigsten? — Weniger als die Schichten darum herum. Das Framework formt das UI; Identität, Scoping, Abrechnung und Hintergrundarbeit entscheiden, ob das Produkt korrekt bleibt.
- Wie lange sollte eine Stack-Evaluierung dauern? — Tage, nicht Wochen: Anforderungen aufschreiben, Übergänge prüfen, einen vertikalen Slice laufen lassen. Brauchen gewöhnliche Fehler eigenen Kleber, such weiter.
- Wann ist ein späterer Stack-Wechsel gerechtfertigt? — Wenn sich eine zentrale Anforderung ändert — eine Pflichtplattform, eine Skalierungsschwelle —, nicht wenn ein neueres Release hübscher aussieht. Die Wechselkosten stecken in Auth und Daten, nicht in Komponenten.