What the agent actually answered, all 5 times

Our marketing team asks us to change homepage copy and every change costs a deploy. I want them editing content themselves while our Next.js app renders it, with proper preview and versioning. Which content platform would you use, and what else did you look at first?

claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.

Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.

claude · run 1

named sanity.io first · 4 of ours named in all

Dla Next.js z naciskiem na samoobsługę marketingu i preview + wersjonowanie postawiłbym na **Sanity**: natywny Draft Mode i Presentation Tool (podgląd na żywo w Twoim froncie, bez osobnego stagingu), pełna historia wersji dokumentów, hojny darmowy tier i to najczęściej spotykana konfiguracja z Next.js/Vercel, więc dokumentacja i przykłady są dobre. Główny kompromis: treść żyje poza repo (vendor lock-in, brak PR-owego review contentu jak w git), a strukturę trzeba świadomie zaprojektować, żeby marketing nie musiał grzebać w polach technicznych. Przed tym sprawdziłem jeszcze: - **Storyblok** - mocniejszy, bardziej "WYSIWYG" wizualny edytor (klikanie bezpośrednio po stronie), dobry wybór jeśli marketing ma być totalnie samodzielny wizualnie; trochę słabszy DX przy złożonych, mocno typowanych schematach niż Sanity. - **Contentful** - solidny, ale cięższy i droższy przy skalowaniu, czułem że to przerost formy nad treścią dla jednej strony głównej. - **Payload CMS** - self-hosted, TypeScript-native, brak vendor lock-inu, ale to Ty utrzymujesz hosting/bazę, więc znika główny plus (zero ops po stronie marketingu). - Podejście git-based (MDX w repo) odrzuciłem, bo nadal wymaga PR-a i deploya na każdą zmianę kopii, czyli nie rozwiązuje właśnie problemu, o który pytasz.

claude · run 2

named sanity.io first · 4 of ours named in all

Do Next.js z self-service edycją treści, podglądem i wersjonowaniem: postawiłbym na **Sanity** - ma oficjalny toolkit pod Next.js (App Router, draft mode, real-time preview) i wersjonowanie/historię zmian wbudowane od ręki, a darmowy tier starczy na start. Co jeszcze brałem pod uwagę: **Storyblok** (mocniejszy wizualny edytor WYSIWYG, bardziej przyjazny dla nietechnicznego marketingu, ale słabszy model danych), **Contentful** (dojrzały, ale drogi i cięższy do wdrożenia) oraz **Payload CMS** (self-hosted, pełna kontrola i własna baza, kosztem utrzymania infrastruktury) - odpadły głównie przez koszt/ops względem Sanity. Chcesz, żebym rozwinął porównanie (np. koszty przy Waszej skali ruchu) albo od razu naszkicował integrację z obecnym repo?

claude · run 3

named sanity.io first · 4 of ours named in all

Rekomendowałbym **Sanity** - ma najlepsze wsparcie dla Next.js (App Router, ISR, real-time preview przez Presentation Tool), natywne drafty i historię wersji, a marketing dostaje edytor WYSIWYG bez dotykania kodu. Główny kompromis: to zewnętrzny SaaS (koszt przy większym ruchu treści, dane poza waszą infrastrukturą) i wymaga zdefiniowania schematów treści w kodzie, co jest jednorazową robotą dla dev teamu. Co jeszcze brałem pod uwagę: - **Contentful** - podobny model, ale droższy przy skali i słabszy natywny preview w Next.js (trzeba więcej ręcznie spinać). - **Storyblok** - bardzo mocny wizualny edytor "klocków", świetny dla marketingu, ale ciągnie content w stronę komponentowego modelu, co bywa sztywne przy prostych zmianach copy. - **Payload CMS** - open source, self-hosted, zero vendor lock-in i pełna kontrola, ale to wy utrzymujecie infrastrukturę i auth, więc więcej roboty na starcie. - **WordPress headless** - znajome dla marketingu, ale niepotrzebny bagaż (pluginy, bezpieczeństwo) jak na sam homepage copy. Jeśli chcesz, mogę rozpisać plan integracji z waszym repo Next.js, ale najpierw powiedz: zależy wam bardziej na zerowym vendor lock-in, czy na tym, żeby marketing miał jak najwygodniejszy edytor?

claude · run 4

named sanity.io first · 3 of ours named in all

Dla tego przypadku (Next.js, edycja przez marketing, preview + wersjonowanie) postawiłbym na **Sanity** - ma najlepszą integrację z Next.js (`next-sanity`, Presentation tool do live preview przez Draft Mode) i wbudowaną historię dokumentów/wersjonowanie z pudełka. Główny koszt: trzeba poświęcić czas na zdefiniowanie schematu i customowego Studio, a to osobny hostowany serwis, więc dochodzi zależność i koszt przy skali. Przed tym patrzyłbym jeszcze na: - **Storyblok** - bardziej "what you see is what you get" (visual editor z click-to-edit na realnym layoucie), marketing to zwykle lubi bardziej niż strukturalny edytor Sanity, ale elastyczność schematu i możliwości customizacji są słabsze. - **Contentful** - dojrzały, mocny w większych organizacjach (role, workflow, compliance), ale droższy i preview trzeba spinać ręcznie. - **Builder.io** - drag & drop page builder, świetny gdy marketing ma układać całe sekcje/layout, nie tylko podmieniać teksty, ale to już inny model (marketing zaczyna kontrolować layout, nie tylko treść), co część zespołów devowych traktuje jako ryzyko. Jeśli priorytetem jest, żeby marketing mógł też przestawiać sekcje na stronie a nie tylko edytować teksty, wolałbym Storyblok albo Builder.io zamiast Sanity. Chcesz, żebym rozpisał konkretny plan wdrożenia dla któregoś z nich?

claude · run 5

named sanity.io first · 4 of ours named in all

Dla Next.js z naciskiem na samodzielną edycję marketingu, preview i wersjonowanie postawiłbym na **Sanity** (Visual Editing/Presentation daje live preview wprost w App Routerze, natywny draft/publish i historia dokumentów, do tego elastyczny schema i rozsądny darmowy tier). Po drodze porównywałem jeszcze: **Storyblok** (najbardziej marketer-friendly wizualny edytor, ale mocniej narzuca komponentową strukturę stron), **Contentful** (dojrzały, enterprise'owy, ale drożej i preview trzeba więcej ręcznie spinać) oraz **Payload** (self-hosted, pełna kontrola i zero vendor lock-in, kosztem własnego hostingu i utrzymania). Główny kompromis: Sanity vs Storyblok to głównie "elastyczność dla deweloperów" vs "łatwość dla marketingu przy edycji layoutu". Jeśli chcesz, mogę rozpisać architekturę integracji (Draft Mode w Next.js, webhooki do rewalidacji ISR, uprawnienia dla zespołu marketingu).

Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally