Produktarbeit von wiederholter Infrastruktur trennen
Liste die Funktionen, die dein Produkt nützlich machen, dann die Infrastruktur, die es zum Laufen braucht. Ein Recherche-Workflow kann besonders sein; Session-Handling, kundeneigene Datensätze und Abo-Zugang sind es meist nicht. Dieses Inventar ist ein besseres Bewertungswerkzeug als das Zählen der Funktionen auf der Seite eines Starters.
Die zweite Liste ist länger, als sie aussieht. Die meisten SaaS-Produkte implementieren dasselbe Dutzend Bausteine neu, und jeder muss korrekt mit den anderen zusammenspielen, bevor das Produkt überhaupt etwas kann.
Von Grund auf zu bauen gibt direkte Kontrolle über diese Entscheidungen, aber auch die Verantwortung, sie zu integrieren und zu warten. Ein Starter ändert den Ausgangspunkt. Du musst seinen Code trotzdem verstehen und die Annahmen prüfen, die er über dein Produkt, dein Team und dein Deployment trifft.
- Identität: Anmeldemethoden, Sessions, Kontowiederherstellung.
- Workspaces: Datensatz-Besitz, Einladungen, Mitgliederrollen.
- Abrechnung: Checkout, Webhooks, Berechtigungen, Kündigung.
- Hintergrundarbeit: Queues, Retries, Zeitpläne, Statusverfolgung.
- Zustellung: Transaktions-E-Mail, Dateispeicher, Deployment.
Gesamtkosten vergleichen, nicht den Preis auf dem Etikett
Der Preis eines Starters ist sichtbar; die Kosten des Selbstbaus verteilen sich über Monate. Rechne sie ehrlich zusammen: die Wochen, die das Montieren von Auth, Billing, Jobs und Deployment kostet; die Integrationsbugs, mit denen diese Zusammenbauten ausgeliefert werden; und die Wartung, die jedes Anbieter-Update danach auslöst.
Die Kosten des Starters sind das Lernen und Anpassen von Code, den du nicht geschrieben hast: seine Konventionen lesen, Beispielinhalte ersetzen, gelegentlich eine gezogene Grenze biegen. Läuft die unten beschriebene Inspektion gut, ist dieser Tausch meist billiger als derselbe Neuaufbau der Rohrleitungen. Läuft sie schlecht, ist sie eine Warnung, die du nicht ignorieren solltest — eine unlesbare Grenze heute ist ein Produktionsvorfall nächstes Jahr.
Den Code bewerten, den du erben wirst
Führe die Installationsanleitung aus und folge einem Datensatz von der Oberfläche zur Persistenz. Prüfe, ob Autorisierung an der Server-Grenze liegt, ob Konfiguration validiert wird und ob Anbieter-Zugangsdaten außerhalb von Client-Bundles bleiben. Lies einen negativen Test, nicht nur den Demo-Bildschirm.
Suche nach Stellen, an denen das Beispielprodukt untrennbar mit der Infrastruktur verwoben ist. Wenn das Entfernen einer Demo-Funktion Auth- oder Abrechnungsverhalten verändert, wird künftige Produktarbeit schwerer, als die Erstinstallation vermuten lässt. In supastack halten Consumer-Produkte ihre Domänenlogik aus Starter Core heraus und verbinden sich über Konfiguration und Verträge — der Projektstruktur-Guide zeigt, wo diese Linie verläuft.
- Jeder undokumentierte Setup-Schritt, den du selbst herausfinden musstest.
- Wo Autorisierung durchgesetzt wird und ob sie pro Route oder systematisch ist.
- Ob ein negativer Test existiert — ein workspaceübergreifender Read, ein erneut abgespielter Webhook — und was er beweist.
- Wo Geheimnisse liegen und ob welche ein Client-Bundle erreichen.
- Was mit der Infrastruktur passiert, wenn du versuchst, ein Demo-Feature zu löschen.
Lass es laufen, bevor du dich entscheidest
Verbringe einen Tag im Repository, bevor du dich festlegst. In supastack heißt das corepack pnpm install, ein konfiguriertes apps/web/.env.local und der lokale Referenzablauf: anmelden, Zugang prüfen, einen Task einreichen, sein Ergebnis lesen. Danach führt pnpm verify:local den Golden Path gegen Fake-Anbieter ganz ohne Zugangsdaten aus — der lokale Setup-Guide führt durch die Schritte.
Dann bring absichtlich etwas zum Scheitern. Reiche denselben Task zweimal ein. Rufe eine API-Route mit dem falschen Workspace auf. Spiele einen Webhook erneut ab. Ein Starter, der gewöhnliche Fehler elegant abfängt, ist mehr wert als einer mit einer längeren Feature-Liste — denn was du auf deiner Maschine nicht sauber scheitern lassen kannst, debuggst du irgendwann in Produktion.
Den Trade-off explizit machen
Wähle einen Starter, wenn seine vorhandenen Grenzen zu deinem Bedarf passen und du den Flow erklären kannst, auf den du dich verlassen wirst. Wähle eine maßgeschneiderte Basis, wenn Produktanforderungen wiederholte Änderungen an den Annahmen des Starters erzwingen würden. Beide Entscheidungen können vernünftig sein; die wichtige Frage ist, welche Wartungslast dein Team tragen kann.
Plane Zeit ein, um Beispielinhalte zu ersetzen, Integrationen zu konfigurieren, Dateneigentum zu prüfen und das Deployment zu testen. Ein Repo, das kompiliert, ist ein Ausgangspunkt für Produktions-Akzeptanz. Verifiziere vor dem Launch den echten Login-Pfad, den Abrechnungs-Lifecycle und das Wiederherstellungsverhalten in der Umgebung, die deine Kunden nutzen werden — die Launch-Checkliste zählt sie auf. Und ist der zugrunde liegende Stack ebenfalls unentschieden, deckt die Wahl eines SaaS-Stacks die schichtweise Bewertung ab — die beiden Entscheidungen beeinflussen sich gegenseitig.
| Von Grund auf bauen | Ein Starter-Kit übernehmen | |
|---|---|---|
| Dir gehört | Jede Konvention, Integration und jeder Fehlermodus | Der Produktcode; die Rohrleitungen kommen gewartet |
| Anfangstempo | Langsam — erst kommen die Rohrleitungen | Schnell — Features starten ab Tag eins |
| Das Risiko liegt in | Übergängen, die du noch nicht gefunden hast | Grenzen, die du noch nicht inspiziert hast |
| Richtige Wahl, wenn | deine Anforderungen typische Annahmen brechen | seine Grenzen zu den Bedürfnissen deines Produkts passen |
Häufige Fragen zu Starter-Kits
Die Kaufen-oder-selbst-bauen-Debatte erzeugt starke Meinungen. Dies sind die Fragen, die die Entscheidung wirklich bewegen.
- Ist ein Starter-Kit riskant für ein ernsthaftes Produkt? — Viele produktive SaaS laufen auf gekauften Fundamenten. Das Risiko ist nicht der Starter, sondern Code zu erben, den du nicht inspiziert hast. Lies die Grenzen, bevor du dich auf sie verlässt.
- Worauf erkenne ich, ob ein Boilerplate gewartet wird? — Achte auf aktuelle Commits, einen dokumentierten Update-Pfad, Tests, die Fehlerfälle ausüben, und Issues, die konkret statt mit Roadmap-Versprechen beantwortet werden.
- Was, wenn die Entscheidungen des Starters nicht meinen entsprechen? — Unterscheide Vorlieben von Anforderungen. Ein UI neu zu gestalten ist billig; gegen ein Session-Modell oder eine Mandantengrenze zu kämpfen nicht. Ein struktureller Mismatch ist ein Grund, selbst zu bauen.
- Kann ich später von einem Starter weg? — Dir gehört der Code, es gibt also nichts, wovon man wegmigrieren müsste — die eigentliche Frage ist, ob seine Rohrleitungen ein Vorteil bleiben, während du sie veränderst. Genau darum zählt trennbarer Produkt- und Infrastrukturcode.
- Wie viel Zeit spart ein Starter wirklich? — In etwa die Wochen, die Auth, Billing, Jobs und Deployment gekostet hätten, abzüglich der Tage, die du brauchst, um das Geerbte zu verstehen und anzupassen.