Das Problem mit Boilerplates, die alles mitliefern
Die meisten SaaS-Boilerplates liefern die Marketing-Site zusammen mit dem Produktcode aus. Das Versprechen klingt vernünftig: „Du bekommst alles — Landing Pages, Preistabellen, Blog, Dashboard. Lösch einfach, was du nicht brauchst."
Das Problem: Niemand weiß, was man bedenkenlos löschen kann.
Marketing-Komponenten importieren geteilte Utilities. Geteilte Utilities werden von Dashboard-Komponenten verwendet. CSS-Klassen, die für Landing-Page-Animationen definiert wurden, könnten in der Tailwind-Konfiguration referenziert sein, auf die dein Produkt angewiesen ist. Nach einer Stunde, in der du Imports nachverfolgst und Löschungen testest, fragst du dich langsam, ob das Entfernen des Marketing-Codes irgendwo in Production etwas kaputt macht — und ob du es erst dann merkst, wenn ein Kunde sich meldet.
Das ist keine theoretische Überlegung. Jede Stunde, die ein Kunde damit verbringt, Code zu prüfen, den er gar nicht angefordert hat, ist eine Stunde, in der er nicht an seinem eigentlichen Produkt arbeitet. Und diese Bereinigungssteuer potenziert sich — bei jedem Dependency-Update, jedem Refactoring, jeder Onboarding-Session für neue Teammitglieder muss man sich durch Code navigieren, der eigentlich „einfach zu löschen" sein sollte.
Wir haben entschieden: Das ist kein sinnvoller Standard.
Unsere Trennungsstrategie
nextsaas.ai verwendet eine Monorepo-Architektur mit Turborepo und pnpm workspaces. Produkt und Marketing-Site leben in vollständig getrennten Applikationen:
| Aspekt | Typische Boilerplate | nextsaas.ai Ansatz |
|---|---|---|
| Struktur | Eine App mit allem | apps/boilerplate/ + apps/marketing/ |
| Dependencies | Geteilt, oft verflochten | Scoped pro Applikation |
| Build | Ein Build, ein Bundle | Unabhängige Builds, parallele Ausführung |
| Komponenten-Leakage | Marketing-Komponenten überall importierbar | Durchgesetzte Scope-Grenzen |
| Bereinigung für Kunden | Stunden manueller Löscharbeit | Keine — sie erhalten nur das Produkt |
| Dev-Server | Ein Port, alles lädt | Separate Ports, starte nur, was du brauchst |
Der entscheidende Punkt ist: Trennung geht nicht nur um Dateiorganisation. Es geht um Dependency-Isolation. Wenn Marketing und Produkt separate Applikationen mit eigenen package.json-Dateien, eigenen Build-Konfigurationen und eigenen Deployment-Targets sind, kann Marketing-Code nicht versehentlich zur Abhängigkeit des Produkts werden.
Scoped Packages in der Praxis
Geteilter Code zwischen den beiden Applikationen läuft über explizit gescopte Packages. Die UI-Komponentenbibliothek verwendet ein Scope-System, das steuert, welche Komponenten für welche Applikation verfügbar sind:
@nextsaasai/ui/boilerplateexportiert Komponenten, die für das Produkt-Dashboard gedacht sind — Datentabellen, Formularlayouts, Settings-Panels.@nextsaasai/ui/marketingexportiert Komponenten, die für die Marketing-Site gedacht sind — Hero-Sections, Feature-Grids, Testimonial-Cards.@nextsaasai/ui/sharedexportiert Komponenten, die wirklich applikationsübergreifend sind — Buttons, Badges, Tooltips, Theme-Primitives.
Die Hürde für „shared" ist bewusst hoch angesetzt. Eine Komponente landet erst dann im Shared-Scope, wenn beide Applikationen tatsächlich dieselbe Implementierung benötigen. Im Zweifel duplizieren wir lieber, als zu teilen — denn eine falsche Abhängigkeit zwischen Marketing und Produkt ist schlimmer als ein paar Zeilen doppelter Code.
Das wird auf Import-Ebene durchgesetzt. apps/boilerplate/ kann nicht aus @nextsaasai/ui/marketing importieren, und apps/marketing/ kann nicht aus @nextsaasai/ui/boilerplate importieren. Die Grenze ist strukturell, keine bloße Konvention, die jemand in einer langen Nacht versehentlich verletzen könnte.
Die Delivery-Pipeline
Wenn ein Kunde das nextsaas.ai Kit erhält, bekommt er einen sauberen Monorepo-Workspace. Die Delivery-Pipeline entfernt automatisch Marketing-spezifische Applikationen und Konfigurationen, während die vollständige Workspace-Struktur erhalten bleibt, auf die das Produkt angewiesen ist.
Das bedeutet: Kunden starten mit einem Workspace, der ihr Produkt enthält, die benötigten Shared Packages — und nichts weiter. Keine übrig gebliebenen Marketing-Routes, die ihr Routing verwirren. Keine ungenutzten Marketing-Dependencies, die node_modules aufblähen. Kein Marketing-CSS, das mit den Produkt-Styles konkurriert.
Die Delivery-Pipeline führt automatisierte Checks durch, um sicherzustellen, dass das Kunden-Package unabhängig baut, alle Tests bestehen und keine Referenzen auf entfernten Marketing-Code übrig bleiben. Ein Kunde sollte unmittelbar nach dem Erhalt seines Packages pnpm install und pnpm dev ausführen können — ohne jeden Bereinigungsschritt.
Was saubere Architektur ermöglicht
Die Architekturgrenze zwischen Marketing und Produkt ist nicht nur eine Frage der Code-Sauberkeit. Sie ist eine Form des Respekts gegenüber der Zeit und Aufmerksamkeit des Kunden.
Wenn ein Entwickler beginnt, auf einer Boilerplate zu bauen, prägt die erste Erfahrung sein Vertrauen in die gesamte Codebase. Wenn diese erste Erfahrung darin besteht, herauszufinden, welche Dateien gelöscht werden müssen und welche nicht, lautet die implizite Botschaft: „Wir haben das zuerst für uns selbst gebaut und es im zweiten Schritt für dich angepasst." Wenn die erste Erfahrung ein sauberer Workspace ist, in dem jede Datei für die eigenen Ziele relevant ist, ist die implizite Botschaft eine andere: „Wir haben das für dich gebaut."
Diese Trennung ermöglicht auch etwas Praktisches, das mit wachsendem Projekt an Bedeutung gewinnt. Marketing kann neue Landing Pages, Blogbeiträge und Dokumentationsupdates veröffentlichen, ohne das Produkt zu berühren. Das Produkt kann neue Features, Security-Patches und Dependency-Upgrades erhalten, ohne dass Marketing betroffen ist. Unabhängige Release-Zyklen bedeuten schnellere Iteration und weniger Risiko auf beiden Seiten.
Architekturentscheidungen sind Produktentscheidungen. Die Art, wie du Code organisierst, kommuniziert, was dir wichtig ist. Wir haben uns entschieden, die Erfahrung des Kunden ab dem ersten pnpm install in den Vordergrund zu stellen.