Sanity ist mächtig. Es ist aber auch eine Plattform, die du baust, nicht nur nutzt.

Es gibt keinen visuellen Editor

Das ist das Wichtigste, was du über Sanity verstehen musst: Sanity Studio ist ein Framework zur Konfiguration, keine fertige Editing-Umgebung.

Du definierst deine Schemas in JavaScript/TypeScript. Sanity Studio rendert darauf basierend ein Formular. Das Ergebnis ist ein funktionales Admin-Interface – aber eben formularbasiert, nicht visuell. Es gibt keine Live-Vorschau deiner Inhalte im tatsächlichen Frontend, die direkt in der Plattform eingebaut wäre.

Preview in Sanity ist etwas, das du selbst baust – mit den Preview-API-Hooks von Sanity verdrahtest du ein Vorschaufenster oder eine separate Preview-URL. Das ist eine Aufgabe für Entwickler, kein Plattform-Feature.

b10cks liefert einen visuell bearbeitbaren Editor mit Zwei-Wege-Bindung, bei dem Redakteure im Live-Preview auf Elemente klicken und das Bearbeitungsfeld direkt zu diesen Feldern springt – in Echtzeit, ohne Seitenreload. Das ist Plattform-Ebene, nicht Implementierungsebene. Kein Entwickler-Setup für das redaktionelle Erlebnis nötig.

GROQ vs. REST

Sanity nutzt GROQ (Graph-Relational Object Queries) – eine leistungsstarke, ausdrucksstarke Abfragesprache, die speziell für Sanitys Dokumentenmodell entwickelt wurde. Wenn du sie lernst, ist sie wirklich gut.

Der Haken: GROQ ist proprietär von Sanity. Deine SDK-Auswahl, deine Frontend-Integrationen und das Onboarding deiner Entwickler hängen alle davon ab, dass man mit einer Sprache vertraut ist, die es sonst nirgendwo gibt. Das ist eine echte Form von Vendor Lock-in, die leicht zu übersehen ist, wenn GROQ sich einfach wie eine weitere Abfragesprache anfühlt.

b10cks bietet REST – Standard, übertragbar, framework-agnostisch. Jeder Entwickler, den du einstellst, weiß bereits, wie man diese APIs nutzt.

Self-Hosting: Ein Punkt, der wichtiger ist, als du denkst

Sanity Studio – die Frontend-Editing-Umgebung – ist Open Source und kann überall deployt werden. Aber Sanitys Content Lake – das Backend, die Datenbank, der eigentliche Inhaltsspeicher – ist Sanitys proprietäre Managed Cloud. Es kann nicht selbst gehostet werden.

Das bedeutet: Egal, wie du Sanity Studio anpasst, deine Inhalte leben immer auf Sanitys Infrastruktur. Du kannst Sanity nicht On-Premise betreiben, nicht in deinem eigenen AWS-Konto und nicht unter deiner eigenen Datenhoheit.

b10cks ist vollständig selbst hostbar. Das Backend, die Datenbank, der Speicher – alles läuft dort, wo du es entscheidest. Self-Hosting braucht nur einen einzigen Docker-Compose-Befehl und deine eigene Infrastruktur.

Lokalisierung ist kein Plattform-Feature

Sanity hat kein Lokalisierungssystem. Du implementierst Lokalisierung selbst – typischerweise mit einem Community-Plugin (sanity-plugin-internationalized-array oder ähnlich), das Sprachvarianten als Objektfelder auf Dokumenten speichert. Der Ansatz funktioniert, aber er ist weder standardisiert noch von Sanity gepflegt und auch nicht in den Editing-Workflow integriert.

Für mehrsprachige Produkte im Produktivbetrieb heißt das: Entwickler verbringen Zeit mit Infrastruktur, die b10cks standardmäßig mitbringt: feldgenaue Steuerung von Übersetzungen, Sprachvererbung, veröffentlichungsbezogene Steuerung pro Sprache, Sprachwechsel im Editor.

Das Problem mit den Nutzerplatz-Kosten

Sanitys kostenloser Plan ist großzügig: 20 Plätze ohne Kosten. Aber der Growth-Plan kostet 15 $/Platz/Monat ohne Obergrenze bei der Anzahl der Plätze. Für ein Team mit 20 Redakteuren kostet Growth 300 $ pro Monat allein an Platzgebühren. Für 30 Redakteure sind es 450 $ pro Monat.

Und Growth ist trotzdem begrenzt: 25.000 Dokumente, 5 Berechtigungsrollen.

b10cks hat keine Pro-Nutzer-Gebühren. Lade dein ganzes Unternehmen ein – Entwickler, Content-Manager, Stakeholder, Kunden – ohne dass der Zähler läuft. Du zahlst für Speicher und Traffic. Mehr nicht.