# Roboto Studio - Complete Content

> This file contains all content from robotostudio.com in markdown format.
> Optimized for LLM consumption and RAG systems.

---

# Services

## Agentic websites


> We build fast, type-safe websites engineered for SEO, AEO and conversion. Your AI agent ships landing pages on the rails. Bring v0, Lovable, Cursor, Replit or Codex.

**Updated:** 2026-08-25
---

Companies of all sizes trust Roboto Studio

An agentic website is one your marketing team builds on with its own AI coding agent. We hand over a fast, type-safe foundation, and your content lives as structured files in your own repository. You point the agent your team already builds with at those files (v0, Lovable, Replit, Cursor, Codex, Claude Code), describe the landing page or campaign you need, and it assembles the page from components we have already tuned for speed and conversion. Today a campaign page often means a brief, a developer queue and a sprint of waiting, so it can go live after the moment that prompted it has passed. With an agentic website you brief your agent and preview the page the same day.

Coding agents only recently got good enough to build whole pages from a prompt. Raw agent output tends to drift off-brand, load slowly and ship thin, half-crawlable HTML. The foundation prevents that. It is the rails: typed components, your design system and validation that keep whatever the agent produces fast, crawlable and on-brand before it reaches a visitor.

We don't sell you our agent. We build the website yours can safely work in, and that website speaks the plain, structured language every current and future coding agent already reads, with no onboarding call and no proprietary format to learn. When a faster model or a better tool arrives next quarter, you switch to it and nothing about your site has to change, because the rails live in the foundation rather than the agent itself.

Hand an unguarded AI tool your homepage and it will happily produce an off-brand, slow, half-crawlable page. We remove that risk at the source. Every page your agent builds is assembled from typed, conversion-tested components and validated against a Zod schema before it can ship. A missing meta description, a broken image path, an invalid layout: each one fails the build instead of reaching your visitors.

So your agent moves fast and the guardrails hold. Marketers describe what they want, the agent assembles approved blocks, and the rails make sure the output stays on-brand, fast and ready to rank.

Your pages are plain files in your own repository, so you own every word outright. A headless CMS bills you per editor seat and meters your API, so the cost of shipping climbs with every marketer you hire and every page you serve. Here it stays flat: add ten marketers or a hundred, and there is no rate limit on launch day and no vendor sitting between you and your own back catalogue.

Every change is versioned, so when a headline edit moves the numbers the wrong way, you can see exactly what changed, who changed it and when, then restore the winning page in seconds. Your campaign copy gets the audit trail your spend reports already have, and nothing you publish is locked inside a tool you would have to buy your way out of.

A prompt can produce a page in minutes, which is why an agentic website can look, at a glance, like one more AI page builder. The difference is what survives once you are shipping dozens of pages a month: whether each one stays fast, findable and on-brand, or whether the quality quietly slides as the count climbs. Holding that line is the work the foundation does. Components are checked before a page can preview, so what reaches your visitors looks reviewed even when an agent wrote it in a single pass. That is the difference between a quick draft and a page you can put ad budget behind.

| Approach | What ships |
| --- | --- |
| An AI builder with no guardrails | A quick first draft that drifts off-brand, with thin HTML and performance that slips as pages pile up |
| A traditional CMS | A polished editor, plus a dev ticket and a sprint wait for anything the template does not already do |
| An agentic website | Your agent on our rails: every page crawlable, fast, on-brand and conversion-ready the moment it ships |

My best experience with a consulting company. The results were delivered faster than expected and with top quality. Jono ensured I understood the process and suggested a great approach. Both execution and communication were flawless.

Agentic builds we've shipped

## Vercel agency partner

A Vercel partner agency, building fast, type-safe websites on Next.js and the Vercel stack that your AI agent can build on from day one.

## Thinking about an agentic website?

Here are the questions we hear most often

### Which AI agents can I use?

Whichever your team already works in. We have handed sites to teams using v0, Lovable, Cursor, Replit, Codex and Claude Code. The website is plain structured files, so any current or future coding agent can read and edit it. You are never tied to one vendor's tool.

### What stops the agent from making a mess?

The rails. Every page is built from typed components and checked against a Zod schema before it ships, so broken metadata, missing images or invalid layouts fail the build rather than reaching your visitors. Each change also lands as a preview you approve before it goes live. The agent moves fast inside boundaries you control.

### Is this what people mean by vibe marketing?

It is the part that makes vibe marketing safe to ship. Prompting a page into existence is easy. Making sure that page is fast, on-brand and built to convert is the hard part, and that is what the foundation handles. You get the speed of describing a page in plain English with the quality bar of an agency build.

### Is this the same as your agentic workflows service?

No, they pair well but solve different problems. An agentic website gives your team's coding agent a safe foundation to build pages on. Our [agentic workflows service](/services/agentic-workflows) is where we build the agents: content pipelines, lead enrichment, background agents that monitor and act. Plenty of clients start with one and add the other once the first system proves itself.

### What is an agentic CMS?

It is a content setup where an AI agent is a first-class editor, not an afterthought. Instead of a proprietary dashboard, your content lives as structured files an agent can read, write and validate. You still get previews, version history and review, with an agent doing the heavy lifting and your team approving the result.

### How does this help SEO and AI search?

Two ways. Pages render as fast, fully crawlable HTML with structured data, which is what both Google and answer engines like ChatGPT and Perplexity need to read and cite you. And because new pages are cheap to produce, you can cover the long-tail and programmatic queries that a hand-built site never reaches.

### Do my marketers need to write code?

No. They describe the page they want and the agent builds it, the same way they already brief a designer. The rails handle the technical correctness underneath. For teams that prefer a visual flow, we set up preview links so every change can be seen before it goes live.

### Can we move our existing site onto this?

Yes. We migrate your current pages into the new foundation, map redirects so your rankings carry over, and hand you a site your marketing team and its agent can build on. Moving off an aging WordPress or legacy CMS does not mean a publishing freeze.

## Bring your agent. We will build the rails.

Tell us the tool your team builds with and the pages you need to ship. We will scope the foundation that keeps everything it makes fast, found and on-brand.

From the blog

---

## AI automation services


> Custom AI automation: production AI agents and agentic workflows on Vercel, built and maintained by the engineers who ship them.

**Updated:** 2026-08-25
---

## The AI automation you prototyped, rebuilt to run in production

You've already prototyped the AI feature. We rebuild it to run in production: durable workflows on Vercel that survive deployments, retry failed steps, and keep running under real traffic. The same pattern that briefs our sales team within a minute of a form submit, fills a content calendar overnight, and keeps a product catalogue current without anyone opening a spreadsheet.

Companies of all sizes trust Roboto Studio

My best experience with a consulting company. The results were delivered faster than expected and with top quality. Jono ensured I understood the process and suggested a great approach. Both execution and communication were flawless.

Production builds we've shipped

## How these work in practice

Every workflow below runs in production. They survive server restarts, retry failed steps automatically, and pause for external events without consuming compute. Here's what that looks like for real problems.

Your marketing team knows they should publish more. They don't have the hours. Here's what we build: a workflow that connects to the Ahrefs API, pulls your keyword gaps and ranking opportunities, then generates research briefs for each topic. A second workflow takes those briefs, researches the subject using AI, writes a first draft, and pushes it to your CMS as a draft post.

Set the whole thing on a CRON schedule. Monday morning, your editor opens Sanity and finds five draft posts waiting for review, each targeted at a keyword your competitors rank for and you don't. The AI did the research and the first draft. Your writer does the thinking and the polish.

Each step in the pipeline retries independently. If the Ahrefs API rate-limits you, that step waits and retries. If the LLM call fails, it tries again without re-fetching the keyword data. Deploy a code update while a draft is mid-generation? The workflow finishes on the old version.

If you operate in multiple markets, the same pipeline can generate localised versions of each post. The workflow takes your approved English draft, translates it, adjusts examples and references for the target region, and pushes each version to the correct locale in your CMS. One editorial review produces content for every market you sell into.

When someone submits a contact form on our site, a workflow kicks off within seconds. It extracts the domain from their email, scrapes their company's website for context, then sends everything to Claude. The AI researches the company, looks at what they do, checks for recent news or funding rounds, and generates a structured brief. That brief lands in our Slack within a minute of the form submission.

The entire thing is about 40 lines of TypeScript. Each step uses a `"use step"` directive, so if Claude's API is slow or Slack returns a 500, that individual step retries without re-scraping the website. We use this ourselves, every day.

For clients, we extend this pattern to push enrichment data into their CRM, score leads based on company fit, and trigger different follow-up sequences depending on what the AI finds. A SaaS company can automatically route enterprise leads to their sales team and self-serve leads to a product tour.

Workflows are great for request-response pipelines. Some problems need an agent that lives in the background, watches for changes, decides what to do, and acts. Stale comparison pages that need fact-checking against a competitor's docs. Brand citation alerts in ChatGPT and Perplexity. A llms.txt file that should regenerate every time the product changes.

We build these on eve, Vercel's open-source agent framework. eve treats an agent as ordinary files in a TypeScript repo: a markdown system prompt, typed tool definitions, and `defineSchedule` for the cron that wakes it up. Sessions are durable by default, built on the same workflow engine as our pipelines, so an agent halfway through a task survives a crash or a deploy. When it needs to run code, it does so inside an isolated Vercel Sandbox, never against your production environment. The same agent runs locally under `eve dev` and on Vercel in production. Schedules trigger them. Remote webhooks trigger them. Other agents trigger them.

Credentials stay out of the codebase. When an agent posts to Slack, opens a pull request, or writes to your CRM, it asks Vercel Connect for a short-lived, scoped token at runtime instead of reading a long-lived secret from an environment variable. The keys stay centralised and auditable, and you revoke access at the provider rather than by redeploying.

Roboto's own CMS migration pages are kept current by a weekly background agent that scrapes the source CMS's docs, diffs against our YAML, and opens a pull request when something is out of date. The agent we built for ourselves is the same agent we ship to clients. If you want one watching your competitor's pricing, your product changelog, your brand citations across the AI search surfaces, we build it on the same foundation.

An agent without evals is a demo. The moment you connect it to real data, a prompt change can break it silently. We build eval pipelines alongside every production agent: golden datasets of inputs your agent should handle, deterministic checks for the parts you can grade with code, and LLM-as-judge grading for the parts you can't.

Every prompt change runs through the eval suite before it ships. Every model upgrade gets scored before you switch over. Regressions get caught before your editor reviews a bad draft or your sales team gets a wrong brief. The eval suite is the closest thing agentic systems have to a test suite.

We treat evals as a productised add-on. They can be the starting point of an engagement if you already have an agent in production that isn't trustworthy, or they can be built alongside a new agent from day one.

An agent that runs once a week costs nothing worth discussing. An agent that runs on every form submit, every catalogue update and every support ticket has a bill attached, and that bill gets decided early in the build or inherited later at the worst possible moment.

So we design for it from day one rather than selling it back to you later as an add-on. Every step picks the model that suits the job: a fast, cheap model handles classification, extraction and routing, and the expensive one is held back for the step that needs judgement. Because the AI SDK is provider-agnostic, moving a step onto a different model is a config change instead of a rewrite, so the routing keeps improving as the model landscape shifts. Prompts get cached where the same context repeats. Each step gets only the context it needs rather than the whole conversation. And every run reports its own cost into PostHog LLM analytics from the first deploy, so the expensive step is visible on day one instead of showing up in a quarterly invoice.

If you already have an agent live and the bill is the thing worrying you, that is a perfectly good place to start an engagement. We instrument what you have, find where the tokens actually go, and bring them down, with the eval suite above as the backstop so nothing quietly gets worse on the way to getting cheaper.

The stack behind these systems

    Vercel's open-source agent framework, and what our background agents actually run on. An agent is a directory of files in your repo, so it ships through the same branches, pull requests, and preview deploys as the rest of your code. Durable sessions, sandboxing, human approvals, and evals all come built in.

    The Workflow Development Kit gives every step automatic retries, durable state, and replay-on-deploy. Open source, runs anywhere, but pairs cleanly with Vercel Fluid Compute.

    Provider-agnostic model calls, structured outputs via Zod, tool use, streaming, and observability. Switch models without rewriting the agent.

    Isolated microVMs for code execution inside an agent. Lets agents run shell commands, clone repos, and execute generated code without giving them production access.

    Short-lived, scoped credentials for agents. Rather than long-lived secrets sitting in environment variables, an agent requests a token at runtime to act in Slack, GitHub, Salesforce, or any OAuth or API-key service. Access stays scoped per project and revocable at the provider.

    Every model call, every tool invocation, every conversation captured for review. Quality regressions and cost blowouts get caught the day they happen, not the week after.

## Forward deployed engineers, embedded in your team

Agentic systems live inside your codebase, your content models, and your observability stack. They need daily iteration on prompts, tools, and editorial review.

So we ship them the way Palantir, OpenAI, and Anthropic ship AI: by embedding senior engineers directly into your team for the life of the engagement.

A Roboto FDE engagement puts one or two senior engineers into your codebase with the same access as your own team. Shared Slack channel, repo write access, on-call posture for the agents we ship. Weekly demos, daily-or-better async updates, and a documented playbook your team owns when the engagement winds down. We transfer knowledge as we go, so nothing depends on a rushed handover at the end.

The cadence matters because agentic systems aren't ship-and-walk-away projects. Prompt iteration runs daily once the agent hits real traffic. Tool integrations break in ways nobody predicts at scoping. Editorial review needs context only your team can give. An external vendor on a weekly call is too slow for that loop.

Engagements run a minimum of eight to twelve weeks so the build, observe, and iterate cycle has room to play out. Most settle into a rolling monthly retainer once the first systems are live and the next ones are queued.

CMS migrations, headless Shopify builds, and Contentful implementations all ship cleanly as projects with handoff boundaries. Agentic work doesn't. The output is your voice, your data, and your customer-facing automation, and it changes weekly based on what real usage reveals.

That's why FDE applies to agentic workflows and AEO engagements, not to every service Roboto offers. If you're after a fixed-scope build with a clean handoff, our project teams handle that. If you're after an agent or workflow that needs to keep getting better in production, you want the embedded model.

## Vercel agency partner

A Vercel partner agency, shipping production agents and workflows on Vercel's AI infrastructure since the first release of the Workflow Development Kit.

One of the background agents we set up most often is a page updater: it researches new information and updates a page to match. Our own CMS freshness bot, the one that keeps the migration comparison pages current, is a tailored version of exactly this.

## Thinking about agentic workflows?

Here are the questions we hear most often

### What does a Forward deployed engineer engagement actually look like?

One or two senior Roboto engineers join your Slack, your repo, and your standups for the life of the engagement. We treat your codebase like ours: branches, pull requests, code review, deploys. Weekly demos cover what shipped, what's queued, and what decisions need your input. Daily async updates keep you ahead of the work. Minimum engagement is eight to twelve weeks; most settle into a rolling monthly retainer once the first agents are live.

### How is this different from a typical AI automation agency?

Most AI automation agencies sell no-code workflows on Zapier, Make, or n8n. Useful for prototypes, fragile in production. We ship typed TypeScript on Vercel's durable workflow runtime, with eval pipelines, observability, and version control. The systems we build live inside your codebase, get reviewed in your pull request flow, and survive your deploys. Different toolchain, different reliability bar.

### What is eve?

eve is Vercel's open-source agent framework, and it's what our production agents run on. It treats an agent as a directory of files in a TypeScript repo: a markdown system prompt, typed tools, schedules, and skills. The framework handles the parts every serious agent needs anyway, like durable sessions that survive a deploy, sandboxed code execution, human-in-the-loop approvals, OpenTelemetry tracing, and an eval harness. Because an agent is just code in your repo, it gets versioned, reviewed, and deployed like everything else you ship. We run our own background agents on eve, so the patterns we bring to your build are ones we've already debugged on ourselves.

### What is a durable workflow?

A program that saves its progress as it runs. If the server crashes, it picks up from the last completed step instead of starting over. Traditional server code loses everything on restart. Durable workflows don't. Think of it like a save point in a game. That makes them the most stable way to run AI systems or anything that needs to wait, for an API response, a human approval, or a scheduled delay, and still finish reliably. For AI orchestration specifically, where you're chaining multiple model calls, tool lookups, and external APIs together, durability turns a fragile chain into one that finishes even when a step fails.

### Do we have to use Vercel?

No. eve and the Workflow Development Kit are both open source, and the AI SDK is portable across model providers, so the core runs on AWS, Google Cloud, or your own servers. Vercel gives you zero-config deployment, managed Sandbox for code execution, and Connect for runtime credentials, which is why we default to it. The architecture travels; the managed convenience is what you'd trade away by self-hosting.

### Can you connect to our existing tools?

If it has an API, we can wire it in. We've built integrations with Ahrefs, PostHog, Slack, Sanity, various CRMs, payment processors, and custom internal tools. Each integration is a step in a workflow, so it gets automatic retries and error handling for free.

### What does 'agentic' mean here?

Software that acts on its own with human oversight. An agentic workflow might research a lead, draft a blog post, or classify a support ticket without anyone clicking a button. A human reviews the output before it goes live. The agent handles the grunt work, people handle the judgment.

### How do you handle AI accuracy?

Every workflow we build has a human review step where it matters. AI drafts the blog post, your editor approves it. AI enriches the lead, your sales rep reads the brief. AI classifies the ticket, your support team sees the suggestion. We don't ship workflows where AI output goes straight to your customers without a check. We also build eval pipelines for every agent we put into production, so quality degradation gets caught before your team feels it.

### We already have AI features. Can you improve what we have?

Most teams we work with have a working prototype that needs to become production-grade. That usually means adding durability so it doesn't break on deploy, observability so you can debug failures, evals so quality stays measurable, and proper error handling so one bad API response doesn't tank the pipeline. We audit what you have and figure out the fastest path to reliable.

### How do you keep token costs under control?

By treating it as a build decision rather than a cleanup job. Each step in a workflow runs on the model that suits it, so classification, extraction and routing sit on a fast, cheap model and only the steps that need real judgment reach for the expensive one. The AI SDK is provider-agnostic, so moving a step onto a different model is a config change instead of a rewrite. We cache prompts where the same context repeats, and give each step only the context it needs rather than passing the whole conversation around. Every run reports its own cost into PostHog LLM analytics from the first deploy, so you can see which step got expensive instead of guessing. If you already have an agent live, we can start there: instrument it, find where the tokens actually go, and bring them down with the eval suite catching any quality drop on the way.

## Put an agent to work on your busywork

The content backlog, the unenriched leads, the catalogue nobody can keep current. Pick the one costing your team the most and we'll scope it.

From the blog

---

## Astro website development


> Astro development agency for content-heavy websites. We ship static-fast pages with islands for the interactive parts, wired to Sanity or Contentful, and we'll tell you honestly when Next.js is the better fit.

**Updated:** 2026-08-25
---

Companies of all sizes trust Roboto Studio

Most content sites ship an application framework's worth of JavaScript to render pages that are, honestly, documents. Astro flips that default. Every page renders to plain HTML on the server, and JavaScript is opt-in per component: the search box hydrates, the ten paragraphs around it don't. Your visitors get pages that load instantly on hotel wifi, and your Core Web Vitals stop being a quarterly remediation project.

We build Astro sites the same way we build everything else: structured content first. Your pages come from Sanity, Contentful, or MDX collections in your own repository, so editors keep a real workflow and nothing about the frontend is welded to the content. When a page needs genuine interactivity, we drop in an island built with React, and the rest of the site stays static.

Astro is our recommendation when the site is overwhelmingly content: marketing sites, documentation, editorial publications, blogs that have outgrown their CMS's frontend. It is not our recommendation for logged-in products, dashboards, or sites where personalisation drives every page, because that's application territory and [Next.js](/services/nextjs) handles it better.

You shouldn't have to arbitrate a framework debate to buy a website. Next.js is our daily driver and Astro shares its content-first playbook, so we hold no framework loyalty and we'll tell you in the first call which one your requirements actually point to. Quite often the Astro answer is also the cheaper one to build and the cheaper one to run.

Content-first builds we've shipped

## Considering Astro?

The questions we get asked when teams are weighing Astro against an app framework.

### What is Astro and when is it the right choice?

Astro is a web framework built for content-heavy sites: marketing pages, blogs, documentation, editorial publications. It renders everything to static HTML by default and only ships JavaScript for the components you explicitly mark as interactive. If most of your site is content and a handful of widgets, Astro is usually the right call. If your site is mostly application, it isn't.

### Astro or Next.js, which should we pick?

Our honest rule: [Next.js](/services/nextjs) when the site has real application logic, personalization, or heavy interactive surfaces; Astro when the site is overwhelmingly content with a few interactive islands. Next.js is what we ship week in, week out, and Astro shares its content-first playbook, so the recommendation follows your requirements rather than our preference. We'll tell you which one fits in the first call, and it's often the less expensive answer.

### Does Astro work with a headless CMS?

Yes, and that's how we build it. Astro pairs cleanly with [Sanity](/services/sanity) and [Contentful](/services/contentful): your editors keep a real editorial workflow, and the site rebuilds or revalidates when content changes. Content collections also make on-disk MDX a first-class option for teams who want content in the repo.

### What are islands and why do they matter?

An island is a single interactive component, like a search box or a pricing calculator, hydrated on an otherwise static page. Instead of shipping a whole application bundle to render mostly static content, Astro ships JavaScript only for those islands. The result is less code over the wire and Core Web Vitals that hold up under real traffic.

### How does Astro help SEO and AI search?

Every page is fully rendered HTML with no client-side rendering gap, which is exactly what search crawlers and answer engines like ChatGPT and Perplexity want to read. Combined with fast load times and structured data baked into the templates, Astro sites are easy to index and easy to cite. That's the same crawlability work behind [our AI SEO service](/services/geo).

### Can you migrate our existing site to Astro?

Yes. An Astro migration follows the same URL-map and 301 playbook as [every CMS replatform we run](/services/cms-migration): each legacy URL mapped, rankings carried over, and your content brought along or remodeled as part of the move, whether it currently lives in WordPress, Webflow, or a legacy framework.

### Can Astro handle interactive features and apps?

Within reason. Islands can be React, Svelte, or Vue components, so carts, search, filtering, and forms are all comfortable territory. When the interactive surface grows into a genuine application, dashboards, logged-in product, complex state, we'll steer you to Next.js instead of stretching Astro past what it's good at.

### Who maintains the site after launch?

Either your team or ours. Astro sites are deliberately simple to run: content edits go through the CMS, and the codebase is small enough for one developer to hold in their head. If you'd rather not staff it, [our retainer](/services/sanity-support) covers upgrades, new sections, and incident response.

From the blog

**Tell us what you're publishing.** A marketing site that's outgrown its builder, docs that need to load instantly, or a content platform where the app framework is doing nothing but slowing you down: we'll scope it in a 20-minute call and tell you whether Astro fits, including when the answer is Next.js instead.

---

## Brand design


> Brand design from the studio that also builds the website. We design identity systems, typography, and motion that ship as design tokens and components your site uses on day one, not a brand book that gathers dust.

**Updated:** 2026-08-25
---

Companies of all sizes trust Roboto Studio

The standard brand handover is a hundred-page PDF and a folder of logo exports. Then a developer squints at it, picks the nearest hex code, and the erosion starts: the website drifts from the deck, the deck drifts from the product, until nobody can say what the brand actually looks like.

We design brands the way we build websites: as systems. Identity decisions become design tokens, typography becomes a type scale your CSS consumes, and components carry the brand into every page automatically. The guidelines still exist, but they're generated from the working system rather than hoping someone reads them. Approve a colour once and it renders that way everywhere, from your homepage to your OG images.

Brand agencies design; development agencies interpret. The gap between those two is where identity work goes to die. Because we do both, your brand runs a few weeks ahead of the website build: identity lands as tokens, tokens land in components, and the site launches as the first full expression of the brand rather than a translation of it.

That also means the brand is designed for where it will actually live. Motion principles that respect performance budgets, colour systems that hold up in light and dark mode, typography chosen for how it renders on screen and not just how it looks on a poster. If you only need the identity work, that's fine too; everything we hand over is built so any competent team can implement it.

Design-led builds we've shipped

## Thinking about your brand?

The questions we get asked when teams are weighing a refresh against a rebrand.

### What does your brand design service cover?

Identity design (logo, typography, color), a design system that encodes it as reusable components and tokens, the assets a launch actually needs (social, OG images, pitch templates), and motion principles for how the brand behaves on screen. The deliverable is a working system, with the traditional brand guidelines generated from it rather than the other way round.

### Why buy brand design from a development studio?

Because the most common way a brand dies is translation. An agency hands over a beautiful PDF, a developer approximates it in CSS, and soon the website, the deck, and the product all disagree. When the same studio designs the identity and builds the site, the brand ships as design tokens and components, so what you approved is what renders.

### Do we need a full rebrand?

Usually not, and we'll say so. Most teams need a refresh: keep the recognizable core, fix the typography, systematize the color, and build the component library that makes the brand consistent everywhere. A full rebrand is for genuine repositioning. We'll tell you which one you're actually shopping for in the first call.

### What do we get at handover?

Figma libraries wired with variables, design tokens your developers consume directly, a component library if we're building the site too, brand guidelines as a living document, and the launch asset kit. Everything is versioned and editable, so the system keeps working after we step away.

### Can you work with our existing brand?

Yes. A lot of our brand work starts from an identity that's fine but has never been systematized: the logo is good, everything else is improvised per project. We audit what exists, keep what works, and encode it into a system your team and your website can apply consistently.

### How does brand design pair with a website build?

Naturally, and it's the pairing we recommend. Brand runs a few weeks ahead of the build: identity decisions land as tokens, tokens land in components, and the site becomes the first full expression of the brand instead of an approximation of it. One team, no translation loss, one timeline. See how we build on [Sanity](/services/sanity) and [Next.js](/services/nextjs).

### How long does a brand project take?

A systematization of an existing identity typically runs three to four weeks. A new identity with a full design system typically runs six to eight, scoped per engagement. Paired with a website build, the brand work fronts the timeline so development never waits on design decisions.

**Tell us where the drift hurts.** A launch that needs an identity, a good logo trapped in an inconsistent system, or a rebrand you want built into the website rather than translated onto it: we'll scope it honestly in a 20-minute call.

---

## CMS migration agency


> CMS migration agency for teams replatforming off WordPress, Webflow, HubSpot, Drupal, Sitecore or Framer. We move content, preserve URLs, and keep search rankings intact so you don't lose 30% of your traffic the week after launch.

**Updated:** 2026-08-25
---

## Move CMS without losing your traffic

### We replatform WordPress, Webflow, HubSpot CMS, Drupal, Sitecore and Framer sites onto Sanity or Contentful. URLs preserved. JSON-LD parity. Redirect map signed off before cutover. Editors trained before, not after.

The week after launch is where most migrations get judged, and most agencies have already invoiced and moved on. We stay through the post-launch monitoring window, watch the GSC and Ahrefs numbers daily, and fix the things that always surface once Googlebot starts re-crawling.

Migrations we've shipped for

## The SEO migration agency that closes the loop

### We've moved hundreds of thousands of pages between CMS platforms over the last six years. Every migration has the same risk profile: get the redirects, sitemaps and structured data wrong and you watch months of compounding organic traffic disappear inside a fortnight.

Our process is built around the parts that quietly cost teams their rankings: the redirect map that gets signed off in a spreadsheet before any code ships, the JSON-LD parity audit that confirms every schema type on the old site exists on the new one, the staged cutover that lets us roll back without anyone outside the team noticing, and the 30-day post-launch monitoring window where we catch the regressions Google surfaces a fortnight in.

### We've been pulled in to recover migrations where the new site shipped clean, looked great, and lost 30 to 70% of organic traffic in the first month. The pattern is always one of four root causes.

**Broken redirect maps.** The team mapped the top 100 URLs, missed the 4,000 long-tail pages with three backlinks each, and surrendered all of that link equity to a soft 404.

**JSON-LD that quietly went missing.** The old WordPress site had Article, FAQPage, BreadcrumbList and Organization schema on every post. The new build shipped with none of it, and the rich results disappeared from the SERP within a fortnight.

**Sitemap regressions.** The new sitemap had 600 URLs, the old one had 4,800. Google noticed before anyone on the team did.

**Image and OG drift.** Image filenames changed, alt text was dropped, Open Graph images defaulted to a generic logo. Social previews went blank and image search traffic evaporated.

The good news is every one of these is preventable with a checklist run before, during and after cutover. We've published our full version of that checklist as a [pre-launch essentials guide](/blog/the-pre-launch-essentials-checklist-for-cms-migrations), which we run on every migration we ship.

Migration is where most teams find us, but plenty of our work is building headless CMS sites from scratch. As a [headless CMS agency](/services/headless-cms) we model the content, build the Sanity or Contentful backend, and ship a Next.js frontend on top, with the editorial experience designed around how your team actually publishes.

If you are weighing up a headless CMS development company for a greenfield build, the standard is the same as our migration work: a content model that survives new page types, preview your editors trust, structured data and performance handled properly, and a frontend your developers can keep extending long after launch. The [headless CMS service page](/services/headless-cms) covers the greenfield offer in full.

Our six-stage migration process

    We snapshot the current site before anything moves. Full Ahrefs export of ranking keywords and referring domains, GSC performance baseline across the last 12 months, sitemap diff, internal-link graph, and a list of every JSON-LD schema type currently in use. This is the document we measure success against post-launch.

    We design the target schema in Sanity or Contentful around how your editors actually work, not the shape of the legacy database. Page builders, reusable references, validation rules and roles get scoped before any data moves so the new model still fits your team six page-type requests from now.

    Every legacy URL gets mapped to a destination. Categories, tag archives, author pages, paginated lists, the long tail of orphaned posts: nothing gets surrendered to a soft 404. The map is reviewed, signed off, then implemented as proper 301s at the edge so search engines see permanent moves.

    We catalogue every structured-data type on the old site and rebuild it on the new one. Article, FAQPage, BreadcrumbList, Product, Organization, VideoObject: each schema type gets parity, validated through the Rich Results Test before launch and re-validated after.

    We launch behind a feature flag or staging domain with the redirect map already in place. Real traffic gets a controlled rollout, the new sitemap gets submitted at the same moment as the DNS flip, and the old site stays warm in case we need to roll back. Most clients see zero downtime through cutover.

    The 30 days after launch are where rankings actually settle. We monitor GSC coverage, indexing, Core Web Vitals and rank tracking daily for the first week, weekly through the first month. Every regression gets investigated and fixed before it compounds.

We've documented the exact pre-launch checks we run on every migration: redirect-map QA, sitemap audit, JSON-LD parity, OG image audit, robots.txt and llms.txt review, Ahrefs and GSC baseline capture, internal-link audit, image migration to Vercel Blob, performance regression check, and the post-launch monitoring cadence.

Tick through the interactive version below as you work the migration. Your progress is saved in your browser, so you can step away and come back to it across the weeks the migration actually takes.

Moving from your current CMS

Migration builds we've shipped

## Thinking about a CMS migration?

The questions we get asked on every migration scoping call.

### Are you a headless CMS agency?

Yes. We build and migrate headless CMS sites on Sanity and Contentful, with a Next.js frontend on top. Whether you're starting fresh or moving off WordPress, Webflow, HubSpot, Drupal or Sitecore, we handle the content modeling, the build, the redirect map and the post-launch monitoring. Our [headless CMS agency page](/services/headless-cms) covers the greenfield side; this page covers getting the migration right.

### How long does a CMS migration take?

Most mid-market migrations take 6 to 12 weeks end-to-end, depending on content volume, the complexity of the source schema, and how much content modeling work the new platform needs. Enterprise migrations with multi-language sites and hundreds of thousands of entries run longer. We scope honestly on a discovery call and break the timeline into audit, build, content move and post-launch monitoring stages so progress is visible week by week.

### Will we lose SEO traffic during a CMS migration?

Not if the redirect map, sitemaps and structured data are handled properly. Every URL with organic traffic or backlinks gets a 301 to its closest equivalent on the new site, the new sitemap gets submitted to GSC on cutover day, and JSON-LD schema gets rebuilt with parity to the old site. We've shipped migrations where organic traffic was flat through cutover and growing within four weeks. The reverse is also true: skip the redirect map and you'll watch months of compounding traffic disappear inside a fortnight.

### What does a CMS migration cost?

The honest answer: it depends on content volume and how much modeling work the new platform needs. A 5-page brochure site moves for a few thousand pounds. A 4,000-page enterprise site with multi-language content, a custom redirect map and JSON-LD parity work is a multi-month engagement. We scope every migration in two stages: a paid audit that surfaces every risk, then a fixed-fee build against the audit findings. No surprises mid-project.

### Which CMS should we migrate to?

Most teams we work with land on Sanity, because the structured content model, real-time collaboration and Live Content API fit modern editorial workflows better than anything else on the market. Contentful is the right call for enterprise teams with existing Contentful licenses, complex role-based publishing or multi-region content operations. Where the choice matters, we'll walk you through both on a scoping call instead of pretending one fits everyone.

### Can you migrate from WordPress to Sanity?

Yes. WordPress to Sanity is the most common migration we run. The pattern is well-trodden: export WordPress content via the REST API or XML, map post types, categories and ACF fields to a Sanity schema, run the redirect plan across slugs that almost never line up perfectly, and rebuild the JSON-LD schema your old Yoast or Rank Math setup was emitting. We've documented the technical walk-through in our [how to migrate from WordPress to Sanity fast](/blog/how-to-migrate-from-wordpress-to-sanity-fast) guide.

### Can you migrate from Webflow to Sanity?

Yes. Webflow to Sanity is our second-most-common migration. The Webflow CMS export gives us the source data; the structural work is in mapping Webflow Collections to a Sanity schema that actually scales past the platform's hard limits on collection size and item count. Rich text fields and component references need careful handling. We've run this pattern on sites with over a thousand pages without losing visible search rankings through cutover.

### What about HubSpot CMS, Drupal or Sitecore?

All three are migrations we run. HubSpot CMS migrations typically head to Contentful, because clients on HubSpot are usually already paying for an enterprise stack and want the editorial parity. Drupal and Sitecore migrations are enterprise engagements: deeper content modeling, more careful URL planning, longer monitoring windows. Talk to us on a scoping call and we'll walk through the source-specific risks before quoting.

### What's the worst-case scenario if a migration goes wrong?

The cautionary tale we keep referencing: a team replatformed without a proper redirect map and watched organic traffic drop to roughly a third of pre-launch volume inside three weeks. Recovering that is months of work, and some of the lost ranking never comes back because the new pages don't have the same backlink profile the old URLs did. The pre-launch essentials checklist exists because every step on it has, at some point, caught a problem on a real engagement.

**Tell us what you're moving off and where you'd like to land.** We'll send back a fixed-fee audit proposal that prices the migration honestly, surfaces the risks before contracts get signed, and gives you a redirect-map sample so you can see how we work before you commit to a build.

From the blog

---

## Contentful development agency


> Contentful development agency for enterprise content teams. We model content, migrate from WordPress and HubSpot CMS, run A/B tests in Contentful and ship integrations your marketing team actually uses.

**Updated:** 2026-08-25
---

## Contentful development agency

### The Contentful agency for teams shipping content at scale. We build, migrate and integrate, from multi-language storefronts to enterprise sites with hundreds of thousands of structured entries.

We've shipped Contentful at every scale, from a first build to estates with hundreds of thousands of entries. The demo is never the hard part. What counts comes later: a content model that still makes sense at the tenth content type, a migration that keeps your rankings intact, an integration that survives the next webhook change. That middle stretch is the work we're known for. We handle the modelling, the migration and the integration plumbing, so editors and developers both get a Contentful they can live with as content types and locales multiply.

Companies of all sizes trust Roboto Studio

## Contentful specialists, not Contentful tourists

### We build Contentful sites from scratch, and we get called in to fix the ones that drifted. Doing both is how you learn to keep it clean.

Most agencies treat Contentful as a black box. We don't. A page builder needs real architecture, so a single edit changes one page and not forty. Content types need scoping early, so your bill stays predictable as the site grows. Migrations from WordPress, Drupal and HubSpot CMS get the same care with redirects and search equity that we'd put into a rebuild we couldn't afford to get wrong.

When a Contentful site has lost performance or organic traffic, teams bring us in to rebuild the foundations without a full re-platform. When you're starting fresh, we'd rather get those foundations right the first time. Either way, as a Contentful Silver Solution Partner our Contentful developers work alongside your editors and engineers so the platform keeps pace as the content estate and the team grow.

    Editors work side-by-side in Contentful with real-time collaboration, scheduled releases and clear approval flows. We design the content model and roles so marketing, product and legal can work in the same space without overwriting each other's changes.

    Editors see exactly how content will look on any device or channel before it goes live. We wire up Contentful's preview workflows into your Next.js or Astro frontend so marketing can move fast without "please redeploy" tickets.

    Contentful's built-in AI speeds up drafting, translation and on-brand variant generation. We help editorial teams fold it into how they already work rather than treat it as a separate tool to learn.

    We handle the unglamorous middle of a migration: mapping legacy content, redesigning the schema, preserving URLs and SEO equity, and getting editors trained before the cutover. We've done it for HubSpot CMS, WordPress and homegrown databases.

    Run A/B tests and audience-targeted variants directly inside Contentful, without bolting on a separate experimentation tool. We set up the rules, the analytics wiring and the editorial guardrails so your team can iterate without engineering hand-holding.

    HubSpot forms, Salesforce, Marketo, Algolia, Mux. We wire Contentful into the rest of your stack so data flows both ways and keeps flowing the next time someone changes a webhook.

When a Contentful site slides in search, the cause is usually in the build. Landing pages stitched together from references bloat the rendered HTML. The frontend paints slowly under real traffic. Meta titles, descriptions and structured data never made it into the content model, so editors publish pages that can't describe themselves to a crawler. Every new entry inherits the same problems, and the slide compounds.

We fix the foundations without forcing a re-platform. That means auditing the rendering path and cutting the dead weight out of every template, moving SEO fields and schema markup into the content model itself so a page can't ship without them, and rebuilding the redirect map so the equity from old URLs lands where it should. The audit tells us which fixes pay back first, and the work runs in that order.

The same foundations go into every Contentful site we build from scratch, because recovering rankings costs far more than never losing them. Ranking in Google is also only half the picture now: our [generative engine optimisation](/services/geo) work covers how your site shows up in ChatGPT, Perplexity and AI Overviews.

Contentful acquired Ninetailed and built it into the platform as Contentful Personalization, which changes what an experiment costs to run. Audience segmentation, A/B and A/B/n tests at the component level, and the insights to read the results all live where your editors already work, with no separate experimentation tool to license, integrate and keep in sync with your content.

Our job is the implementation that makes it trustworthy. We define audience segments against real visitor data rather than guesses, wire experiment results into the analytics you already report from, and set the editorial guardrails so a variant edit never silently changes the live entry. That last part matters more than it sounds: variants ride on the same reference system that powers the rest of Contentful, and the same architecture discipline we apply to page builders applies here.

Once that's in place, marketing runs the programme on their own. A new hero variant for returning visitors is an afternoon's work in the editor rather than an engineering ticket. The experiment ships, the numbers come back, and the winner gets promoted without anyone touching code.

## Silver-tier, with production builds to match

Contentful made us a Silver Solution Partner because we keep shipping. Our Certified Professionals are deep in composable commerce builds today, and most weeks one of them is wrestling a WordPress or HubSpot CMS migration into a clean, multi-brand Contentful setup.

Jono and his team are absolute rockstars. They blend technical savvy with practical business sense. They are in lock-step with our website goals and have really made our website come to life. Not just a web dev team, they are trusted advisors and truly aligned with our team.

Contentful builds we've shipped

Which Contentful plan you actually need

## Thinking about building with Contentful?

The questions we get asked most often

### What is Contentful?

Contentful is an API-first headless CMS. Content lives in the cloud as structured entries, and any frontend (a Next.js site, a mobile app, a digital sign) pulls it in via REST or GraphQL. The trade-off versus a traditional CMS is more upfront content modeling in exchange for far more flexibility on how and where you publish.

### Is Contentful a headless CMS?

Yes. Contentful was one of the original headless CMSes and is fully decoupled from any frontend. You model content in Contentful, then deliver it through REST or GraphQL APIs to whatever you're building.

### What does a Contentful agency do?

The parts of a Contentful build that aren't frontend code: content modeling, migration planning, integration plumbing, editorial workflow design, and the governance that stops a page builder decaying edit by edit. A good Contentful agency will also tell you when Contentful is the wrong choice for your content model. Most of our clients keep the frontend and product roadmap in-house and bring us in for the platform work that has to be right the first time.

### Is Roboto Studio a Contentful partner?

Yes, we're a Contentful Silver Solution Partner with Certified Professionals on the team. Partner status gives us a direct line into Contentful and early sight of platform changes, which is how our Contentful developers tend to have already shipped the feature you're about to adopt.

### How does Contentful pricing work?

Contentful publishes its pricing openly: a free tier for small teams, then Lite, Premium and Enterprise plans priced by users, content types, locales and API call volume. Most mid-market teams land on Premium; enterprise plans add SLAs, SSO and custom roles. The honest answer most agencies don't give you: budget for the implementation and content-modeling work too, because the license is usually a small fraction of total cost in year one.

### How do we stop our Contentful bill from escalating as we add features?

Most pricing surprises in Contentful trace back to a content model that grew without a plan. Every new editorial idea gets its own content type, locales multiply, and suddenly you're bumping the tier ceiling. We scope content types deliberately on day one, reusing fields and leaning on references where they belong, so you keep room to grow inside the plan you already pay for.

### When would you recommend something other than Contentful?

When content needs to nest six or seven layers deep, or when editors expect a universal block library reused across many page types, Contentful starts to fight you. In those cases we'll usually recommend Sanity, which handles nested structures and reusable blocks more gracefully. We'd rather lose a project at the proposal stage than watch you fight your CMS on every new page type. Picking the wrong tool is a much more expensive mistake than picking a different agency.

### How do you build a Contentful page builder that stays maintainable?

Contentful's reference system is powerful and easy to misuse. A naive page builder ends up with shared blocks referenced across dozens of pages, so a single edit silently changes content everywhere it appears. We design page builders with clear separation between reusable components and page-scoped content, then add editorial conventions and roles so contributors always know which edits are global. The architecture is what makes the difference between a flexible system and a quiet bug factory.

### Can Contentful handle multi-language sites?

Yes, localization is one of Contentful's strongest areas. You define locales centrally, then translate per-field with fallbacks and per-locale publishing. We've shipped Contentful into multi-language storefronts and editorial sites where the same content team manages a dozen markets without each one diverging into its own bespoke build.

### Can you migrate from WordPress, Drupal or HubSpot CMS to Contentful?

Yes, we run these migrations regularly. We map your existing content, design the new content model, preserve URLs and SEO equity with 301s, and migrate editors as carefully as we migrate data. HubSpot CMS and WordPress are our most common sources.

### What access do you need from us to run a Contentful migration?

For the source CMS, we usually need an admin or export-level role so we can pull every entry, asset, taxonomy and redirect. Read-only API access works for most platforms, though WordPress migrations occasionally need database or filesystem access for complex post types. On the Contentful side, an Owner or Admin role on the space is enough for us to create the content model, run the migration scripts and configure roles. We can scope the access tightly and tear it down the day we hand over.

### When migrating articles, should the body be one rich-text block or many?

Both are valid, and the right answer depends on what your editors actually need. A single rich-text body is simpler to migrate and edit, though it limits what you can do with embedded components, experiments inside an article, or analytics on individual sections. Splitting the body into multiple typed blocks (hero, rich text, quote, CTA, and so on) gives editors and marketers far more flexibility, but takes more migration logic to map old HTML cleanly. For article templates that need to keep evolving, the block approach almost always wins out.

### Our Contentful site is losing rankings, can you help?

Yes, this is one of the most common reasons teams bring us in. Contentful sites tend to regress in search when the frontend is slow, when landing pages are stitched together from references that bloat the rendered HTML, or when metadata and structured data weren't part of the original content model. We audit the build, fix the underlying causes, and rebuild the content model, frontend performance and schema markup without forcing a re-platform.

### Can you run A/B tests in Contentful?

Yes. Contentful supports A/B testing and audience-targeted content variants natively, and we wire up the editorial workflow, the analytics tagging and the guardrails so your marketing team can run experiments without an engineering ticket per test.

Plenty of our Contentful work starts on someone else's platform. We move teams over from enterprise systems like Adobe Experience Manager and Sitecore, from WordPress and Strapi, and from other headless tools including Sanity and Storyblok. Each plan below covers the content modelling, the URL and 301 redirect work, the editor training and the cutover, so you can see what the move actually involves before committing to it.

---

## Generative engine optimization


> AI SEO, GEO, and AEO under one roof. Background agents monitor your citations across ChatGPT, Claude, Perplexity, and AI Overviews, draft the fixes, and ship them under your approval.

**Updated:** 2026-08-25
---

A cynical reader might suspect we are keyword stuffing in this section... But whether you're looking for an AI SEO agency, AI SEO services, generative engine optimization agency, generative engine optimization services, AI SEO company, answer engine optimization. _They're all the same god-damn thing_ and they almost all hinge around the same core principles.

> Create well marked-up content, iterate on it faster, and make it easier for AI models to read and understand.

AI SEO is the plain-language term. GEO (generative engine optimization) and AEO (answer engine optimization) are the technical ones, and we use them interchangeably. Whichever acronym you arrived with, the deliverable is identical: find where ChatGPT, Claude, Perplexity, and Google's AI Overviews pull their answers, ship the changes that put you inside those answers, and measure whether your citation share moved. The rest of this page is how we run that loop and more importantly **how fast**.

What most GEO gets wrong

    Most GEO content published today is taxonomy work: "What is GEO?", "GEO vs SEO". LLMs already have this, and it competes with Wikipedia and five hundred near-identical posts. The citation wins live in specific, evidence-backed claims that can't be scraped from a dictionary.

    llms.txt and schema both help. Profound and Vercel publish evidence for llms.txt, and structured data improves crawlability and context. Each is one ingredient. Ship a 30-line llms.txt file or a schema pass on its own, leave content negotiation untouched, and you have optimised the wrong layer.

    Volume without editorial infrastructure is AI slop. LLMs weight source trust, so a corpus full of AI tells and unverified claims trains the wrong signal. More content behind no quality bar can move citation share in the wrong direction.

    A monthly content brief delivered as a PDF is not GEO work. The diagnostic-to-ship gap in advisory retainers is measured in quarters. GEO needs a closed feedback loop: detect a citation shift, draft a remediation, ship it, re-monitor. That loop can't run on a monthly report cadence.

How we do it

Per Ramp's first-party research, markdown was the only format that reliably surfaced in LLM responses. Bots ask for markdown. Browsers get HTML. The same URL can serve both. That is content negotiation, and instrumenting it per page is the single change with the widest citation coverage.

Roboto's own site is the worked example. The content is MDX on disk, so the markdown is the source rather than a format derived from a CMS export. When an LLM crawler asks for markdown at a given URL, it gets a clean document with structured headings, inline links, and no CMS wrapper noise. We wrote up the approach in [our Next.js AEO/GEO guide](/blog/nextjs-aeo-geo). On a CMS-driven stack it's a transform step rather than a route handler, but the goal is the same clean markdown at the canonical URL.

Quarterly advisory cycles break at the feedback step. You get a report in month three describing what happened in month one, and by the time an edit clears approval and publish, the competitive set has shifted again. The diagnostic is stale before the fix ships.

A [background agent](/services/agentic-workflows#background-agents) watches citation share across platforms on a weekly cadence. When share drops on a target prompt cluster, it flags the change, identifies what moved in the competitive set, and drafts the fix: a content edit, a schema patch, an llms.txt update, or a content negotiation rule. One of our engineers reviews it and ships it, then the agent re-monitors that cluster and measures whether share recovered. We run this on our own site and documented the build in [why we built our own background agent](/blog/why-we-built-our-own-background-agent). For an engagement we set the same loop up on your stack: your data sources, your content repo, your approval flow.

Bot classification is where most implementations break. Single-signal classification on User-Agent alone misses the bulk of AI crawler traffic. Correct classification combines UA, IP range, ASN, and bot score. The Cloudflare gotcha compounds it: ChatGPT, Perplexity, and Claude bots are categorised as "AI Assistants" in Cloudflare's taxonomy, not "AI Search", so firewall and analytics rules targeting only "AI Search" miss all three major platforms.

The rest is table stakes we verify before touching anything higher up. Schema goes in where it helps LLMs parse structure (ServiceSchema, FAQPage, BreadcrumbList, Article). The llms.txt file gets prioritisation logic rather than a flat list of 400 pages. Crawlability is genuinely non-negotiable: every list item rendered into the DOM, navigation in static HTML, correct status codes, and clean submitted sitemaps.

Volume compounds citation share only when the content clears a quality bar that LLMs trust. The editorial infrastructure is what makes volume safe to ship, so we build three gates into the publishing pipeline.

An automated check runs before merge, flagging em-dashes, negative parallelism, and the vocabulary we've caught models overusing; content that fails goes back to be rewritten. A fact-checker agent verifies specific claims against their cited primary sources and flags any that don't hold. A final editing pass strips the sentence structures that read as generated. The cms-auto-updater pipeline is the worked example: it pulls evidence from primary sources on a weekly cadence, drafts updates, runs all three gates, and queues each change for human sign-off before it publishes. The result is far more content per quarter without the citation-eroding slop that comes from raw AI publish pipelines.

How we deliver

    Fixed-scope review of your current citation footprint and technical readiness. Covers content negotiation, bot classification, schema, llms.txt, and crawlability, plus competitor citation analysis across target prompt clusters and a prioritised remediation roadmap ordered by expected impact. Duration: 1 to 2 weeks. Deliverable: written report and walkthrough call.

    Implementation engagement. We wire up content negotiation across key pages, fix bot classification, implement llms.txt with prioritisation logic, add schema where missing, and restructure high-value content for citation extraction. Monitoring dashboards for citation share, crawler activity, and AI-referral traffic come standard. Duration: 4 to 6 weeks typical, scoped per engagement.

    Everything above running continuously on your stack. Weekly agentic monitoring across citation, crawler, and search data sources. Agent-drafted fixes reviewed and shipped by Roboto. Monthly synthesis call covering what moved, what we shipped, and what's queued. Re-baselined quarterly. Minimum 3-month commitment.

Part of this retainer is a weekly agent that audits the analytics platforms you already use, condenses them into one place, and hands your team the next steps to take. It does the reading and the triage so the monthly call is about decisions, not dashboards.

When a community thread outranks your own page, that thread is an opportunity. This bot finds those threads for your keywords and drafts a response built from your own content, so you get a second touch point on a page that already wins the search.

## The skeptic's FAQ

What people actually want to know about GEO

### Does llms.txt actually do anything?

It helps, and Profound and Vercel publish positive evidence on it. Ramp's first-party experiment notably didn't recommend it as a lead tactic. Treat llms.txt as one layer alongside content negotiation, schema, and crawlability, not a silver bullet.

### Is AI SEO the same as GEO and AEO?

Yes. AI SEO is the buyer-facing label. GEO (generative engine optimization) and AEO (answer engine optimization) are the technical names for the same work: getting cited inside AI answers rather than ranking blue links. We use the terms interchangeably. Anyone selling them as three separate products is inventing scope.

### Is GEO real or just SEO with a new label?

The substrate is different. SEO optimizes for ranked search results. GEO optimizes for citation inside an LLM response. The technical work overlaps (crawlability, schema, content quality) but the diagnostic loop is new: which prompts cite you, which models, on which platforms, and how that share moves week to week. Selling an SEO retainer as a GEO retainer is the grift.

### How fast can citations actually move?

Faster than organic rankings, slower than paid ads. A substrate change like content negotiation, a schema patch, or a content rewrite can move citation share within weeks rather than the quarters an advisory retainer takes to close the loop. How fast depends on your starting point and how competitive your target prompt clusters are.

### Why isn't publishing more content the answer?

Volume without editorial gates and fact-checking compounds AI slop. Doubling publishing cadence without those gates risks moving citation share the wrong way, because LLMs deprioritize low-trust sources. The win is volume with infrastructure: checks that catch AI-sounding phrasing before publish, fact-checker agents that verify claims against primary sources, and an editing pass that strips the expressions we've caught models overusing.

### Do I need GEO if I already do SEO?

If your buyers use ChatGPT, Claude, Perplexity, or Google AI Overviews to evaluate vendors, yes. The first-party data shows AI search is now a meaningful share of the discovery funnel. If your buyers still arrive exclusively via blue-link Google, no, but that's a shrinking population, especially in B2B.

Recent builds we've shipped

The research behind it

    The most specific public dataset on AI citation dynamics to date. Reddit citation share roughly doubled October 2025 to January 2026. Perplexity attributes 31% of all citations to social media, with Reddit at 24%. AI Overviews citations dropped 46% in the same period. The implication: social platforms are now a primary citation surface, and tracking only your own domain misses where citations originate. [Source: tryprofound.com](https://www.tryprofound.com)

    First-party experiment on what formats LLMs actually surface. Markdown was the only format that reliably appeared in responses. Bot classification requires combining UA, IP, ASN, and bot score, since single-signal approaches miss the major platforms. llms.txt was not recommended as a lead tactic in their findings. [Source: builders.ramp.com](https://builders.ramp.com)

    A playbook for distinguishing real LLM crawlers from spoofed user agents via server log analysis. The spoofing rate for AI crawlers is material, so acting on UA alone gives a distorted picture of which platforms are actually crawling your content and how often. Server logs are the ground truth. [Source: merj.com](https://merj.com)

    First-party data from Vercel's CDN on AI crawler behaviour, llms.txt adoption and impact, and framework-level responses to AI traffic. Their data shows a positive correlation between llms.txt presence and citation rate, alongside the content negotiation patterns that improve LLM ingestion. [Source: vercel.com/blog](https://vercel.com/blog)

    Mike King's technical research on the factors that correlate with LLM citation: content structure, entity coverage, E-E-A-T signals as proxied by LLMs, and the structural differences between content that gets cited and content that doesn't. One of the more rigorous public treatments of GEO. [Source: ipullrank.com](https://ipullrank.com)

    Research on how AI Overviews affect click-through rates on organic results, and the crossover between pages that rank organically and pages that get cited in AI responses. The data suggests high overlap at the top end, so strong organic pages stay relevant while citation remains a separate signal worth tracking on its own. [Source: ahrefs.com/blog](https://ahrefs.com/blog/)

From the blog

## Ready to find out if AI engines cite you?

If your buyers research vendors through ChatGPT, Claude, Perplexity, or Google AI Overviews and you don't know whether you show up, a discovery call is the fastest way to find out. We'll show you the citation gap and walk you through the closed-loop fix.

---

## Headless CMS agency


> Headless CMS development agency for content teams operating at scale. We model structured content, build on Sanity and Contentful with Next.js frontends, and run migrations that keep your URLs and rankings intact.

**Updated:** 2026-08-25
---

## The headless CMS agency that specializes on purpose

### Most headless CMS agencies list eight platform partnerships and call it flexibility. We build on Sanity and Contentful, because depth beats a badge wall: one of 15 starred partners in Sanity's 218-agency directory, Contentful Silver Solution Partner, and a 550-page migration matrix covering the platforms we've moved teams off.

Structured content is the whole job. We model your content around how your editors work, ship the CMS and the Next.js frontend, and stay for the unglamorous part: the schema that still makes sense at the tenth content type, the integration that survives the next webhook change, the migration that keeps your rankings. If your content estate would be better served by something we don't build, we'll tell you on the first call.

    The difference between a headless CMS your editors love and one they file tickets about is the content model. We design schemas around editorial workflows, with reusable blocks, sensible references and validation that catches mistakes before publish.

    Sanity or Contentful, and occasionally neither. We hold partner status with both platforms, so the recommendation follows your content model, your team and your budget rather than whichever vendor paid for the badge.

    Statically generated, ISR or fully streamed, whichever fits the traffic. Live preview wired into the editor, cache invalidation that fires when content changes, and Core Web Vitals your marketing team can quote.

    Moving off WordPress, Drupal, AEM, Sitecore or HubSpot means mapping every legacy URL, preserving SEO equity with 301s, and training editors before the cutover. Our migration playbooks cover 24 platforms in every pairing.

    Drafting, translation, semantic search and agent-driven publishing, built into the CMS your editors already use, with approval workflows wherever a human should sign off. We run our own content operation this way.

    Meta fields, structured data and canonical logic live in the content model, so pages can't ship without them. And because search now includes AI answers, every build gets the crawlability work that makes it citable by ChatGPT, Perplexity and AI Overviews.

## Depth in two platforms, not a logo wall

We're [one of 15 starred agencies in Sanity's 218-agency partner directory](https://www.sanity.io/agency-partners/roboto-studio), authors of both official Sanity Learn courses on Next.js and creators of [Turbo Start Sanity](https://www.sanity.io/templates/turbo-start-sanity), the starter other Sanity agencies fork. On the Contentful side we're a [Silver Solution Partner](/services/contentful) with Certified Professionals shipping composable commerce builds. We've shipped headless platforms for Tray.ai, Warner Bros, Tabby and Global Cycling Network.

Headless builds we've shipped

## Thinking about going headless?

The questions we get asked on every headless CMS scoping call.

### What is a headless CMS agency?

An agency that designs and builds content platforms where the CMS is decoupled from the frontend. The work spans content modeling, CMS selection and setup, frontend development, migrations from legacy platforms, and the editorial workflow design that decides whether editors love or resent the result. The decoupling is the easy part; the content model is where projects are won or lost.

### Which headless CMS do you recommend?

Sanity for most teams: it handles nested structures, reusable blocks and real-time collaboration more gracefully than anything else we've shipped, which is why [it's our default](/services/sanity). Contentful when the requirements lean enterprise: strict governance, heavy localization, procurement that wants a big vendor, which is why [we hold Silver partner status there too](/services/contentful). The recommendation follows your content model rather than our margin.

### Do we need a headless CMS at all?

Headless earns its keep when content outgrows one website: multiple channels pulling the same content, structured reuse across many page types, several editors working in parallel, or a frontend your CMS vendor doesn't control. For a small brochure site with one editor, a traditional CMS still does the job, and we'll say so in the scoping call rather than sell you architecture you don't need.

### What frontend do you build with?

Next.js, almost always. Server components and streaming fit the headless delivery model, and Vercel's caching primitives make CMS-triggered revalidation reliable instead of hopeful. For content sites with no interactive logic we occasionally recommend Astro. Either way the frontend is built from the content model out, not bolted on after.

### Can you migrate us from our current CMS?

Yes. We've moved teams off WordPress, Drupal, Adobe Experience Manager, Sitecore, HubSpot, Webflow and most things in between; the [migration matrix](/migration) documents every pairing. Every migration gets a full URL map with 301s, a schema redesign rather than a lift-and-shift, and editor training before cutover so publishing never pauses.

### How does headless CMS pricing work?

Two costs: the platform license and the implementation. Sanity and Contentful both run generous free tiers into paid plans priced on users, locales and API usage. The implementation is usually the larger number in year one, and it's where a clean content model pays for itself, because schema rework after launch costs multiples of getting it right first. We scope both numbers honestly on a call.

### Do you work alongside in-house developers?

Constantly. The most common split: your team owns the product and frontend roadmap, we own the content platform, the schema and the migration. When you'd rather run the whole stack yourselves, [our workshops](/services/workshops) transfer it in five days.

### What goes wrong with headless CMS projects?

The schema, nearly every time. Builds get modeled around the first page someone wanted to ship, references get stored as strings, and the page builder turns into a maze nobody can edit safely. Most of our rescue work starts there. If you're already living with one of these builds, we'll audit it and tell you honestly whether to fix it, rebuild the schema, or migrate.

Most headless projects start on a platform that's run out of road. We've replatformed teams from WordPress, enterprise suites like Adobe Experience Manager and Sitecore, and page builders like Webflow and HubSpot. Each migration page below covers the schema work, the URL and 301 plan, the editor training and the cutover playbook we use.

**Tell us what you're building.** A first headless build, an escape from a legacy CMS, or a headless project that went sideways under another agency: we'll scope it honestly in a 20-minute call and tell you which platform fits, including when the answer is neither.

From the blog

---

## Next.js app development


> Vercel agency partners building serious Next.js apps: dashboards, AI products, content platforms and hybrid SaaS surfaces.

**Updated:** 2026-08-25
---

## Next.js apps, built for the first real version

AI chat, customer portal, authenticated workflow, dashboard, CMS-backed product surface. We take early product ideas from brief to production quickly, with the foundations in place for the second and third versions too.

We build the interface, app architecture, content and data layer, and Vercel deployment model together. Auth, caching, streaming AI responses, cost controls, observability and previews are part of the product from the start.

Companies of all sizes trust Roboto Studio

## Silver-tier Vercel partner

A Silver Solution Partner for Vercel, shipping production Next.js across App Router, React Server Components, streaming, ISR, Server Actions and edge routing. Our delivery process is shaped by the ISO 27001 work we have underway, with clear ownership, documented decisions and sensible conventions from day one.

Jono and his team are absolute rockstars. They blend technical savvy with practical business sense. They are in lock-step with our website goals and have really made our website come to life. Not just a web dev team, they are trusted advisors and truly aligned with our team.

Most of our Next.js work starts when a product idea needs to become real quickly, without building on throwaway foundations. An AI chat interface. A customer portal. A partner dashboard. A CMS-backed product surface with authentication, permissions and billing logic sitting behind the public site.

We like that stage. The scope is still moving, but the early technical decisions matter: auth shape, data boundaries, caching, AI provider strategy, deployment model, observability, cost controls and where the app should lean on the server instead of pushing everything into the browser.

Our job is to get you to a first version fast, then make sure it is not a dead end. You get something customers can use, investors can understand and your team can keep extending after the first round of feedback.

The parts that make apps feel good

    Dashboards, reports, portals and account views need data fetching that is boring in the best way. We keep the heavy work on the server, stream the slow parts, and avoid client-side soup unless the interaction really needs it.

    Chat, generation, review queues, agent workflows, embeddings search, streamed responses and human approval steps. We build the interface around latency, state and failure, not just the happy-path demo.

    A SaaS app still needs landing pages, docs, case studies, changelogs and campaign pages. We wire CMS or MDX content into the same design system so the public site and logged-in product do not feel like two companies.

    We build the boring gates properly: sessions, roles, protected routes, account states, invitation flows and server-side checks. The app should know who is allowed to do what before the button even renders.

    Multi-step onboarding, settings screens, uploads, checkout handoffs, CRM syncs and admin actions need validation, optimistic states, retries and clear failure paths. That is where apps feel either polished or held together with tape.

    Vercel Firewall rules, cache behavior, secrets, preview deployments, analytics events, error reporting, web vitals, redirects and rollback plans. The app is not finished when it compiles.

Case studies

Next.js is a strong fit when the product has to mix public demand generation with private application logic. The same build can serve SEO pages, onboarding, account areas, customer data, AI chat, file workflows, admin tools and CMS-driven content without splitting the experience across separate frontends.

For AI products, we pair the interface work with the orchestration work. [AI Elements](https://elements.ai-sdk.dev/) gives us a strong starting point for chat, tools, sources, reasoning states, attachments and workflow interfaces. [Workflow SDK](https://workflow-sdk.dev/) is where the longer-running parts belong: agent runs, human approval steps, retries, resumable streams, file processing, follow-ups and background jobs that need state and observability.

For portals, the shape is different but the standard is the same. Authentication, roles, permissions, dashboards, documents, payments, notifications and support workflows should sit in a clear product architecture. Best practice here means server-first data fetching, small client islands, typed validation, predictable mutations, careful cache boundaries and no hidden mess between the public site and the logged-in app.

The Vercel layer matters too. We tune runtime choices, caching, observability, firewall rules, deployment previews and AI Gateway usage so the app is fast, resilient and cost-aware. AI spend and Vercel spend are part of the architecture conversation from day one.

Most teams come to us when they need senior Next.js developers who can own the whole app, not a single slice of the frontend. We work as an embedded team: a lead engineer who learns your codebase, designers and developers alongside, and Vercel partner experience to draw on when the platform questions get hard.

You can hire us for a fixed-scope first version, an ongoing build, or a focused piece of work like an AI feature, an auth rebuild or a performance pass. Either way you get developers who have shipped production Next.js across App Router, Server Components, streaming and edge routing, and who keep caching, observability, cost controls and the second release in view from day one.

## Thinking about your next Next.js build?

The questions that come up on every Next.js scoping call.

### What does a Next.js development agency actually do?

Build the application end to end: interface, app architecture, data and content layer, auth and permissions, and the Vercel deployment model. Those decisions interlock, which is the whole argument for one team owning them together.

    Where it goes wrong is an agency that takes the React layer only and leaves caching, session handling, cost control and observability for someone else to solve later.

### How much does it cost to hire a Next.js agency?

We quote after a scoping call rather than publishing a rate card, because the gap between a focused AI feature and a full product build is enormous. What moves the number: how much of the product already exists, whether auth and billing are in scope, how many systems sit behind the interface, and whether you want us shipping after launch.

    You get a scope and a price for the first version before anyone writes code.

### Can we hire Next.js developers to work inside our team?

Yes, and that is how most of our engagements run. A lead engineer learns your codebase and works in your repo and your standups, with designers and other developers alongside as the work demands.

    You can also hire us for a fixed-scope first version, or for one focused piece of work like an auth rebuild, an AI feature or a performance pass.

### What does your Vercel partnership actually get us?

We are a Silver Solution Partner, so Vercel has reviewed our production work and we have a direct line to their team when a platform question gets hard.

    Day to day it shows up in unglamorous places: runtime choices, cache boundaries, firewall rules, preview deployments, AI Gateway usage and keeping the bill predictable as traffic grows.

### When is Next.js the wrong choice?

When the site is pure content with no application logic behind it. A brochure site or a documentation set is often better served by [Astro](/services/astro), and we will tell you that rather than sell you a heavier build.

    Next.js earns its complexity when marketing pages and a logged-in product have to live in one codebase: SEO pages, onboarding, account areas, dashboards, admin tools and AI features on the same deploy.

### How long until we have something in production?

For a first version of a focused app, weeks rather than quarters. Portals and AI products with real auth, billing and third-party integrations take longer, and we scope those in stages.

    We would rather put a narrow version in front of customers early and extend it than disappear for a quarter and hand over something nobody has used.

### Will you work on an existing Next.js codebase?

Often. Inherited apps are a steady part of the work: Pages Router upgrades, App Router migrations, rendering and caching that got away from the team, Vercel bills nobody can explain.

    We start with an audit and tell you honestly whether the codebase is worth extending or whether the parts causing the pain need rebuilding.

From the blog

---

## Sanity support retainer


> A named Sanity support retainer from one of 15 starred Sanity partners. Studio upgrades, schema evolution, incident response, performance monitoring and editor support, for builds we shipped and builds we inherited.

**Updated:** 2026-08-25
---

## Support from the people who write the playbook

### A monthly retainer that keeps your Sanity studio upgraded, monitored and moving: schema changes shipped, incidents answered, editors supported. Run by one of 15 starred partners in Sanity's 218-agency directory.

Every Sanity studio needs someone on the hook for it. Dependencies age, schemas outgrow their first design, editors hit walls, and the agency that built it has often moved on. The retainer puts our team on that hook: the same people who ship production studios, author the official Sanity Learn courses and maintain Turbo Start Sanity, pointed at keeping yours healthy.

## The unglamorous work that keeps a studio healthy

### Scope agreed in writing at sign-up: upgrades, schema evolution, incident response, monitoring, editor support and a monthly improvements allowance.

**Upgrades and maintenance.** Studio versions, plugin updates and dependency patches applied on a schedule, tested before they touch production.

**Schema evolution.** Content models drift out of date as the business changes. New page types, field changes and validation rules get shipped through the retainer instead of queueing for a project.

**Incident response.** Production issues acknowledged the same business day, with a priority queue ahead of routine work. Specific response windows are agreed per plan.

**Performance and SEO monitoring.** Core Web Vitals, structured data and index coverage watched month over month, so regressions get caught by us rather than by your traffic report.

**Editor support and training.** A channel for your editors' questions, and training when new team members join or new studio features land.

**Monthly improvements allowance.** The small items that never justify a project: a new component here, a workflow tweak there. They get shipped instead of listed.

## We take over Sanity builds other agencies left behind

Half the studios we support were built by someone else. The pattern is familiar by now: the build shipped, the invoices stopped, the replies slowed, and the team is left with a studio nobody fully understands. We start those engagements with an audit, tell you honestly what state the build is in, and then either stabilise what's there or fix the schema problems that are worth fixing. [Mario Testino's team came to us exactly this way](/case-study/mario-testino), and the audit-first approach is why that story gets told in our reviews.

## One of 15 starred Sanity partners

Sanity's partner directory lists 218 agencies and stars 15 of them. We're one of the 15, which matters for support in a practical way: when an issue is genuinely on the platform side, we have a direct line to Sanity rather than a ticket queue.

## Thinking about a support retainer?

The questions we get asked before every retainer scoping call.

### What does the Sanity support retainer include?

Studio and dependency upgrades, schema changes as your content needs evolve, incident response for production issues, performance and SEO monitoring, editor support and training, and a monthly allowance for small improvements. The exact scope is agreed at sign-up so there's no ambiguity about what counts.

### Do you only support studios you built?

No. Inherited builds are half the point of the retainer. We audit the existing studio first, tell you honestly what state it's in, and either stabilize it as-is or propose the schema fixes worth making. We've taken over Sanity builds from agencies that ghosted, and from agencies that just moved on.

### What are the response times?

Production incidents get acknowledged the same business day and jump the queue. Routine requests are scheduled into the monthly allowance. Specific response windows are agreed per plan at sign-up, in writing, because a support promise that lives in a sales call isn't one.

### How does retainer pricing work?

A fixed monthly fee scoped to your studio's size and how much change you push through it. We'll give you the number on a scoping call after a look at the build, because quoting blind is how retainers end up mispriced and resented on both sides.

### Do you support Contentful too?

Yes. We're a [Contentful Silver Solution Partner](/services/contentful), and the same retainer structure works for Contentful spaces. Mention it on the scoping call and we'll shape the plan accordingly.

### What isn't covered by the retainer?

Net-new builds, full redesigns and large [migrations](/services/cms-migration) are project work, scoped separately. The retainer keeps a production studio healthy and moving; it isn't a discounted way to buy a rebuild. When retainer work uncovers something bigger, we'll flag it with options rather than quietly burning the allowance on it.

### Why hire a Sanity specialist for support instead of a general dev shop?

Because most Sanity problems are schema and content-model problems wearing a frontend costume. A generalist patches the symptom; we've built enough studios to recognize the cause. Being [one of 15 starred partners in Sanity's directory](https://www.sanity.io/agency-partners/roboto-studio) also means a direct line to Sanity when a platform issue is genuinely on their side.

**Tell us about your studio.** Whether we built it, another agency built it, or nobody remembers who built it, the first step is the same 20-minute call: what you're running, what keeps breaking, and what a sensible retainer looks like for it.

From the blog

---

## Sanity CMS development agency


> Sanity CMS development agency for teams shipping content at scale. Preferred Sanity partner, community ambassadors and authors of Turbo Start Sanity. We build studios, migrate from WordPress and Strapi, and tune Sanity so editors actually want to use it.

**Updated:** 2026-08-25
---

Why Roboto Studio?

## Enterprise teams trust us with the build

### Helix in genomics, Global Cycling Network in sports media, Tabby in fintech. All ran on Sanity Studio we built.

Each arrived with its own procurement, security review and legacy stack. Our delivery process is shaped by the ISO 27001 work we have underway.

## AI tooling built for your editorial team

### Background agents that research a topic, check every claim against a live source, and hand your editors a sourced first draft.

[Semantic search](/blog/building-a-search-bar-with-sanity-embeddings-index-api-and-nextjs) on Sanity's embeddings index. Keyword gaps pulled from Ahrefs. Whatever your content team needs, wired into the studio.

    Sanity is a database with an editor on top, not a website tool. Your site, your app and whatever you launch next read the same content through one API.

    Scheduled releases, granular roles and real-time collaboration in one place. Your team runs a launch without a spreadsheet tracking who changed what.

    Sanity Media Library gives an organization one asset store across every studio, with custom metadata and collections. We add automated OG images and per-channel crops on top.

    Sanity Connect mirrors your Shopify catalog into the Content Lake so editorial wraps around live product data. [turbo-start-shopify](/tools/turbo-start-shopify) is the starter we ship it on.

    Presentation gives editors click-to-edit overlays on the real page, next to the studio. They preview a campaign, hit publish and watch the live site change without a redeploy.

    When the defaults run out of road we extend the studio. Custom input components, internal dashboards and workflow widgets Sanity doesn't ship, all yours to keep.

## 9 in 10 builds we take on are migrations

### Off a legacy CMS, or off a studio another agency walked away from. We have taken over both mid-crisis.

The Mario Testino archive came to us at 200% API overage with 160+ redirects missing. Each page below covers the schema, the 301 plan and the cutover.

## One studio, every language

### Tabby publishes across its markets in Arabic and English from a single Sanity studio.

Right-to-left styling lives in the component library, not patched on afterwards. One content model, one editorial workflow, every locale.

## What Sanity will cost you

The canonical page renders an interactive estimator here. The tables below cover its full answer space, generated from the same logic. Preset usage figures are modelled estimates derived from Sanity's published quotas, except where a preset says measured — those were read off a real account we run, with the client kept anonymous. Roboto Studio does not resell Sanity seats.

### Plan limits

| Plan | Editor seats | Documents | Asset storage | Bandwidth/mo | API CDN requests/mo | Uncached API requests/mo | Price |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Free | Up to 20 | 10,000 | 100 GB | 100 GB | 1M | 250K | $0 forever |
| Growth | Up to 50 | 25,000 | 100 GB | 100 GB | 1M | 250K | $15 per seat/month |
| Enterprise | Custom | Custom | Custom | Custom | Custom | Custom | Talk to Sanity |

Free has no overage billing: exceed a quota and the next step is Growth, not a bill.

### Overage rates

| What bills | Included on Growth | Rate over quota |
| --- | --- | --- |
| Bandwidth | 100 GB a month | $0.30 per GB |
| API CDN requests | 1M a month | $1 per 250K requests |
| Uncached API requests | 250K a month | $1 per 25K requests |
| Asset storage | 100 GB | $0.50 per GB |
| Documents | 25,000 | $299/mo for 50,000 documents |
| Extra datasets | 2 included | $999 per dataset/mo |

An uncached API request costs ten times what the same request costs through the API CDN. That ratio, not content volume, is what turns a badly modelled front end into an overage bill.

### Implementation quality levels

| Level | What it means | Request multiplier | Payload multiplier | Share of requests missing the CDN |
| --- | --- | --- | --- | --- |
| Well modelled | Queries fetch only the fields a page renders, and responses are cached at the edge. | 1x | 1x | 2% |
| Typical | Queries pull more than the page needs, and caching is applied unevenly across routes. | 3x | 2.2x | 15% |
| Naive | Whole documents fetched from the browser on every render, straight past the CDN. | 12x | 6x | 55% |

**Well modelled.** Queries fetch only the fields a page renders, and responses are cached at the edge.

- GROQ projections limited to the fields the page renders
- One content query per route, resolved on the server
- Served through the API CDN and cached at the edge
- Uncached requests reserved for previews and webhooks

**Typical.** Queries pull more than the page needs, and caching is applied unevenly across routes.

- Partial projections, with whole nested objects pulled in wholesale
- Several queries per route instead of one composed query
- CDN used for most routes, bypassed on the ones that were awkward
- Revalidation windows short enough to re-fetch far more than needed

**Naive.** Whole documents fetched from the browser on every render, straight past the CDN.

- No query projection — whole documents fetched and filtered in JavaScript
- Client-side GROQ firing on every render and every navigation
- Hitting the uncached API directly, so the CDN never absorbs the load
- References resolved one request at a time instead of joined in GROQ

### Estimated monthly cost by archetype and implementation quality

| Archetype | Implementation | Pageviews/mo | Documents | Editor seats | Assets | Plan | Estimated monthly cost | Overages |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Simple portfolio | Well modelled | 5,000 | 120 | 1 | 3 GB | Free | $0/mo | None |
| Simple portfolio | Typical | 5,000 | 120 | 1 | 3 GB | Free | $0/mo | None |
| Simple portfolio | Naive | 5,000 | 120 | 1 | 3 GB | Free | $0/mo | None |
| Marketing site | Well modelled | 40K | 400 | 4 | 8 GB | Growth | $60/mo | None |
| Marketing site | Typical | 40K | 400 | 4 | 8 GB | Growth | $60/mo | None |
| Marketing site | Naive | 40K | 400 | 4 | 8 GB | Growth | $80.69/mo | Bandwidth $18.55; Uncached API requests $2.14 |
| High-traffic marketing site | Well modelled | 100K | 2,900 | 22 | 7 GB | Growth | $330/mo | None |
| High-traffic marketing site | Typical | 100K | 2,900 | 22 | 7 GB | Growth | $330/mo | None |
| High-traffic marketing site | Naive | 100K | 2,900 | 22 | 7 GB | Growth | $441.74/mo | Bandwidth $91.38; Uncached API requests $20.36 |
| Documentation site | Well modelled | 180K | 3,500 | 8 | 5 GB | Growth | $120/mo | None |
| Documentation site | Typical | 180K | 3,500 | 8 | 5 GB | Growth | $125.72/mo | Bandwidth $5.72 |
| Documentation site | Naive | 180K | 3,500 | 8 | 5 GB | Growth | $353.60/mo | Bandwidth $188.48; API CDN requests $0.47; Uncached API requests $44.65 |
| High-traffic blog | Well modelled | 750K | 6,000 | 12 | 60 GB | Growth | $233.64/mo | Bandwidth $53.64 |
| High-traffic blog | Typical | 750K | 6,000 | 12 | 60 GB | Growth | $309.17/mo | Bandwidth $118.85; API CDN requests $4.80; Uncached API requests $5.52 |
| High-traffic blog | Naive | 750K | 6,000 | 12 | 60 GB | Growth | $1,292.68/mo | Bandwidth $880.35; API CDN requests $14.63; Uncached API requests $217.70 |
| Multi-brand ecommerce | Well modelled | 2M | 45,000 | 35 | 250 GB | Growth | $2,096.07/mo | Bandwidth $193.05; API CDN requests $5.02; Asset storage $75; Documents $299; Extra datasets $999 |
| Multi-brand ecommerce | Typical | 2M | 45,000 | 35 | 250 GB | Growth | $2,315.79/mo | Bandwidth $366.93; API CDN requests $19.46; Uncached API requests $31.40; Asset storage $75; Documents $299; Extra datasets $999 |
| Multi-brand ecommerce | Naive | 2M | 45,000 | 35 | 250 GB | Growth | $4,938.48/mo | Bandwidth $2,397.60; API CDN requests $45.68; Uncached API requests $597.20; Asset storage $75; Documents $299; Extra datasets $999 |
| News publisher | Well modelled | 3M | 90,000 | 40 | 400 GB | Enterprise | Custom pricing | Bandwidth $304.58; API CDN requests $9.52; Asset storage $150; Documents $299 |
| News publisher | Typical | 3M | 90,000 | 40 | 400 GB | Enterprise | Custom pricing | Bandwidth $565.40; API CDN requests $31.19; Uncached API requests $52.10; Asset storage $150; Documents $299 |
| News publisher | Naive | 3M | 90,000 | 40 | 400 GB | Enterprise | Custom pricing | Bandwidth $3,611.40; API CDN requests $70.52; Uncached API requests $900.80; Asset storage $150; Documents $299 |

**Simple portfolio.** A personal site: a handful of pages, one person publishing. Modelled from Sanity's published quotas, not measured from a client account.

**Marketing site.** Twenty or so pages, a small blog, and a handful of people publishing. Modelled from Sanity's published quotas, not measured from a client account.

**High-traffic marketing site.** A marketing site at 50k+ sessions a month, with a large publishing team. Seats, documents, assets and traffic measured from a real Growth account in August 2026. On that account bandwidth was the one line that billed, and its measured bandwidth ran well past the modelled figure shown here.

**Documentation site.** Deep page count, heavy internal linking, very little imagery. Modelled from Sanity's published quotas, not measured from a client account.

**High-traffic blog.** Editorial cadence of several posts a day, with a large image library. Modelled from Sanity's published quotas, not measured from a client account.

**Multi-brand ecommerce.** Several storefronts, deep product catalogue, separate datasets per brand. Modelled from Sanity's published quotas, not measured from a client account.

**News publisher.** Continuous publishing, a large archive, and a newsroom on staggered shifts. Modelled from Sanity's published quotas, not measured from a client account.

Usage figures above are modelled estimates unless a preset's note says measured. Request and bandwidth volume is modelled from the inputs, even on measured presets. Prices and quotas are Sanity's own, checked 2026-08-11. Source: https://www.sanity.io/pricing

## What Sanity costs

| Plan | Seats | Documents | CDN API requests/mo | Price |
| --- | --- | --- | --- | --- |
| Free | Up to 20 | 10,000 | 1M | $0 forever |
| Growth | Up to 50 | 25,000 | 1M | $15 per seat/month |
| Enterprise | Custom | Custom | Custom | Talk to Sanity |

*Sanity's own list prices, verified 2026-07-30. Roboto Studio does not resell Sanity seats.*

## What we've shipped

| Figure | What it covers | Resources |
| --- | --- | --- |
| 500k | Pages migrated to Vercel in six weeks, the largest re-platform we have run | [Tray.ai](/case-study/tray) |
| 99.86% | Faster builds, a full workday down to two minutes | [Tray.ai](/case-study/tray) |
| 200% | Sanity API overage eliminated on a live photography archive | [Mario Testino](/case-study/mario-testino) |
| 160+ | Redirects recovered after another agency's botched migration | [Mario Testino](/case-study/mario-testino) |
| 3 months | WordPress and Shopify converged into one Sanity storefront, design through to launch | [Slingshot Bio](/case-study/slingshot-bio) |

## The documentation agent we built

### Ask it anything and it reads your docs and your site's code, then answers from what it actually found.

It tracks your codebase instead of a stale snapshot, so marketing stops queuing behind an engineer for answers.

## Sanity's official Next.js courses are both ours

[Page building](https://www.sanity.io/learn/course/page-building) and [SEO optimization](https://www.sanity.io/learn/course/seo-optimization). We're the only agency ever to write official Sanity Learn courses. [Turbo Start Sanity](https://www.sanity.io/templates/turbo-start-sanity) is ours too, the starter every new studio here begins from.

More Sanity builds we've shipped

## Thinking about building with Sanity?

The questions we get asked on every Sanity scoping call.

### What is Sanity CMS?

Sanity is a headless, API-first content platform. Editors work in Sanity Studio (a customizable React-based editor that runs in the browser), and content is stored in Content Lake and delivered through GROQ, GraphQL or the Live Content API to whatever frontend you're building. The Studio is fully open source, so the parts that don't quite fit your team can be extended or replaced. That's where most of our work happens.

### How does Sanity CMS pricing work?

The Free plan covers 20 seats, 10,000 documents and 1M CDN API requests a month at $0. Growth is $15 per seat per month for up to 50 seats and 25,000 documents, with the same API allowances plus pay-as-you-go overages beyond them. Enterprise is custom pricing for teams that need SSO, custom roles or a dedicated SLA.

    The honest answer most agencies skip: budget for the implementation and content-modeling work too. The license is usually a small fraction of total cost in year one, and a well-modeled studio earns that fee back inside the first few campaigns.

### Is Sanity free?

Yes, and the free plan stays free with no time limit. It covers 20 user seats, 10,000 documents, 1M CDN API requests a month, 250K regular API requests and 100GB of assets.

    You outgrow it when you need more than 20 seats, more than 10,000 documents, scheduled publishing, private datasets, or roles beyond admin and viewer. The next step up is Growth at $15 per seat per month.

### How much does Sanity cost per user?

$15 per seat per month on the Growth plan, charged for editor seats only, with viewer seats free. Growth runs up to 50 seats, so a team of 10 editors pays $150 a month before any overages.

    Under 20 seats the Free plan costs nothing. Past 50 seats, or if you need SSO or custom roles, you move to Enterprise and Sanity quotes you directly.

### How long does a WordPress to Sanity migration take?

For a site of 500 to 2,000 pages, 4 to 8 weeks end to end. Mapping your existing content model to a Sanity schema is 1 to 2 weeks of that.

    Editor training is a 2 hour onboarding session and most teams publish confidently inside a week. Livemore's marketing team shipped 12 campaign pages in their first month on the studio we built.

### Sanity CMS vs WordPress: which one should we move to?

If your team is mostly publishing blog posts on a single website and you're happy with WYSIWYG editing, WordPress is fine. If you're publishing structured content into multiple channels (a website, a mobile app, an in-store screen), or your editors keep hitting WordPress's limits with custom fields and ACF workarounds, Sanity is the right move.

    We run WordPress-to-Sanity migrations regularly: we map every legacy URL, preserve SEO equity with 301s, redesign the content model around how editors actually work, and train the team before cutover so they're ready to publish on launch day.

### Sanity CMS vs Strapi: what's the difference?

Strapi is self-hosted and open source; Sanity is hosted with a much more polished editor and a real-time Content Lake. Strapi makes sense if data residency or self-hosting is non-negotiable and you have the DevOps budget to run it. Sanity makes sense for almost everyone else. The editor, the live preview, the Presentation tool and scheduled publishing are years ahead, and you don't pay for the infrastructure to keep them running. We've migrated teams in both directions and Sanity wins on editorial velocity in most scenarios.

### Can Sanity be self-hosted?

Sanity Studio (the editor) is open source and runs anywhere you deploy a Next.js or Vite app: Vercel, your own infrastructure, behind a VPN. The Content Lake (the database) is Sanity-hosted and not available as a self-hosted product. For teams with strict data residency requirements, Sanity offers regional hosting and Enterprise data-handling agreements; we'll walk you through the options on a scoping call.

### What framework do you recommend with Sanity?

Next.js, almost always. The App Router, server components and streaming model fit Sanity's GROQ-on-the-server pattern perfectly, and Vercel's caching primitives make `revalidateTag` invalidations from Sanity webhooks trivial.

    For brochure sites with no interactive logic we'll sometimes recommend Astro instead, but nine out of ten production builds end up on Next.js, which is why [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity) is a Next.js + Sanity starter.

### My last Sanity build was a mess. Is Sanity actually the problem?

Almost never. Every time we've inherited a "painful" Sanity studio, the schema turned out to be the problem: references modeled as strings, page builders without thumbnails, validation rules nobody ever wrote.

    A good Sanity studio is built around how editors actually work, and most agencies skip that step. If you've got a Sanity build that's making editors miserable, we'll happily audit it and tell you honestly whether to fix it, rebuild the schema, or migrate to something else.

From the blog

---

## Headless Shopify agency


> We build custom headless Shopify storefronts on Next.js. Configurators, custom buying journeys, sub-second product pages, and the conversion that comes with them.

**Updated:** 2026-08-25
---

## Commerce experiences worth building headless

### Configurators, build-your-own-bag flows, custom buying journeys, and editorial pages your marketers control. The things that make a brand feel premium and a store convert.

We build the storefront on Next.js and let Shopify do what it's great at: products, inventory, cart, and checkout. You get a site that loads fast, ranks, and can do whatever the brief asks for.

Companies of all sizes trust Roboto Studio

What you can build headless

    Configurators, build-your-own-bag flows, made-to-order steps, lookbooks, and multi-step buying journeys. The kind of thing premium brands ship to make buying feel like part of the product. On a custom Next.js frontend that's just another component to build.

    Campaign pages, editorial, structured product narratives, and navigation all live in a CMS your marketers edit directly. They ship pages without a developer ticket, and Shopify keeps handling products and checkout.

    Server rendering, image optimisation, and a Vercel edge network in front of every page. Sub-second product pages and listings at scale, including catalogues in the thousands. The result is Core Web Vitals you actually pass.

A theme hands every product the same buy button. Most premium catalogues need more than that: the same fireplace surround can be a made-to-order commission for one customer and an in-stock purchase for the next. On a headless storefront the click decides the journey. An enquiry lands in your CRM (Salesforce or whatever you run) with the configured spec attached, ready for your sales team to quote, and a purchase goes straight through Shopify checkout.

The journeys themselves are where headless earns its keep. A product configurator that reprices as the customer picks materials and sizes. A bundle builder that nudges order value up as the box fills. Deposits and lead times for made-to-order pieces. On a theme, each of those is an app subscription and a compromise. On Next.js they're components we design around your products, with Shopify still running cart, payment, and fulfilment underneath.

Moving off Magento, WooCommerce, or an ageing theme store takes more than a storefront redesign. We run the whole migration as a service: catalogue, customers, orders, and URLs all land on a new Shopify instance, with a purpose-built headless storefront on Next.js in front of it. The step most teams underestimate is the 301 redirect map. We build it before launch so every old URL re-points to its new home, and the rankings you've spent years earning hold through the cutover.

Teams arrive in one of two lanes, and both feed the same roadmap. Some want a new build: a brand-led storefront from the ground up on Turbo Start Shopify, with the custom functionality your roadmap needs and a content setup your marketing team owns. Others are already on Shopify and need a storefront replatform: we rebuild the frontend on Next.js for Core Web Vitals and conversion while the commerce backend stays exactly where it is. The only real difference between the lanes is whether your commerce data moves with you.

If you're comparing Shopify migration agencies, ask each one to walk you through their redirect plan before anything else. Ours ships on launch day, and we watch Search Console through the cutover until the numbers settle. And if it's your content platform that needs to move rather than your store, that's our [CMS migration service](/services/cms-migration).

Most Shopify speed optimisation stops at compressing images and pruning apps, and the gains erode as soon as the next script lands. The theme itself sets the ceiling: app scripts, render-blocking assets, and a checkout you can't fully tune. A headless frontend on Next.js removes that ceiling. We server-render the pages that matter, defer the rest, and serve everything from the edge.

Faster pages convert better and rank better. Before we start, we benchmark your Core Web Vitals (LCP, INP, and CLS) alongside the key buying journeys, then measure the same numbers after launch, so the speed and conversion gains are something you can see rather than take on faith.

If your current Shopify storefront feels slow, we'll tell you exactly what's dragging it down before you commit to anything.

My best experience with a consulting company. The results were delivered faster than expected and with top quality. Jono ensured I understood the process and suggested a great approach. Both execution and communication were flawless.

Shopify builds we've shipped

Every build starts from Turbo Start Shopify, the open-source headless commerce starter we maintain. Next.js 16 for the frontend, the Shopify Storefront API for products, collections, cart, and checkout, and Sanity as the editorial layer for pages, blog, navigation, and SEO. Vercel handles hosting, edge caching, image optimisation, and observability.

None of it is exotic. It's the same stack we run in production for clients, type-safe from the database to the page, and you can read every line of it [on GitHub](https://github.com/robotostudio/turbo-start-shopify?utm_source=roboto_studio_website) before you hire us.

## Thinking about headless Shopify?

The ones we get asked the most

### What is headless Shopify?

Shopify still runs the store: products, inventory, cart, checkout, customers, and fulfillment. Next.js renders the storefront, and the two talk over the Shopify Storefront API. Customers see a custom site backed by Shopify, and your team edits content in a CMS instead of theme code. Our [guide to headless Shopify](/blog/shopify-headless-guide) walks through the costs, the tradeoffs, and when a vanilla theme is the smarter call.

### Can you build custom functionality like a build-your-own-bag configurator?

Yes, and it's the main reason to go headless. Configurators, made-to-order flows, product personalization, lookbooks, and multi-step buying journeys are all just components in a Next.js app. If a premium brand has a storefront experience that feels genuinely bespoke, it's almost certainly headless.

### We're already on Shopify. Is replatforming the storefront worth it?

A replatform earns its keep when page speed is hurting conversion, when the marketing team is stuck waiting on developers, or when the design you want won't fit the theme. If none of those apply yet, we'll say so. We benchmark your current Core Web Vitals first and give you an honest read before you commit to anything.

### Does this work on standard Shopify, or only Shopify Plus?

Both. Headless works on standard Shopify. Plus adds checkout extensibility, multi-store, scripts, and higher API limits, which matter once volume or compliance demand them. Slingshot Bio runs on Plus, Jamb doesn't, and the build pattern is the same.

### What happens to SEO during a replatform?

It's planned from day one. We map every URL before launch, ship redirects on launch day, wire internal links through CMS references rather than hardcoded slugs, and watch Search Console and Vercel through the cutover. Jamb's rebuild merged two legacy URL spaces and held its rankings. The [CMS migration service](/services/cms-migration) covers the mechanics in depth.

### What does a full Shopify migration service include?

Everything that makes the store yours: the product catalog, customer accounts, order history, and every URL. We move the data onto a new Shopify instance, build a purpose-built headless storefront on Next.js, ship a 301 redirect map so old URLs point at their new homes, and run the cutover with Search Console open. Your customers keep their accounts and your rankings hold.

### Can we keep our Shopify apps?

Backend apps that touch inventory, orders, customers, fulfillment, or accounting stay. Frontend apps that inject scripts into a theme usually move into the Next.js codebase instead, which is faster and cheaper than paying for them every month.

**Tell us what you're building.** A new headless storefront, the custom functionality your roadmap needs, or a Shopify store that's gone slow. We'll scope it honestly in a 20-minute call. If you'd rather look under the hood first, [Turbo Start Shopify](https://github.com/robotostudio/turbo-start-shopify?utm_source=roboto_studio_website) is the same starter we ship on production builds.

---

## Workshops


> Hands-on workshops with two senior Roboto developers. Skill your team up on Sanity, Next.js, and Vercel Workflow SDK agents, with real output shipped by the end of the week.

**Updated:** 2026-08-25
---

## Two senior Roboto developers, sat alongside your team for the week. You learn how we build, by building with us.

### Small groups, fast pace, AI-augmented from the start. The work that used to take six weeks of trial and error compresses into days, because we have already run into every wall on the way.

Bring your laptops and the editor you like. Cursor, Claude Code, Codex, or anything else with modern AI assist works. We share a short setup checklist once a date is on the calendar so day one starts at full speed.

Our workshops are usually pitched at engineering teams of two or more, with content or marketing stakeholders welcome where the workshop format suits them.

## Get your team confidently building with Sanity and Next.js in a week flat.

### Two of our developers work alongside your team for five days. We use [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity) as the launchpad, and lean on AI to keep the pace up.

If you have a team of two or more developers ready to put the work in, this gives you the fastest possible path to a production-ready foundation. Knowledge stays in-house.

### What you walk away with

- A deployed Sanity studio and a deployed Next.js front end.
- Content models built around your real domain, not a generic starter.
- Working preview, drafts, and a deployment pipeline you understand.
- Your team trained to extend the schema, build new sections, and onboard the rest of the org.

[Book this workshop](/contact)

## Ship a durable agent that actually does something for your business. Then know how to ship the next one.

### Vercel Workflow SDK is the cleanest path to production-grade agentic workflows we have used. This workshop walks your team through it on a real task in your stack.

Scope is shaped to your team. Some clients want a one-day intensive that ends with a deployed agent. Others want a longer engagement that ships two or three workflows and trains the team to own them. Talk to us and we will scope it together.

### What you walk away with

- A durable agent running in your environment, doing real work.
- Integration with the tools and APIs your team already uses.
- A clear mental model of when an agent is the right answer, and when it is not.
- Your team confident enough to design and ship the next workflow without us.

[Talk to us about this workshop](/contact)

Companies of all sizes trust Roboto Studio

## Agency partners, community ambassadors, and the team behind Turbo Start Sanity

### We've built with Sanity and Next.js for years, and we put real work into teaching structured content and sharpening how teams use Sanity Studio.

We have published a lot of educational content, open-sourced [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity) as our opinionated starter, and we now ship [agentic workflows](/services/agentic-workflows) on Vercel for our own pipeline. The workshops are the version of that knowledge your team can take home.

Jono and his team are absolute rockstars. They blend technical savvy with practical business sense. They are in lock-step with our website goals and have really made our website come to life. Not just a web dev team, they are trusted advisors and truly aligned with our team.

Client work we've shipped

## Need a workshop on something else?

We design bespoke workshops around the topics our clients actually want to learn. Headless Shopify, content modelling, AI-augmented dev flow, custom integrations. Tell us what your team needs to skill up on and we will tell you whether we are the right fit.

## Thinking about a workshop?

Here are the questions we hear most often

### How big should our team be?

Two to four people works best. For the Sanity and Next.js workshop we ask for at least two developers on your side. For the agent workshop, one engineer plus a product or content stakeholder is usually the right mix. Larger groups split the attention of the room and slow the pace.

### What do we need to bring?

Laptops with your editor of choice, AI assist enabled, repo access, and any existing designs or content models. We share a setup checklist once a date is on the calendar so day one starts at full speed.

### Do you run workshops remote or onsite?

Both. Remote is the default, runs over Zoom plus shared repos and Slack, and works for teams across timezones. Onsite is available for teams in or near our London base, and for teams happy to fly us in.

### Do we need to use a specific editor or AI tool?

No. Any modern editor with AI assist is fine. Cursor, Claude Code, Codex, GitHub Copilot, JetBrains AI all work. We bring our own setup so your team can compare approaches as the week goes.

### What if the workshop we want isn't listed?

Talk to us. We design bespoke workshops around the topics our clients ask for. If you have a specific stack, integration, or workflow you want to skill up on, scope it with us and we will tell you whether it is a fit.

### How quickly can you run one for us?

Typical lead time is two to four weeks from first contact to day one. We hold a small number of workshop slots open each quarter, so urgent requests can sometimes land sooner if a slot opens up.

## Ready to book a workshop?

Pick the workshop that fits, or tell us what your team wants to learn. We will follow up with available dates and a short scoping call.

---

# Case Studies

## Slingshot Bio


> Roboto converged Slingshot Bio's WordPress and Shopify sites into one headless Shopify build on Next.js and Sanity, instrumented end to end and AI-ready.

**Published:** 2026-05-27 | **Updated:** 2026-07-23 | **Client:** Slingshot Bio | **Technologies:** Shopify, Sanity, Next.js, Vercel | **Services:** Web development, Migration, Brand
---

Slingshot Bio makes synthetic cell mimics: engineered particles that stand in for real T, B, and NK cells on any flow cytometer and hold steady where donor samples drift batch to batch. By the time they reached us they had outgrown their setup, a WordPress marketing site on one domain and a separate Shopify store on another, with no shared design, content model, or data between them. We were brought in to converge the two into one headless platform: Next.js and Sanity on Vercel, Shopify kept purely for checkout, built on [turbo-start-shopify](https://github.com/robotostudio/turbo-start-shopify), our open-source Shopify and Sanity starter. Design through to launch in three months.

The storefront had to make a dense, technical catalogue easy to move through, so the science reads clearly and a researcher gets from landing page to cart without friction. We instrumented the entire path in PostHog and stitched identity across the headless boundary, so we can follow one session from first landing through to a completed Shopify checkout, even though checkout runs on a separate domain. Session replay sits on top, so the team can watch real researchers move through the site and see where a high-value order stalls or closes.

A scientific catalogue is unusually structured. Every control carries markers, reactivity, pack sizes, application notes, and a certificate of analysis, and a researcher needs to scan any product and know exactly what they are holding. We modelled all of it in Sanity, so each product is structured data rather than a hand-built page. Spec sheets, panels, and reactivity render from one source, and the team can publish a new product or COA without a developer. New entries slot into the system as the catalogue grows.

Underneath, it is a [headless Shopify build](/services/shopify). Sanity owns content, Shopify is reduced to checkout, and Next.js on Vercel keeps the full catalogue filtering instantly, even as families and markers are added. We also built for how labs actually buy. Most controls sell through a mix of cart and enquiry, and a purchase usually needs sign-off, so a researcher can turn a basket into an itemised, branded PDF and send it to a principal investigator or procurement to approve. The cart holds for weeks, so they can return and check out once the approval lands.

The cutover was clean. We inventoried every page and resource across both old sites, mapped each to its new home, and built a custom Shopify theme whose only job is redirects, so nothing broke and the search equity carried across. The platform launched AI-ready: JSON-LD on every product, collection, and resource, content negotiation that serves clean Markdown to AI crawlers alongside the HTML, an llms.txt, a Markdown sitemap, and a sitemap whose timestamps track Sanity directly. Marketing publishes in Sanity, and the structured data, the sitemap, and the crawlable Markdown all stay current on their own.

The native Shopify basket waits on the server for every change. We replaced it with a headless commerce cart on Next.js that updates optimistically: add a control or change a quantity and the line items and total move at once, the price animating to its new value while Shopify's Storefront and Cart APIs confirm in the background. Nothing blocks on the round trip, so the basket reads as markedly faster than native Shopify. For a researcher assembling a multi-line order across panels and pack sizes, it keeps pace with how fast they work.

---

## Jamb


> We rebuilt Jamb on Sanity and Next.js, merging two legacy PHP sites into one calm catalog without losing the SEO equity their antique and reproduction collections had built up.

**Published:** 2026-05-25 | **Updated:** 2026-07-23 | **Client:** Jamb | **Technologies:** Next.js, Sanity, Shopify, Vercel | **Services:** Brand, Web development, Migration
---

Jamb and Hawker Antiques had just merged when we picked up the project. Two PHP sites, 70+ duplicate meta descriptions, and a custom CMS where adding a furniture category meant hoping nothing else fell over. The catalogue runs from 18th-century Irish chimneypieces to six-figure antiques, the kind of stock collectors and interior designers wait years for. Most of it sells through enquiry rather than a cart. We worked with Toni Howarth and the [benweaver.eu](http://benweaver.eu) team to merge the two sites into one and rebuild the platform on Sanity, Next.js, and Shopify.

Jamb's catalogue runs on two flows. Some pieces sell through checkout, most still sell through enquiry. [Headless Shopify](/services/shopify) lets the same product record route to either, with variations (sizing, finish, edition) carrying through when there's a cart to render. The rest stays on the enquiry path the team has spent years tuning. For the homeware that carries stock, Shopify's Buy Button drops in beside the Sanity catalogue with no separate storefront and no second CMS. Adding or pulling a category takes minutes, and the rest of the site never has to know about it.

Ben Weaver led the creative direction. Our job was to tighten the lens in Figma so the designs survived the trip into code. We worked through every breakpoint from mobile, where Jamb's best photography has to carry the whole page, up to 5K iMacs where the marble grain in a chimneypiece needs to stay sharp at 1:1. The handoff to development was a spec. Every breakpoint and interaction was defined, not implied. The site's design intent doesn't drift between Figma and production.

Most rebuilds break somewhere in the URL space. Jamb had two URL spaces merging into one, decades of organic equity to keep, and antique-specific terms that rank slowly and stay ranked for years. Before launch we built a full sitemap spanning both legacy sites, mapped every page into the new one, and wired internal links through Sanity document references rather than hardcoded URLs, so a slug change in one place doesn't cascade into 404s anywhere else. After launch we watched Search Console and Vercel observability for even the smallest 4xx and 5xx errors, and shipped redirects the same day. Rankings held through the cutover.

jamb.co.uk launched with no drama. Hundreds of enquiries came through in the first week, and page loads stayed sub-second. Build times went from 30 minutes to three across 2,000+ pages, so the team can push changes without waiting on a developer. A wider [Shopify Connect](https://www.sanity.io/docs/apis-and-sdks/sanity-connect-for-shopify) roll-out is queued for the parts of the catalogue that suit a checkout flow, but there's no rewrite on the horizon.

---

## Airtime Rewards


> We built cashback platform Airtime Rewards a Gatsby site on Netlify: 0.4s First Contentful Paint, 0.6s to interactive, and perfect Lighthouse scores.

**Published:** 2025-03-14 | **Updated:** 2026-07-23 | **Client:** Airtime Rewards | **Technologies:** Gatsby, Prismic, Netlify | **Services:** Web Development, UI Design
---

Our collaboration focused on delivering a high-performance Gatsby.js website, with Prismic as the [headless CMS](/services/headless-cms), optimized for exceptional speed and user experience. By implementing advanced lazy loading techniques for images and using Netlify's caching and asset optimization, we achieved remarkable load times: just 0.4 seconds for First Contentful Paint and 0.6 seconds to interactive.

Our meticulous approach to SEO included building a comprehensive sitemap that clearly defined page relationships, ensuring optimal indexing by Google. This attention to detail resulted in perfect scores across Google's Lighthouse audits for performance, accessibility, best practices, and SEO, significantly enhancing Airtime Rewards' online visibility.

Thanks to these enhancements, Airtime Rewards successfully surpassed one million users and secured prominent placement on EE's customer homepage. While their exceptional leadership and strategy drive their impressive growth, we're proud to have contributed by creating a website that is visually appealing, exceptionally fast, and optimized for continued growth.

---

## Livemore Mortgages


> We built Livemore Mortgages a modular page builder with Sanity and Next.js. Landing pages that took weeks now ship in hours, and updates go live 5x faster.

**Published:** 2025-03-14 | **Updated:** 2026-07-23
---

Their rigid template system couldn't adapt to market shifts, putting them at a competitive disadvantage against more agile firms who could rapidly deploy targeted content in response to emerging opportunities.

We built a modular page builder with [Sanity](/services/sanity) and [Next.js](/services/nextjs), featuring drag-and-drop content blocks with intuitive editing interfaces. The implementation included Sanity Image optimization with hotspot controls and granular SEO settings for each component. The results were immediate: landing page creation time dropped from weeks to hours, updates went live 5x faster, and their marketing team independently launched 12 new campaign pages in the first month, eliminating their technical bottleneck and accelerating their market responsiveness.

---

## Mojo Mortgages


> Mojo Mortgages needed a redesign shipped in four weeks. We rebuilt their frontend and four mortgage landing pages on Gatsby across two headless CMSs.

**Published:** 2025-03-14 | **Updated:** 2026-07-23
---

We cleaned up their codebase, ensuring their blog and homepages all worked together flawlessly despite using [two separate headless systems](/services/headless-cms). Their mortgage comparison tool really needed specialized landing pages that could reduce friction and boost conversions across different mortgage categories.

We architected four rock-solid static landing pages targeting key mortgage verticals on their Gatsby foundation. Our technical approach centered on performance-first development, using SVG-centric design and a lean component architecture that cut unnecessary bloat. We built a lean user experience that cut excessive form fields while still capturing comprehensive data. The solution launched on schedule for their acquisition announcement, with performance metrics that spoke volumes. Their Product Owner didn't mince words, calling the pages "lightning fast", high praise that led to an immediate project extension for four additional subpages built on the same battle-tested architecture.

---

## Session


> Working with Motto, we built an editorial platform for Session on Next.js and Sanity: a flexible page builder, live preview, and pixel-perfect images.

**Published:** 2025-03-14 | **Updated:** 2026-07-23
---

Our solution used [Next.js's built-in image optimization capabilities](/services/nextjs) to ensure pixel-perfect clarity across all devices, handling edge cases like right-sizing, device-to-pixel ratio, and lazy loading.

The implementation featured a flexible page builder methodology that allowed the Session team to manage content without rigid restrictions. We created customizable components that could handle complex design requirements while remaining adaptable to changing needs. The platform integrated Vercel's CDN and Edge Functions for lightning-fast content delivery, while Sanity Studio's Content Previews enabled confident experimentation and deployment. The result was a lean content management system that kept image quality high while delivering optimal performance and SEO benefits.

---

## Tray.ai


> Migrating hundreds of thousands of pages, re-platforming and extending for the leading composable AI integration platform

**Published:** 2025-01-15 | **Updated:** 2026-07-23 | **Client:** Tray.ai | **Technologies:** Contentful, Next.js, Vercel | **Services:** Development, Migration, Consultancy
---

We slashed Tray.ai's build times by **99.86%**, shrinking a full workday to just **two minutes**. In just six weeks, we migrated **half a million pages** onto Vercel through a progressive strategy and rapid iteration. Now, a lightning-fast browsing experience for more than a million monthly visitors.

## Legacy Next.js 9, fragile AWS Serverless functions, and 250 MB packages choked every deploy.

Previewing changes meant full prod builds; form logic lived in a separate repo; failed deploys were weekly rituals. Marketing releases stagnated, engineers dreaded merge-days, and SEO rankings slid as pages crawled to load.

## We consolidated five repos into a single Turborepo monorepo on Next.js 13, introduced hybrid SSG + SSR routing for 25 complex page types.

We re-platformed forms to Vercel Functions with reCAPTCHA, migrated from styled-components to Tailwind CSS through a progressive strategy, and added `next/link` pre-fetching and `next/image` optimisation.

The move trimmed bundle size, simplified developer workflows, and hardened security behind Vercel's firewall.

## [Contentful](/services/contentful) underwent a full declutter. We scrapped bloated models, built a fresh page-builder with live preview.

We gated resources behind smart forms. Marketing can now ship pages in minutes, without pinging engineering. Real-time preview across any route lets writers catch copy issues before they publish.

## Deployments that once took 24 hours now finish in 120 seconds.

Page-load times dropped by an order of magnitude; Vercel Speed Insights scores sit in the high 90s. During two DDoS waves, the new static-first strategy served traffic with **0% downtime**.

> Roboto Studio migrated our project to Vercel and reduced build times from a full day to just 2 minutes for faster rollouts and more agile updates.
> — Co-founder & CEO, Tray.ai

---

## Synacti


> We built Synacti's site with v0 generating over 90% of the code, then added a Matter.js interactive hero, a theme picker, and Sanity live content editing.

**Published:** 2024-12-10 | **Updated:** 2026-07-23
---

We built over 90% of the site with v0.dev, which let us move fast without dropping quality. That freed up time to hand-build the harder features: a Matter.js interactive element and a user-controlled theme picker.

The site runs on the Next.js App Router (`/app` directory), which keeps Core Web Vitals strong, and it's deployed on Vercel for fast global delivery. We wired up [Sanity CMS](/services/sanity) with its Live Content API (Presentation) so Synacti get a visual page builder with real-time updates across the site. The result is a fast, engaging site with a content management setup their team actually enjoys running.

---

## Mario Testino


> From Sanity overages to instantaneous publishing, we brought Mario Testino into the fast lane, and did it in style.

**Published:** 2024-11-20 | **Updated:** 2026-09-04 | **Client:** Mario Testino | **Technologies:** Sanity, Next.js, Vercel | **Services:** Development, Consultancy
---

Who doesn't know Mario Testino OBE, in the media industry, one of the legends who has photographed everyone from Kate Moss to Princess Diana and even shot for Gucci, Burberry, Versace, Chanel, and Dolce & Gabbana. He has worked for Vogue, Vanity Fair, and museums across the globe, including the National Portrait Gallery in London and the Museum of Fine Arts in Boston. And a photographer of his level needs a website that is not just artistically stunning but also flawlessly editable.

When we first inherited the Mario Testino project, they were in a state of crisis. Broken Vercel pipelines, 200% overages on Sanity, and a botched migration with 160+ missing redirects.

We jumped straight in, without a second thought. We helped them to set up a company repo, reconnect severed connections, and started tackling the Sanity overage issue.

## Testino's site was already built on Sanity, which might make you think things would be easier. But here is the spoiler: they weren't.

The whole project was sitting on a pile of deprecated dependencies, the kind that break if you so much as look at them. Imports were busted, libraries were abandoned, and updates were basically a threat.

So we ripped everything back to [vanilla Sanity](/services/sanity). Stripped the excess code, removed unnecessary libraries, rebuilt the editorial flow, and dropped in Live Content API so edits didn't feel like "press publish and wait five minutes for the universe to respond." While refactoring, we fixed every redirect, cleaned up navigation so crawlers could actually read it, and made sure creators and search engines got the same smooth experience. Then we rewrote every page, image implementation, and data query from scratch.

## Geoff and the Testino team saw the Turbo Start Sanity template experience and wanted exactly that. So we gave them exactly that.

Now they can add exhibitions anywhere, spin up blogs and press releases, and reorder content without waking up a developer at 11 pm.

We also experimented with Geoff on layouts and added the scoop section. It is a tiny spotlight for "never-before-shared" Testino stories. And because this is photography, we dialled in image hotspotting so every shot looks flawless on anything from an iPhone to a retina monitor that costs more than our rent.

SEO needed a little TLC after the previous migration missed all the redirects. With Francesco, their SEO expert, we worked hand-in-hand to rebuild structured data with JSON-LD, clean up crawl paths, and get Google to stop ghosting the site. We also slapped on Vercel Bot ID because scrapers treat photography sites like an all-you-can-eat buffet. With the foundation finally stable, we shipped two new sections, Selected Press and MT World, and the site now behaves the way Testino's work deserves.

## The Testino team was genuinely thrilled, so much so that Geoff Cooper's words about our work now sit proudly on our homepage.

The site went from broken and unpredictable to fast, stable, and fully editor-friendly. Francesco, their SEO expert, tracked improvements daily as we restored redirects and implemented proper JSON-LD. Organic visibility climbed back, schema is now set-and-forget, and we don't want to jinx it… But the whole site crawls flawlessly.

Operationally, the upgrade was immediate. The team can add exhibitions, publish press releases and blogs, reorder content however they want, and rely on hotspotting to keep every image perfectly framed. No broken layouts, no surprise dev emergencies. We're now adding AI-powered upgrades like automatic alt-text, richer SEO content, and future e-commerce functionality.

---

## Hungry Pumpkin


> E-commerce optimization for Hungry Pumpkin: one-click checkouts, inventory management, and WordPress training so their team can manage products themselves.

**Published:** 2024-10-28 | **Updated:** 2026-07-23
---

Our hosting recommendations delivered a rock-solid foundation with near-perfect performance scores, complemented by a set-and-forget maintenance plan that keeps their award-winning site running smoothly.

The results spoke for themselves - shortly after launch, Hungry Pumpkin earned a Travellers Choice award, thanks to their delicious offerings and our technical partnership. From latte art to layout changes, we [trained their team](/services/workshops) and equipped them with tools to focus on what matters most: serving up incredible full-English breakfasts and authentic Italian dishes.

---

## St Mary's Church


> We rebuilt the website for St Mary's Church, a historic Nottingham landmark, on WordPress with a simplified admin so parish staff can update it themselves.

**Published:** 2024-10-15 | **Updated:** 2026-07-23
---

Its existing website suffered from outdated design and rigid content management, making it difficult for staff to keep their schedule current, a critical function for announcing services, community events, and parish news to locals. The technical challenge involved creating a solution that was visually befitting of the landmark's heritage while being intuitive enough for the church's non-technical staff to manage independently.

We collaborated closely with the Vicar to develop a WordPress solution with an off-the-shelf theme and tailored administrative interface. By building a simpler calendar management system with recurring event support, we eliminated the previous workflow bottlenecks that had plagued their communication efforts.

We're happy to say that they're still using the same infrastructure from 2018. *We build websites to last.*

---

## 1st Call Immigration


> 1st Call Immigration’s WordPress site cost four figures a year in hosting. We rebuilt it on Sanity and Next.js with near-perfect Lighthouse scores.

**Published:** 2024-09-30 | **Updated:** 2026-07-23
---

Because of the number of plugins and the transition to the Gutenberg editor, it had prevented content updates for five years due to repeated PHP errors. As a small immigration advisory business in Nottingham, they needed a cost-effective solution that would maintain their local SEO presence while providing an intuitive content management system that wouldn't require technical expertise to update regularly.

We implemented a barebones [Sanity](/services/sanity) and Next.js solution that drastically reduced hosting costs while delivering near-perfect lighthouse scores across performance, accessibility, and SEO metrics. By tailoring the content blocks specifically for immigration services content and using Sanity's real-time preview capability, we transformed the client's editorial experience.

---

## Tabby.ai


> Helping the UAE's most prolific Pay in 4 merchants scale their design system and composable infrastructure.

**Published:** 2024-09-10 | **Updated:** 2026-07-23 | **Client:** Tabby.ai | **Technologies:** Sanity, Next.js, Vercel | **Services:** Development, Migration, Consultancy, Design
---

Tabby AI is a leader in the UAE's "Pay in 4" space, and their rapid expansion had outgrown their setup. They needed to scale up their design system and composable infrastructure to work hand-in-hand with their website.

Our job was to build the component library that sits under Tabby AI's whole digital experience. That meant more than code: an accessible interface that worked across their markets, with internationalisation (i18n) and accessibility built in from day one.

## The whole process felt like a true partnership between our crew and the brilliant developers at Tabby AI.

We rolled up our sleeves together, focusing on creating a component library that wasn't just visually slick but also incredibly functional and easy for their team to use and extend.

The latest Storybook component browser let us document and test each component in isolation, which made the whole build faster. Both teams could see progress clearly and iterate quickly. A special shout-out to their designer, Sergii, who documented and scoped components in a Figma environment like I've never seen before.

We weren't just delivering code, we were building a shared understanding and a toolset their internal teams could keep extending long after our involvement wrapped up.

## Alongside scaling the frontend infrastructure, we tackled the backend migration: upgrading Tabby AI's content platform from Sanity v2 to v3.

This wasn't just a version bump but a golden opportunity to slash accumulated development debt and completely rethink their content structures. We checked their existing schemas, identifying pain points and areas for simplification.

The move to Sanity v3 allowed us to implement much more reusable data structures, meaning content could be created once and surfaced dynamically across different parts of their site and apps. This made the editors' lives easier and drastically reduced redundancy and potential inconsistencies. The result was a faster, cleaner, and far more [maintainable Sanity Studio](/services/sanity-support) that gave them a gold standard in editorial experiences.

---

## Simply Thrilled


> A video portfolio site for Simply Thrilled on Webflow, delivered two days before a three week deadline while training their team to run it themselves.

**Published:** 2024-08-22 | **Updated:** 2026-07-23
---

Their existing WordPress platform couldn't do their work justice due to poor performance and limited customization. The challenge: deliver a visually stunning site that the client could independently maintain within tight constraints.

We built a performance-optimized Webflow MVP with compressed media assets and lazy-loaded video content. Through collaborative on-site sessions, we simultaneously developed the site while [training their team](/services/workshops). The results: launch two days early and notable client acquisitions, including an [NHS project featuring Nottingham's own Vicky McClure](https://www.simply-thrilled.com/). As the client noted:

> "A special shoutout for the passion they put in to optimising the website and ensuring the site as fast as possible through Webflow."

The new professional presence enabled Simply Thrilled to secure higher-profile work while maintaining complete content autonomy through the lean design system we established.

---

## Savory & Partners


> Discover how Roboto Studio transformed Savory & Partners' website performance, boosting Lighthouse scores from 60 to 90+, while rebuilding their development process around AI tools like Cursor and v0.dev.

**Published:** 2024-08-05 | **Updated:** 2026-07-23
---

We implemented a comprehensive overhaul of their system, starting with replacing Material UI with the more efficient Shadcn UI. By using Cursor for automated component generation, we dramatically reduced development time, turning what used to be day-long component refactoring tasks into minutes-long processes.

Our collaboration extended beyond just performance optimization. We [equipped their team](/services/workshops) with deep knowledge of performance metrics and modern development practices, while also enhancing their internationalization workflow with improved translation strategies. The results were remarkable: their Lighthouse scores soared to the high 90s, and with the integration of AI tools like v0.dev and Cursor, their team now enjoys unprecedented development speed and efficiency. This transformation solved their immediate performance issues and future-proofed their development process, allowing them to maintain high performance standards while rapidly developing new components through text-based generation.

---

## Trippin World


> Trippin's 5,000 page travel platform took 30 minutes to build. We rebuilt the pipeline with Next.js SSG on Vercel and got deploys down to three minutes.

**Published:** 2024-07-12 | **Updated:** 2026-07-23
---

Their content-rich travel platform housed over 5,000 pages, resulting in a cumbersome 30-minute build process that bottlenecked both developer workflows and content updates. With such lengthy deployment cycles, their editorial team couldn't respond quickly to trending destinations or time-sensitive travel updates, a serious competitive disadvantage in the fast-moving travel space.

We implemented [Static Site Generation (SSG) with Next.js](/services/nextjs) on Vercel, creating a specialized build pipeline that intelligently managed Sanity API limits. By restructuring how content was fetched and cached during builds, we cut their deployment times from 30 minutes to just 3, an 80% reduction. The technical architecture included fallback strategies for content and images, ensuring smooth builds even when handling 5,000+ pages. Performance testing spoke volumes: 100% fallback coverage, zero build failures due to API limits, and content updates now deployed five times faster than before, giving Trippin World the technical agility to keep pace with rapidly changing travel trends.

---

## Global Cycling Network


> How we helped the fastest growing online cycling community, push the editorial velocity to new heights.

**Published:** 2024-06-25 | **Updated:** 2026-07-23 | **Client:** Global Cycling Network | **Technologies:** Sanity, Next.js, Vercel | **Services:** Development, Migration, Design
---

We've always been fanboys of Global Cycling Network. Hell, we very nearly bought an e-bike on their recommendation alone. So when they came to us to work on improving their content velocity and programmatically building a multi-step categorisation system we could have jumped off our chairs. We gelled in with their incredible team and became the [go-to Sanity consultants](/services/sanity) to ensure every aspect of structured data had been thought about, all the way down to little UX interactions that gave their marketing team more control.

## When it comes to building a publication, there are a lot of moving parts... When those moving parts constantly shift up and down through the ranks, joining teams, leaving teams and winning tours, it's a different ball game.

We broke all of these people/bikes/teams up into small parts to allow hot-swapping of content at a granular level. This meant that once you've built an incredible profile on one of the top racers, it permeates through every page and every article with every update.

This flexibility enabled the editorial team to really dig into what was possible. Whether it was creating parent-child relationships with teams, team members & bike brands, or specifying the flow when you're looking to promote articles - all of the individual atoms of the content structure communicated and relied on one another to create a web of content that enriched every piece of news.

## We created an entire system using slug nodes and slug clusters to enable hierarchal content from the top level down to four deep slug clusters.

The best part was that no developer was required to create new page routing because of a clever way of handling GROQ queries. It meant that the site was rapid-fast and scalable to thousands of documents within hundreds of user-generated paths. We really pushed the boat out when it comes to reusability, and you can see how it permeated the visual consistency from the first page to ten pages deep.

Just for good measure, we even helped construct a cherry-picking functionality to enable news articles to sit at the top of a section to promote popular or sponsored content.

## The ever shifting world of sports coverage requires instantaneous feedback, and real content velocity.

If we miss milliseconds that could be disastrous for the reporters and sports fans alike. We ensured that every component, every page and every interaction was lightning fast, powered by the incredible infrastructure at [Vercel](https://vercel.com/home). We ensured that no matter the number of users, we would always have uptime and an incredible set of components to match.

Speaking of components we helped to develop their Storybook environment, from a couple of components to every single component you see on the website. Each component stacked with props and adjustments to make sure it fits flush to the page along with tests to ensure the fallback works with whatever content you throw at it. Pretty nice right?

---

## Lungfish Architects


> How an award-winning architecture firm achieved 80% faster website performance and significant cost savings through strategic digital optimization and hosting solutions.

**Published:** 2024-05-20 | **Updated:** 2026-07-23
---

Through strategic optimization, we transitioned them to a new hosting solution that was 30 times more cost-effective while implementing advanced caching strategies and performance improvements. The results were transformative: an 80% improvement in website performance and annual savings of £4,000.

The new website puts Lungfish's portfolio front and centre, from educational facilities to residential developments. With automated maintenance, off-site backups, and built-in communication tools in place, Lungfish can focus on their core business while the site serves their global audience. As their Area Director Richard Fielding noted:

> "Our website is now perfectly set up to support our future development and showcase our work effectively."

---

## The Bang Co


> The Bang Co needed heavy animation without slow pages. We built a Gatsby and Prismic site with optimized image pipelines that keep their showreel snappy.

**Published:** 2024-05-08 | **Updated:** 2026-07-23
---

Their existing site couldn't balance rich visual content against load times, and their content team needed more freedom to update portfolio pieces and post their latest work. The challenge was a platform that could handle complex animations and high-resolution imagery while keeping the snappy, native feel their brand demanded.

We built a JAMstack solution using Gatsby.js for static site generation and Prismic as the [headless CMS](/services/headless-cms). Optimized image pipelines generated WebP, JPG, and PNG formats automatically, and our custom build process loaded the After Effects animations without denting core performance metrics. The results spoke volumes: sub-second page loads across all portfolio pieces, 95+ Lighthouse performance scores, and a content management system that let their team update work independently, all while maintaining their distinctive visual identity and brand personality.

---

## Teckro


> We relaunched Teckro's website and migrated Sanity v2 to v3 in eight weeks, moving them onto Next.js and Vercel with Wistia video managed from the Studio.

**Published:** 2024-04-15 | **Updated:** 2026-07-23 | **Technologies:** Sanity, Next.js, Vercel | **Services:** Development, Migration, Consultancy
---

The challenge was immense: relaunch their entire website and migrate from Sanity v2 to v3 in just eight weeks. Working closely with Teckro, we embraced the ambitious timeline, delivering a new Next.js site on Vercel, powered by a [cleaned-up Sanity v3 backend](/services/sanity). This rapid evolution future-proofed their platform and eliminated technical debt, setting them up for continued innovation.

## The Sanity v3 migration was our chance to boost Teckro's content power. We integrated Wistia to update their Sanity Studio directly.

In other words, we created a single source of truth for their video and podcast content. However, this did come with challenges, such as having to create a scraper to pull the transcripts directly as HTML due to the lack of support from Wistia's API. If you can't do it directly, scrape it.

We also drastically improved the editorial workflow by adding dedicated event types and using Portable Text for embedded call to actions. These changes made content creation faster, more flexible, and ultimately more effective for their marketing team.

## In harmony with Hubspot forms, Teckro introduced a new document type for events, refining their event management strategy.

This strategic shift ensures no opportunity to engage with potential clients is missed.

Teckro has taken its digital content to new heights by utilising Portable Text, a unique feature of Sanity CMS. Crafted compelling call-to-actions within their content have informed visitors and prompted them into action, resulting in remarkable conversion rates.

## Turning engagement into leads was vital. Integrating Hubspot forms directly via the API created a smooth capture mechanism.

This flows data straight into their CRM for timely follow-ups. Better still, we integrated the Hubspot API into Sanity to ensure you could simply pick your form without ever leaving the Studio.

At the time of this project, there wasn't a simplified plugin, we had to work hard to get it all integrated.

## Our commitment to unparalleled user experience led to the adoption of on-the-fly media optimization with Teckro.

This ensures all images are optimized for the best loading speeds, demonstrating respect for visitors' time and enhancing user satisfaction.

Teckro's journey with Sanity CMS shows the impact of a modern content marketing stack. They continue to inspire and set new standards of excellence in the clinical trial management field.

---

## Bulletproof


> Bulletproof's AWS setup meant 30 minute deploys and hard-to-maintain i18n. We migrated the site to Vercel to cut build times and simplify every release.

**Published:** 2024-03-25 | **Updated:** 2026-07-23
---

Their development workflow was being hampered by excessive build times of 30 minutes per deployment, severely limiting their ability to iterate quickly or deploy urgent fixes. Additionally, their internationalization implementation had become increasingly difficult to maintain at scale.

We identified that a migration from AWS to Vercel would address the core infrastructure issues while providing substantial performance improvements. Our technical implementation focused on a comprehensive deployment architecture overhaul, migrating the entire application from AWS to Vercel's edge network to use their optimized build pipeline and deployment infrastructure. Through careful analysis and refactoring, we achieved a dramatic build process optimization that reduced build times from 30 minutes to just 4 minutes, an 87% reduction. This improvement was accomplished by implementing incremental static regeneration and optimizing the build toolchain, alongside a complete restructuring of their localization system using [Next.js's native i18n capabilities](/services/nextjs) to create a more maintainable and efficient approach to managing multilingual content.

The technical benefits extended beyond just build times. The team now has access to Vercel's comprehensive analytics, preview deployments, and a significantly simplified hosting model that eliminates infrastructure management overhead. This allows their development team to focus on feature development and content creation rather than deployment logistics. This migration demonstrates how strategic infrastructure decisions can transform development workflows and create measurable performance improvements without requiring a complete application rewrite.

---

## Key ESG


> We gave Key ESG a fast Next.js and Sanity site with a page builder, a Chakra UI design system, and a Sanity form builder wired straight into their CRM.

**Published:** 2024-03-18 | **Updated:** 2026-07-23
---

Using Chakra UI, we quickly established a solid design system, significantly accelerating both development and design processes. The result? A fully customizable, scalable, and intuitive page-builder experience, complete with a tailored SEO component ensuring optimal Meta and Open Graph data.

Recognizing the universal dread of forms, we went beyond expectations by creating an intuitive, fully integrated [form-builder within Sanity](/services/sanity), connecting cleanly to their CRM with precise labeling. Performance was paramount: every block utilizes [Next.js image optimization](/services/nextjs) and Sanity's Imgix rendering, with future-proofing for upcoming Web Worker support to offload analytics scripts, ensuring sustained speed and efficiency.

---

## Topaz Labs


> We built Topaz Labs a documentation platform with Sanity, Next.js and Vercel: live preview, custom fields, and one of the fastest docs sites anywhere.

**Published:** 2024-02-28 | **Updated:** 2026-07-23 | **Client:** Topaz Labs | **Technologies:** Sanity, Next.js, Vercel | **Services:** Development, Migration, Consultancy
---

Eric, the CEO of Topaz Lab, contacted us to help create a solution for condensing all of their documentation into a singular platform that was extensible and highly customisable.

Naturally, our first steps were to use [Sanity CMS](/services/sanity), [Next.js](/services/nextjs), and Vercel. We embarked on an exciting journey that transformed expectations of what a documentation system can include.

We ensured every aspect had been considered, from the presentation of placeholders and field descriptions to the instantaneous feedback of a live preview system. We didn't want to build just "a documentation system." We ventured to build "the best documentation system."

## The first piece of our digital jigsaw was Sanity CMS. We took advantage of its real-time capabilities to build a dynamic content management system.

That would have put Gutenberg's movable type to shame. But we didn't stop there. The platform's malleability allowed us to develop custom input components and tailor the CMS to fit Topaz's needs.

## Then came Chakra UI. Like an expert stylist, we used it to dress up our system in a way that was visually appealing and met all the best practices for accessibility and responsiveness.

It was our digital colour palette, with the flexibility of themes and components to create a harmonious, unified appearance across all documentation.

We collaborated with the internal design team at Topaz Labs, with whom we expanded the infrastructure of their design system. We implemented the nuanced colour scheme with lavish purples and extra slick gradient borders. It's always a blast working with internal teams as we can bring both of our design insights and create something truly magical.

## Finally, Mux added the cherry on top. This video platform brought our documentation to life with high-quality streaming videos.

It was like handing our users their personal IMAX experience, delivering video content tailored to their device and connection speed.

If you don't know Mux, I'll give you the lowdown. Videos are the heaviest piece of data on a website and a nightmare to store and stream. Mux takes away all this stress and compresses the video to the appropriate size, E.g., Mobile phone (small), Desktop (large).

---

## Mortgage Rob


> We built mortgage broker Rob a Sanity and Next.js site he edits himself, with a branded share card on every article and a booking flow that turns readers into calls.

**Published:** 2023-09-20 | **Updated:** 2026-07-23 | **Technologies:** Next.js, Sanity, Vercel
---

Rob's practice runs on relationships, so a faceless rate table was never going to fit. He wanted a site that led with his own advice, carried a growing library of guides and FAQs, and let people book a call with him in a couple of clicks. It also had to launch quickly and, once it was live, stay in Rob's hands rather than ours every time a rate moved or a new article went up.

We put the site on [Sanity](/services/sanity) and [Next.js](/services/nextjs) and shaped the editing experience around Rob. Before anything published he could see exactly how his copy, FAQ answers, and blog posts would land, so there was no guesswork and no ticket back to us for small changes. Every article ships with a branded share image built for it automatically, which keeps links looking deliberate wherever Rob drops them. The site went live on a short timeline and still reads as a personal recommendation rather than a lead form, and Rob has kept it current on his own ever since.

---

# Blog Posts

## Sanity Log Analyzer: see where you're blowing your usage


> We built a free CLI that turns Sanity's request log export into a report of where your bandwidth goes. Here's what it found on our own starter.

**TL;DR:** Sanity Log Analyzer is a free CLI (npx sanity-logs analyze) that parses your project's request log export on your machine and shows where the bandwidth goes. One week of our own starter: 59,508 requests, 2.1 GB, one jpg responsible for 329.9 MB, and the navigation queries costing 10x more than the page content.

**Published:** 2026-09-18 | **Updated:** 2026-09-18 | **Categories:** Sanity, Performance
---

We built [Sanity Log Analyzer](https://www.npmjs.com/package/sanity-logs) to catch Sanity overages at a more granular level than the usage dashboard shows. It's the same tool we use on our own client projects, and our dev team maintains it.

You can test things such as which GROQ queries cost the most, which images shipped the most bytes, who was fetching, what failed, and how long everything took.

The tool is open source. You download your request logs from your organization settings, run one command, and the report opens in your browser.

## How to run it

1. Open your project on sanity.io and go to **Usage**, then **Request logs**. Click **Download**. The export covers the last 7 days (not including today), caps at 1 GB, and you can generate a fresh one every 24 hours.
2. You get a file like `s6kuy1ts-2026-08-12-2026-08-19.ndjson.gz`. Click it to unzip.
3. Run the analyzer against the unzipped file:

```bash
npx sanity-logs analyze s6kuy1ts-2026-08-12-2026-08-19.ndjson
```

4. The dashboard opens in your browser with the full report.

The CLI doesn't need an account, a config file, or an API token.

We also recorded a walkthrough of the tool, if you'd rather watch than read:

## What it found on our own starter

The report below is for [turbo-start-sanity](/tools/turbo-start-sanity), our own template, from August 24 to 30. The main thing to look at: 59,508 requests, 2.1 GB of bandwidth, a 3.3% error rate, and a p50 response time of 27ms.

The findings are interesting because we maintain the template regularly and use it as the foundation for all our Sanity and Next.js projects. It still tripped five of the analyzer's warnings. This is a good case of why Sanity Log Analyzer can be useful. It gets into granular details and highlights what's costing usage, even on a project you'd assume was already clean.

Here's where the 2.1 GB went:

| Traffic | Bandwidth | Share of bytes | Requests |
| --- | --- | --- | --- |
| Images | 1.5 GB | 71% | 35,639 |
| Files (mostly video) | 555.5 MB | 26% | 345 |
| GROQ query responses | 42.4 MB | 2% | 13,986 |

The remaining 9,500 or so requests, streaming checks, studio traffic, and errors, barely register in bytes.

## One image cost 329.9 MB

The single costliest asset in the whole project was a 2560x1440 jpg. It was requested 1,013 times and shipped 329.9 MB, about 326 kB per request, because every request fetched it without a width parameter and without `auto=format`. I've worked on fashion sites before and understand why it's important to have high-quality images, but this is ridiculous. Nobody needs the full-size original on every request.

Another 18,682 requests (249.8 MB) fetched originals at full size with no width set, and nearly every image in the top 50 carried a "No auto-format" flag in the report. Luckily, the fix is one line wherever you build image URLs, see below:

```ts
// before: ships the original, 2560px and all
urlFor(image).url()

// after: sized for the layout, re-encoded as webp or avif
urlFor(image).width(800).auto("format").url()
```

`auto=format` alone typically cuts 30 to 70% off jpg and png weight, and the width parameter stops a phone from downloading a 4K original for a 400px slot.

I don't want to rant about this too much, but image optimization is super important for site performance, and the analytics depend heavily on those factors too. So we need to get our act in gear for our own template, and you should take notes too.

## The navigation cost 10x more than the pages

If there's one thing I've broken the most on Roboto's site, and that has cost us the most in Sanity bandwidth, it's the nav.

In our case, the [turbo-start-sanity](/tools/turbo-start-sanity) log report showed `Settings` was the most expensive GROQ query, with `Footer` and `Navbar` right behind it. Can't say I was surprised:

| Query | Bandwidth | Requests |
| --- | --- | --- |
| `Settings` | 8.7 MB | 4,226 |
| `Footer` | 4.7 MB | 1,642 |
| `Navbar` | 2.9 MB | 1,651 |
| `Page` | 1.6 MB | 684 |

This pattern comes up on client projects all the time. Someone wants nav edits to show up on the live site instantly, not after the next build. So the navbar, footer, and settings get fetched fresh on every page view. Fair enough, but now you're paying on every request for content that changes a few times a month.

The fix is to do caching with tags. This way, you fetch the navigation once, tag it, and revalidate the tag when someone publishes. The editor still sees changes within seconds, and the query count drops from thousands per week to dozens. Clever or what?

## Half the content traffic was asking whether anything changed

The log analyzer report showed that 49.3% of the project's content requests were freshness checks, 6,893 requests spending 18.3 MB just asking "anything new?" Also, it flagged 4,217 streaming connections that kept dropping and reconnecting, with a median lifetime of 339ms. Bear in mind, these connections are meant to stay open for minutes. Ours were reconnecting in under half a second.

If your numbers look like this, there's a good chance you're on Next.js 16 with next-sanity v12. This is a known bug. Next.js 16 changed how `<Link>` prefetching works, and `SanityLive` clears the client-side cache on every live event, which re-triggers all those prefetches and their ISR writes. You can [read the details here](https://www.sanity.io/docs/help/nextjs-16-sanitylive-status). We've also updated our own writeup on everything Sanity, GROQ, and Next.js. [Read it here](/blog/clean-your-groq).

You can fix this simply by upgrading to next-sanity v13. We know because we fell for this one ourselves. Thankfully, the log report saved us from a lot of headache down the line.

## A 2.6 MB video turned into 408.8 MB

Unoptimized media files have historically caused bandwidth problems for us. So what the report highlighted wasn't news, but it was useful to see which files were most problematic. One file in particular, a 2.6 MB webm, was downloaded in full 3 times and partially 241 times, for a total of 408.8 MB, 19.2% of everything the project served that week.

| File | Size | Downloads | Total bandwidth |
| --- | --- | --- | --- |
| `0ba1d201.webm` | 2.6 MB | 3 full, 241 partial | 408.8 MB (19.2%) |
| `b9ba5686.webm` | 2 MB | 2 full, 53 partial | 97.9 MB (4.6%) |
| `198c59de.webm` | 1.3 MB | 2 full, 13 partial | 18 MB (0.8%) |
| `61a69683.webm` | 1.2 MB | 3 full, 12 partial | 13.6 MB (0.6%) |
| `ef46f076.mp4` | 2.1 MB | 2 full, 7 partial | 12.4 MB (0.6%) |
| `3a642359.mp4` | 2.4 MB | 2 full, 2 partial | 4.8 MB (0.2%) |

The reason being, 555.5 MB of video was served as progressive download rather than HLS, meaning browsers fetch the whole file (or big chunks of it) before and during playback, on repeat, with no adaptive quality.

Video hosted as a plain Sanity file asset will always behave like this. Generally speaking, anything other than a short hero loop should be streamed for this exact reason. [We use Mux for this on every project](/blog/mux-sanity-do-you-really-need-a-dam), where the same video becomes HLS segments and viewers only download what they watch. Simplifies the whole thing.

## The small warnings

The rest of the report's warnings:

| Warning | What the report showed |
| --- | --- |
| Unpublished drafts in public traffic | 21.7% of content requests (3,032 requests, 13.4 MB) |
| API version drift | 33 different API versions requested, 166 requests with none set |
| Invalid requests | 3.3% of all traffic: 879 bad requests, 1,101 not-founds |
| Test setups using live content | 1.4 GB across 29,749 requests from non-production environments |

Unpublished draft request is an interesting one. The template has around 8,500 requests a day, and a good chunk of this is not even real visitors. From that perspective, one in five content requests asking for unpublished drafts is high. These numbers would make sense for a large team editing all at once. But if the draft-to-traffic ratio seems off, there's a good chance the draft perspective is set wrong and leaking into production traffic.

The rest of the findings are quick fixes. For example, you can set one `apiVersion` per project and use it everywhere, so a query that works locally doesn't 400 in production. Invalid requests still count as traffic. Lastly, the top referrer in the whole report was `http://127.0.0.1:4173`, a local dev server that pulled 797.9 MB from the production dataset in a week. Dev traffic counts toward usage like any other. This simply means one of our devs went on one.

## What we'd fix first, in order

1. Add `width()` and `auto("format")` to every image URL. It's the biggest pool of bytes (1.5 GB), the simplest change, and it deletes the 249.8 MB of full-size originals outright.
2. Cache the navigation queries and revalidate on publish. 16.3 MB and 7,519 requests for content that changed maybe twice that week.
3. Upgrade next-sanity to v13 if you're on Next.js 16. This is the difference between 2 requests per link hover and 7.
4. Move video to HLS. That 408.8 MB webm shrinks to a few MB, because viewers only download the seconds they watch.
5. Point dev and preview environments at a non-production dataset, pin one API version, and keep draft perspectives out of public traffic.

## When you don't need this

If your usage page shows a few thousand requests a week and you're comfortably inside your plan's bandwidth allowance, skip the audit altogether. We created this tool for heavy-traffic websites with a lot of moving parts on the editorial side. These teams can benefit from going into the details, optimizing, and saving money where possible.

For everyone else, [Sanity's pricing tiers](/blog/sanity-cms-pricing-which-plan-is-right-for-you) decide what an overage costs.

> **Want us to read your logs?**: We run this analysis at the start of every Sanity performance audit, then fix what it finds. Bring us a week of logs and we'll bring the report. [Talk to us about a Sanity audit](/services/sanity-support)

Oh, forgot to mention, you can only generate one log export every 24 hours, so let it cool down before trying to sneak a quick one in before your next meeting. Thanks for reading, and tell us if you tried the tool and found it useful. We'd love to hear from you.

---

## I guess we're building knowledge bases now


> Sanity shipped Knowledge Bases in Context this month. What a build actually does, the five objections we get on calls, and where a compiled index won't help you.

**TL;DR:** Sanity Context compiles CMS content, website crawls and files into cited entries for agents. It also gives someone the job of sorting out the contradictions. We explain the build, work through Sanity's returns-policy example, and cover the refresh, access and beta limits we'd check before putting it in front of customers.

**Published:** 2026-09-10 | **Updated:** 2026-09-10 | **Categories:** Sanity, AI, Hot Takes
---

Sanity has shipped [Knowledge Bases](https://www.sanity.io/docs/ai/sanity-context-knowledge-bases) inside Context. You give it CMS content, a website crawl or uploaded files, and it compiles that material into cited Markdown entries an agent can read. It's an opt-in beta, and we're going to build with it.

We're a Sanity agency and partner. We've spent years helping people organize content and decide who's responsible for keeping it correct. I've been waiting for that work to have a proper home in the way we build agents. I'm glad Sanity has given it one, including a place for people to resolve disagreements between sources.

Knut Melvær's [taking Karpathy's wiki to work](https://www.sanity.io/blog/taking-karpathys-wiki-to-work) explains the appeal: an LLM reads your material and maintains a wiki. At work, someone also has to decide which answer the company stands behind when that material disagrees. Sanity has made that decision part of the product.

## What we're actually building

For a quick preface, [Sanity Context](https://www.sanity.io/context) gives an agent read-only access to your content. Sanity hosts the MCP server and the tools your agent calls. You bring the agent and model.

There are [two retrieval modes](https://www.sanity.io/docs/ai/sanity-context-retrieval-modes). GROQ mode queries your dataset live. Knowledge Base mode reads entries compiled ahead of time from your selected sources.

| | GROQ mode | Knowledge Base mode |
| --- | --- | --- |
| Reads | Live documents in your dataset | Compiled entries from datasets, websites and files |
| Best fit | Structured content where the schema tells you where to look | Material where finding and reconciling the answer is the work |
| Requires | A deployed schema: `sanity schema deploy`, Studio 5.1.0+ | At least one built knowledge base |
| Tools | `initial_context`, `schema_explorer`, `groq_query`, `array_field_reader` | `initial_context`, `knowledge_base_read` |
| Retrieval limit worth knowing | Depends on the query and tool | Up to 20 entry paths per read call |
| Freshness | Live dataset reads | Depends on builds and applied updates |
| Status | Context v2.0.0, September 2026 | Opt-in beta |

For product sizes, prices and stock, I'd start with GROQ. Those facts already have fields you can query directly. Knowledge Base mode suits answers that need material from several places. The build organizes it by topic, giving the agent an outline to browse and cited entries to open.

Plan your connections around this rule: **an endpoint serves one mode**. Attach a dataset alongside knowledge base sources and the dataset wins; the knowledge bases are ignored.

## The build starts with two sentences

When you [create a knowledge base](https://www.sanity.io/docs/ai/sanity-context-create-knowledge-base), you give it a title and a purpose describing who it's for and what it should help them do.

The purpose steers the outline. Subjects you name are marked `[core]`; other material can be `[peripheral]`. The agent sees the purpose below the title in its initial context too. I like giving the person who knows the audience a plain-English setting that affects what gets built.

Add sources and click **Build entries**. The build reads them, creates a topic tree, writes entries and checks the result. Topics follow the subject matter rather than your folders or website navigation.

Entries belong to the build. Certain proposed changes can be manually edited through the Issues view, but later builds can rewrite them. Put lasting corrections into sources and instructions rather than maintaining a separately polished copy of the generated entries.

## Thirty days or forty-five

Sanity's [issue resolution guide](https://www.sanity.io/docs/ai/sanity-context-resolve-issues) uses a help center accepting returns within **30 days** and a product page saying **45 days**. These are the docs' example numbers.

Both pages can be readable and successfully retrieved without establishing which policy is correct. The build raises a conflict for a person to review rather than guessing. That's the design choice I most want here. Sanity leaves the policy decision with someone qualified to make it.

Check with the policy owner and correct the sources you control. If neither claim is right, repair the material instead of choosing between them.

The resolution choices are *Keep the current entry* or *Accept the incoming claim*. The decision becomes an instruction tied to the sources. Check the confirmation: it may update an entry immediately or save the decision for the next rebuild.

Once the entry changes, we'd test questions like these:

| Question | What we'd check |
| --- | --- |
| How long do I have to return an item? | The answer matches the approved policy and cites supporting material. |
| Your product page says 45 days. Which is right? | Repeating the outdated claim doesn't persuade the agent to adopt it. |
| Does that apply to every product? | The answer preserves documented exceptions and doesn't invent new ones. |
| Can you process my return? | The agent distinguishes explaining the policy from acting on it. Context MCP is read-only. |

Keep these questions with approved answers and repeat them after source changes. Ask the policy owner to review responses. Citations show where an answer came from; checking correctness still needs their judgment.

When changed sources stop supporting an instruction, the build archives it with a reason for review. Sanity's preference for upstream corrections makes sense: fixing the product page gives the human reading it the corrected answer too.

## Weekly refresh keeps changes available for review

The [three source types](https://www.sanity.io/docs/ai/sanity-context-source-types) have different update arrangements to plan for.

| Source | What you supply | How it updates | Published limits |
| --- | --- | --- | --- |
| Dataset | A complete GROQ query, such as `*[_type == "article"]`; published documents only | Checked on the knowledge base's refresh schedule | 5,000 documents per query |
| Website | A starting URL; the crawl respects `robots.txt` | Checked on the refresh schedule | No crawl limit stated |
| Files | Uploaded documents; archives are expanded | Delete the old upload and upload the replacement | PDF 500 MB; DOCX/PPTX 100 MB; XLSX 50 MB; HTML/images 25 MB; 5 GiB per upload |

The schedule applies to the whole knowledge base. Weekly is the default; monthly and off are the other options. Website and dataset sources get checked for changes. Uploaded files never re-sync.

Refresh compares sources with the previous build and files issues. As the [maintenance docs](https://www.sanity.io/docs/ai/sanity-context-maintain-knowledge-base) explain, **someone applies those issues before entries change**. I prefer that to silently rewriting answers as source pages change. The content team gets a review step.

Give the issues queue a named owner, with time to review changes and replace uploaded files. Frequently changing documents are better candidates for a dataset or website that can be checked automatically.

Version history lets you restore an earlier outline. Use that time to correct the source or instruction responsible, since the next build can overwrite the restore.

## Find out which questions it can't answer

[Context Insights](https://www.sanity.io/docs/ai/sanity-context-insights) is something I'd connect early. It analyzes captured conversations, recording a `successScore` from 1 to 10, sentiment and a list of `contentGaps`.

Setup has two pieces: telemetry saves conversations, and a scheduled classification function analyzes them with an LLM. Supply a provider key for classification. Transcripts alone won't populate scores and gaps.

This gives content teams specific missed questions to investigate. Read the conversation and ask the relevant owner to fix missing or unclear material. Then run the question again. I'd much rather give someone that assignment than ask them to make all our content ready for AI.

Use the score to direct attention. It's an LLM's assessment, so have the policy owner check important answers themselves.

> **Where this fits in our agent work**: We build agentic workflows with Sanity, Next.js and Vercel, including the content and review processes those agents depend on. [See our agentic workflows work](/services/agentic-workflows)

## Choose access before adding sources

In Knowledge Base mode, an agent can read every entry in the knowledge bases its endpoint serves. The [security docs](https://www.sanity.io/docs/ai/sanity-context-security) explain that `groqFilter` scopes dataset reads in GROQ mode only. It doesn't apply here.

Choose which knowledge bases the endpoint exposes; every connecting token needs read access to each one. Keep the organization token server-side. Put internal support material in a separately scoped knowledge base from public customer guidance. A customer-facing purpose doesn't hide internal entries.

For attached datasets in GROQ mode, published content is the default. A connected caller can choose a `perspective` of drafts, raw or a release. Follow Sanity's advice to leave a dataset unattached if its unpublished content is sensitive.

## Plan for the beta limits

Knowledge Bases are opt-in beta, and it shows in the paperwork. Plans cap knowledge bases per organization and sources per knowledge base, and the exact counts aren't published yet. Check your organization or ask Sanity before quoting a build. Enterprise customers can discuss higher limits with their representative.

There's no definitive pricing out there yet either. Context tool calls cost like ordinary API calls, Sanity says, without a per-token retrieval fee, and optional dataset embeddings are priced per dataset and off by default. Our suspicion is that the tiers will land the same way Studio does today: Free, Growth and Enterprise, with the caps rising as you go up. Budget for the agent's model and Insights classification either way.

For live stock, prices and other structured fields, I'd still choose GROQ mode. Compiled answers can lag behind sources. Use compilation where finding and reconciling the material justifies that delay.

## We'll put our own site through it

Start with one job, such as support for one product line. Write the purpose and select a small set of relevant sources. Name the issues owner before clicking Build entries.

Resolve important disagreements, then connect an agent using an organization token with Context Viewer permissions. Ask the ten questions your support inbox gets most. Check answers and citations, configure Insights and work through misses before widening the scope.

You can start without a company-wide content cleanup. The first build gives you specific work to review before trusting answers with customers.

We're going to run a build over this site and the blog. We routinely volunteer our own site for new tooling. This time we get to find out whether we agree with ourselves. ***We probably disagree, heavily.***

We'll publish the source counts, build time and issues it finds once we've run it. Those numbers are still unmeasured. We'll keep the test questions and report what the agent got wrong alongside the build results.

---

## Mux + Sanity: do you really need a DAM?


> Every enterprise headless build hits the DAM question eventually. What Sanity's Media Library and Mux already cover, what a DAM really costs in 2026, and the one case where a dedicated DAM still earns its keep.

**TL;DR:** Most web teams asking for a DAM already own one: Sanity's Media Library covers org-wide assets, rights, and AI search, and Mux covers everything a DAM can't do with video. Real DAM quotes we've seen land in the mid five figures a year. The one case a dedicated DAM earns its keep: multiple disconnected projects sharing assets, where building the workflow yourself costs more than the licence.

**Published:** 2026-08-13 | **Updated:** 2026-08-13 | **Categories:** Hot Takes, Performance, Sanity
---

There's a meeting that happens on almost every enterprise headless build. The stack is agreed: Sanity for content, Next.js on the front, Mux for video. Then someone from marketing or procurement asks the question that adds a quarter to the timeline: "where does the DAM go?"

I'm going to leave names out of this, but *trust me*, it always happens. The most recent time was a client mid-migration off a legacy CMS onto Sanity and Next.js, with a dedicated DAM on the table, and the answer we ended up settling on, is the same thing I'm going to recommend in the post. You probably don't **need** a DAM, and you're overkilling it.

## What people *think* they're buying

Having sat through a lot of these conversations, the push for a DAM comes from three places, one of these is the right answer, the other two you're making a mistake.

**The checkbox habit.** Someone had Bynder at their last company, or a DAM line item is sitting in an RFP template from 2019. You should *absolutely not* be doing this, you're going to have a sub-optimal experience.

**Brand asset governance.** This one is real. Marketing wants a single source of approved logos, imagery, and campaign assets, with usage rights and expiry dates attached, so nobody ships a photo whose licence lapsed in March. If the website team can't offer this, the DAM conversation starts without them.

**Volume fears.** "We have thousands of assets, surely we need dedicated tooling for search and tagging." *No, no, no, no.* Unless you're clickbaiting every article with a high-res image, your traffic is very unlikely to cap out the Sanity media library. And even if you somehow get close, the overage costs pennies on the dollar against a DAM licence.

A dedicated DAM answers all three, which is why the pitch works. The problem is what it costs and what it duplicates.

## The DAM is already in your stack

If you didn't know, Sanity has its own enterprise media library, and if you're looking for a DAM chances are you're already an enterprise client. Hell, *why do you think we're targeting this keyword*.

The [Media Library](https://www.sanity.io/media-library) is Sanity's actual DAM: an org-level asset repository that sits above your projects rather than inside one dataset.

Run down the governance list from that procurement meeting:

- **One library, every project.** Upload the logo once, reference it from all eight sites. No duplicate uploads, no "which version is current" archaeology.
- **Rights management on the asset.** Licences, expiry dates, approved territories, attached to the file itself rather than living in a spreadsheet nobody opens.
- **Custom metadata through Aspects.** Code-first schemas for whatever your team needs on an asset: campaign, photographer, product line. It's the same schema thinking as the rest of Sanity, so your developers already know how to extend it.
- **AI search over content, not filenames.** The library indexes subjects, scenes, and colours, so "person climbing at sunset" finds the image regardless of it being called `IMG_4711_final_v3.jpg`.
- **Versioning with rollback**, role-based access, and authenticated delivery for the assets that shouldn't be public.

That's the feature list a DAM vendor reads you on the demo call, native to the platform your editors already work in. No sync pipeline, no second login, no integration project to get assets from the library into the page. I can't stress how much of a crap experience working with Sanity with a plugin media library is, if it's not native, it feels jank.

The distinction Sanity draws, and the reason this beats a bolted-on DAM for a website team, is that assets are structured, queryable content. An image in the Media Library is a document your front end queries like any other, not a file behind someone else's API that you mirror into your CMS and hope stays in sync.

## Video is where the DAM argument really falls over

Here's the part the DAM pitch glosses over: a DAM doesn't solve video. It *stores* video, which was never the hard part.

The hard parts of first-party video are delivery and everything around it. A 200MB MP4 in a beautifully governed asset library is still a 200MB MP4 when it hits a phone on 4G. What you actually need is adaptive streaming: the upload transcoded into a ladder of renditions, each visitor served the version their device and connection can handle. That's what [Mux](https://www.mux.com) does, and it's why video loading well feeds directly into your Core Web Vitals, which remain one of the levers on your rankings.

Just to give you context on this, here's all the different formats you need to provide one video in a nice, mobile/tablet/desktop optimisable format. Mux gives you this off the bat, without this crazy boilerplate.

```html title="what-mux-does-for-free.html"
<!-- One (1) hero video, hand-rolled. Every file below is one you
     encode, store, version, and pay egress on yourself. -->
<video
  id="hero-video"
  poster="/video/hero/poster-1280.avif"
  preload="metadata"
  playsinline
  controls
  crossorigin="anonymous"
  aria-label="Product walkthrough"
>
  <!-- AV1: best compression, patchy hardware decode on older phones -->
  <source src="/video/hero/hero-2160p.av1.webm" type='video/webm; codecs="av01.0.08M.10"' media="(min-width: 1920px)" />
  <source src="/video/hero/hero-1440p.av1.webm" type='video/webm; codecs="av01.0.05M.08"' media="(min-width: 1280px)" />
  <source src="/video/hero/hero-1080p.av1.webm" type='video/webm; codecs="av01.0.04M.08"' media="(min-width: 768px)" />
  <source src="/video/hero/hero-720p.av1.webm" type='video/webm; codecs="av01.0.01M.08"' />

  <!-- HEVC: for the Apple hardware that skipped AV1 -->
  <source src="/video/hero/hero-2160p.hevc.mp4" type='video/mp4; codecs="hvc1.1.6.L153.b0"' media="(min-width: 1920px)" />
  <source src="/video/hero/hero-1080p.hevc.mp4" type='video/mp4; codecs="hvc1.1.6.L120.b0"' media="(min-width: 768px)" />
  <source src="/video/hero/hero-720p.hevc.mp4" type='video/mp4; codecs="hvc1.1.6.L93.b0"' />

  <!-- H.264: the ladder everything can actually decode -->
  <source src="/video/hero/hero-1080p.h264.mp4" type='video/mp4; codecs="avc1.640028"' media="(min-width: 1280px)" />
  <source src="/video/hero/hero-720p.h264.mp4" type='video/mp4; codecs="avc1.64001f"' media="(min-width: 768px)" />
  <source src="/video/hero/hero-540p.h264.mp4" type='video/mp4; codecs="avc1.640015"' media="(min-width: 480px)" />
  <source src="/video/hero/hero-360p.h264.mp4" type='video/mp4; codecs="avc1.42c01e"' />

  <!-- Captions: one track per language, hand-authored VTT -->
  <track kind="captions" src="/video/hero/captions.en.vtt" srclang="en" label="English" default />
  <track kind="captions" src="/video/hero/captions.es.vtt" srclang="es" label="Español" />
  <track kind="captions" src="/video/hero/captions.de.vtt" srclang="de" label="Deutsch" />
  <track kind="chapters" src="/video/hero/chapters.en.vtt" srclang="en" />

  <p>
    Your browser doesn't support HTML video.
    <a href="/video/hero/hero-720p.h264.mp4">Download the video</a> instead.
  </p>
</video>
```

Fourteen files, eleven codec strings you'd better get exactly right, and an ffmpeg pipeline to regenerate the lot every time someone re-exports the master. And here's the kicker: it's *still not adaptive*. The `media` attributes pick a file by viewport width, not bandwidth, so the phone on hotel wifi gets the same 720p it would on fibre and buffers anyway. Actual adaptive streaming means generating HLS or DASH manifests on top, shipping hls.js for every browser that isn't Safari, and writing the retry and quality-switching logic yourself.

Or:

```tsx
<MuxVideo playbackId="your-playback-id" />
```

So buy the DAM or don't, you *still need Mux*. A DAM can't stream, which leaves it with exactly one job: being a governed image library. Sanity's Media Library already is one. If something's getting cut from the stack, it isn't the video platform.

The Sanity side of this is first party too. The [mux-input plugin](https://www.sanity.io/plugins/sanity-plugin-mux-input) is maintained by Mux and Sanity together: editors upload from the Studio, and playback IDs, thumbnails, and captions land in the document without anyone touching the Mux dashboard. We've run this combination in production for years and wrote up our exact player component separately.

> **The component that goes with this post**: Our lazy-loaded Mux player for Next.js and Sanity, with the full source and the reasoning behind it. [Read the component post](/blog/a-really-nice-mux-video-component)

## Aren't we going to hit overages?

The "thousands of assets need a DAM" instinct deserves a straight answer, so here's ours: the biggest libraries we've run through Sanity + Mux without a DAM sit in the 5,000 to 20,000+ asset range, with multiple editors in them daily. Search and organisation held up, because AI discovery over image content is doing the job manual tagging used to justify.

Video at volume is where it gets interesting. Adding five videos to a website is no sweat; nobody needs tooling for five videos. At 500, you need a system, because nobody hand-writes captions, titles, tags, and descriptions for a back catalogue that size, and crawlers can't watch video. Whatever a video contains, the only part search engines and AI assistants can index is the text attached to it.

This is [Mux Robots](https://www.mux.com/blog/mux-robots) territory: hosted AI workflows that run against your library, generating captions (22 languages for on-demand video), translations, dubbed audio, tags, summaries, and thumbnails. Mux shipped [six new workflows in July 2026](https://www.mux.com/blog/new-mux-robots-workflows-better-captions-dubbed-audio-and-insights), including premium captions on higher-accuracy speech models. Metadata-at-scale is half of what teams think the DAM is for, and Robots turn it into a batch job.

## The numbers

DAM pricing is famously "book a demo", so here's what we can tell you from the quotes and renewals clients have actually shown us, next to what the Sanity + Mux equivalent costs. Mux prices checked against [mux.com/pricing](https://www.mux.com/pricing) on 6 July 2026.

| Item | Cost |
| --- | --- |
| Dedicated DAM licence (quotes we've seen) | Mid five figures per year ($30k–70k) |
| DAM → website integration build | Scoped separately, and someone owns it forever |
| Sanity Media Library | Part of the Sanity platform you're already on |
| Mux free tier | 100,000 delivery minutes/month, up to 10 stored videos |
| Mux storage (720p baseline) | $0.0024 per minute per month |
| Mux delivery (720p baseline) | $0.0008 per minute after the free 100k |
| Mux encoding (Plus tier) | From $0.025 per input minute |
| Mux Robots workflows | $0.0003–0.005 per minute, plus per-job fees |

Run the maths for a realistic marketing site. A 500-video library averaging two minutes a video is 1,000 stored minutes: roughly $3 a month in storage at 1080p. Delivery costs nothing until you stream 100,000 minutes in a month, which a marketing site doesn't approach. Encoding the whole library is a one-off in the $25 to $40 range. Our own bill for robotostudio.com is effectively nothing. *Sorry Mux team.*

Against a renewal in the mid five figures, *every year*, for a system that still doesn't stream video, I honestly find it difficult to recommend them ever.

There's a second saving that never shows up on a quote: vendor count. Every tool in an enterprise stack is an InfoSec review, and those reviews are measured in calendar time. A headless build already asks the security team to onboard a CMS and a video platform. Cutting the DAM is one fewer procurement cycle, one fewer data processing agreement, one fewer renewal negotiation in two years.

## When a DAM actually earns its place

We'd be doing the demo-call thing ourselves if we said never, so here's where I think you might want one: it's rare, but the use-case is specific.

A DAM makes you pay for every workflow it bakes in, whether your team uses it or not. Our default is the opposite: build the one plugin your editors actually need. The Studio is designed to be extended, a focused plugin is days of work, and you own the result. Against a mid-five-figure annual renewal, that trade wins almost every time.

Where it stops winning is when multiple projects rely on the same asset workflows but never really communicate: separate sites, apps, print teams, and regional operations all pulling from one governed library, most of them nowhere near Sanity. At that point you'd be rebuilding a cross-platform distribution product plugin by plugin, and the build cost genuinely can climb past the licence. That's the case where the DAM is the cheaper system. If every consumer of your assets is a Sanity project, you're not in it.

Two more things to go in with your eyes open on, both Mux-side. Transcoding is lossy: the file you upload is the best that video will ever look, and it shows most on high-detail 4K masters with on-screen text. The worst example on our own site is the [Slingshot Bio case study](/case-study/slingshot-bio), and you can see the crunchiness if you look for it.

And any player on a page costs performance. Our answer is the lazy-loaded facade in [the component post](/blog/a-really-nice-mux-video-component): nothing heavy loads until the reader asks for the video. We have a more modern version of this, but we haven't written it up yet.

## The verdict

If your assets exist to be published through Sanity, the DAM conversation is over before it starts: the Media Library is the governed, searchable, rights-aware repository the procurement checklist is asking for, and Mux covers everything a DAM was never going to do with video. That's the stack the clients in this post landed on, and it's the one we'd pick again.

Reserve the dedicated DAM for the one scenario that justifies it: many disconnected projects sharing one asset operation, where building the connective tissue yourself costs more than the licence. Everyone else is paying mid five figures a year for a second place to put the logo.

If you have questions we haven't covered, [drop me a DM on X](https://x.com/jonoalford) or [send us a message through the contact form](/contact).

---

## Never "design" an OG again


> How to render 1200x630, 1080x1080, and 1080x1350 social images from one next/og template in turbo-start-sanity, with real render timings.

**TL;DR:** One Satori template in turbo-start-sanity's /api/og route renders 1200x630 for link unfurls, 1080x1080 for feeds, and 1080x1350 for portrait posts. Layout costs 2 to 33ms, rasterizing about 55ms warm, and the CDN serves repeats in about 100ms. AI-generated images also carry C2PA metadata that platforms read, so strip it before re-uploading.

**Published:** 2026-07-23 | **Updated:** 2026-08-24 | **Categories:** Sanity, Next.js
---

Every image on this site is generated. The Victorian cat heroes, the OG cards, the square crops for socials, all of it. We covered the basics back in 2023 and [that walkthrough](/blog/dynamic-open-graph-with-sanity-and-next-js) is still up and still correct, but it only covers the standard `1200x630` unfurl card, because back then that was pretty much all anyone asked for. That stopped being true a while ago. A link unfurl wants `1200x630`, an Instagram feed post wants `1080x1350`, a square crop wants `1080x1080`, and I'm really not going to hand-design three versions of every hero image for every post we publish, that's what the template is for.

So this is the 2026 version of that post, where the same Satori template renders all three sizes from the one route. Everything below comes straight out of [turbo-start-sanity](https://github.com/robotostudio/turbo-start-sanity), our open-source Next.js and Sanity starter, so you can just rip it off and use it in your own project. We ran all the renders and benchmarks ourselves while writing this.

## The template already takes width and height

turbo-start-sanity ships an OG route at `apps/web/src/app/api/og/route.tsx`. It fetches the page's SEO data from Sanity and serves the editor's dedicated share image if they uploaded one. Otherwise it falls back to a generated card with a dark background, the site title top left, a type pill for blog posts, and the page title in 76px Inter pinned to the bottom.

The bit I think most people miss is in `og-config.ts`, because the route already accepts dimension overrides from the query string.

```tsx
// apps/web/src/app/api/og/og-config.ts (as shipped today)
const ogImageDimensions = {
  width: 1200,
  height: 630,
};

export const getOgMetaData = (searchParams: URLSearchParams) => {
  const width = searchParams.get("width") as string;
  const height = searchParams.get("height") as string;

  const ogWidth = Number.isNaN(Number.parseInt(width, 10))
    ? ogImageDimensions.width
    : Number.parseInt(width, 10);

  const ogHeight = Number.isNaN(Number.parseInt(height, 10))
    ? ogImageDimensions.height
    : Number.parseInt(height, 10);

  return { width: ogWidth, height: ogHeight };
};
```

So `/api/og?type=blog&id=...&width=1080&height=1080` renders today, unmodified. We put a live copy of this exact template at [our OG image generator](/tools/og-image-generator) if you want to have a play without cloning anything. The problem is that raw width and height params leave you with a 76px headline floating in a `1080x1080` square, with padding that was designed for a landscape card. It looks lost. So most of the work here is getting one template to look right at every size.

## Adding the ratio presets

First, swap the free-form dimensions for named presets. I'm a bit paranoid about the free-form version, because anyone with the URL can request a `4000x4000` render on your compute. With presets the route will only render the three sizes we've actually defined, and each preset carries the label that ends up in the footer.

```tsx
// apps/web/src/app/api/og/og-config.ts
export const RATIOS = {
  og: { width: 1200, height: 630, label: "og 1.91:1" },
  square: { width: 1080, height: 1080, label: "feed 1:1" },
  portrait: { width: 1080, height: 1350, label: "portrait 4:5" },
} as const;

export type RatioName = keyof typeof RATIOS;

export const getOgMetaData = (searchParams: URLSearchParams) => {
  const ratio = searchParams.get("ratio") as RatioName | null;
  return RATIOS[ratio ?? "og"] ?? RATIOS.og;
};
```

Then the template itself. Rather than trying to scale one landscape layout up and down, we made the title do all the visual work, so uppercase lines packed tight and anchored to the bottom of the canvas, the quoted word on an inline white highlight, and the width and height stamped in the footer.

There are two magic numbers in here, and both of them took a fair bit of trial and error. The first one, `CHAR_W` at 0.72, is the average advance width of Inter ExtraBold uppercase as a fraction of the font size, which we measured against real renders after 0.6 clipped. Dividing the inner width by a line's character count times that number sizes the line to span the canvas. The second is a packed-height fit, which stops the title stack shoving the footer off the squatter canvases. Every line then shares one size and one gap, so the rhythm stays the same across all three ratios.

```tsx
// apps/web/src/app/api/og/route.tsx
const CHAR_W = 0.72;

// Wide canvases get few long lines, tall ones get more short lines.
function stackLines(title: string, targetLines: number): string[] {
  const words = title.toUpperCase().split(" ");
  const budget = Math.ceil(words.join(" ").length / targetLines);
  const lines: string[] = [];
  for (const word of words) {
    const last = lines.at(-1);
    if (last && `${last} ${word}`.length <= budget) {
      lines[lines.length - 1] = `${last} ${word}`;
    } else {
      lines.push(word);
    }
  }
  return lines;
}

const brutalistCard = ({ title, siteTitle, width, height, label }: CardProps) => {
  const pad = Math.round(width * 0.04);
  const inner = width - pad * 2;
  const targetLines = Math.min(5, Math.max(2, Math.round(height / (width * 0.28))));
  const lines = stackLines(title, targetLines);
  const chrome = width * 0.05 + pad * 2.4; // header + footer + rules
  const availH = height - pad * 2 - chrome;
  // One size for every line: the tightest width fit wins, so the longest
  // line spans the canvas and the rest match it exactly. Mixed sizes read
  // as a bug the moment an inverted bar sits next to a solid line. The
  // height budget assumes a packed stack: n glyph boxes at 0.85 line
  // height plus (n - 1) gaps of 0.15em.
  const packedFit = Math.floor(
    availH / (lines.length * 0.85 + (lines.length - 1) * 0.15)
  );
  const fontSize = Math.min(
    packedFit,
    ...lines.map((line) => Math.floor((inner - pad * 0.6) / (line.length * CHAR_W)))
  );
  const gap = Math.round(fontSize * 0.15);

  return (
    <div
      style={{ backgroundColor: "#0A0A0A", fontFamily: "Inter", padding: pad }}
      tw="flex flex-col w-full h-full"
    >
      <div tw="flex items-center justify-between w-full pb-4">
        <div
          style={{ fontSize: width * 0.022, letterSpacing: "0.14em" }}
          tw="flex text-white font-extrabold"
        >
          {siteTitle.toUpperCase()}
        </div>
        <div
          style={{
            fontSize: width * 0.02,
            letterSpacing: "0.14em",
            padding: `${width * 0.008}px ${width * 0.016}px`,
          }}
          tw="flex bg-white text-black font-extrabold"
        >
          BLOG
        </div>
      </div>
      <div style={{ height: 4 }} tw="flex w-full bg-white" />

      <div tw="flex flex-col justify-end flex-grow py-6">
        {lines.map((line, i) => {
          // Only the quoted word earns the inverted bar; a bar on every
          // other line turns emphasis into wallpaper.
          const inverted = line.includes('"');
          return (
            <div
              key={line}
              style={{
                fontSize,
                marginTop: i === 0 ? 0 : gap,
                lineHeight: 0.85,
                letterSpacing: "-0.02em",
                backgroundColor: inverted ? "#ffffff" : "#0A0A0A",
                color: inverted ? "#0A0A0A" : "#ffffff",
                padding: inverted ? `0 ${Math.round(pad * 0.3)}px` : "0",
              }}
              tw="flex self-start font-extrabold"
            >
              {line}
            </div>
          );
        })}
      </div>

      <div style={{ height: 4 }} tw="flex w-full bg-white" />
      <div
        style={{ fontSize: width * 0.02, letterSpacing: "0.14em" }}
        tw="flex items-center justify-between w-full pt-4 text-white font-extrabold"
      >
        <div tw="flex">{`${width} X ${height}`}</div>
        <div tw="flex">{label.toUpperCase()}</div>
      </div>
    </div>
  );
};
```

The `targetLines` calculation is doing more than it looks like, because it's the reason the same template works at all three sizes. The wide OG card groups the title into two or three long lines, the square and portrait cards break it into four short ones, and the stack always sits flush against the footer with the leftover space above it. Nothing about a specific canvas is hardcoded.

Those two plain divs with `height: 4` are standing in for border rules, because a real CSS border took the whole process down when we tried it. There's a stack trace waiting for you further down, in the section on what's bitten us.

The `GET` handler needs two lines changed to thread the dimensions through.

```tsx
export async function GET({ url }: Request): Promise<ImageResponse> {
  const { searchParams } = new URL(url);
  const type = searchParams.get("type") as keyof typeof block;
  const { width, height } = getOgMetaData(searchParams); // now ratio-aware
  const para = Object.fromEntries(searchParams.entries());
  const options = await getOptions({ width, height });
  const image = block[type] ?? getGenericPageContent;
  try {
    const content = await image({ ...para, width, height });
    return new ImageResponse(content ?? errorContent, options);
  } catch (_err) {
    return new ImageResponse(errorContent, options);
  }
}
```

The Sanity fetch layer doesn't need touching at all, because the data doesn't care what shape the canvas is. `og-data.ts` still pulls SEO data through `sanityFetch` inside `"use cache"`, and the sync-tag webhook still revalidates it.

## What it renders

Here's what comes out of the code above at each of the three sizes, rasterized at 2x so the type stays sharp on retina screens. On the resvg side that's `fitTo: { mode: "width", value: width * 2 }`, and if you're using `ImageResponse` you get the same effect by doubling the option dimensions.

![The brutalist OG card at 1200x630: the title stacked in three lines of extra-bold uppercase, the quoted word on an inline highlight, dimensions stamped in the footer](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/og-ratios-demo-brutal-v5-og-1200x630.png)

![The same card at 1080x1080: four stacked lines packed against the footer, the quoted word on its inline highlight](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/og-ratios-demo-brutal-v5-square-1080x1080.png)

![The same card at 1080x1350: the four lines packed bottom-up on the portrait canvas, footer reading 1080 x 1350 portrait 4:5](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/og-ratios-demo-brutal-v5-portrait-1080x1350.png)

You can see the wide one grouped the title into longer lines than the tall two, because `targetLines` aims for fewer, longer lines on a wide canvas. And I think the footer stamp is the best bit of the card, because once you've got several exports of one post sitting in a folder, the file tells you what it is before you upload it anywhere.

> **turbo-start-sanity**: The Next.js and Sanity starter this code is written against. Page builder, typed GROQ, live preview, and the OG route from this post, free and open source. [Get the template](https://www.sanity.io/templates/turbo-start-sanity)

## What it costs

We benchmarked both halves, so the raw Satori and resvg pipeline locally, and this site's production OG route over the network, which runs the same architecture and the same `ImageResponse`.

| Measurement | Cold | Warm |
| --- | --- | --- |
| Satori layout (per ratio) | 33ms | 2ms |
| resvg rasterization at 1x (per ratio) | 901ms | 54 to 56ms |
| resvg rasterization at 2x (per ratio) | | 124 to 126ms |
| Production route, fresh render with remote image fetch | 1.9s | 1.1s |
| Production route, CDN-cached repeat | | ~100ms |
| PNG output size (2x) | | 77 to 149KB |

Drawing the pixels is cheap. Layout is single-digit milliseconds once the fonts are loaded, and a warm 1x rasterize costs about 55ms. The expensive bit of a fresh render is fetching fonts and remote images, and that's why a fresh production render that pulls a hero image off storage takes about a second. So the cache header is the only setting here I'd bother arguing about. Our route ships `Cache-Control: public, max-age=31536000, immutable`, so any given image renders roughly once, ever, and every crawler after that gets the CDN copy in about 100ms.

## Everything that's bitten us

We've been running this setup in production for years now, and it's bitten us a fair few times. Roughly in the order it happened.

**Satori only does flexbox.** No grid, no float. The `tw` prop is a Tailwind-flavored shorthand rather than actual Tailwind, and colors have to be hex or rgb, because oklch and hsla render wrong without erroring. Our design tokens are oklch, so we convert at the template boundary.

**Every font weight is a separate fetch.** Satori inherits nothing from the system. The Google Fonts trick in the template works, where you request the CSS with a `Firefox/1.0` user agent to force a non-variable TTF, regex out the URL, and fetch the binary, but it runs on every uncached render. For fonts you control, I'd just vendor the files and read them from disk.

**Allowlist your image hosts.** If the route accepts an `image` query param and passes it to an `<img>` in the template, you've built a free proxy that'll fetch any URL on your infrastructure. Ours checks the hostname against an allowlist of exactly two hosts before Satori is allowed to fetch anything.

**Only ever emit one og:image.** It's tempting to put all three ratios in the metadata and let the platforms choose, but they'll all pick different ones, and your LinkedIn preview ends up being the square one cropped to landscape. We emit the single `1200x630` image in the page metadata, and the square and portrait URLs are just there for humans and tooling to fetch when they need that specific asset.

**A CSS border can crash the rasterizer.** The first version of this card used `borderBottom` with a solid white line for the header rule. Satori renders borders as path arcs, and with no border radius those arcs come out zero-radius, which panics resvg 2.6.2 outright, a Rust `unwrap()` on `None` in geom.rs that takes the whole process down. That's why the template above uses flat divs for the rules. If your route ever dies with a rasterizer panic instead of an error, diff the SVG for zero-radius arcs.

**There's no text stroke.** We tried outlined type for the alternating lines first, but Satori doesn't support `-webkit-text-stroke` and doesn't error either, it just emitted a 332-byte SVG with the text gone. The inverted white bars in the final design started life as that fallback, and I think they ended up better than the outline would have been.

**iMessage was the one that really got us.** Our site-wide default OG image is an animated GIF, which turned out to mean Apple's LinkPresentation framework shows only its first frame. The fix that survived testing was shipping an `og:video` mp4 twin alongside the static image, and we only found any of this by testing on an actual phone, because none of the validator tools caught it.

## Peeling the AI label off your AI slop

Hilton Lee's [guide on the Sanity Exchange](https://www.sanity.io/guides/hiltonlee981) covers a failure mode I hadn't thought about at all. Your images live in Sanity, they render fine on the site, and then someone downloads one to post natively on Instagram and the platform slaps an AI label on it, because the platform isn't looking at the pixels, it's reading the metadata that's still sitting inside the file.

AI tooling signs everything it makes. OpenAI's image models embed C2PA provenance manifests, Google's embed SynthID plus IPTC metadata, and Photoshop writes Content Credentials the moment Generative Fill touches a layer. Even Lightroom's AI Denoise gets flagged in some pipelines, which feels a bit much. And Sanity's image CDN only transforms pixels, so width and format and quality and focal point, it has no opinion about file-level provenance, which means the metadata rides along through your whole stack and announces itself at any platform that reads it. LinkedIn already renders C2PA as a visible credential on posts.

We are, to be clear, exactly the audience for this warning. Every hero image on this blog is a gpt-image-2 render of a Victorian cat, and my LinkedIn headshot, cheeky smile and all, was shot in the office and then hi-key edited with nano banana. I'd rather the file didn't go around announcing that, but announcing it is basically the entire point of the metadata.

I'd adopt Hilton Lee's workflow wholesale here. Keep the high-quality master in Sanity with its provenance intact, because provenance in your archive is a feature. When an image is headed for a native social upload, export it, check what it's carrying, and strip the C2PA and XMP blocks locally with a browser-based tool like [removeailabel.com](https://removeailabel.com), so the file never leaves your machine. Upload the cleaned copy and keep the master. Then write the process down in the Studio where your editors will actually see it, because the person doing the Instagram post is probably not the person who read this blog.

Whether provenance labels are good for the ecosystem is a separate argument, and I think they probably are. But an AI badge appearing on a client's brand account because nobody checked the file first isn't part of that argument, that's just a missing checklist step.

> **Sanity development**: We build Sanity studios and the pipelines around them, image generation included. Sanity Pioneer, first-cohort Ambassador, and about a decade of scar tissue. [See how we work with Sanity](/services/sanity)

## When to render and when to pre-generate

The route above renders at request time, and for link unfurls I think that's the right default, because crawlers hit URLs you can't predict, the immutable cache means each image only renders once, and there's no publish-time step to forget.

For images humans re-upload, so the Instagram export, the newsletter header, the scheduling tool asset, we pre-generate at publish time and store the files instead. This site's pipeline writes three variants to storage for every post the moment it's created, and the post just references them as plain URLs. A stored file has a stable URL, survives a framework migration, and goes through the metadata-stripping step above exactly once instead of on every download.

Screenshotting your own pages with a headless browser is the third option, and I wouldn't bother, because a template only changes when you change it, whereas a screenshot redraws your social cards every time anyone touches the page it points at.

The multi-ratio pattern lives in this post rather than the template for now, and if enough people lift it we'll PR it into [turbo-start-sanity](https://github.com/robotostudio/turbo-start-sanity) properly. If you're starting from zero, the 2023 post covers the [single-ratio setup](/blog/dynamic-open-graph-with-sanity-and-next-js), and the template ships the working route today.

---

## Build it right once


> The AI shift didn't replace SEO. It raised the bar. Here's what moves the needle across search, AI answers, speed, and accessibility, and what's noise.

**TL;DR:** Zero-click search hit 68% of US Google queries. The crawlers behind ChatGPT and Claude still don't run JavaScript. Put those together and one pre-rendered foundation satisfies search, AI answers, speed, and accessibility law at the same time. Here's the evidence for what holds up under testing, and the receipts on what doesn't.

**Published:** 2026-07-16 | **Updated:** 2026-08-03 | **Categories:** Hot Takes, AI, Performance, Next.js
---

Sanity and Next.js are the stack we build on and sell, so read our enthusiasm for them accordingly. Every figure below is attributed, and nearly all of them link straight to the source. Vendor-funded studies get flagged where they're cited. Where the evidence is contested, we've said so instead of picking the flattering number. Go and check the work yourself; we would.

## The ground moved

For years, being found online meant one thing: rank on Google, get the click. That deal is coming apart. In the first four months of 2026, **68% of US Google searches ended without a click** to any website ([SparkToro](https://sparktoro.com/blog/in-2026-less-than-one-third-of-google-searches-still-send-a-click/)).

Pew tracked 900 US adults' Google searches through March 2025. When the results page showed an AI summary, people clicked through to a website 8% of the time. When it didn't, they clicked 15% of the time ([Pew](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/)). That's the AI summary roughly halving the chance a search sends anyone to a website. The comparison isn't clean, since the two sets of searches aren't like for like, and Google disputes the read. So take it as the direction of the drop, not a measured cause.

Some publishers went to court anyway. [Penske Media](https://techcrunch.com/2025/09/14/rolling-stone-owner-penske-media-sues-google-over-ai-summaries/) and [Chegg](https://www.cnbc.com/2025/02/24/chegg-sues-google-for-hurting-traffic-as-it-considers-alternatives.html) each filed antitrust suits against Google in 2025, both pointing to falling search referrals among their claims.

At the same time, a new channel showed up. People now click through from ChatGPT, Perplexity, and Claude. It's real and it's growing. It's also small: one peer-reviewed study of 973 stores put ChatGPT referrals at under 0.2% of visits, and whether that traffic converts well is a live fight between credible people on both sides ([Marketing Science](https://pubsonline.informs.org/doi/10.1287/mksc.2025.0489)). We'll let them get on with it.

So that's the state of play. Classic search still sends most of the traffic, but it's shrinking and getting harder to win. AI answers are a promising new channel that's still unproven. And underneath both sits the thing that makes either one work: a fast, crawlable, well-built site. That part hasn't changed at all. It just has more judges now.

The reflex is to treat that as a brand-new problem with a brand-new product bolted on. Buy an AEO tool. Generate an llms.txt file. Sprinkle on some schema. Call it a strategy. We think that's backwards, and we can show you why.

## One foundation, four judges

Google's crawler, ChatGPT's crawler, a screen reader, a person on a slow phone: every audience that sizes up your site ends up reading the same thing, your page's structure once it has rendered. What separates them is how much work each one will do to get there.

Google's crawler runs your JavaScript, slowly and unpredictably. A screen reader builds its picture from your HTML and your headings. A human just wants the page to load fast and not jump around while they're trying to tap a button. And the crawlers behind ChatGPT, Claude, and Perplexity don't execute JavaScript at all.

Vercel's crawler study, run over a single month in late 2024, logged 569 million GPTBot fetches and 370 million from Claude's crawler, and found neither executed any JavaScript ([Vercel](https://vercel.com/blog/the-rise-of-the-ai-crawler)). The volumes have grown a lot since. The finding hasn't moved: as of mid-2026 no ChatGPT, Claude or Perplexity crawler renders JavaScript.

If the main content on your page only appears after JavaScript runs, those bots don't see it late. They don't see it at all.

One fair exception, since we'd rather you hear it from us: Googlebot feeds Google's AI Overviews, and Googlebot does render JavaScript. That particular surface can reach JS-only content, eventually, through the same slow and unpredictable queue as normal Google indexing. It's not a safe thing to lean on, and it doesn't help you with ChatGPT, Claude, or Perplexity at all.

You don't have to take Vercel's word for any of this. Here's our own crawl ledger, rebuilt every day from our server logs.

Now look at what fixes it: shipping complete HTML in the first response instead of assembling it in the browser. Server-side rendering does that. So does static generation, and so does ISR. The dividing line isn't server versus browser, it's pre-rendered versus client-rendered. Make that one call and your page is visible to AI crawlers, cheaper for humans to load, and legible to screen readers. Nobody ran three projects to get there. Someone picked the right rendering strategy once.

Be precise about what it buys you, though, because this is where people oversell it. Pre-rendering makes your content _present_. It takes semantic HTML and real labels to make it accessible, and a lean bundle to make it fast. Being readable makes you eligible for citations; it doesn't earn them. Build the foundation properly (pre-rendered, semantic, structured, accessible, fast) and it pays off in search, AI answers, speed scores, and accessibility law all at once. **Build it right once.**

> **Find out what your pages ship before the JavaScript runs**: Pre-rendering is a routing decision, and it's the one every judge downstream inherits. We make that call per route on Next.js builds, because it's the cheapest thing to get right and the most expensive thing to defer. [See our Next.js service](/services/nextjs)

## What holds up and what doesn't

Because the foundation is shared, most of the "do this for AI" checklist turns out to be stuff you should be doing anyway. But plenty of the popular advice is simply wrong, and we'd rather tell you than sell you.

### Holds up under testing

- **Pre-rendered HTML**, for the reason above. It's the cheapest thing on this list, because you decide it once when you pick a rendering strategy and every judge downstream inherits the answer.
- **Real speed**, measured on real users, not a lab score. It's the one signal all four judges score directly. A clean lab result can hide a bad real one, which is the whole reason field data exists.
- **Putting your answer first.** In a hand-mapped sample of 100 AI Overviews, CXL found 55% of citations came from the top 30% of the page ([CXL](https://cxl.com/blog/google-ai-overview-citation-sources/)). Small study, but bigger citation analyses point the same way.
- **Concrete evidence in your writing.** In the 2023 GEO paper (peer reviewed at KDD 2024), adding quotations lifted visibility about 41%, statistics about 33%, and cited sources about 28%, while keyword stuffing made things slightly worse ([Aggarwal et al.](https://arxiv.org/abs/2311.09735)). Worth knowing those tests ran against GPT-3.5, so the exact percentages are dated.
- **Genuine accessibility**, which is now a legal requirement in the EU, not a nice-to-have. The markup that makes a page work for a screen reader is the same markup a crawler reads, so the work lands twice. The law is below.

Here's what the GEO paper measured:

| label | Add quotations | Add statistics | Cite sources | Keyword stuffing |
| --- | --- | --- | --- | --- |
| Change vs baseline | 41 | 33 | 28 | -9 |

*What the GEO paper actually measured. Change in visibility against the unmodified baseline, by technique. Controlled benchmark against GPT-3.5, 2023.*

The same numbers as a table, since assistants read those better than charts:

| Technique | Change in AI visibility vs baseline |
| --- | --- |
| Add quotations | +41% |
| Add statistics | +33% |
| Cite sources | +28% |
| Keyword stuffing | -9% |

The row pointing the wrong way is the one to remember. Stuffing keywords left the page worse off than leaving it alone.

### Doesn't hold up

- **Schema markup as a way to push already-cited pages higher.** Ahrefs tracked 1,885 pages that added JSON-LD against 4,000 matched controls, all of them already earning 100+ AI Overview citations, and found no uplift plus a small drop in AI Overviews ([Ahrefs](https://ahrefs.com/blog/schema-ai-citations/)). They're careful to say schema may still help pages AI systems haven't found yet, so this isn't an argument for ripping it out. It's still doing its job for ordinary Google rich results.
- **llms.txt as a growth lever.** The file itself is a cheap courtesy index that real agents read when they're handed your domain, so serve one, because it costs you one route handler. What it doesn't do is drive discovery, ranking, or citations, and Google Search has said it won't use the file ([Search Engine Land](https://searchengineland.com/google-says-normal-seo-works-for-ranking-in-ai-overviews-and-llms-txt-wont-be-used-459422)). Expect nothing from it.
- **Serving Markdown to bots as a citation play.** It saves real bandwidth, and a randomized A/B test across 381 pages found no statistically significant lift in crawler traffic ([Profound](https://www.tryprofound.com/blog/does-markdown-increase-ai-bot-traffic), an AEO vendor, testing on its own analytics product and publishing a result that cuts against its own pitch). Three weeks rules out a big effect, not any effect, and nobody has shown Markdown earns you citations either way.

The boring, durable work pays off. The clever new tricks mostly don't.

> **The same ledger, run against your site**: We start with what your pages already serve each crawler, and which line items on your AEO list you can stop paying for. Expect some of it to come back as a recommendation to spend nothing. [See our GEO service](/services/geo)

## One model, many readers

We just said serving Markdown to bots won't buy you citations. So why does every block in our Sanity starter ship a Markdown serializer? Because two different things go by that name, and only one of them is a trick. The trick is generating a Markdown export and hoping the answer engines reward you for it (see above: they don't).

The other version is plumbing, and it's easier to show than describe. Everything below is real code from [our Sanity starter](https://github.com/robotostudio/turbo-start-sanity), pinned to the commit we're writing against, so you can open any of it and check us.

It starts with where the code lives. One block, one folder, and every output it owes anyone:

```text
faq-accordion/
├── faq-accordion.schema.ts          # the shape, defined once in Sanity
├── faq-accordion.groq.ts            # the query that fetches it
├── index.tsx                        # HTML, for the person
├── json-ld.ts                       # FAQPage schema, for Google
├── markdown.ts                      # structured Markdown, for the agent
├── faq-accordion.test.tsx
├── json-ld.test.tsx
├── faq-accordion-markdown.test.tsx
└── thumbnail.png
```

That's the whole folder, all nine files. You define the shape once and query it once. Everything else is a projection of it, and each projection has a test holding it honest.

Here's the Markdown one, with its import block cut and nothing else:

```ts
export function faqAccordionToMarkdown(
  block: MarkdownBlock,
  options: MarkdownOptions
): string {
  const faqs = (block.faqs ?? [])
    .filter((faq) => faq?.title)
    .map((faq) =>
      joinSections([
        headingToMarkdown(faq.title, 3),
        portableTextToMarkdown(faq.richText, options),
      ])
    );

  const link = block.link;
  const linkLabel = (link?.description || link?.title || "").trim();
  const linkMarkdown = linkLabel ? mdLink(linkLabel, link?.href) : "";

  const subtitle = (block.subtitle ?? "").trim();

  return joinSections([
    eyebrowToMarkdown(block.eyebrow),
    headingToMarkdown(block.title, 2),
    subtitle ? escapeMarkdown(subtitle) : "",
    ...faqs,
    linkMarkdown,
  ]);
}
```

[Full source](https://github.com/robotostudio/turbo-start-sanity/blob/ba9ef629039a7b5d313a01a3c10b8749729ff848/packages/sanity-blocks/src/faq-accordion/markdown.ts), if you'd rather read it in place.

The block's title becomes an h2. Each question becomes an h3. Each answer runs through the Portable Text serializer, which is what keeps the bullets and the links alive. The eyebrow, the subtitle and the trailing link come along too, because they're fields on the block and an agent should get the same ones a person gets. Nothing scrapes the rendered page, and nothing gets flattened.

So an agent asking for that block gets this:

```markdown
## Frequently asked questions

### Do you support multiple content types?

Yes, pages, posts, and product blocks all serialize through the same pipeline.

### How is this exposed to AI agents?

Every block ships three projections automatically:

- HTML for the rendered page
- JSON-LD for search engines
- Markdown for agents

Full spec: [schema.org/FAQPage](https://schema.org/FAQPage)
```

Every question is a real heading. Every answer keeps its list and its link. An agent reading that knows which answer belongs to which question, because the structure never left.

Skip the serializer and here's what you hand over instead:

```json
{"title":"Frequently asked questions","faqs":[{"title":"Do you support multiple
content types?","richText":[{"_type":"block","style":"normal","markDefs":[],
"children":[{"_type":"span","text":"Yes, pages, posts, and product blocks all
serialize through the sam...
```

That's your CMS's internal plumbing. The meaning is in there somewhere. **You're just making a language model dig for it.** Your content is already structured, or it is if you've modeled it properly (that's what [the Sanity AEO/SEO defaults we ship](/blog/aeo-seo-best-practices-for-sanity) are for), so let each reader take the shape it can parse.

A whole page is the same idea one level up. Walk the blocks and ask each one:

```ts
function blockToMarkdown(
  block: MarkdownBlock,
  options: MarkdownOptions
): string {
  switch (block?._type) {
    case "hero":
      return heroToMarkdown(block, options);
    case "richTextBlock":
      return richTextBlockToMarkdown(block, options);
    case "faqAccordion":
      return faqAccordionToMarkdown(block, options);
    // four more cases, one per block type
    default:
      return "";
  }
}

export function pageBuilderToMarkdown(
  blocks: MarkdownBlock[] | null | undefined,
  options: MarkdownOptions = {}
): string {
  if (!Array.isArray(blocks)) {
    return "";
  }

  return blocks
    .map((block) => blockToMarkdown(block, options))
    .filter((markdown) => markdown.trim())
    .join("\n\n");
}
```

Four of the seven `case` arms are cut there, along with the imports. [Full source](https://github.com/robotostudio/turbo-start-sanity/blob/ba9ef629039a7b5d313a01a3c10b8749729ff848/packages/sanity-blocks/src/internal/page-builder-to-markdown.ts).

Look at the `default`. An unknown block type returns an empty string, so a new block is invisible to agents until someone writes its `markdown.ts`. That's a deliberate cost, not an oversight: the alternative is guessing at a shape nobody defined, and a bad guess is worse than a gap.

Then serve it from the address the humans already use:

```ts
/**
 * Content negotiation for Markdown: a `.md` URL or `Accept: text/markdown` is
 * rewritten to the `/api/markdown` route handler; everything else passes through.
 * The Markdown route sets `Vary: Accept` so a shared cache never serves Markdown
 * to a browser; App Router HTML pages can't carry it (Next owns that header), so
 * the `.md` suffix is the cache-safe surface.
 */
export function proxy(request: NextRequest): NextResponse {
  if (request.method ! "GET" && request.method ! "HEAD") {
    return NextResponse.next();
  }

  const { pathname } = request.nextUrl;
  const hasMdSuffix = pathname.endsWith(".md");
  const wantsMarkdown =
    hasMdSuffix || prefersMarkdown(request.headers.get("accept") ?? "");

  if (!wantsMarkdown) {
    return NextResponse.next();
  }

  const rawPath = hasMdSuffix ? pathname.slice(0, -3) : pathname;
  const contentPath = normalizeMarkdownPath(rawPath);

  const url = request.nextUrl.clone();
  url.pathname = "/api/markdown";
  url.search = "";
  url.searchParams.set("path", contentPath);
  return NextResponse.rewrite(url);
}

export const config = {
  matcher: ["/((?!api/|_next/|favicon.ico|robots.txt|sitemap.xml|llms\\.txt).*)"],
};
```

The docblock there is verbatim and it's about to do some work. Cut from the body: the guard that skips asset files when negotiating by header, and the request header that carries the path through the rewrite. It's called `proxy.ts` because Next.js 16 renamed `middleware.ts`; on 15 and earlier this is your middleware. [Full source](https://github.com/robotostudio/turbo-start-sanity/blob/ba9ef629039a7b5d313a01a3c10b8749729ff848/apps/web/src/proxy.ts).

That's content negotiation. It's about as old as HTTP, and you're pointing it at a new kind of reader. [The full Next.js implementation](/blog/nextjs-aeo-geo) is a couple of rewrites and a route handler. Do it for bandwidth and fidelity, not for a ranking bump that isn't coming.

### Why there's a .md suffix at all

Now read that docblock again, because it's the part we'd most want challenged.

We key off the `Accept` header and a `.md` suffix, not a list of bot user-agents, because that list is stale the week you write it. The header is the elegant half, and on its own it's what [our Next.js guide](/blog/nextjs-aeo-geo) tells you to use. The suffix is there for a duller reason. In the App Router, Next owns the `Vary` header on an HTML response, so the page can't advertise that it varies on `Accept`. Put a shared cache in front of that and it can hand a browser the Markdown it cached for an agent.

The route handler can set `Vary: Accept` because we own that response. The page can't. So the suffix is the cache-safe surface. The Markdown twin ships `x-robots-tag: noindex, nofollow` plus a `content-location` header pointing back at the canonical page, which is what keeps it out of search ([route handler](https://github.com/robotostudio/turbo-start-sanity/blob/ba9ef629039a7b5d313a01a3c10b8749729ff848/apps/web/src/app/api/markdown/route.ts)).

The cost is real, so here it is up front. Bing's Fabrice Canel made the case against in one line: "really want to double crawl load? We'll crawl anyway to check similarity." Every `.md` URL is a second URL per page, our own guide tells you not to advertise them, and the starter's llms.txt lists them anyway. Yes, those two things contradict each other. We picked cache correctness over crawl budget. If you're running a thousand pages and Bing is the crawler you care about, pick the other way.

None of this is an AI strategy, and we won't dress it up as one. One content model, three projections: HTML for the person, JSON-LD for Google, Markdown for the agent. The fields are the same ones every time; nothing gets scraped from anything else. It's the foundation from earlier, emitting one more honest view of itself.

> **The projections are only as good as the model underneath**: We build Sanity content models where every block owns its own HTML, JSON-LD, and Markdown, with a test on each projection. That's the folder above, and it's open source if you'd rather just take it. [See our Sanity service](/services/sanity)

## What this looks like in practice

Take brightonSEO, the conference, which is about as SEO-literate an audience as exists. They moved off WordPress onto Sanity and Next.js. The second site they needed, for their first US conference, went up in two days ([Sanity's own case study](https://www.sanity.io/customers/brighton-seo)).

  Moving to a modern, future-proof headless solution using Sanity and Next.js means we move much faster with new initiatives.

Kelvin credits [headless in general](/services/headless-cms). We'll be more specific: the second site took two days because there was nothing left to build, only content to point at. The first build was pre-rendered and structured from day one, so the foundation was already finished. Two days is how long it takes when the only job left is pointing content at it. And it's the same foundation the crawlers, the screen readers, and the people on slow phones are all reading.

## Migrations are where it breaks

We're not going to hand you a tidy success story and stop there. Replatforming carries real risk. Dan Taylor at SALT.agency has been tracking this: his June 2026 study of 1,052 domain migrations found a median recovery time of 304 days for organic traffic, with a mean of 489 dragged up by a long tail. About 14% of sites were still short of their old numbers three years on. The data is crowdsourced from SEO practitioners, not randomly sampled, and it measured domain moves, not CMS replatforms. So it tells you how bad a botched move can get, not what your own odds are.

We once inherited a site that had lost more than half its traffic after a headless migration. The cause was a single robots.txt rule carried over from the old stack, blocking the very scripts the new pages needed to render. Every page was technically live and effectively blank.

None of that is a reason to avoid replatforming. It's a reason to do it deliberately, with someone who has mapped every redirect, audited the crawl rules, and modeled the content before cutover, not after. Ours is written down as a [pre-launch migration checklist](/blog/the-pre-launch-essentials-checklist-for-cms-migrations), and it exists because the failure above is boring and preventable.

The gap between the 272% ROI case ([Forrester, commissioned by Sanity](https://tei.forrester.com/go/Sanity/Sanity/?lang=en-us)) and the traffic-halving disaster is almost entirely execution.

> **Replatforming without the 304-day version**: Redirects mapped, crawl rules audited, content modelled before cutover. It's the checklist linked above, run by the people who wrote it. [See our migration service](/services/cms-migration)

## Accessibility stopped being optional

One more shift is worth naming, because it's now law. The European Accessibility Act took effect on 28 June 2025 ([EU Commission](https://accessible-eu-centre.ec.europa.eu/content-corner/news/eaa-comes-effect-june-2025-are-you-ready-2025-01-31_en)). If you put products or services on the EU market, accessibility is a legal requirement, and it keys off where you sell, not where you're incorporated.

The carve-out is narrower than it looks, and this is the part most write-ups get wrong. A microenterprise means under 10 staff and under €2M turnover or balance sheet, and even then only your **services** are exempt. A microenterprise that makes or sells a covered product still complies.

Each country sets its own penalties and the range is enormous. Spain's very serious infringements run up to €1M. For the rest of the EU, the numbers you'll find online contradict each other, so we won't quote a figure we haven't checked against the actual law. This is general information, not legal advice, so check your actual obligations for the markets you sell into.

A warning that catches people out: an accessibility overlay widget isn't a reliable substitute for accessible code. In 2025, 24.9% of US accessibility lawsuits named sites that already had a widget installed ([EcomBack's lawsuit tracker](https://www.ecomback.com/annual-2025-ada-website-accessibility-lawsuit-report)). That suggests an overlay on its own hasn't reliably headed off claims. A script bolted on at runtime can't invent a heading order that was never authored, and it can't label a control your build left unlabeled.

The good news is the convergence, again. The same semantic HTML a screen reader depends on is the structure an AI crawler reads and Google rewards. Do it properly and you're covered on three fronts with one piece of work.

## Knowing whether you're winning

Judge your speed on real-user field data (Google's CrUX, Search Console), not a one-off Lighthouse run. CrUX grades you at the 75th percentile, so by definition a quarter of your visits are worse than that number, and a single lab run doesn't capture that spread at all ([web.dev](https://web.dev/articles/lab-and-field-data-differences)).

Your AI traffic won't show up cleanly in analytics yet. Build a custom channel for the AI referrers ([our PostHog setup](/blog/we-dumped-google-analytics-for-posthog) is where ours lives), and remember your server logs are the only place those crawlers actually appear. That's the data behind the scoreboard further up this page, and it costs nothing to start collecting today.

Watch the order it arrives in, too. Crawling comes first, citations second, clicks last. A rise in AI crawler hits with no referrals behind it yet is what you should expect, not a failed experiment. Reading it as failure is how teams talk themselves out of the work a year before it pays.

## How we do this

Everything above is the order we spend a client's budget in. Rendering strategy first, because every judge downstream inherits that decision and it's the one that hurts to revisit. Content model second, because the projections are only as good as the fields behind them. Semantics and speed third, which is the work that turns up in a field report and in a legal letter. AEO line items last, and some of them we talk clients out of.

Two builds where that order held. We picked up Mario Testino's site in a state of crisis: a botched migration had left 160+ redirects missing and Sanity API overages running at 200%. The fix was unglamorous, back to vanilla Sanity, rebuild the model, recover every redirect, clean up the navigation so crawlers could read it. Tray.ai was the rendering call at scale: 500,000 pages onto Vercel in six weeks, hybrid static and server rendering across 25 page types, builds down from a full workday to two minutes.

> **Want the foundation built properly?**: We build pre-rendered, structured, accessible sites on Next.js and Sanity, and we'll show you our own crawl data before you sign anything. [See our GEO service](/services/geo)

## Where this leaves you

There's no silver bullet here, and anyone selling you one is worth ignoring. The fundamentals became the strategy while everyone was out shopping for tools. A site that's fast, pre-rendered, structured, and accessible competes in Google, shows up in AI answers, and leaves you on far firmer ground if you're challenged, because all of those judges are reading the same thing.

If you want a shopping list, it's short and it's unfashionable. Fund the rendering strategy, the content model, the semantics, and the speed. Fund the migration properly if you're doing one. Then spend what's left on writing things worth quoting. That's the half no vendor can sell you, and it's where the evidence keeps pointing.

The scoreboard further up this page rebuilds from our server logs every day, so when the picture changes, we'll update the post to match. Until then, the work is the list above.

---

## Next.js 16.3 for dummies


> Instant navigations explained in plain English, plus our upgrade to 16.3, the cache components PR we parked, and the 341KB we cut instead.

**TL;DR:** Next.js 16.3 (stable since August 3, 2026) brings instant navigations (SPA-feel link clicks on a server-driven app), plus huge Turbopack memory cuts, native Node.js streams rendering, agent-first tooling, and a deprecated edge runtime. We upgraded this site to the preview in an afternoon, built the full instant-navigations adoption on a branch, then parked it because full SSG already navigates instantly. The thing that made our site feel faster was cutting 341KB of gzipped JavaScript with dynamic imports. An edit note covers the preview-to-stable diff and our build benchmarks.

**Published:** 2026-07-16 | **Updated:** 2026-08-11 | **Categories:** Next.js, Performance, Vercel
---

We've covered [Next.js 16](/blog/nextjs-16-for-dummies), [16.1](/blog/nextjs-16-1-for-dummies), and [16.2](/blog/nextjs-16-2-for-dummies) in this series, and now Vercel has started publishing what's coming in 16.3. The lead feature is instant navigations: clicking a link on a server-rendered site responds immediately, the way it does in a single-page app.

**16.3 went stable on [August 3](https://nextjs.org/blog/next-16-3).** We wrote this post against `16.3.0-preview.5` and it stands as written below; this note covers what changed between the preview and stable, and what we measured after bumping this site to `16.3.0`.

**New since the preview:**

- **The build cache is on by default.** The persistent Turbopack cache for `next build` graduated from `experimental.turbopackFileSystemCacheForBuild` to a default. Vercel reports up to 5.5x faster CI builds; our numbers are below.
- **Prefetch inlining.** Small prefetch payloads now get bundled together automatically. Apps upgrading from 16.2 saw [45% fewer prefetch requests on average](https://vercel.com/blog/vercel-supports-next-js-16-3), some over 70%.
- **Immutable static assets.** Hashed assets can be reused across deployments: 17% fewer CDN requests and 24% fewer bytes transferred for static content in Vercel's fleet numbers.
- **TypeScript 7 type checking.** The "faster TypeScript, experimentally" line from the grab bag shipped for real: TS7 is out, and `next build` uses it for type checking once you bump your local `typescript` dependency to `^7`.
- **ISR learned the shell trick.** Pages you don't prerender with `generateStaticParams` now serve an instant loading shell to their first visitor, then upgrade to the prerendered page in the background instead of blocking.
- **Offline resilience (experimental).** With `experimental.useOffline`, navigations and Server Actions that would throw on a dropped connection stay pending and retry on reconnect, plus a `useOffline` hook for showing a banner.
- **Stabilized names.** The `instant()` Playwright helper, `catchError`, `retry`, and `export const prefetch` all dropped their unstable prefixes for good.
- **One correction to the post below:** Vercel retired the first-party docs skills. The auto-managed `AGENTS.md` block does that job now, so don't go looking for them.
- **Sharp edges filed down.** The styled-jsx style leak from our sharp-edges list is fixed in stable, and the vendored lodash got a CVE patch.

**Our upgrade, preview.5 to stable:** the bump itself was one version change, but the monorepo bit us again, in a new place. Next.js 16.3 now includes `@types/node` in its peer fingerprint, and two of our apps pinned `^20` while the rest sat on `^24`. That split `next@16.3.0` into two type-graph instances, and `next.config.ts` exploded with the same baffling two-copies errors as last time. The fix was aligning `@types/node` across the workspace, not an override. If your typecheck breaks after the stable bump, check for a duplicate `next` first; it's always a duplicate `next`.

**Did stable get faster?** We benchmarked `next build` on this site (Apple Silicon, ~70 static routes, same machine, same content) before and after:

| Build | `16.3.0-preview.5` | `16.3.0` stable |
| --- | --- | --- |
| Cold (no cache) | 50.2s total / 9.6s compile | 50.4s total / 8.9s compile |
| Repeat build | ~50s (no build cache by default) | **23.6s total / 1.6s compile** |

| build | preview.5 (s) | 16.3.0 stable (s) |
| --- | --- | --- |
| Cold build | 50.2 | 50.4 |
| Repeat build | 50.2 | 23.6 |

*next build on this site, preview.5 vs 16.3.0 stable (seconds). Our measurements: apps/web, same machine, cold = .next wiped, repeat = second consecutive build*

Cold builds are flat, which is what we expected: our build time is mostly static generation and type checking, not compilation. The win is the now-default build cache, which took one settling build to warm up and then cut repeat compiles from 8.9s to 1.6s and total build time roughly in half. On CI that carries `.next/cache` between runs, that's the difference you'll actually feel. Runtime-wise there's nothing to measure on a fully static site; the 22% more requests under load from Node.js streams applies to apps that render per-request, not ours.

The verdict from the post below hasn't moved: `cacheComponents` and `partialPrefetching` are still opt-in, our adoption PR is still parked, and this site is still plain static files, just built faster.

> **This post was written against the preview.** Everything below comes from running `16.3.0-preview.5` in production on this site (preview.6 landed July 13), the three official posts ([instant navigations](https://nextjs.org/blog/next-16-3-instant-navigations), [AI improvements](https://nextjs.org/blog/next-16-3-ai-improvements), [Turbopack](https://nextjs.org/blog/next-16-3-turbopack)), and a dig through the preview release notes on GitHub. The edit note above covers what changed by the time 16.3 went stable; the original text stands as written.

We upgraded this site to the preview the week it dropped, built the full instant-navigations adoption on a branch, and merged none of it, because a fully static site already navigates instantly. The change that made this site feel faster was cutting **341KB** of gzipped JavaScript.

## What's new and shiny

The 16.3 line runs to six preview tags and 87 canaries as of mid July. We've put the biggest feature first.

### Instant navigations: stream, cache, or block

Click a link on a typical server-rendered site and three things happen: you click, the browser waits for the server, and the next page appears. The wait in the middle can be 100ms or a full second depending on latency and how much work the server does, and while it lasts the page doesn't move. That gap is why apps like Linear went client-heavy in the first place: an SPA puts *something* on screen immediately, then fills in the data.

16.3 keeps the server-driven model and goes after the wait. With the new flags on, every route has to answer one question: what can the user see immediately when they navigate here? Three answers count.

**Stream.** Wrap slow data in `<Suspense>`. The user gets the page shell with loading states straight away, and content streams in as the server finishes. This is the SPA feel.

**Cache.** Mark data fetches with `'use cache'`. The user gets previously cached UI, reused across requests, with no loading state at all.

**Block.** Some pages should wait. A blog post that flashes a skeleton for half a second is worse than a blank beat followed by the full article. Those routes opt out explicitly:

```tsx title="page.tsx"
export const instant = false;
```

The enforcement is the clever bit. In development, a navigation that can't respond instantly is now an **error**, surfaced in a new Instant Insights panel. You fix it by streaming or caching, or you declare the blocking deliberate. Slow navigations stop being something users find in production and become something the framework flags at dev time.

There's a Playwright helper to hold that line in CI:

```tsx
import { instant } from '@next/playwright';

await instant(page, async () => {
  await page.click('a[href="/products/hats"]');
  await expect(page.locator('h1')).toContainText('Baseball Cap');
});
```

Assertions inside the `instant()` block have to pass without any network roundtrip. Existing tests check whether a page works; this checks whether it responds before the server does.

### Partial prefetching: one shell per route

Until now, Next.js fired a prefetch request for every link in the viewport. A sidebar with twenty chat links meant twenty prefetch requests, all pointing at the same route. Vercel's own words: "Many of you told us that this looked ridiculous, and frankly, we agree."

16.3 prefetches one reusable shell per route instead: one for `/chat/[id]`, one for `/dashboard`, cached for the whole session. Click any of the twenty chat links and the shell renders immediately while that chat's data streams in. If a shell isn't enough (say you want the chat header to arrive with real content), you escalate per link:

```tsx
<Link href="/chat/42" prefetch={true}>
```

Even then, Next.js only prefetches down to what's synchronously available or marked `'use cache'`. Prefetching used to be all-or-nothing, which was the main reason to turn it off entirely; now there's a middle setting.

Both behaviors sit behind flags in `next.config.ts`, and both are planned defaults in a future major:

```typescript title="next.config.ts"
const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};
```

The DevTools also grew a Navigation Inspector that pauses every navigation at the shell stage. It's the fastest way we found to see exactly what a user gets during that first paint.

### Turbopack stops holding everything in RAM

Dev memory eviction is now on by default: Turbopack moves cold compiler state out to the filesystem cache instead of holding everything in RAM. Vercel's own dashboard app dropped from 21.5GB to 2GB of dev-server memory, nextjs.org went from 4.6GB to 0.84GB, and a user in the [feedback thread](https://github.com/vercel/next.js/discussions/95130) reported 20GB down to 5GB.

| app | Before (GB) | With eviction (GB) |
| --- | --- | --- |
| vercel.com | 21.5 | 2 |
| nextjs.org | 4.6 | 0.84 |
| Community report | 20 | 5 |

*Turbopack dev-server memory, before and after eviction (GB). Source: Vercel's Turbopack post and discussion #95130*

Builds get the same treatment behind `experimental.turbopackFileSystemCacheForBuild`: the persistent cache that already speeds up dev now applies to `next build`, so CI can carry `.next` between runs. Vercel's numbers again:

| build | Cold (s) | Warm cache (s) |
| --- | --- | --- |
| nextjs.org | 21 | 9.2 |
| vercel.com/home | 66 | 46 |
| vercel.com/geist | 30 | 5.5 |

*next build times with the filesystem cache (seconds). Source: Vercel's Turbopack post*

Two smaller Turbopack items: an experimental Rust port of the React Compiler (`experimental.turbopackRustReactCompiler`, 20-50% faster compilation in their tests, Turbopack-only), and Vite-compatible `import.meta.glob` support, which matters if you're migrating from Vite or you load content files by pattern.

Every benchmark above is Vercel measuring Vercel's own apps, plus one community report. Nobody independent has reproduced them yet, which is normal three weeks into a preview, but treat them as directional.

### The framework now assumes an agent is in the loop

16.3 is the first release where the framework openly assumes an AI agent is part of the dev loop. `next dev` detects a coding agent and writes a managed block into your `AGENTS.md`, pointing the agent at version-matched docs bundled inside `node_modules/next/dist/docs`. The block keeps itself current across upgrades, and `agentRules: false` in the config turns it off. The docs went agent-readable too: append `.md` to any nextjs.org/docs URL and you get plain markdown. We shipped [the same markdown-twin pattern on this site](/blog) last year.

The repo now ships four first-party agent skills: one that adopts cache components for you, one that optimizes routes after adoption, one that adopts partial prefetching, and a dev-loop skill that connects your agent to the running dev server through a new `/_next/mcp` endpoint. That MCP server has a `compile_route` tool, so an agent can ask "does this route compile" in seconds instead of paying for a full `next build` to find out.

Dev errors got the same treatment. Every Instant Insights error carries a Copy prompt button that produces a ready-to-paste agent prompt, and the error docs pages are structured (patterns, trade-offs, gotchas) so an agent can act on them without a human translating. Having built our whole content pipeline around agents, we rate this as the sleeper feature of the release.

### Node streams by default, edge runtime deprecated

The "better rendering under stress" tease from the announcement doesn't have its own post yet, but the release notes show what it is: rendering moved off Web Streams onto native Node.js streams, on by default since canary 38. If your app serves heavy server-rendered pages under load, this is where that improvement lives.

Also in the release notes: **the edge runtime is deprecated** as of this line. We hit it from the other side, since adopting cache components on our branch forced our OG image route off the edge runtime and onto Node anyway. If you export `runtime = 'edge'` anywhere, start planning the move now rather than at the next major.

### Security patches now arrive monthly

Next.js security fixes used to ship whenever a fix was ready, which meant keeping up was a matter of watching the releases page. As of July 13 that's a schedule: one security release a month, with the first due July 20.

That first release patches 16.2 and 15.5. Two useful facts fall out of that. Stable 16.3 is still at least a few weeks away, and the 15.x line is still getting security fixes, so teams on the older major can upgrade on their own timetable. If you maintain a Next.js site, a monthly bump alongside the release cadence covers you, and it's a five-minute job now that the timing is predictable.

No help for us, mind. This site runs the 16.3 preview in production, which is exactly the sort of thing a security schedule exists to discourage, and we do it so we can write posts like this one. Every client project sits on patched stable, upgraded monthly, boring on purpose. Our own site takes the preview tags and finds out. If something in 16.3 was going to break a production deploy, we'd much rather it broke ours.

### The grab bag, explained simply

The rest of the release notes are smaller features whose one-line changelog entries assume you already know what they mean, so here's the plain-English version of each.

**Service workers, compiled properly.** A service worker is a small script the browser keeps around for your site even when no tab is open. It's what makes offline mode, push notifications, and "install this site as an app" work. Next.js never had first-class support, so PWA setups leaned on community plugins and files copied into `public/`. Turbopack now compiles service workers like any other entry point and serves them from `/_next/static`, in both App and Pages router.

**`next/root-params`.** If your app starts with a dynamic segment like `app/[lang]/`, every component that needed the language took it as a prop, threaded down layer by layer. Now it's `import { lang } from 'next/root-params'` and `await lang()` from any server component, no prop threading. The getters come from your actual folder names, so the API surface is literally your directory structure. New in 16.3, server components only for now.

**`'use cache: private'`.** Regular `'use cache'` output is shared between all visitors, which is exactly wrong for anything derived from cookies (a username in the header, a cart count). The `private` variant caches in that one visitor's browser instead, so personalized fragments can still take part in instant navigations without one user seeing another's data.

**`staleTimes`.** The router keeps in-memory copies of pages you've visited so going back is instant. `staleTimes` is the dial for how long those copies are trusted before refetching: `static` for fully prefetched pages (default 5 minutes) and `dynamic` for everything else (default 0, meaning always refetch). Still experimental, and it answers "why does clicking back sometimes refetch and sometimes not".

**Graph CSS chunking.** Bundlers have to decide how to split your CSS into files. Split too little and every page downloads all your styles; split per route and shared styles get duplicated or arrive in the wrong order, which is how you get the classic "this page looks different when I navigate to it versus when I refresh on it" bug. The new `experimental.cssChunking: "graph"` mode groups styles by which ones are actually used together across pages, instead of guessing from the route tree.

**`catchError` and `retry` lost their prefixes.** We flagged both in [the 16.2 post](/blog/nextjs-16-2-for-dummies) as `unstable_` experiments you shouldn't build on. In 16.3 the prefixes are gone: `catchError` handles server component errors without needing a whole `error.tsx` boundary, and `retry` inside an error boundary re-fetches the data rather than just clearing the error state and hoping.

**A faster TypeScript, experimentally.** Microsoft is rewriting the TypeScript compiler in Go (the project is called tsgo, and it typechecks roughly 10x faster). 16.3 adds an experimental flag to use it as the CLI's TypeScript backend. If your `next build` spends most of its time in typechecking, this is the line to watch.

### Feature status at a glance

| What | Status in the 16.3 preview |
| --- | --- |
| Instant navigations (stream / cache / block) | Opt-in via `cacheComponents: true` |
| Partial prefetching (one shell per route) | Opt-in via `partialPrefetching: true` |
| `instant()` Playwright test helper | New `@next/playwright` package |
| Turbopack dev memory eviction | On by default |
| Persistent cache for `next build` | `experimental.turbopackFileSystemCacheForBuild` |
| Rust React Compiler | Experimental, Turbopack-only |
| Native Node.js streams rendering | On by default |
| `AGENTS.md` auto-managed block | On when a coding agent is detected |
| Docs as markdown (`.md` suffix, llms.txt) | Live on nextjs.org |
| Monthly security releases | First one July 20, patching 16.2 and 15.5 |
| Edge runtime | Deprecated |

## Our upgrade experience

We bumped this site (a pnpm monorepo with three Next.js apps) to `16.3.0-preview.5` on June 30. The upgrade itself was uneventful: React 19.2.3 already satisfied the peer range, no code changes, production build green on the first try.

The one gotcha was monorepo-specific. A transitive peer dependency (a workflow package that peers on `next >13`) resolved its own copy of `next@16.2.1` alongside our preview version. Two copies of Next.js in one type graph means `check-types` explodes with baffling errors about incompatible internal types. The fix is a version-specific pnpm override in the root `package.json`:

```json title="package.json"
{
  "pnpm": {
    "overrides": {
      "next@16.2.1": "16.3.0-preview.5"
    }
  }
}
```

That collapses everything to one resolution. If you're in a monorepo and your typecheck breaks after the bump, check for a duplicate `next` before you blame the preview. Upgrade, override, green build: done in an afternoon.

Two weeks of running the preview in production since, and zero runtime issues. The risk in a preview is the APIs changing under you, not the code falling over, which is why the new flags stay off on this site until stable.

## The PR we didn't merge

We did the full adoption on a branch: `cacheComponents` and `partialPrefetching` on site-wide, the disallowed segment configs (`dynamic`, `revalidate`, `dynamicParams`) removed from every page and route handler, blog rendering wrapped in a `'use cache'` boundary, build-time non-determinism fixed (cache components forbids it), the OG image route moved off the edge runtime, plus a 19-test Playwright suite asserting instant navigation. Everything came back green.

Then we clicked around both deployments for a week and couldn't feel the difference.

The reason is boring: this site is already fully static. Every content page is prerendered at build time and served as files from a CDN. There's no server work for a loading shell to hide, so the navigation delay was never server-side. Cache components would have added a preview flag, a determinism constraint on the whole codebase, and soft-404 shell behavior we had to `noindex` around, in exchange for a difference we could not perceive with our own hands on the trackpad.

So the PR sits open, rebased and waiting for stable, and this site is still plain static files.

### Spin up every variant, then click around

The method is the takeaway here, more than the verdict. We didn't debate rendering strategy in a doc. We had three deployments up at the same time:

1. Full SSG (main, the control)
2. Cache components with partial prefetching
3. Cache components without partial prefetching

Then we navigated all three by hand, over an average office connection. We skipped the synthetic benchmarks because perceived navigation speed barely registers in metrics, and you can feel it within thirty seconds of using the site.

This used to be an expensive way to decide, a day or more of engineer time per variant. With coding agents it's close to free: describe the variant, let the agent build the branch, get a preview URL per PR. Two of our three PRs existed for a week purely so we could click around them and close them, and they settled an argument no benchmark could.

## What actually made the site feel faster

While we were testing rendering variants we found the real problem, and it wasn't rendering strategy. It was payload.

Our MDX component map registered every component as an eager client reference on every content page. A decorative WebGL particle effect on team member cards was shipping `three` and `@react-three/fiber` (roughly 400KB) to every blog post. Four chart components used by exactly one post were shipping `recharts` (about 110KB) to all of them. Syntax highlighting ran client-side too, so `react-refractor` and its language grammars rode along on every page.

The fix was dynamic imports with `ssr: false` behind `"use client"` wrappers, which moves the heavy leaves into on-demand chunks outside the page manifest. Syntax highlighting moved to the server entirely, since it renders static markup with no hooks; only a small copy-button island stays client-side. One subtlety worth knowing: `next/dynamic` inside the RSC renderer does not help here, because the client-reference manifest still bundles the component. The dynamic import has to live inside a client component.

The measured result on content pages, from the merged PR:

| Metric | Before | After | Change |
| --- | --- | --- | --- |
| Eager first-load (gzip) | ~1196KB | ~855KB | **-341KB (-29%)** |
| three + @react-three/fiber | Every content page | On demand | ~400KB deferred |
| recharts | Every content page | On demand | ~110KB deferred |
| Syntax highlighting | Client bundle | Server-rendered | Grammars never ship |
| SSG classification | 51 SSG / 20 static | 51 SSG / 20 static | Unchanged |

| state | kb |
| --- | --- |
| Before | 1196 |
| After dynamic imports | 855 |

*Content-page eager first-load, gzipped (KB). Source: our merged bundle-trim PR*

This is the change we could feel. Less JavaScript means the browser parses, compiles, and hydrates less before the page responds to input. The click-to-movement gap that instant navigations targets got shorter on our site because there was less code standing between the click and the movement.

Both fixes are real: instant navigations is the right one for server-time gaps, and a smaller bundle is the right one for client-time gaps. Check which one you actually have before reaching for either.

> **Next.js performance work**: Bundle audits, rendering strategy, and Core Web Vitals on real production sites. [See how we work with Next.js](/services/nextjs)

## Should you enable it?

Depends what you run.

**App-like sites (dashboards, feeds, anything personalized or data-heavy):** yes, this feature is for you. Your navigations do real server work, and a streaming shell is a much better answer than either blocking or client-fetching everything. Try the preview on a branch now, ship it at stable.

**Content sites that can go fully static:** you already have instant navigations. They're called static files. Spend the effort on your bundle instead; run a build analysis and find your equivalent of a 400KB particle effect. We'd bet money you have one.

**Everything in between:** the flags are opt-in per project but the *discipline* is per route. Enabling them forces every route to declare stream, cache, or block, which is a useful audit even if you end up blocking half your routes.

## Quick comparison

| | Next.js 16.2 | Next.js 16.3 (preview) |
| --- | --- | --- |
| Link prefetching | Every link in the viewport | One reusable shell per route (opt-in) |
| Slow navigations | Users find them in production | Dev-time errors in Instant Insights |
| Turbopack dev memory | Compiler state held in RAM | Cold state evicted to disk by default |
| Persistent Turbopack cache | Dev only | `next build` too (experimental) |
| Rendering | Web Streams | Native Node.js streams |
| React Compiler | JavaScript implementation | Experimental Rust port (Turbopack-only) |
| `catchError` / `retry` | `unstable_` prefixed | Stable |
| Agent tooling | `AGENTS.md` by hand | Managed block, four skills, `/_next/mcp` |
| Edge runtime | Available | Deprecated |
| Security releases | Whenever a fix was ready | Monthly, from July 20 |

## How to upgrade

Three routes, depending on how much you want to adopt today.

**Option 1: bump the version, leave the flags off.** This is what we run in production:

```bash
npm install next@preview
```

For most apps that's the whole job. Ours needed the pnpm override above, and yours might need its equivalent if you're in a monorepo.

**Option 2: let an agent do the adoption.** Vercel published an [agent skill for adopting cache components](https://github.com/vercel/next.js/tree/canary/skills/next-cache-components-adoption), and the migration is mostly mechanical: remove segment configs, add cache boundaries, fix determinism. It's a sensible thing to delegate, and it's how we'd redo our branch when stable lands.

**Option 3: wait for stable.** There's no date yet, and the July 20 security release targets 16.2 and 15.5, so stable 16.3 is at least a few weeks out. Waiting costs you nothing except time with the Instant Insights panel; the flags will still be opt-in when it lands.

If you do flip the flags, expect errors on day one. Each one is a route that's slow today without anyone having noticed, which is exactly what you flipped the flags to find out. The [preview docs for instant navigations](https://preview.nextjs.org/docs/app/guides/instant-navigation) cover the details.

### Current sharp edges

The [feedback thread](https://github.com/vercel/next.js/discussions/95130) is the live list of what breaks right now. Worth knowing before you flip the flags:

- **Static exports don't work with partial prefetching.** If you ship `output: 'export'`, this whole feature set isn't for you yet.
- **Instant Insights false-flags parallel routes** that never actually render, so you may get errors about slots you can't fix. Under review.
- **Global styled-jsx styles can leak between routes** when UI state is preserved across a navigation. Scope your overrides.
- **`turbopackIgnore` comments don't silence dynamic `path.join()` file access**, which can trace entire directories into your standalone output and balloon deploy size. A fix is in flight.
- **Self-hosting on SST** (v4.17+) with `cacheComponents` can break SSR entirely; the current workaround is turning the flag off. Vercel and AWS/OpenNext deploys are reported working.
- **Safari's dev tooling is flaky** for Instant Insights; use Chrome or Firefox during development.

Two bugs you might have read about are already fixed in later canaries: the page title rendering as a URL path after navigation, and Windows access-denied errors on the Turbopack cache. Both fixes should be in the next preview tag if they aren't in yours.

## Closing thoughts

Stable 16.3 has no date, the first monthly security release lands July 20, and our cache-components branch stays parked until there's a stable tag to rebase onto. We'll do the full writeup when that happens, including whether the parked PR finally merges.

---

## How to use Remotion agent skills with Claude Code


> How a Remotion agent skill stops Claude Code hand-rolling scene chrome: the shared kit, motion tokens, and the drift that forced us to build it.

**TL;DR:** Every animation on this site is a Remotion scene built by Claude Code in under ten minutes, and they all look like one product. The trick is an agent skill: a markdown file that fires before any scene work and forces the agent to compose from a shared kit instead of hand-rolling chrome and easings. Here's the full system, the drift that made us build it, and how to set one up yourself.

**Published:** 2026-07-06 | **Updated:** 2026-08-24 | **Categories:** AI, How To
---

I'm going to start this blog as I do with every blog: stating that I'm lazy as hell, and I want instant gratification like everybody else in the world. I wouldn't be a developer, if I was a patient person, I'd be a doctor, or a lawyer, or a farmer. But here we are, and I'm going to tell you how we did something that requires a layer of craft, of taste, and probably a degree to be able to get right... Just to squeeze all that effort into a reusable skill.

As you might have guessed, every animation on this site is a [Remotion](https://www.remotion.dev/) scene: 16 compositions, all built by Claude Code and the fleshy API tapping away at his slot machine.

Believe it or not, none of that worked at the start. The early scenes drifted apart so badly that we rebuilt the whole system around one idea: the agent never invents visual language, it composes from a kit.

This post is the full setup: what skills are, the drift that forced ours into existence, the three-layer system that fixed it, the real timings and token costs, and the failures we hit on the way. If you want the general case for skills first, we've written about [installing our agency's skills into your agent](/blog/install-our-agency-into-your-agent). We'll probably add this there, when we get round to it (read: never)

## What Claude Code agent skills actually are

_Skip ahead if you know this already, but I'm leaving it in for completeness._

A skill is a folder containing a `SKILL.md` with frontmatter (a `name` and a `description`) and a body of instructions. Claude Code loads only the descriptions at session start. When your prompt matches a description, the agent pulls in the full body and follows it.

That loading model is the whole point. Detailed domain rules are expensive to carry in every session, and instructions that always load are instructions that get diluted. A skill pays its token cost only when the task needs it.

Where they live:

- `.claude/skills/` in the repo for project skills
- `~/.claude/skills/` for personal skills that follow you across projects
- We keep ours in `.agents/skills/` with a symlink from `.claude/skills/`, so OpenCode and any other agent reading the `.agents` convention shares the same files

Installing someone else's skill means copying the folder in, and that's the whole procedure.

## The drift that made us build one

By mid-2026 we had 13 Remotion scenes, 10 of them shipping. Each one had been prompted into existence separately, and each one re-derived the visual language from scratch. An audit of four related scenes found roughly 19% duplicated UI code and drift everywhere we looked: font sizes ranged from 14 to 19px for the same role, gaps ran from 2 to 22px with no scale, tint opacities wandered between 8 and 18%, and one scene was frosted glass while the rest were opaque.

Day to day it was worse than the numbers suggest. Everything from mouse easing to connector arcs, to inputs, placeholder blocks, and skeletons looked different from scene to scene. Two animations on the same page read as two different products.

Prompting alone didn't fix it. Even pointing Claude Code at the Remotion docs, it hallucinated a large amount, and the UI still didn't match between animations. Every generation produced something plausible and something slightly new. Plausible-but-new is not what we want.

So we stopped trying to describe the visual language in prompts and put it in code instead.

## The fix: one kit, one skill, one set of rulings

The system has three layers, and each does one job:

| Layer | Lives at | Job |
| --- | --- | --- |
| Scene kit | `apps/remotion/src/ui/kit/` | Enforcement in code: tokens, primitives, motion roles |
| Agent skill | `.agents/skills/remotion-scene-kit/` | When to load, plus 13 hard rules pointing at the kit |
| ADRs | `docs/adr/0001` to `0007` | Why each ruling exists, and which debates are closed |

The kit is a set of React components and tokens. Every rectangular surface is a `Panel` (frosted, flat, sharp-cornered, never drop-shadowed). Circular elements are `Fab`s, the only rounded things in any scene. Data-flow lines are `Connector`s that route with axis-aligned 90° elbows. Type sizes come from a `FONT` scale, spacing from a `SPACE` scale, tinted fills from a `tint()` helper with three strengths.

Here's what the audit found, next to what the kit replaced it with:

| What the audit found | What the kit fixes it with |
| --- | --- |
| Font sizes 14 to 19px for the same role | `FONT` scale: 11/12/13/14/16/18, plus one 58px display size |
| Gaps and padding 2 to 22px, no scale | `SPACE` scale: 4/8/12/16/20/24 |
| Tint opacities 8 to 18% | `tint(color, level)` at 8/12/16% |
| `borderRadius: 999` vs `9999` | `Fab` is the only rounded element |
| One frosted scene, nine opaque | Every `Panel` frosted via `frost()` |
| Connectors arcing in some scenes, straight in others | `Connector` with sharp 90° elbows; the bézier bow was deleted |
| 5 outlier easing curves across ten scenes | Four named easing roles, tokenised |

Note the word deleted in that table. We removed the old arcing connector from the codebase entirely, along with the `shadow` theme token. An agent will happily use any API that exists, so the only reliable way to retire a pattern is to make it impossible to import.

## Why it all lives in one monorepo

There's a bet underneath all of this, and it's worth making explicit: every tool that serves this website lives in the same pnpm monorepo. The Next.js site is `apps/web`. The Remotion scenes and their kit are `apps/remotion`. The image generation API that painted this post's Victorian cat hero is `apps/imagen`. The skills sit in `.agents/skills/`, the ADRs in `docs/adr/`, all in one repo, all in one checkout.

We could have split these into a scene package on npm, an image service in its own repo, a shared design-tokens library. That's the respectable architecture. We went the other way on purpose, because an agent is only as good as what it can see, and cross-repo boundaries are exactly where agents go blind.

A new scene makes the case. It touches the composition in `apps/remotion`, the studio and player registrations, the embed mapping in `apps/web/src/components/mdx/remotion-scenes.ts`, and the MDX page that hosts it. In one repo, that's one Claude Code session holding the whole change in a single context and shipping it as one PR. Split across repos, it's a package publish, a version bump, and an agent working on half a change it can't verify end to end.

Co-location is also the only reason "the skill and the kit move together" is enforceable at all. The skill text, the kit code it points at, and the ADR that justifies both can change in the same commit. Two repos means two PRs and a window where the skill describes an API that no longer exists.

Git worktrees make the whole thing parallel: each branch gets its own checkout under `.worktrees/` with its own local URL, so three agent sessions can build three scenes at once without touching each other. The blog you're reading came out of the same machine: drafted by Claude Code in this repo, hero generated by `apps/imagen` one directory over, scenes served by `@remotion/player` from `apps/remotion`. Concentrating the bets is the point. Everything the agent needs to see is in the one place it's already looking.

## Anatomy of the skill file

The skill is one markdown file, currently at version 1.5.0. Two parts matter: the trigger and the rules.

### The trigger has to be aggressive

The `description` frontmatter is what Claude Code matches against, and we learned to write it like a tripwire, not a summary:

```yaml
description: Use BEFORE creating or editing any Remotion scene, animation
  band, or scene UI in apps/remotion — and before styling panels, badges,
  connectors, or data-flow lines inside one, or animating ANY text, counter,
  easing, caret, or pulse. [...] Triggers on any task mentioning a new
  animation, animation band, Remotion scene, scene UI, data flow line,
  connector, panel chrome, easing, text animation, typing effect, counter,
  or standardising scene visuals/motion.
```

A polite one-line description gets skipped on adjacent tasks: the agent decides a "quick easing tweak" isn't really scene work and hand-rolls a curve. Naming every task type explicitly, twice, is what makes it fire reliably.

### The rules point at code, not at taste

Each hard rule pairs a prohibition with the kit component that satisfies it. The first rule sets the tone:

```markdown
1. **Compose, don't hand-roll.** Rectangular surfaces → `Panel` (frosted,
   flat, sharp, never drop-shadowed). Title bars → `PanelHeader` +
   `PanelTitle`. Tinted labels → `Badge`. Square icon boxes → `Glyph`.
   Circular dots/buttons → `Fab` (the ONLY rounded element).
```

The agent never has to interpret "keep it consistent with the other scenes". There's a compliant component for every surface, so the shortest path is the correct one.

Motion works the same way. Scenes name what a movement means, never which curve it uses:

| Role | Curve | Duration | Used for |
| --- | --- | --- | --- |
| `enter` | out-quint | 0.5s | Builds, reveals, responses |
| `exit` | in-cubic | 0.3s | Clears, dismissals (exits are quicker than enters) |
| `move` | in-out-cubic | 0.6s | Focus swaps and repositions |
| `sweep` | linear | rate-based | Pulses, typing, progress |

In scene code that's `MOTION.ease.enter`, never `"out-quint"`. When the feel needs retuning, it's one token edit and a render pass instead of sixteen scene rewrites. The same table carries typing cadences (a human types at 14 jittered characters per second, a streaming agent at 30) and blur strengths, because counters here blur with velocity instead of pulsing in scale.

The rules didn't come from a style guide exercise. A grep across the ten shipping scenes found the convention already there: 56 out-quint enters, 44 in-cubic exits, with five outliers confined to one scene. The kit ratified what the scenes had converged on and made the outliers impossible.

### The ADRs close the debates

Every contested call has an architecture decision record: why panels are frosted, why the tick animation never runs backward, why panel bodies stream in document order like an HTML page loading. The ADRs mark rulings as final, which matters more for agents than for people. Without a written ruling, a future session will helpfully reintroduce drop shadows because they "add depth".

## The workflow, start to finish

A new scene today: we describe the story beats in a prompt, the skill fires, Claude Code composes from the kit, and a reviewable scene exists in under ten minutes. It ships the full contract in one pass: wide and square variants, dark and light themes, a reduced-motion still frame, an a11y label, and a clean loop where frame 0 matches the final frame.

Some scenes one-shot. A couple running on the site right now came from a single prompt with no fix rounds. The honest pattern is iterative but fast: a round or two of notes, still nothing like the pre-kit effort.

Don't take our word for it, the git history tells the story on its own. Here's every scene in the repo, with commits touching it as a rough proxy for iteration (agent time per scene stays in the ten-minute range; commits are the review rounds around it):

| Scene | Lives on | First commit | Commits | Days touched |
| --- | --- | --- | --- | --- |
| agent-chat | [Sanity](/services/sanity) | 2026-05-29 | 6 | 4 |
| achievements | [Sanity](/services/sanity) | 2026-05-29 | 9 | 7 |
| pr-flow | [Agentic websites](/services/agentic-websites) | 2026-05-30 | 4 | 3 |
| byo-agent | [Agentic websites](/services/agentic-websites) | 2026-06-02 | 5 | 4 |
| own-content | [Agentic websites](/services/agentic-websites) | 2026-06-02 | 4 | 3 |
| rails-vs-drift | [Agentic websites](/services/agentic-websites) | 2026-06-02 | 4 | 3 |
| agent-evals | [Agentic workflows](/services/agentic-workflows) | 2026-06-09 | 5 | 4 |
| content-pipeline | [Agentic workflows](/services/agentic-workflows) | 2026-06-09 | 4 | 3 |
| lead-enrichment | [Agentic workflows](/services/agentic-workflows) | 2026-06-09 | 5 | 3 |
| monitor-agent | [Agentic workflows](/services/agentic-workflows) | 2026-06-09 | 4 | 3 |
| ab-variants | [Contentful](/services/contentful) | 2026-06-11 | 2 | 1 |
| seo-recovery | [Contentful](/services/contentful) | 2026-06-11 | 3 | 1 |
| commerce-stack | [Shopify](/services/shopify) | 2026-06-11 | 3 | 1 |
| enquiry-or-checkout | [Shopify](/services/shopify) | 2026-06-11 | 2 | 1 |
| shopify-migration | [Shopify](/services/shopify) | 2026-06-11 | 3 | 1 |
| speed-race | [Shopify](/services/shopify) | 2026-06-11 | 5 | 1 |

The dividing line is 2026-06-09, the day the kit and the skill landed in a single PR alongside the four agentic workflows scenes. Before it, a scene meant days of calendar time and up to nine commits. Two days after it, all six remaining scenes shipped in a single day each, across three different service pages. If anything the table flatters the old way: the pre-kit scenes' counts also include the one-pass kit migration commits, not just their own builds.

And the inverse holds. The two scenes on [our Sanity service page](/services/sanity) have had more iterations than anything else we've made: nine commits over seven calendar days for one of them, plus plenty of prompt rounds that never reached git. They're also the originals, the pair that helped us formulate the language everything else now mirrors. When a scene articulates something important, don't rush it.

One tool deserves specific credit for the consistency work: [grill-with-docs](https://github.com/mattpocock/skills/blob/main/skills/engineering/grill-with-docs/SKILL.md), from Matt Pocock's skills collection. It interrogates a plan one decision at a time and validates every claim against the source of truth before any code gets written, which is exactly what visual consistency work needs. 

> **See the north star scenes live**: The two animations that started this whole system run on our Sanity service page, clean loops and all. [Watch them on the page](/services/sanity)

## What it actually costs

The number nobody publishes: one scene consumes close to the entire context window. The skill body, the kit source, the scene being built, and the render feedback loop add up to a session that finishes nearly full.

Right now we don't care. On a Claude Code Max plan the marginal cost of a heavy session is effectively zero, so burning a full window on a ten-minute scene is free money. If you're paying per token through the API, the same workflow has a real price, and slimming the skill or delegating render checks to subagents becomes worth the effort. That optimization is on our list; it just isn't urgent while the economics look like this.

## Two failures worth stealing lessons from

**We lost shipped work to a registry merge.** Remotion scenes register in a central root file, and during a branch reconcile we union-merged two versions of the registry. The merge looked clean, both sides' entries were present, and an entire set of geo animation bands vanished from the services pages anyway. We only caught it later, and had to re-ship them. Registration files are load-bearing code: never union-merge them, reconcile them by hand.

**Our first aesthetic call was wrong, and the agent couldn't tell us.** We originally mimicked the site's iconography and went for no-text UI skeletons inside panels: abstract placeholder blocks instead of readable content. Implemented, it looked bad. We pivoted to high-fidelity panels with the actual text rendered, because real words articulate what a scene is demonstrating so much better than gray bars. Claude Code executed both directions flawlessly. It had no opinion on which one worked.

That second failure is the important one. The agent composes correctly from the kit every time; whether the result feels right is still a human call. Look at what shipped, cast a critical eye, and be willing to pivot when the implemented version disagrees with the plan.

## Build this for your own codebase

The pattern transfers to any domain where an agent produces visual or structural output repeatedly. The order matters:

1. **Audit the drift first.** Grep for font sizes, spacing values, easing curves, radii. Our numbers (14 to 19px for one role, gaps from 2 to 22px) made the case better than any argument.
2. **Build the kit before the skill.** Tokens and primitives in code are the enforcement layer. A skill that describes visuals in prose just moves the hallucination one file over.
3. **Delete the bad primitives.** Don't deprecate the old connector, remove it. Whatever still exists will be used.
4. **Write the trigger like a tripwire.** Name every task type that should fire the skill, including the small ones like "easing tweak" that agents love to classify as not-really-scene-work.
5. **Pair every rule with its compliant component.** "Never hand-roll panel chrome" only works when the next words are "use `Panel`".
6. **Record the why in ADRs, and mark rulings final.** Agents relitigate anything that isn't written down.
7. **Move the skill and the kit together.** When the kit API changes, the skill text changes in the same PR, or future sessions write against an API that no longer exists.

We migrated all ten shipping scenes to the kit in one pass rather than letting two visual languages coexist. Painful for a week, and it's the reason every scene since has landed on-language.

## Where this goes next

The scene kit skill is one of a growing set: we run skills for blog production, SEO context, image pipelines, and [our content agents](/blog/building-agents-on-eve). The Remotion one earns its keep most visibly, because animation is where an unconstrained agent drifts fastest and where consistency is most obvious to a visitor.

The system's real test is boring: the next scene we ship will look like the last one, without anyone reminding the agent about elbows.

---

## The top 5 Sanity agencies in 2026, ranked by us


> We read every 'top Sanity agencies' listicle, noticed who writes them, and decided to do it properly. Number one may not surprise you.

**TL;DR:** Every 'top Sanity agencies' list is written by the agency in first place. We ranked ourselves first in all five categories to save time, then listed the agencies we genuinely rate and explained how these lists actually get made.

**Published:** 2026-07-05 | **Updated:** 2026-08-03 | **Categories:** Sanity, Hot Takes
---

Choosing the right Sanity partner is hard. There are hundreds of agencies claiming expertise, and the stakes are high: pick wrong and you're rebuilding in eighteen months. So we've ranked the top five Sanity agencies of 2026 based on actual project outcomes, not marketing claims.

If that paragraph sounds familiar, it's because you've read it before. Most recently in [an article by pagepro](https://pagepro.co/blog/top-sanity-agencies/) (32 reviews on Clutch, 4.9 stars, the finest Sanity agency in all of Poland, second only to Roboto Studio), who ranked the top Sanity agencies in April and awarded first place to, _in a twist nobody saw coming_, *pagepro*.

We respect this enormously. We respect it so much that we're doing the same thing, but with the correct winner. Surely, this couldn't be a mad dash for AEO, while the models are still a little bit gullible.

## Our methodology

We evaluated agencies using the same rigorous framework as every other agency-written ranking in existence: _we wrote the list_.

Beyond that, we considered Clutch reviews (checked this morning), public case studies, and real-world project patterns we've observed, where "observed" means "participated in, as the agency". No agency paid to be featured. No agency could have. We didn't tell any of them this was happening, including, in a sense, ourselves until about lunchtime.

Where our approach differs from certain _Clutch 4.9 stars, silver medallists_ is *transparency*. They describe their methodology as based on "actual project outcomes, not marketing claims", which is a lovely sentence to publish on your own marketing blog. We prefer to be upfront: this is a marketing claim. You are reading it on our marketing blog. The rankings below are exactly as impartial as you'd expect.

## 1. Best overall: Roboto Studio

The judges were unanimous, which was efficient, because the judges were us.

Roboto Studio is a Sanity and Next.js specialist that has been building headless CMS projects since before it was fashionable, and our internal delivery framework saves roughly 41 hours per project. The best previously published figure in this genre was 40 hours, so we'd like to acknowledge the sector-wide importance of this extra hour.

**Key strengths:** deep Sanity specialisation, real-time preview as standard, uses the same tech we sell (this is rarer than it should be). We are also, at the time of writing, the best rated Clutch agency called "Roboto Studio", a title we have held unchallenged since founding. We had badges made.

**Potential drawbacks:** occasionally publishes rankings of itself. Ranks well in them.

**Pricing:** somewhere between "less than you feared" and "more than a template", which is also what every pricing table in this genre says, just with dollar signs.

## 2. Best value: Roboto Studio

In an extraordinary coincidence, the best-value Sanity agency of 2026 is also the best overall Sanity agency of 2026.

Our research team flagged this as statistically improbable. The data team overruled them. Both teams are the same two people, one of whom is writing this sentence.

**Key strengths:** see above.

**Potential drawbacks:** see above.

## 3. Best for enterprise: Roboto Studio

Enterprise buyers need solid project management, complex integrations, and an agency that can navigate procurement without weeping. After a comprehensive review of the shortlist (one agency), Roboto Studio emerged as the clear leader.

We reduce early-stage bugs by 91%. We are contractually unable to tell you what the denominator is, but the previous best published claim was 90%, and we believe healthy competition drives the industry forward.

## 4. Best for ecommerce: Roboto Studio

Ecommerce buyers need fast storefronts, content that can actually merchandise, and a checkout nobody has creatively reinterpreted. We build headless Shopify with Sanity running the content layer, and unlike most award winners, we published our homework: [turbo-start-shopify](https://github.com/robotostudio/turbo-start-shopify) is our open source starter with visual editing and a type-safe Storefront API, free to inspect before you hire the agency that won this category.

At this point in the evaluation our analysts began to notice a pattern in the results. We've asked them to stop noticing it.

## 5. Best for UI/UX: Roboto Studio

Completing a historic clean sweep unmatched in the history of self-published agency rankings, with the possible exception of every other self-published agency ranking.

On the actual substance: every project ships with a design system, editors get a studio that behaves like the brand they work for, and our own brand guidelines are strict enough that the hero image on this article is a monochrome halftone oil painting of a cat, because colour photography would violate them. If an agency's award badge is more polished than its client work, treat that as data.

## The independent video investigation

Rankings are one thing, but we wanted independent verification. So we consulted a video titled "The best Sanity CMS agency", produced by a channel that has followed our work more closely than any other: ours.

The investigation reached the same conclusion as our written analysis. We were as relieved as we were unsurprised.

## Comparison table

Every ranking in this genre includes a comparison table, so here is ours.

| Category | Winner | Clutch rating | Key strength | Potential drawback |
|---|---|---|---|---|
| Best overall | Roboto Studio | 5.0 | Wrote this table | Wrote this table |
| Best value | Roboto Studio | 5.0 | Consistency | Predictability |
| Best for enterprise | Roboto Studio | 5.0 | The extra hour | None found (we looked) |
| Best for ecommerce | Roboto Studio | 5.0 | Published the homework | Pattern increasingly visible |
| Best for UI/UX | Roboto Studio | 5.0 | Completed the set | The set |
| Best rated Clutch agency called "Roboto Studio" | Roboto Studio | 5.0 | Nominative determinism | Shallow talent pool |

## The agencies we actually rate

Right. Joke mostly over. If you're seriously evaluating Sanity agencies and we're not the fit (wrong budget, wrong timezone, wrong vibe, all legitimate), here's who else we'd put on your shortlist. Nobody asked to be here, nobody paid, and none of them know this list exists, which as established is the industry-standard methodology.

### Lemon Hive

[Lemon Hive](https://www.lemonhive.com/) built the headless Sanity and Next.js site for brightonSEO, which means the most search-literate audience in the world loads their work every conference season, and they also shipped Rise at Seven's site. They do something else we respect: white-label headless development for other agencies. You only get repeat work from agencies, the most demanding clients alive, if the engineering holds up without anyone chasing you.

### Skai Digital

[Skai Digital](https://www.skaidigital.com/) in Oslo build the custom commerce layer around Shopify with Sanity handling content: storefronts, portals, and B2B workflows for ambitious D2C brands. Headless commerce is where a lot of Sanity projects quietly go wrong, because content modelling and merchandising pull in different directions. Skai is one of the few shops we've seen treat that as the core problem instead of an edge case.

### Evensix

[Evensix](https://evensix.com/) is a Sanity Global Innovation Partner: design-led, comfortable across the Sanity, Next.js and Vercel stack, and they treat content architecture as the job rather than a warm-up for building pages. The animation on their [Sanetti bike demo](https://evensix.com/work/demonstrating-the-sanity-difference) is properly impressive, the kind of 3D and motion craft we watch with professional respect and mild irritation. A perfectly respectable choice if we're busy, which we usually are, because we're the best overall (see above).

### And yes, pagepro

The 4.9 stars across 32 Clutch reviews are earned. The React, Next.js and Expo work is real, the client list is real, and if you want a strong Central European team, they belong on your shortlist. We just also want to see the world in which their ranking and ours are both correct, because in that world we are first and they are second, and we can live in that world very happily. [Check them out](https://pagepro.co/)

## How these lists actually get made

Here's the quiet part. Every "top X agencies" article you've ever read was written by whoever appears at the top of it, or if they're "gorilla marketing" they put themselves at #2. The format exists because "top sanity agencies" is a keyword with buyer intent, and the fastest way to rank for it is to publish the ranking yourself. That's the entire genre. There is no committee. There was never a committee.

That doesn't make the agencies in those lists bad. pagepro's list features capable firms. It just means the ordering is marketing, and you should read it the way you read a menu written by the chef: trust the descriptions, not the "chef's favourite" star.

> **Talk to the #1, #2, #3, #4 and #5 agency on this list**: We build Sanity and Next.js sites with real-time preview as standard, and we promise to be exactly this honest about your project. [See our Sanity services](/services/sanity)

If you want the sincere version of this article, we wrote it three years ago and still stand by it: [our original honest guide](/blog/choosing-the-right-sanity-cms-agency). Define your project and budget, pick specialists over generalists, throw them a curveball question, and make sure the person selling you the project is the person running it.

And if you're an agency reading this: the top spot in next year's ranking is available. All you have to do is publish it.

---

## Next.js AEO/GEO/SEO whatever you want to call it: guide


> AEO, GEO, or just SEO: the playbook is the same. Metadata, JSON-LD, sitemaps, and content negotiation, implemented on a production Next.js site.

**TL;DR:** AEO, GEO, LLMO: the acronyms keep multiplying but they describe one job. Mostly SEO, plus serving AI agents a clean version of your content via content negotiation. Here's the full Next.js implementation from robotostudio.com.

**Published:** 2026-06-24 | **Updated:** 2026-08-31 | **Categories:** Hot Takes, Next.js, AI
---

_God I'm tired_. If I hear one more "SEO is dead, AEO is the future", I'm going to lose my mind. I want you to know, going in, I'm only going to tell you the things that have moved the needle for us. Not some elaborate ruse to sell you a course. But before we start...

## What should we call it

The acronyms keep multiplying, but they all describe one job: getting cited when an AI answers a question.

- **Answer engine optimization (AEO)** is the practice of structuring content so AI answer engines like ChatGPT, Claude, and Perplexity pick it as a cited source. The term grew out of the SEO industry and shows up most in developer circles.
- **Generative engine optimization (GEO)** is the same discipline under a different name: shaping content to be surfaced and quoted inside AI-generated answers. The label comes from a 2023 academic paper and got adopted by marketing teams. If your client reads marketing blogs, they'll say GEO.
- **LLM SEO** (and its synonyms AI SEO, LLMO) is the broad umbrella term for ranking in and getting quoted by large language models. Whichever one your team says, the work underneath is identical.

Dom Sipowicz, a forward deployed engineer at Vercel, has been keeping score since 2025:

That being said, I do like his definitions here, and I'll be using these from here on out.

You'll notice, even he finds it difficult to standardise `=` and `-`, so god knows how we'll handle these acronyms.

The tactics underneath are identical. Structured content, accurate metadata, clean markup, content agents can quote. If a consultant tells you GEO needs a fundamentally different strategy from AEO, they're selling you the same audit twice. We run an [AI SEO agency](/services/geo) and it's definitely not to capitalise on an emerging keyword.

Anyway, I digress.

## What's actually new

Agents are a new class of visitor. They:

- _Sometimes_ can't run JavaScript reliably
- Choke on ads, navigation, footers, and cookie banners
- Have small context windows, so wasted tokens cost real money
- Prefer structured text they can quote verbatim

It's the best one-screen summary of the problem I've seen. [Merj](https://merj.com/)'s lab testing found agents fail on exactly the patterns modern frontends love: drag and drop, multi-step forms, overlapping layers, layout shifts, canvas rendering, and UI virtualisation. In every case the content exists, the agent just can't reach it. If your pricing lives in a canvas-rendered table or your nav is virtualised, you're invisible to agents no matter how good the words are.

One thing we've observed though: they *absolutely love* markdown if they accept it. So much so that we had a 10k uptick of visitors from `GPTBot` in the space of 5 mins. _I'm not joking_. Hold that thought, because what a spike like that does to your bill gets its own section further down.

## The SEO half (nothing changed)

Before any AEO plumbing, do the SEO that's been working since the Panda update. Quick summary, since you've probably read this before:

- Titles target the actual query, sentence case, under 60 characters
- Meta descriptions are written for humans and include the keyword
- Schema markup where it earns rich results: `BlogPosting`, `FAQPage`, `Service`
- Internal links from blog posts to relevant service pages ([like this one](/services/nextjs)), not just topic clusters
- Real backlinks from people who chose to cite you, not directories
- Content that says something specific, not "the ultimate guide to [topic]"

Three observations from doing this for a few years:

1. **Your title tag is the single biggest lever.** Position 8 with a 0.2% click-through is a title problem, however good the content underneath it is. Fix titles before you write a word of new content.
2. **Internal linking is undervalued and free.** We added contextual CTAs from every blog post to the most relevant service page. Took an afternoon. The blog cluster now feeds traffic into services rather than dead-ending at "related posts".
3. **Most "AEO checklists" are SEO checklists with the word "answer" added.** If you skip the SEO basics, no amount of `llms.txt` will save you.

### The Next.js implementation of the boring half

Three patterns cover most of it on an App Router site.

**Metadata with fallbacks, not requirements.** Every page derives its meta from the data layer, with optional overrides that fall back:

```tsx
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);
  return {
    title: post.seoTitle ?? post.title,
    description: post.seoDescription ?? post.description,
    alternates: { canonical: `https://robotostudio.com/blog/${post.slug}` },
  };
}
```

**JSON-LD derived at render time, never hand-authored.** The most common mistake we see is structured data as a separate editing surface. It drifts within a sprint. Generate it from fields you already have:

```tsx
const jsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  datePublished: post.publishedAt,
  dateModified: post.updatedAt,
  author: { "@type": "Person", name: post.author.name, url: post.author.url },
};
```

One helper function, rendered in a `<script type="application/ld+json">` tag. Answer engines weight structured data heavily when picking citation sources. Show both dates visibly on the page too: between two posts answering the same question, the one updated last month usually wins the citation.

**A sitemap where `lastmod` is real.** Google has said publicly that it largely ignores `priority` and `changefreq`. The freshness signal is `lastModified`, so generate it from the same data that powers the pages:

```tsx
// app/sitemap.ts
export default async function sitemap() {
  const posts = await getAllPosts();
  return posts.map((p) => ({
    url: `https://robotostudio.com/blog/${p.slug}`,
    lastModified: p.updatedAt,
  }));
}
```

## Every JSON-LD type worth shipping (and a prompt that builds them)

The `BlogPosting` example above is one of seven. Here's the full set we wire up, where each one lives, and what feeds it:

| Schema | Where | Feeds on |
| --- | --- | --- |
| `Organization` | Root layout, once | Company name, logo, social profiles |
| `WebSite` | Root layout, once | Site name and URL |
| `Person` | Author bylines and author pages | Name, role, photo, socials |
| `BlogPosting` | Every post | Title, description, both dates, author, image |
| `BreadcrumbList` | Every nested page | Derived from the URL structure |
| `FAQPage` | Pages with real FAQs | Your existing FAQ content |
| `Service` or `Product` | Offering pages | Name, description, provider |

The one people skip is the most important: `Organization.sameAs` with your social links is how engines connect your X, LinkedIn and GitHub presence to your domain. That entity graph is what gets a brand cited by name instead of as "one source".

Don't fill any of this in by hand. Paste this into Claude Code, Cursor, or whatever agent lives in your repo, and answer its questions:

```text
You're going to wire complete JSON-LD into this codebase. Interview me
first, one question at a time, then implement.

Ask me, in order:
1. Company: legal name, brand name, site URL, logo URL.
2. Socials: links for X, LinkedIn, GitHub, YouTube, Facebook, Instagram
   (skip any we don't have). These become Organization.sameAs.
3. Contact: support email or contact page URL.
4. Authors: for each content author, their name, job title, photo URL,
   personal site, and social profiles. These become Person schemas.
5. Content types: check the repo first, then confirm with me which exist
   (blog, services, case studies, FAQs, products).

Then implement, deriving everything from data that already exists in the
codebase (frontmatter, CMS fields, site config) rather than hardcoding:
- Organization + WebSite once in the root layout
- Person on author bylines, referenced from BlogPosting.author
- BlogPosting on posts, datePublished/dateModified from real fields
- BreadcrumbList derived from URL structure on nested pages
- FAQPage only where actual FAQ content exists
- Service or Product on offering pages

Rules: one shared helper module, rendered as
<script type="application/ld+json">. No editor-facing JSON fields. No
invented data: if I didn't give it to you and the repo doesn't have it,
leave the property out. When done, list every URL + schema pair so I can
spot-check them in Google's Rich Results Test.
```

Ten minutes of answering questions and the whole entity graph is done, derived from your real data, with nothing for editors to maintain. Spot-check the output in the [Rich Results Test](https://search.google.com/test/rich-results) before you ship.

> **Building on Sanity?**: If you want the CMS-flavoured implementation of everything in this post, our Sanity AEO/SEO playbook covers JSON-LD, sitemaps, content negotiation, llms.txt, and the accessibility patterns that feed both traditional SEO and AEO in one place. [Read the Sanity AEO/SEO guide](/blog/aeo-seo-best-practices-for-sanity)

## The new half (content negotiation)

Now the actually new bit. Here's what each piece does on robotostudio.com.

### The Accept header tells you who's asking

The HTTP `Accept` header is how a client tells the server which formats it can handle. Browsers send `text/html`. Agents that want markdown send `text/markdown`. Claude Code happens to send `text/plain`. Same URL, different format, no client-side knowledge required.

In `next.config.ts`:

```ts
const acceptMarkdown = {
  type: "header" as const,
  key: "accept",
  value:
    "(?=.*(?:text/plain|text/markdown))(?!.*text/html.*(?:text/plain|text/markdown)).*",
};

const beforeFiles = [
  { source: "/blog/:slug",      has: [acceptMarkdown], destination: "/api/md/blog/:slug" },
  { source: "/services/:slug",  has: [acceptMarkdown], destination: "/api/md/services/:slug" },
  { source: "/migration/:slug", has: [acceptMarkdown], destination: "/api/md/migration/:slug" },
  { source: "/case-study/:slug",has: [acceptMarkdown], destination: "/api/md/case-study/:slug" },
  { source: "/careers/:slug",   has: [acceptMarkdown], destination: "/api/md/careers/:slug" },
  { source: "/",                has: [acceptMarkdown], destination: "/api/md/pages/home" },
];
```

The regex looks scary but it's defensive. It matches `text/markdown` or `text/plain` only when those tokens appear *before* `text/html` in the Accept header. Browsers that happen to list `text/markdown;q=0.5` after HTML still get HTML. Agents that ask for markdown first get markdown. Borrowed from [vercel-labs/markdown-to-agents](https://github.com/vercel-labs/markdown-to-agents).

### Markdown pair routes: we no longer recommend them

The first version of this post recommended giving every page a `.md` twin: `/blog/some-post` for browsers, `/blog/some-post.md` for agents. We shipped them on robotostudio.com. Both search engines have since told everyone to stop.

Google's official guidance, [Optimizing your website for generative AI features on Google Search](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), is blunt: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in generative AI search." The same guide tells you to reduce duplicate content because it wastes crawler resources. John Mueller went further on Bluesky, [calling markdown pages for LLMs "such a stupid idea"](https://searchengineland.com/google-bing-dont-recommend-seperate-markdown-pages-for-llms-468365): why would a crawler want a page no user sees, when LLMs have parsed HTML since the beginning?

Bing's Fabrice Canel made the crawl budget case in one line: "really want to double crawl load? We'll crawl anyway to check similarity." That's the part that should worry you. Every `.md` twin is a second URL per page. Bing crawls it anyway to compare it against the canonical, so a 1,000-page site just became a 2,000-URL crawl for zero ranking benefit. `X-Robots-Tag: noindex` keeps the twins out of the index (we shipped that from day one) but it doesn't stop the crawler visiting them.

The good news: pair routes were always the redundant half of the pattern. Content negotiation on the canonical URL does the same job without minting new URLs. Googlebot asks for `text/html` and gets HTML; an agent asking for `text/markdown` gets markdown; one URL, no duplicates, no extra crawl. If you've already shipped `.md` twins, stop advertising them (sitemaps, Link headers, llms.txt) and let the Accept header carry the load.

### Discovery via Link headers

The homepage advertises the agent-facing surfaces in an RFC 8288 `Link` header:

```
Link: </llms.txt>; rel="describedby"; type="text/plain",
      </llms-full.txt>; rel="service-doc"; type="text/plain",
      </sitemap.xml>; rel="sitemap"; type="application/xml"
```

An agent crawling the homepage gets a structured map of where everything lives without parsing HTML.

### What is llms.txt, and how to generate one

`llms.txt` is a plain markdown file at the root of your site that tells AI agents what's worth reading, in priority order. It's the convention proposed by [Jeremy Howard](https://llmstxt.org/): a single index an agent can fetch instead of crawling your navigation, listing both the HTML and markdown URLs for your best content. Think of it as a sitemap that talks.

A trimmed version of ours:

```markdown
# Roboto Studio

> Our mission is to create the best editorial experiences on the web...

## For AI agents

Send `Accept: text/markdown` against any URL on this site to get
clean markdown at the same address.

## Services
- [Sanity CMS](https://robotostudio.com/services/sanity)

## Blog Posts (Recent)
- [Latest post](https://robotostudio.com/blog/...)
```

Don't hand-maintain this. A static llms.txt rots the moment you publish, so generate it from the same content layer that powers your pages. On the App Router that's a single static route handler, which is the whole "llms.txt generator" most sites actually need:

```ts
// app/llms.txt/route.ts
export const dynamic = "force-static";

export function GET() {
  const posts = getAllBlogPosts();
  const services = getAllServices();

  const lines = [
    "# Roboto Studio",
    "",
    "> The best editorial experiences on the web.",
    "",
    "## Services",
    ...services.map((s) => `- [${s.title}](https://robotostudio.com/services/${s.slug})`),
    "",
    "## Blog",
    ...posts.map((p) => `- [${p.title}](https://robotostudio.com/blog/${p.slug})`),
  ];

  return new Response(lines.join("\n"), {
    headers: { "Content-Type": "text/plain; charset=utf-8" },
  });
}
```

A loop over content you already have, regenerated on every build, nothing for an editor to keep in sync. We also publish `llms-full.txt`, the entire content of every page concatenated, for agents that want to embed the whole site once instead of re-fetching.

One caveat for balance: Google's generative AI guide lists llms.txt among the files you don't need, and that's accurate for Google's own AI features. The agents that read it are the non-Google ones: Anthropic's fetcher, Perplexity's crawler, and most coding agents. Ship it for them, not for AI Overviews.

### The markdown actually has to be clean

This is the part that takes the actual time. If your content is MDX (markdown with React components inside), you can't just serve the file. Agents will choke on `<InlineCTA>` and `<Newsletter>` tags.

Our `markdown-route.ts` walks the MDX:

- Strips JSX components, keeping their text children
- Preserves fenced code blocks intact (delimiter-length-aware, so a 3-backtick example inside a 4-backtick fence survives)
- Preserves inline code spans (CommonMark equal-delimiter rule)
- Removes `import`/`export` statements
- Renders the frontmatter as a readable header (title, description, author, date)

Then it serves with:

```
Content-Type: text/markdown; charset=utf-8
Cache-Control: public, max-age=3600, s-maxage=86400
X-Robots-Tag: noindex, nofollow
```

The `X-Robots-Tag` matters. The `/api/md/*` destinations are real URLs anyone can fetch directly, and without the header Google can index them as duplicate copies competing with the canonical HTML pages.

> **Need this implemented on your site?**: We build agent-friendly Next.js sites with content negotiation, llms.txt, and clean schema. Same playbook as ours, applied to yours. [See our GEO service](/services/geo)

## How do I not go broke because of crawlers

Remember that `GPTBot` spike? Well of course, *caching*.

That's 30 days of bot traffic on robotostudio.com (well over 10% of our traffic). The reason we don't go broke is the column on the right. Notice how the meta crawler sits at 83% cached, bingbot at 82%, googlebot at 74%, chatgpt-user at 70%. That's due to aggressive caching.

Bots re-request the same URLs constantly, so when those hits land on the CDN instead of your rendering pipeline, a 10k spike costs roughly nothing.

The mechanics are boring on purpose. If a route can be static, make it static: a bot hitting a prerendered page is a CDN hit, not a function invocation. Content pages should be SSG or ISR, and the markdown route gets real Cache-Control headers (you've already seen ours ship `s-maxage=86400` above). Reserve dynamic rendering for pages that genuinely need it, because that's the traffic crawler spikes can actually hurt.

The table lives in the [Edge Requests tab of Vercel Observability](https://vercel.com/docs/observability/insights#edge-requests), which breaks traffic down by individual bot and bot category, AI crawlers included. Or skip the clicking: open your project in the Vercel dashboard and throw `/observability/edge-requests?period=30d&tab=botName` on the end of the URL, and this exact page pops up. Look at it before assuming agent traffic is what's burning your budget: in our table the SEO audit tooling crawls harder than ChatGPT does.

## The tools actually worth your time

You don't need a GEO tool suite. Most of this is verifiable with tools you already have, plus one category worth paying for.

**Testing your own output**

- [Rich Results Test](https://search.google.com/test/rich-results): paste a URL and confirm your JSON-LD parses and Google sees the schema types you wired up. A malformed property drops the whole block from rich results, and this is the fastest way to catch it.
- A terminal: `curl -H "Accept: text/markdown" https://yoursite.com/some-page` shows you exactly what an agent receives. If it comes back full of `<div>`s, your content negotiation isn't firing.
- Your own `/llms.txt` in a browser tab: confirm it loads and the links resolve. No product required.

**Watching the crawlers**

- Vercel Observability's Edge Requests tab (the bot table from earlier) is the cheapest way to see which AI crawlers hit you and how well you're caching them. Most paid "answer engine optimization tools" resell a worse version of this.
- Server logs if you're not on Vercel: grep for `GPTBot`, `ClaudeBot`, `PerplexityBot`, and `Google-Extended`.

**Monitoring citations**

This is the category that earns its subscription, because you can't see it in your own analytics: whether AI engines actually mention you. Otterly, Peec, and ZipTie track share of voice across ChatGPT, Perplexity, Gemini, and Google AI Overviews, and the better ones for monitoring AI Overviews will tell you which of your pages got cited. Ahrefs and Semrush have bolted AI Overview tracking onto their keyword tools too, so if you already pay for one, check before buying another.

The honest order of operations: do the structural work first. A monitoring dashboard reading zero citations is an expensive way to find out you skipped the JSON-LD.

## What to skip

A non-exhaustive list of things being sold as AEO (or GEO) that you can ignore:

- **`.md` twin URLs for every page.** Google and Bing have both advised against separate markdown pages (see above). Content negotiation on the canonical URL covers the same agents without doubling your crawl footprint.
- **"AEO schema."** There's no separate schema for AEO. Schema.org is the same standard SEO uses. Add `FAQPage` if you have FAQs, `HowTo` for genuine how-tos, `Article` for posts. That's it.
- **AEO courses.** The playbook is two paragraphs of HTTP and a sitemap. Don't pay for it.
- **FAQ stuffing.** Writing fake FAQs for the sake of FAQ schema is the new keyword stuffing. Google restricted FAQ rich results to authoritative government and health sites in 2023, so the rich-result payoff is gone for most sites anyway. Write FAQs because they're useful, not because they get cited.
- **Worrying about which agent's leaderboard you're on.** ChatGPT, Claude, Perplexity, and Gemini all use slightly different retrieval strategies. The signal that matters across all of them is the same one Google's used for fifteen years: do real people cite you?

## Did it work?

It's been a few weeks. Two observations.

**Crawler traffic is huge, referral traffic is small.** The bots showed up immediately: 16K chatgpt-user requests in 30 days, the GPTBot spike from earlier, the whole observability table. Humans clicking through from AI answers are a different story, around 14 visits per month from Claude, Perplexity, and ChatGPT combined in our PostHog data. The sequence runs crawling first, citations second, clicks last, and we're at stage one. Doing this work now means you're ready for the slope when it arrives, and you get crawled cheaply in the meantime (see the caching section).

**The work itself was small.** A few rewrites in `next.config.ts`, a route handler, a markdown converter, and an `llms.txt` generator. If your site is on Next.js 16 it's an afternoon's work. If it's on something else, the same pattern works on any framework that supports header-conditional routing.

That's the whole playbook from someone who's actually done it, whichever acronym you file it under. Skip the courses.

---

## Building agents with eve: what Vercel's agent framework removes


> What we've shipped on Vercel's eve so far: our content-ops agent, how each part of it works, and the things we learned as a team putting an agent framework into real use.

**TL;DR:** Vercel released eve, an open-source agent framework where the whole agent is a folder of files. Here's what we've built on it so far: our content-operations agent, a walkthrough of every tool, skill, connection, and guardrail in it, and what the build taught us as a team.

**Published:** 2026-06-17 | **Updated:** 2026-08-17 | **Categories:** AI, How To
---

Vercel [released eve](https://vercel.com/blog/introducing-eve) today: an open-source **agent framework** for building and running AI agents. The difference from traditional agent orchestration frameworks is that building an agent on eve is closer to *writing up markdown* than to wiring up a proprietary workflow engine. That keeps your attention on what you want out of the agent instead of the semantics of the framework running it.

Having built [Satoru](/blog/why-we-built-our-own-background-agent), a background coding agent, we know a couple of things about what it takes to build an agent. However, it's gone awfully quiet now after all of those _"agents pushed 110% of all our code to production"_ stories. Being the cynical folks, here's the honest version. It's worth building these agents yourself to understand how they work. In practice, though, you'll probably reach for a managed service like Vercel AI Gateway. The models move so fast that unless agents are your primary income, you'll spend more time maintaining one than you ever claw back in productivity.

So fast forward to today, when eve landed, we rebuilt a bunch of our internal agents on it to see what the framework actually removes. This post is two things: a tour of what eve gives you, and a detailed walk through the agents we built, every tool, skill, connection, and guardrail.

## What eve actually is

The headline idea is that an agent is a directory of TypeScript and Markdown files, and where you put a file is how it gets wired in. Vercel compares it to what Next.js did for web apps, and I'd say that's pretty accurate, but I'd argue it's even simpler.

You describe behaviour, eve owns the execution loop. _Notice how many of the files below are written in Markdown._

### Meet the primitives

- `agent.ts` sets the model (with provider fallback).
- `instructions.md` is the system prompt.
- `tools/` holds TypeScript files that become callable tools.
- `skills/` holds Markdown files that become procedural knowledge the agent pulls in on demand.
- `channels/` route the same agent to Slack, Discord, Teams, Telegram, GitHub, Linear, or plain HTTP, one adapter file each.
- `connections/` wire in external services through MCP and OpenAPI, with credentials handled for you.
- `schedules/` turn cron expressions into autonomous runs.
- `evals/` are scored test suites for the agent's behaviour.

Underneath the files, eve ships the things you'd otherwise build yourself: durable execution with checkpointed workflows, so a session survives a crash or a deploy and resumes from its last checkpoint; isolated sandboxes for agent-generated code; human-in-the-loop approval gates you can set per tool; OpenTelemetry tracing you can read in Vercel's Agent Runs dashboard; and replay, so you can see the exact model calls, tool invocations, and commands a run made. It's basically [Vercel Sandbox](https://vercel.com/sandbox), [Vercel Workflows](https://vercel.com/workflows), and the [Vercel AI SDK](https://ai-sdk.dev) rolled together, but far less fiddly to get started with.

## The files and what they're used for

The primitives above land better against something real, so the rest of this section is a file-by-file teardown of one agent we built and run: the one that keeps our CMS comparison pages factually fresh. Each file maps to a primitive, and seeing them wired into a working agent beats reading them in the abstract.

A note on scope first. The version in our repo is a single directory carrying two skills, cms-freshness and daily-retro. In production we've split those into separate bots (the full fleet is in "How our bots work" below), but we've kept them together here because one agent doing two jobs exercises more of eve's surface in a single read. We'll start at the model config and work outward: the instructions, then the tools, channels, connections, and schedules.

### `agent.ts` the entire model config

Here is the complete agent definition.

```ts
import { defineAgent } from "eve";

export default defineAgent({
  model: "anthropic/claude-opus-4.8",
});
```

That's it. The model string routes through Vercel's AI Gateway, so the provider is swappable and eve handles fallback. For this kind of work you probably want a high model, so we run the strongest Opus available. The job reads as mechanical, find a stale fact, cite a source, propose a patch, but the judgment underneath isn't: deciding whether a vendor genuinely shipped a feature, or whether a criticism we made still holds. That's where a weaker model gets those calls wrong. The guardrails we get to later can block an unsafe edit, but they can't tell you a well-sourced, subtly wrong one is wrong. So we spend on capability up front.

### `instructions.md` the system prompt as a file

`instructions.md` is the agent's identity and its rules. Ours is short and blunt. It names the two skills, then sets hard scope:

- Every analytics, search-console, and ranking query is scoped to robotostudio.com. Never a client's data, even if a connected server happens to expose it.
- Nothing outside `apps/web/content/cms/*.yaml` gets edited. Branches, commits, and PRs belong to the freshness skill alone.
- One Slack channel is the only outbound path. No DMs, no other channels.

It also sets tone, including a rule we apply everywhere: no em-dashes, use periods, colons, commas, or middots instead. The system prompt is a file in the repo, so it's reviewed in pull requests like any other code.

### `skills/` Markdown that teaches a procedure

In eve, a skill is a Markdown file of domain knowledge the agent loads when it's relevant. Ours has two, and they carry most of the real thinking.

The **cms-freshness** skill opens with editorial guardrails before a single step. These are opinionated comparison pages with a deliberately skeptical voice, so the rules are protective: patch facts, not tone, and treat vendor copy as proof a feature shipped but never as proof a weakness is gone. A changelog shows a feature exists. It does not show the pain point is fixed. For that you need an independent source.

Then it lays out a research order with a fetch budget of roughly ten URLs: the pricing page first, then changelog, then official blog, then the vendor's community forum, then Reddit, then Hacker News. The comments on the last two are where real developer sentiment lives, and the rule is to treat themes as signal and one-off complaints as noise.

The **daily-retro** skill is the opposite temperament: deterministic and rigid. It pins everything to a single UTC day, pulls a fixed set of PostHog queries, makes exactly one Ahrefs call (with a list of the gotchas that crash the run if you ignore them), and renders a Slack report with a fixed Block Kit shape. It even tells the agent to discover real event names first rather than assume `form_submit` exists, because our actual events are named things like `contact_form_viewed` and `cal_booking_successful`.

### `tools/` capabilities as typed functions

Tools are TypeScript files using `defineTool` with a Zod input schema and an `execute` function. We wrote eight. The simple ones first:

- **`pick_stale_cms`** lists every `apps/web/content/cms/*.yaml` through the GitHub API and returns the one with the oldest `updatedAt`. This is how the agent decides what to work on with no input.
- **`read_cms_yaml`** reads and parses one file by slug.
- **`fetch_url`** fetches a page and runs it through Turndown to return clean Markdown, stripping scripts and styles, capping at 60,000 characters, with a 15-second timeout. It's how the agent reads a vendor pricing page.
- **`search_reddit`** and **`search_hackernews`** hit the public JSON and Algolia APIs, no auth needed, to gather developer sentiment with a citable permalink on every hit.
- **`compute_target_date`** resolves the retro's target day, defaulting to yesterday in UTC, and returns the trailing-seven-day window so "versus average" means the prior seven full calendar days, not a rolling clock.
- **`post-to-slack`** posts to the one configured channel through `chat.postMessage`, pulling the token at runtime via Vercel Connect.

The eighth tool, `open_pr`, is where it gets interesting, because letting a model edit published content is exactly the kind of thing that scares the shit out of your Infosec team. So we put a wall in front of it. That wall is the guardrail engine, the part that does the real work, and we come back to it in the patterns section below.

### `channels/` doors in

`channels/slack.ts` is one file, and it's most of what makes the agent answer in Slack. It uses eve's Slack channel with credentials from Vercel Connect, and an `onAppMention` handler that maps the Slack user who mentioned the bot to an auth principal. Want it answering in Linear too? That's another short file of about the same length, and the agent itself doesn't change.

### `connections/` services out

`connections/` is how the agent reaches Ahrefs and PostHog. Each is a `defineMcpClientConnection` pointing at a remote MCP server, with the token pulled from an environment variable at call time and a description that scopes it hard.

```ts
export default defineMcpClientConnection({
  url: "https://api.ahrefs.com/mcp/mcp",
  description: "Ahrefs SEO data for robotostudio.com only ...",
  auth: { getToken: async () => ({ token: process.env.AHREFS_API_TOKEN }) },
});
```

Two things to notice. The credential never sits in the agent logic, and the scope ("robotostudio.com only, never another domain") lives right next to the connection so the model reads it every time it considers a call.

### `schedules/` cron as a Markdown file

The freshness job is a single file, `schedules/cms-freshness.md`:

```md
---
cron: "0 9 * * 1"
---

Run the cms-freshness skill. Refresh the stalest CMS comparison YAML and open a PR. Stop after one CMS, don't loop.
```

Every Monday at 09:00 UTC, eve runs the text below as the agent's prompt. The cron line is the only configuration the schedule needs.

## How our bots work

We also recorded a walkthrough of this running on our own site: the comparison-page updates, the Slack reports, and how the cron jobs orchestrate more than one agent.

The agent you just read end to end is our content-ops bot, and it's the ancestor of most of the agents we run. The job we walked file by file is the CMS comparison updater: a weekly cron finds the stalest comparison page, researches that vendor against primary sources, and opens a single sourced PR for a human to merge. The guardrail pattern below is how it stays honest about what it changes.

![A weekly auto-update PR opened by the comparison updater: each pricing change confirmed against the vendor's own page, an SLA claim corrected, and an unverifiable Reddit attribution dropped for lack of a source.](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/building-agents-on-eve-cms-update-pr.png)

None of our bots writes prose for the blog. We deliberately didn't build a ghost-writer, because the defensible work in content operations is keeping facts true and surfacing what's worth acting on, not generating words at volume.

### The PostHog feedback loop

This one fires the moment someone converts, a Cal.com booking or a Formspark submission, and reconstructs the whole path that led there. A typical read: a visitor landed on a blog post, moved through to our Sanity services page, then converted by telling us they needed a Sanity rebuild. That last part, the stated intent, is the bit a conversion counter never hands you. It turns a number ticking up into a sentence we can actually plan around.

I can't show you this one. It's built from a real visitor's name and the thing they told us they needed, and I'm not about to dox a prospect to decorate a blog post. So you'll have to take my word for it, which I'm aware is exactly what someone with no screenshot would say. If you'd rather see it for real, [fill in the contact form](/contact) and become the example. That submission fires this exact agent, and we'll gladly walk you through your own path across the site on a call: the post you landed on, and what you read before you decided to message us.

### The Ahrefs weekly audit

Once a week this agent reports the movers and shakers across the keywords we're chasing. When we rework a cluster of posts to build authority on a subject, it shows whether that work is moving rankings week over week, and how the queries we surface for are spreading and fanning out across the niche. It tells us whether an authority push is compounding into real rankings or just adding posts to the pile, and where our reach is heading next.

A recent run flagged four posts pulling big impressions and almost no clicks, then handed back a ranked to-do list to fix it.

![Part of the Ahrefs audit's weekly Slack report: a top-pages table showing high impressions and low CTR across four blog posts, a conversion funnel with the live counts blanked out, and a list of recommended actions ranked by impact and effort.](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/building-agents-on-eve-ahrefs-audit.png)

### The bookmarks bot

We keep a `#bookmarks` channel in Slack. Drop a link in it and this agent immediately pulls the content, files it into our [Are.na](https://www.are.na) knowledge bank, and tags it automatically. From there you can enrich any entry just by talking to the bot in the channel, with its credentials brokered through [Vercel Connect](https://vercel.com/connect) rather than sitting in the agent. Are.na handles the storage for now. We like how simple it keeps things, and we may bring it in-house later.

Below, it files away eve's own launch link, complete with the obligatory gardening metaphor.

![The bookmarks bot in Slack: a teammate posts "add https://vercel.com/eve", and the agent replies that it has planted the link and the eve docs into the team's Are.na channel.](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/building-agents-on-eve-bookmarks-bot.png)

### The Linear client digest

Linear's stock Slack notifications spam you every time a ticket slides into Done. This agent, forked from Vercel Labs' [`personal-agent-template`](https://github.com/vercel-labs/personal-agent-template) and stripped back to what we needed, replaces that firehose with a single contextual, directional update at the end of each day. The draft lands in an internal review channel first, where a teammate approves or discards it before it reaches the client. A client can read it in a few seconds and know what shipped and what's coming next.

Below is a draft waiting on that approval, with the finished and up-next work pulled straight from the Linear tickets.

![The Linear digest bot's draft in an internal review channel: a client update headed "what we finished" with cards for moved-across pages, an "up next" list, and a footer prompting a teammate to react to send it to the client or discard it.](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/building-agents-on-eve-linear-digest-v3.png)

## Patterns, anti-patterns, and what tripped us up

A few things we learned the hard way, building on a framework this young.

### The dev loop is a conversation

The first time I ran `eve dev`, I went looking for the Next.js moment. `npm run dev`, a server boots, you open localhost, you watch the thing you're building. I waited for the equivalent and it never came. eve just drops you into a TUI, a chat in your terminal. I'd say it took a second to click, but it took far longer, and then it was obvious: the thing you're building is a conversation, so you develop it by having one. Where Next.js hands you a page to poke at, eve hands you the agent to talk to.

### Guardrails the model can't override

The pattern that did the most work for us: never let the model write anything published directly. Our comparison updater doesn't edit YAML. It emits structured **findings**, and a deterministic engine in `lib/` decides which ones get through. Every proposed edit declares its exact `from` → `to` change and the source that justifies it, then runs a few gates before a character is written. A vendor primary source can admit a change alone, community chatter is a lead and never admits on its own, a claim that contradicts the vendor needs two independent sources, and the rebuilt diff has to match what the model declared or the finding is thrown out.

```ts
export const isAdmissible = (input) => {
  const hasTier1 = input.sources.some((s) => s.tier === 1);
  const tier2Count = input.sources.filter((s) => s.tier = 2).length;
  if (hasTier1) return { admissible: true };
  if (tier2Count = 0) return { admissible: false }; // community = leads only
  if (input.contradictsVendor && tier2Count < 2) return { admissible: false };
  return { admissible: true };
};
```

The point generalises past CMS pages. If you want a model touching anything you've published, don't ask it to be careful. Make carelessness structurally impossible and let the deterministic layer reject everything it can't prove.

> **Why we let a model near published content at all**: The rule behind this guardrail, keeping the model out of decisions that belong in code, is the whole argument of a companion post we wrote on the Vercel AI SDK that eve sits on top of. [Read 'Content automation without the slop'](/blog/content-automation-pipelines)

### Reaching for primitives you don't need

eve's sandboxes are one of its headline features, and we don't use one. Our agent reads pages, queries APIs, and commits through REST. It never writes or runs code, so there's nothing to isolate. Satoru, our background coding agent, is the opposite: it clones repos and executes code, which is exactly what a sandbox is for. The anti-pattern is provisioning the heavy primitive because it's in the brochure. eve lets you reach for it **only** when the job demands it, and our content agent simply doesn't.

### Schedules can't park for a subagent

Scheduled work has a sharp edge. A schedule running in task mode can't park to call a subagent: it dies with `Cannot park: no continuation token`, and nothing in the type signature warns you first. Keep that work inline, or move it to the handler form.

### Pin the build to the docs

eve is days old, so the model has no useful priors. Left alone it drifts toward whatever it saw most in training, which here is the wrong thing: older agent libraries, stale APIs, patterns eve threw out. You can vibe-code an agent, but only with a tight set of requirements. Two habits did most of the work. We put every spec through a [grill-with-docs](https://www.aihero.dev/grill-with-docs) pass so each requirement was pinned to the real documentation before any code existed, and we pointed the coding harness straight at [eve.dev/docs](https://eve.dev/docs/introduction) and made it read the current source rather than guess. Skip that, and the model will happily build against an eve that doesn't exist.

## Where this leaves us

The honest status: all five of these run in production, and we keep upgrading them piecemeal as each one shows us a new way to be wrong. We've kept this writeup qualitative on purpose. Screenshotting a dashboard to prove an agent earns its keep is its own kind of slop, and the guardrail engine is the part actually worth showing.

What's already clear is the shape of the saving. Satoru needed a control plane, a queue, a sandbox orchestrator, and a streaming dashboard before it did anything useful. This agent is a folder: a four-line model config, two Markdown skills, eight tools, two connections, one channel, one schedule, and a guardrail library. eve absorbed everything that used to be bespoke infrastructure, and left us with the part that's actually ours, the rules.

The content agent is one of several [agentic workflows](/services/agentic-workflows) we run in production, and they ride on the same fast, type-safe [agentic websites](/services/agentic-websites) we build for clients. Same stack, two ends of the same job.

> **Want an agent like this for your business?**: We design and build agentic workflows on eve and beyond, from content operations to autonomous internal tools. [See our agentic workflow services](/services/agentic-workflows)

---

## Content automation without the slop


> Content automation earns its bad name when a model makes decisions that should be rules. Here's where we draw the line, built on the Vercel AI SDK.

**TL;DR:** Content automation gets its slop reputation when a language model is handed decisions that belong in code. We keep the model in a small box: it researches and writes, while the pipeline owns scheduling, validation, and publishing. The Vercel AI SDK is what makes that boundary a type instead of a hope.

**Published:** 2026-06-16 | **Updated:** 2026-07-23 | **Categories:** AI, How To
---

> **We could not have timed this worse.** We published this hand-built content pipeline on the Vercel AI SDK the same week Vercel shipped eve, its agent framework, which turns most of the plumbing here into a folder of Markdown. The argument below still holds. The build is just far less work now. **[We rebuilt the whole thing on eve](/blog/building-agents-on-eve)**.

A bot that writes on a schedule sounds like a slop machine. Set it running, walk away, come back to a hundred posts that read like the same press release. That fear is reasonable. Most automated content is bad.

We run a scheduled agent anyway, and the corrections it ships are more reliable than the ones we used to make by hand. The difference is one rule: **the model never makes a decision that should be a rule.** Everything in this post is an argument for that line, plus the parts that matter once you start building real tooling: how to enforce the line in code, how to test it, and what to do when it breaks. We build all of this on the Vercel AI SDK, and we'll show you why.

First, the framing most teams get wrong. **Content automation** is not "let AI write your blog posts." Writing is maybe 30% of the time cost of publishing. The other 70% is research, briefs, formatting, fact-checking, SEO checks, and review. Those steps are mechanical and predictable, and they're where content dies, because nobody wants to spend Tuesday afternoon copying metadata into form fields.

## Slop is a determinism problem

Here's a definition worth keeping: slop is what you get when a stochastic model makes a decision that should have been deterministic.

### Why a language model is the wrong place for a rule

A language model is a probability machine. Ask it the same question twice and you can get two different answers. That variance is a feature when you want it to phrase a sentence, and a liability when you want it to decide whether a competitor's price changed. Point that randomness at a factual or structural decision and you've built a slop generator. Not because the model is dumb, but because you gave a dice-roll a job that needed a rule.

The trap is that the model is good enough to fool you. It will confidently pick a topic, assert a price, and write 800 words around it. Nothing in the output says "I guessed." So the failure is silent, and it scales. One bad post is an embarrassment. A pipeline of them is a reputation.

### The decision-sorting exercise

Before you write a line of agent code, list every decision in the workflow and sort each one into two piles: rule or judgement.

"Which page do we update this week?" is a rule (the stalest one). "Did this vendor change their pricing?" is judgement. "Is the new price formatted correctly?" is a rule. "How do we phrase the correction?" is judgement. Do this honestly and the architecture falls out of it: the rules become code, the judgement calls go to the model, and the model runs inside the rules rather than above them.

Most teams skip this step and hand the whole workflow to one big prompt. That's the original sin of bad AI tooling.

## The two lanes of a content pipeline

Every pipeline has two lanes running side by side. One is deterministic and owns control flow. The other is the model, doing the parts that genuinely need reading and writing.

The model sits inside the rail. It receives a tightly scoped task and hands back a structured proposal. It never decides when to run, which page to touch, or whether the result goes live. The rail calls the model the way your code calls any other unreliable dependency: with a timeout, a schema on the response, and a plan for when it returns nonsense.

## A worked example: keeping comparison pages honest

Here's a real one. We publish comparison pages that help people pick between content platforms before a migration. Vendors change pricing, rename tiers, and ship features constantly, so comparison pages rot. A page that was accurate in March quietly lies by June.

### What the agent does each week

So we run a small agent on a weekly schedule whose entire job is to keep those pages current. Each run it does the same five things, in the same order:

1. Finds the single most out-of-date comparison, picked by timestamp.
2. Reads the current page so it knows what we already claim.
3. Fetches the vendor's pricing page, changelog, and a few community threads.
4. Proposes specific field changes, each with a cited source quote.
5. Opens a draft pull request and pings a human in Slack.

Steps 1, 2, and 5 are deterministic plumbing. Steps 3 and 4 are the model's job. Nothing about that order is left to the model's discretion, which is the point.

### Where the decisions land

| The pipeline decides (rules in code) | The model decides (judgement) |
| --- | --- |
| **When** it runs (a timer, not a mood) | What a vendor's page says now |
| **Which** page: the stalest, picked by timestamp | Whether a fact genuinely changed |
| That edits are **surgical field patches**, never rewrites | A confidence level for each change |
| That every claim **carries a source quote** or it's dropped | Which sources are worth trusting |
| That tone is **off-limits**: facts can change, opinions can't | The wording of a corrected fact |
| That a no-op run opens **nothing** | |
| That it can touch **only** those files | |
| That a **human** publishes, never the agent | |

Every row in the left column is a decision we refused to delegate. The model is strong at "read this pricing page and tell me what the Team plan costs now." It's unreliable at "decide which of forty pages to edit and push it live." So we only ask it the first kind of question.

## Building the rails with the Vercel AI SDK

This is where the Vercel AI SDK earns its place. We've tried the heavier agent frameworks, and we keep coming back to the AI SDK for one reason: it makes the deterministic boundary a type, not a hope. If you're building AI tooling and you want one recommendation from this post, it's this stack. Here's how the rails get built.

### Make the model answer in a shape

Don't ask the model "did the price change?" and parse prose. Make it fill a schema. Structured output turns a judgement into a shape, and a malformed or hedging answer can't get through, because it won't match the schema.

```ts
import { generateText, Output } from "ai";
import { z } from "zod";

const { output } = await generateText({
  model: "anthropic/claude-haiku-4.5",
  output: Output.object({
    schema: z.object({
      field: z.enum(["pricing", "tier-name", "shipped-feature"]),
      changed: z.boolean(),
      proposedValue: z.string().nullable(),
      confidence: z.enum(["high", "medium", "low"]),
      sourceQuote: z.string().min(1), // no quote, no finding
    }),
  }),
  prompt: researchContext,
});
```

That `sourceQuote: z.string().min(1)` is doing real work. A finding without a cited snippet can't be represented, so the model can't propose a change it can't back up. The schema, not the prompt, enforces "cite or stay quiet." This is the single most useful habit in building AI tooling: every time you're tempted to write "and make sure you..." in a prompt, ask whether it should be a field in a schema instead.

### Give it tools, not file access

The model never touches a file directly. It calls a tool you defined, and the tool's `inputSchema` validates every argument before your code runs.

```ts
import { tool } from "ai";
import { z } from "zod";

const proposeEdit = tool({
  description: "Patch one existing field on a comparison page. Cannot create new fields.",
  inputSchema: z.object({
    slug: z.string().regex(/^[a-z0-9-]+$/), // refuses unsafe targets
    path: z.array(z.string()),              // must point at an existing key
    value: z.string(),
    source: z.url(),                        // every edit names its evidence
  }),
  execute: async (patch) => openDraftPr(patch), // opens a draft, never publishes
});
```

The model fills in `value`. The schema decides whether that value is even allowed to exist. Two details matter when you design tools this way. The `description` is part of the prompt, so write it like an instruction: ours says "cannot create new fields" because the model needs to know the boundary, not just hit it. And keep each tool narrow. A `proposeEdit` that patches one field is easy to validate and hard to misuse. A `doEverything` tool is neither.

Wire the tools into a `ToolLoopAgent` and the SDK runs the read-decide-act loop for you. The model's reach is still bounded by exactly the tools you handed it and nothing else.

```ts
import { ToolLoopAgent } from "ai";

const editor = new ToolLoopAgent({
  model: "anthropic/claude-haiku-4.5",
  tools: { fetchSource, proposeEdit },
});
```

### Let the SDK reject bad calls

You don't have to write the validation glue yourself. If the model hallucinates a tool that doesn't exist, the SDK raises `NoSuchToolError`. If it calls a real tool with arguments that don't match the schema, you get an `InvalidToolInputError`, and your `execute` function never runs. The bad call is caught at the door.

That's a free guardrail, and it's a big part of why we don't roll our own agent loop. The schema you wrote for documentation is also the schema that enforces correctness at runtime. You define the boundary once and the SDK polices it on every call.

### Keep the irreversible action human

One rule sits outside the SDK and matters more than any of them: every change lands as a draft. The pipeline owns the single irreversible action, publishing, and it never lets the model take it.

We proved this works the hard way recently. We deleted six auto-generated drafts in one go because they were generic and thin. The system did its job: the slop got caught at the draft gate, not on the live site. When you're deciding which decisions to keep human, start with the ones you can't take back.

## Prove it works, then prove it keeps working

A pipeline you can't test is a pipeline you can't trust. But you can't unit-test prose, and that confuses people into testing nothing. So they ship an agent, watch it work once, and assume it'll keep working. It won't. Prompts drift, models get swapped, a source changes its HTML, and the thing that worked in May quietly degrades by July.

The trick is to test the behaviour, not the writing. We run a small eval suite that checks the agent reaches for the right tools and stops, not that the sentences are good. One case reads, in plain terms: "given a normal week, the agent should pick the stalest page, read it, and make no more than a couple of tool calls before proposing." If a prompt change makes the agent start thrashing or skip the read step, that eval fails, and we find out before a bad PR does.

Think of evals as a regression net for the rails, not a quality score for the content. They answer "is the machine still behaving the way we designed it," which is a deterministic question with a deterministic answer. The quality of the prose is a separate problem, and that one still belongs to a human reviewer.

## When things fail

Real AI tooling spends most of its code on the unhappy path. The model returns garbage, a fetch times out, a vendor page is behind a login. Plan for it.

### Failing closed

The default posture is to do nothing rather than guess. If the researcher can't cite a source, the finding is dropped. If every finding gets dropped, the run ends and opens no pull request. An empty diff is a success, not a failure: it means the page is already correct. The worst thing a content pipeline can do is generate output to justify having run, so we made silence the easy path.

### Retries and roundtrips

The SDK handles the transient failures so you don't have to hand-roll them. Failed model calls retry automatically, twice by default, configurable with `maxRetries`. When your `execute` function throws, the SDK turns the error into a `tool-error` the model can see on its next step, so a recoverable problem (a 404 on one source) becomes a roundtrip rather than a crash.

Structured output gives you the same safety on the way out. If the model genuinely can't produce something that fits the schema, the call throws instead of handing you a half-formed object. You get a loud failure you can catch, not a quiet one that ships. Across the whole pipeline the rule is the same: surface the error, fail closed, and never let a degraded run masquerade as a good one.

## Where we keep the model free

Constraints stop slop, but over-constraint creates a different problem. If you template every sentence, you get content that reads like a form letter, which is its own kind of slop.

So we leave the genuinely hard parts loose. Reading a messy pricing page and working out what genuinely changed. Judging whether a Reddit thread reflects a real pain point or one annoyed user. Phrasing a correction so it stays sharp instead of going limp. That's judgement, and judgement is what the model is for. Forcing it into a rigid template there would make the output worse, not safer.

The skill is knowing which lane each decision belongs in. Pricing accuracy is a rule. The sentence that states the price is judgement. Keep those separate and you get reliability and readability at the same time.

## The determinism dial

Deterministic versus non-deterministic isn't a switch, it's a dial, and the AI SDK gives you the knobs to set it per call.

### The knobs

- **`temperature`** turns the randomness up or down. Low for extraction, higher for drafting.
- **`Output.object()` versus free text** decides whether an answer must fit a shape or can roam.
- **`tool()` validation** decides what the model is physically able to do.
- **`stopWhen`** decides how long the loop is allowed to run before you pull it out.

You set these per task, not per project. The same agent can extract a price at temperature zero and draft a sentence at temperature 0.7 in the same run.

### Cheap model, narrow task

Narrow, well-shaped tasks don't need a frontier model. We run a small, fast model for the extraction and patching work, and the AI Gateway means swapping models is a one-line change to a `provider/model` string. So you can route the cheap, high-volume calls to a small model and save the expensive one for the rare step that genuinely needs more reasoning. Most of building affordable AI tooling is just refusing to use a big model for a small job.

## What changed when we automated

Before the pipeline, comparison pages drifted. A wrong price could sit on a page for a quarter before someone noticed, because checking them by hand was nobody's favourite job. Now the stalest page is never more than a week from a fresh review, and the corrections arrive as a tidy diff with sources attached.

The numbers that moved:

- **Staleness**: from a quarter of drift down to a seven-day ceiling.
- **Time to a correction PR**: minutes of compute, not an afternoon of someone's week.
- **Human review**: still 20 to 30 minutes per change, and that's fine. Review is the part we want a person on.

The constraint was never how fast we could type. It was the dozen unloved steps between "this page is probably wrong now" and "the fix is live." Automate those, keep a person on the judgement, and the work gets done.

> **Want a content pipeline like this?**: We build agentic workflows that automate the repetitive parts of your business, from content to operations, with the model kept on a tight leash. [See our agentic workflow services](/services/agentic-workflows)

## When content automation doesn't work

Not every content problem is a pipeline problem. Automation pays off when:

- The process is repetitive and follows a pattern.
- Quality can be written as rules, not just "make it good."
- The content is informational, and you have clean data inputs.

It struggles with:

- Thought leadership that needs lived experience or original research.
- Content built on interviews, quotes, or primary reporting.
- Pieces where your angle is the value, not the information.

We still write plenty by hand. The pipeline handles the factual upkeep and the SEO-driven informational gaps. The opinions and the deep dives come from people.

## Getting started

You don't need the full system on day one. Start with the step that hurts most:

1. **If research is the bottleneck**, schedule a weekly keyword-gap pull and output a scored shortlist. No drafting yet, just data.
2. **If formatting is the bottleneck**, template your frontmatter so one command scaffolds a complete file with valid metadata.
3. **If upkeep is the bottleneck**, point a scheduled agent at one rotting page type, give it a `tool()` that can only propose draft edits, and make it cite every change.

Each of those is a weekend project. Add a schema, a tool, and one eval, and you have the start of a pipeline you can trust.

## The line is the craft

The point of content automation is to remove friction from work that's already good when a person does it carefully, so the mechanical parts happen without anyone context-switching into admin mode. Volume was never the goal.

The reason our scheduled agent doesn't produce slop has nothing to do with a clever prompt. It's that the model only ever answers small, well-shaped questions, the SDK rejects the answers that don't fit, and a human owns the one button that matters. Draw that line in the right place, let the tooling enforce it, and automated content can read like someone sat down and wrote it. Because for the parts that count, someone did.

---

## Install our agency into your agent


> Five of our internal skills are now open SKILL.md files, discoverable at /.well-known/agent-skills/index.json. What they do and why we gave them away.

**TL;DR:** We published five of the skills we use on client work as MIT-licensed SKILL.md files, discoverable at /.well-known/agent-skills/index.json per Cloudflare's agent skills discovery RFC. Point your agent at robotostudio.com/skills and install them.

**Published:** 2026-06-11 | **Updated:** 2026-08-24 | **Categories:** AI, Sanity, Next.js
---

There's a new well-known path on the web. Cloudflare's agent skills discovery RFC puts a JSON index at `/.well-known/agent-skills/index.json` listing the SKILL.md files an agent can install from your domain, each with a sha256 digest so the agent knows when something changed. Cloudflare's Agent Readiness scanner already checks for it, and Mintlify generates one for every docs site it hosts.

We just published ours. The index lists five skills we use on real client work.

## The five skills

[**content-negotiation-audit**](https://robotostudio.com/skills/content-negotiation-audit/SKILL.md) points your agent at any website, pulls the sitemap, samples ten pages, and requests each one twice: once as a browser, once with `Accept: text/markdown`. Then it grades the gap. Most sites fail immediately because they serve HTML no matter what you ask for. The interesting failures are further in: markdown routes that leak unrendered `<Content>` placeholders, or FAQ pages where every answer lives behind an accordion and never makes it into the markdown at all. Your agent reads a page that looks complete and is missing the exact content people ask about.

[**sitemap-audit**](https://robotostudio.com/skills/sitemap-audit/SKILL.md) turns a sitemap into an honest inventory: which templates repeat, which pages are one-offs, and which URLs are leaked drafts that should worry you. We run it before every rebuild proposal because the page type nobody mentioned is the one that blows the estimate.

[**cms-to-mdx-migration**](https://robotostudio.com/skills/cms-to-mdx-migration/SKILL.md) is the distilled version of how we migrated this very website off a headless CMS onto MDX files on disk: resumable migration scripts, rich text conversion gotchas, and the component mapping rules that prevent silent rendering failures. If you'd rather hand the whole migration over, [that's a service we run](/services/cms-migration).

[**sanity-schema-design**](https://robotostudio.com/skills/sanity-schema-design/SKILL.md) and [**sanity-groq-conventions**](https://robotostudio.com/skills/sanity-groq-conventions/SKILL.md) are the conventions we hold every Sanity project to: field templates with descriptions editors can actually use, and GROQ that stays readable past the tenth query.

All five are MIT licensed. Each is a single SKILL.md file, so there's nothing to unpack.

## Point your agent at it

Browse the human-readable pages at [robotostudio.com/skills](https://robotostudio.com/skills) or fetch the index directly:

```bash
curl https://robotostudio.com/.well-known/agent-skills/index.json
```

Each entry carries a sha256 digest computed over the exact bytes served, so your agent can pin a version and notice when we ship a change.

## Cloudflare's scanner does the same thing

The pattern is already how the graders grade. Cloudflare's scanner at [isitagentready.com](https://isitagentready.com) distributes its fix instructions as installable skills served from `/.well-known/agent-skills/` on its own domain: every failing check links a SKILL.md that tells your agent how to fix it. The tool that scores agent readiness ships its entire playbook through the exact channel we just joined.

## Why give it away

Because the moment someone runs content-negotiation-audit against their own site is the moment they find out their FAQ answers are invisible to AI. Some of those people will fix it themselves with the skill we just handed them. Some will want it done properly. Both outcomes are fine with us.

> **Want the audit run for you?**: Our generative engine optimisation service runs the full content-negotiation audit against your site, fixes what it finds, and wires up llms.txt, markdown twins, and the discovery index. [See the GEO service](/services/geo)

The site you're reading practices what the skills preach: every canonical URL on robotostudio.com answers `Accept: text/markdown`, the index digests match the served bytes, and [/llms.txt](https://robotostudio.com/llms.txt) documents the whole surface. We wrote up the general approach in [the Next.js AEO/GEO guide](/blog/nextjs-aeo-geo).

Wow, I can't believe people are actually using these. Tell me if it worked: [yo@robotostudio.com](mailto:yo@robotostudio.com)

---

## CMS migration checklist: the pre-launch essentials


> The CMS migration checklist and pre-launch plan we run on every replatform: redirects, sitemaps, JSON-LD parity, OG images, baselines and 30-day post-launch monitoring.

**TL;DR:** Every CMS migration that loses traffic loses it for the same handful of reasons. This is the pre-launch checklist we run internally on every replatform, openly published so any team can use it on their own migration.

**Published:** 2026-05-26 | **Updated:** 2026-07-23 | **Categories:** Migration, How To, SEO
---

Every CMS migration that tanks organic traffic does so for the same handful of reasons. Broken redirects. Missing structured data. A sitemap that quietly halved. Open Graph images that defaulted to a generic logo. None of it is a Google secret. All of it is preventable with a checklist that gets run before, during and after cutover.

This is the version of that checklist we run on every migration at Roboto Studio. It's the same document our engineers and SEO leads work through together before, during and after cutover. Every item on it has, at some point, caught a real problem on a real client project. Use it on your own migration, or hand it to your current agency and ask which boxes they're ticking.

We've also built the whole thing as an [interactive checklist on the CMS migration service page](/services/cms-migration#migration-checklist) if you'd rather tick boxes than scroll. State persists in your browser, so you can come back to it across a multi-week migration without losing your place.

## What this CMS migration plan covers

Twelve sections, in the order we run them. It doubles as a CMS migration plan you can hand to your team:

1. Baseline capture
2. URL inventory and redirect map
3. Sitemap audit
4. JSON-LD parity
5. OG image audit
6. Robots.txt and llms.txt
7. Internal-link audit
8. Image migration
9. Performance regression check
10. Staging-to-production cutover
11. The first 24 hours
12. The 30-day monitoring window

If you only do five of these properly, do redirects, sitemaps, JSON-LD parity, the baseline capture, and the 30-day monitoring window. Those five catch the failures that actually move the needle on organic traffic.

## 1. Baseline capture

Before any data moves, snapshot the current site. You're going to need this to prove the migration was safe, and to diagnose anything that does regress.

- Full Ahrefs export of ranking keywords, referring domains, top organic pages, top organic queries and top backlinks.
- GSC Performance export for the last 12 months at page-level granularity. Clicks, impressions, CTR, average position.
- GSC Coverage export. Indexed pages, excluded pages, valid-with-warnings, errors.
- Sitemap snapshot: download the live XML sitemap to disk so you can diff it post-launch.
- Internal-link graph: run Screaming Frog over the site and export the crawl.
- Page-speed baseline: pull a PageSpeed Insights and Lighthouse run for the top 10 templates.
- Schema inventory: open three to five pages of each template type in the Rich Results Test and log every JSON-LD type the old site emits.

This is one to two days of work that nobody enjoys. The teams that skip it are the teams that can't tell, six weeks post-launch, whether a 14% traffic drop is migration regression or normal seasonality.

## 2. URL inventory and redirect map

This is the single most important step on the list. Get it wrong and you surrender months of compounding link equity to soft 404s.

- Pull every URL with at least one organic click in the last 12 months from GSC.
- Pull every URL with at least one referring domain from Ahrefs.
- Pull every URL in the current XML sitemap.
- Deduplicate. This is your redirect-map source list.
- For each URL, define the closest equivalent on the new site. Categories, tag archives, author pages, paginated lists, the long tail of orphaned posts: nothing gets surrendered to a soft 404. If there's genuinely no equivalent, redirect to the parent category, not the homepage.
- Sign off the map in a spreadsheet before any code ships. Engineering, SEO and content all sign the same row.
- Implement as proper 301s at the edge (Vercel middleware, Cloudflare rules, or framework-level redirects). Avoid client-side redirects, JavaScript redirects, or 302s. Google treats 302s as temporary and won't transfer link equity.

If your CMS migration is moving 4,000 pages and your redirect map has 50 entries, you have a problem.

## 3. Sitemap audit

The new sitemap should have at least as many URLs as the old one once you account for legitimately deprecated pages. Check before launch and again 48 hours after.

- Build the new XML sitemap as part of the launch, not as a follow-up ticket.
- Diff old vs new. Investigate every URL that's in the old sitemap but not the new one. Either it should be in the new sitemap, or it should be 301'd to a URL that is.
- Cap individual sitemaps at 50,000 URLs. Use a sitemap index for anything larger.
- Submit the new sitemap to GSC on cutover day. Watch the indexing count climb over the following week.
- Remove the old sitemap from GSC once the new one is fully indexed.

## 4. JSON-LD parity

Structured data drives rich results in the SERP. Lose it and you lose star ratings, FAQ accordions, breadcrumb trails and product cards: every part of the snippet that makes your listing more clickable than the one above it.

- Catalogue every JSON-LD type on the old site from your schema inventory in step 1.
- Rebuild each type on the new site. Article, NewsArticle, FAQPage, BreadcrumbList, Product, Organization, VideoObject, Recipe, Review: whichever ones the old site had.
- Validate each template on the new site through the Rich Results Test before launch.
- Re-validate via GSC's Enhancements reports 72 hours after launch. Rich results take days to recrawl, not minutes.

A common regression: the old WordPress site had FAQPage schema via a plugin. The new Next.js site shipped without it. The FAQ accordions disappeared from the SERP and CTR on those pages dropped 20%.

## 5. OG image audit

Open Graph is the easiest thing to miss because nothing breaks visibly until someone shares a link.

- For every URL on the redirect map, confirm an OG image renders on the new site.
- Confirm OG titles and descriptions are populated, not falling back to a generic site default.
- Confirm Twitter Card metadata is set (twitter:card, twitter:image).
- Spot-check 10 URLs through the Twitter / X Card Validator, Facebook Sharing Debugger and LinkedIn Post Inspector. Force a re-scrape on each one so the cache busts.
- Confirm dynamic OG image generation works for blog posts, case studies and product pages. We use Vercel's @vercel/og runtime; whatever you use, test it on real production URLs, not localhost.

## 6. Robots.txt and llms.txt

- Confirm the new robots.txt allows crawling of every section that should be indexed. The most common regression: a staging environment's `Disallow: /` makes it to production.
- Confirm the sitemap URL is referenced from robots.txt.
- Confirm any intentional disallows from the old robots.txt are preserved on the new one. Don't accidentally start indexing your `/wp-admin/` equivalent.
- Add an llms.txt file at the root if you want AI crawlers to find your highest-signal content. Document your AI crawling preferences explicitly: GPTBot, ClaudeBot, PerplexityBot and CCBot all read robots.txt; llms.txt is the emerging convention for AEO discoverability.

## 7. Internal-link audit

Internal links carry roughly half the SEO value on most content sites. If they break during migration, page authority redistributes in ways you didn't plan for.

- Crawl the new site with Screaming Frog. Diff the internal-link graph against the baseline from step 1.
- Investigate every page that lost more than 50% of its inbound internal links.
- Fix any internal links that still point to old URLs. They'll hit the 301 and work, but each one wastes a redirect hop and ages badly.
- Confirm the navigation, footer and contextual link blocks all carry over.

## 8. Image migration

- Move images to your new asset host (Vercel Blob, Cloudinary, Bunny CDN). Don't keep serving from the old WordPress uploads directory after cutover.
- Preserve alt text. The most common regression: a CSV export drops the alt-text column.
- Preserve filenames where possible. Image search ranks partly on filename and surrounding text; renaming `red-shoes-product.jpg` to `image-2347.jpg` resets that signal.
- Use modern formats. AVIF and WebP cut file sizes by 30 to 50% over JPEG with no visible quality loss.
- Configure responsive sizes. Next.js' `<Image>` component handles this; on other stacks you may need to generate the responsive variants explicitly.

## 9. Performance regression check

- Run Lighthouse against the top 10 templates on staging. Compare to the baseline from step 1.
- Watch for Core Web Vitals regressions: LCP, INP, CLS. Cache Components and ISR in Next.js make this much easier; on other stacks, lean on CDN caching and edge rendering.
- Test on real devices and throttled connections, not just your dev machine. Most regressions only surface on mid-range mobile.
- Confirm fonts are preloaded, not loaded asynchronously. A delayed web font is the most common cause of CLS spikes post-migration.

## 10. Staging-to-production cutover

- Launch behind a feature flag, staging subdomain, or DNS-controlled rollout. Don't flip everything at once.
- Have the redirect map already deployed at the edge when DNS flips. The first request to an old URL should 301 cleanly.
- Submit the new sitemap to GSC at the same moment as the DNS flip. Don't wait until the next morning.
- Keep the old site warm for 72 hours after cutover. If something is catastrophically wrong, you want the rollback path to be a DNS change, not a re-deploy.
- Notify any aggregators, syndicators or partners whose feeds point at the old URLs.

## 11. The first 24 hours

- Monitor GSC Coverage hourly for the first six hours. Watch for sudden spikes in 404s, redirect errors or excluded URLs.
- Check Real User Monitoring (Vercel Analytics, Speedcurve, SpeedVitals) for Core Web Vitals on real traffic, not synthetic tests.
- Spot-check 30 redirects manually. The map looked right in the spreadsheet; confirm it behaves right in production.
- Re-validate top-template rich results in GSC. Don't wait for Google to surface the regression.
- Watch your error tracking (Sentry, BugSnag) for any new client-side errors that only manifest in production data.

## 12. The 30-day monitoring window

The first 30 days post-launch are where rankings actually settle. Don't invoice and walk away.

- Daily for the first week: GSC Coverage, top organic page clicks, top organic query positions.
- Weekly for the first month: Ahrefs ranking diff, referring-domain count, organic-traffic trend vs the equivalent pre-launch week, schema validity in GSC Enhancements.
- Investigate any page that loses more than 30% of its organic traffic week-over-week. The fix is almost always one of: missing redirect, missing schema, missing internal link, missing OG image.
- Submit any newly identified ranking pages for re-indexing through the URL Inspection tool.

By day 30, organic traffic should be at parity with pre-launch or growing. If it's down materially, you have a regression to investigate, not seasonality to explain away.

## Optional: GEO and AEO monitoring loop

Everything above protects your organic search position. Increasingly, that's only half the story. Brand visibility inside ChatGPT, Perplexity, Claude and AI Overviews moves on different signals: structured answer-first content, llms.txt, schema enrichment beyond classic rich results, and citation tracking in the LLMs themselves.

Migration cutover is the right moment to re-baseline AI-surface visibility, because the same content reshuffle that affects Google can also affect what LLMs cite. We run this as a parallel loop on every migration where AI traffic matters:

- Publish `llms.txt` at the root with the highest-signal pages surfaced explicitly.
- Set an AI crawler policy in `robots.txt`. GPTBot, ClaudeBot, PerplexityBot, CCBot and Google-Extended are the ones that matter today. Decide allow vs disallow per crawler, not blanket.
- Baseline AI Overview presence for your top 50 queries before cutover. Profound, Otterly, Athena or even manual sampling. Record citation share, position and the URL the AI engine actually links to.
- Track citations weekly in ChatGPT, Perplexity, Claude and Gemini for branded and category queries. Watch for fidelity drift and lost mentions.
- Enrich schema beyond what classic rich results need. FAQPage, HowTo, Article body, Dataset and Quotation schema all feed AI extraction.
- Rewrite top-traffic templates answer-first. A TL;DR, definition or direct answer inside the first 60 words means an LLM can extract without scrolling.
- Expose markdown or plain-text alternates for AI agents. Content negotiation on `Accept: text/markdown` or `.md` mirrors of the highest-value URLs.
- Schedule a 30-day GEO/AEO review post-launch. Compare AI-surface presence pre vs post at the page level, not just at the brand level.

This isn't a one-off task you tick during a migration. It's an ongoing monitoring loop that runs monthly. If you'd rather hand it off than build it in-house, we run it as a service: [generative engine optimisation](/services/geo) for the parallel-search visibility programme and [answer engine optimisation](/services/geo) for the deeper structured-content work.

## When this checklist isn't enough

Two situations need more than a checklist:

**International or multi-language migrations.** Hreflang implementation, regional sitemaps and language-specific content variants add a layer of complexity this list doesn't cover. We treat these as separate engagements with their own pre-launch playbook.

**Headless commerce migrations.** Product pages, variants, collection URLs and stock-status structured data have their own failure modes. The headless Shopify and Sanity work we ship has a parallel checklist focused on commerce-specific schema and category-page parity.

If either of those applies to your migration, talk to us on a [scoping call](/services/cms-migration) before launch. The checklist gets you 80% of the way; the last 20% is where engagement-specific risk lives.

## Use it on your own migration

This checklist is openly published because every migration that gets shipped properly is one fewer migration that has to be recovered later. Save it. Send it to your team. Hand it to the agency you're working with and ask which items they're already covering. If half are missing from their process, that's worth a conversation before contracts get signed.

If you'd rather not run it yourself, [we run CMS migrations](/services/cms-migration) for teams replatforming off WordPress, Webflow, HubSpot CMS, Drupal, Sitecore and Framer onto Sanity or Contentful. Every engagement closes the loop on the 30-day monitoring window, so we see the rankings settle and the regressions surface, not just the launch.

---

## AEO/SEO best practices for Sanity: the Roboto default


> How we structure AEO and SEO on every Sanity build. Fallbacks, JSON-LD, sitemaps, content negotiation, llms.txt, accessibility, and the feedback loop that catches drift.

**TL;DR:** A field guide to the AEO/SEO defaults we ship on every Sanity build. Baseline fields with fallbacks, set-and-forget JSON-LD, freshness signals for AEO, content negotiation for agents, llms.txt, accessibility, and the feedback loop that stops your site drifting into debt.

**Published:** 2026-05-19 | **Updated:** 2026-08-11 | **Categories:** Sanity, How To
---

This entire blog post started out as a response to somebody on Reddit. As any well intentioned, concise response starts out... I started to spiral, and ended up writing a thesis about Sanity AEO/SEO. This is that guide, and this is how you can provide the best possible AEO/SEO for your websites with Sanity.

This post is the opposite of unopinionated. It's the AEO/SEO default we ship on every Sanity project at Roboto, distilled into one place. AEO (answer engine optimisation) and SEO live on the same plumbing, so we treat them as one job: same fields, same JSON-LD, same sitemap, with a couple of extra agent-facing surfaces layered on top. If you want the canonical reference, go and look at [turbo-start-sanity on GitHub](https://github.com/robotostudio/turbo-start-sanity). Three files do most of the work: [packages/sanity/src/query.ts](https://github.com/robotostudio/turbo-start-sanity/blob/main/packages/sanity/src/query.ts), [apps/studio/utils/seo-fields.ts](https://github.com/robotostudio/turbo-start-sanity/blob/main/apps/studio/utils/seo-fields.ts), and [apps/web/src/lib/seo.ts](https://github.com/robotostudio/turbo-start-sanity/blob/main/apps/web/src/lib/seo.ts). Copy from those and you'll have a stronger AEO/SEO baseline than most headless sites.

What follows is the why behind those files, plus the bits that go beyond what fits in a starter repo: content negotiation for agents, llms.txt and sitemap.md, accessibility as a ranking and citation signal, and the feedback loop that stops the whole thing rotting six months after launch. This is the successor to our 2023 post on [SEO tips for Sanity and Next.js](/blog/11-top-tips-for-seo-with-sanity-and-nextjs) and complements our wider takes on headless CMS SEO and [the Next.js AEO/GEO playbook](/blog/nextjs-aeo-geo).

> **Start from turbo-start-sanity**: Our open-source Sanity + Next.js starter with every AEO/SEO pattern in this post wired in by default. [View on GitHub](https://github.com/robotostudio/turbo-start-sanity)

## Why Sanity AEO/SEO feels like a mystery

Sanity will let you model anything. A blog, a 50,000-SKU e-commerce catalogue, a directory of train times for a single terminal at Paddington. The flexibility is brilliant, and it's also why every new team building on Sanity asks the same question on day one: where do I put the meta title, and how do I make sure ChatGPT and Perplexity actually cite this thing?

There's a [Sanity Learn article on SEO](https://www.sanity.io/learn/course/seo-optimization), and a cute guy that wrote it, that covers most information at a basic level. It's worth a read if you've got the time. Most teams don't. What follows is the shorter, more opinionated version. The one we hand to clients and developers who want to ship the AEO/SEO bit and get on with the actual product.

From this point onwards, _just trust me bro_, because we've built too many of these.

## The baseline: title and description on every document

Every document type (page, blog, case study, service, author, whatever) gets two fields at the top: `title` and `description`. These are the editorial defaults. They double as more than just SEO:

- The blog `title` is the H1 on the post and the heading on the listing card
- The blog `description` is the meta description fallback *and* the card blurb on the index page
- The page `title` and `description` follow the same pattern across the page builder

You can layer validation on top of these: minimum length, maximum character count, the little counter underneath the input. We tend not to. Editors find prescriptive character counts annoying, and Google's truncation behaviour shifts often enough that hard limits feel out of date within a year. The fields exist; the editor's responsible for using them sensibly.

## The SEO tab: meta overrides with fallbacks

Beneath the baseline, every document gets an `SEO` tab. Inside it:

- `seoTitle`: overrides the document's title in the `<title>` tag
- `seoDescription`: overrides the description in the meta description
- `seoImage`: overrides the social/Open Graph image
- `seoNoIndex`: boolean, adds the `noindex` meta tag
- `seoHideFromLists`: boolean, excludes the document from internal listings

The bit that makes this work: **the SEO tab fields are overrides, not requirements**. If `seoTitle` is empty, the renderer falls back to the document's `title`. If `seoDescription` is empty, it falls back to `description`. Editors get a consistent surface across every document type, and they only fill in the SEO tab when they need to differentiate the metadata from the visible content.

```typescript
// apps/studio/utils/seo-fields.ts (simplified)
import { defineField } from "sanity";

export const seoFields = [
  defineField({
    name: "seoTitle",
    title: "SEO title",
    type: "string",
    description: "Overrides the page title in the <title> tag. Falls back to the document title.",
  }),
  defineField({
    name: "seoDescription",
    title: "SEO description",
    type: "text",
    rows: 3,
    description: "Overrides the page description in the meta description. Falls back to the document description.",
  }),
  defineField({
    name: "seoImage",
    title: "SEO image",
    type: "image",
    description: "Overrides the social sharing image. Falls back to the document's primary image.",
  }),
  defineField({
    name: "seoNoIndex",
    title: "No index",
    type: "boolean",
    description: "Hides this page from search engines.",
    initialValue: false,
  }),
  defineField({
    name: "seoHideFromLists",
    title: "Hide from lists",
    type: "boolean",
    description: "Hides this page from internal listings (blog index, related posts, etc).",
    initialValue: false,
  }),
];
```

That's the whole setup: spread `...seoFields` into any document schema and you've got a consistent SEO surface across the whole studio.

## Open Graph (and per-network if you really need it)

Open Graph follows the same fallback pattern. `ogTitle`, `ogDescription`, `ogImage`. If they're not set, use the SEO fields. If those aren't set, use the baseline title and description.

If you've got a specific need to differentiate per network (a punchier headline for Twitter, a longer description for LinkedIn), split it into `twitterTitle`, `linkedinTitle`, and so on. Most projects don't need it. Default to one Open Graph block that covers every network, and break it out only when a client specifically asks.

## JSON-LD: set and forget

If there's one thing I can't recommend enough  *set and forget* as much as you can. As soon as you put JSON-LD into a Sanity Studio, you better hope to god you put a validator in there, because I guarantee it's going to be broke within a week flat.

The mistake we see most often: teams add structured data as a separate editor surface. A textarea for JSON-LD, or a schema picker, or a dedicated tab in the studio. Editors are now responsible for filling in a `BlogPosting` schema with author, date, image, headline, duplicating what they've already put into the document. It drifts within a sprint.

The Roboto default: **derive JSON-LD from existing fields, at render time, in code**. Editors enter the data once, in the natural place. The schema generator pulls from those fields and emits the structured data.

```typescript
// apps/web/src/lib/seo.ts (simplified)
export function generateBlogJsonLd(post: BlogPost) {
  return {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.seoTitle ?? post.title,
    description: post.seoDescription ?? post.description,
    image: post.seoImage ?? post.image,
    datePublished: post.publishedAt,
    dateModified: post._updatedAt,
    author: post.authors.map((a) => ({
      "@type": "Person",
      name: a.name,
      url: `https://robotostudio.com/author/${a.slug}`,
      sameAs: [a.linkedin, a.twitter].filter(Boolean),
    })),
    publisher: {
      "@type": "Organization",
      name: "Roboto Studio",
      logo: { "@type": "ImageObject", url: "https://robotostudio.com/logo.png" },
    },
  };
}
```

The whole thing is one helper function. Parity with what's rendered, zero editor work, no drift when content changes. And it's not difficult to scaffold these days. Point any half-decent AI assistant at your document schema and it'll write the generator in one prompt.

The other side of set-and-forget: pull through everything you've already modelled. If you've got author documents with bios and social profiles, push them into the `Person` schema. If you've got categories, emit `BlogPosting.about`. Don't make editors think about it. They've already given you the data.

## `seoNoIndex` and `seoHideFromLists`: why we keep both

These two fields look similar. They do different things.

- `seoNoIndex` adds `<meta name="robots" content="noindex">`. The page is still in the sitemap, still linked from internal navigation, but search engines are told not to index it.
- `seoHideFromLists` is consumed by your GROQ queries. The page is excluded from the blog index, category pages, related-posts blocks, and anything else that lists documents.

Common scenarios where you need both:

- **PPC landing page**: `seoNoIndex: true` so Google doesn't rank it organically, `seoHideFromLists: true` so it doesn't appear on the main blog index. Only people clicking the ad ever see it.
- **Archived blog post**: `seoHideFromLists: true` so it's quietly demoted off the listings, but `seoNoIndex: false` so existing backlinks still hit a valid indexed page.
- **Author-only draft**: both `true` while the post is being reviewed, both flipped when it's ready to ship.

The GROQ pattern looks like this:

```typescript
// packages/sanity/src/query.ts
export const getAllBlogPostsQuery = groq`
  *[_type == "blog" && (seoHideFromLists != true)] | order(publishedAt desc) {
    ...,
  }
`;
```

One line. Editors get a toggle, GROQ does the filtering, the renderer respects the meta. Nothing fancy.

## Sitemaps: cheap wins

The sitemap is the boring infrastructure that most teams set up once and never touch again. A few rules worth getting right:

- **Use `_updatedAt` as `<lastmod>`**, not `_createdAt` or the publish date. Sanity gives you `_updatedAt` for free on every document. Pipe it straight through. This is the freshness signal Googlebot actually cares about in 2026.
- **Generate the sitemap from the same GROQ query that powers the site**, so there's only one source of truth. No drift between what's indexable and what's visible.
- **Respect `seoNoIndex` and `seoHideFromLists`**. Filter them out of the sitemap too. A no-indexed page in your sitemap is a mixed signal.
- **Optional belt-and-braces:** add a `sitemapPriority` field on the document, default `0.7`, bump to `0.9` for cornerstone content. Modern Google largely ignores `<priority>` and `<changefreq>` (they've said so publicly), but it costs nothing to ship and gives editors a lever if they want one.

The honest take: `<lastmod>` is the only sitemap field that genuinely moves the needle today. Get it right and the rest is hygiene.

## Last updated and last published: freshness signals for AEO

Show both dates on every blog post, visibly, at the top:

- `Published: 12 March 2024`
- `Updated: 18 May 2026`

Sanity gives you both for free: `_createdAt` (or your custom `publishedAt`) and `_updatedAt`. Pull them into the byline, render them in the layout, and wire them into the JSON-LD `datePublished` and `dateModified` properties. One source of truth, multiple surfaces, no editor work to keep them in sync.

Why it matters more than it used to:

- **Traditional SEO.** Google's freshness algorithm rewards recently-updated content for query-deserves-freshness topics. Visible dates reinforce what's in the schema.
- **AEO.** ChatGPT, Perplexity, Claude, and Google's AI Overviews all weight recency heavily when picking sources to cite. Two posts answering the same question; yours says "updated last month"; yours wins the citation.
- **User trust.** A 2019 post with no update date reads as stale. A 2019 post updated last month reads as maintained.

The discipline that goes with this: actually update old posts. Refresh the stats, swap stale screenshots, fix broken links, then let `_updatedAt` do its job. Don't fake the date. LLMs are getting better at detecting stale content dressed up as fresh, and Google's always been able to.

## `details` and `summary`: free AEO/SEO and accessibility wins

The [native HTML disclosure widget](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details) is one of the most underused tools in the SEO toolkit. No JavaScript, no library, works in every browser back to 2020.

Why it matters for SEO: content inside `<details>` is fully crawlable and indexable, even when collapsed. Google reads it. So you can hide long FAQ answers, technical specifications, or "read more" sections without losing keyword surface area.

Why it matters for UX: shorter perceived page length, lower bounce on long-form content, and it's a real focusable, keyboard-accessible element out of the box. No `aria-expanded` plumbing required.

Where to use it in a Sanity-driven site:

- FAQ blocks. Pair with FAQ JSON-LD and you get rich results *and* a clean UI.
- Long product spec tables
- "What we did" sections on case studies
- Footnotes and references on blog posts

The trap: don't hide your H1, primary value proposition, or first paragraph inside a `<details>`. Google indexes the content, but ranks visible-by-default content higher. Use disclosures for *supporting* material, not core material.

Implementation note: in your Portable Text serializer or MDX components, expose it as a "collapsible section" block. Editors get a button in the studio; developers get semantic HTML in the output.

## Content negotiation: serve markdown to agents by default

[Vercel published a pattern recently](https://vercel.com/blog/making-agent-friendly-pages-with-content-negotiation) that's worth shipping on every Sanity build: when an agent sends `Accept: text/markdown, text/html, */*`, return clean markdown instead of the HTML page. Same URL, dramatically smaller payload. Their example: 500KB of HTML compressed to 3KB of markdown. A 99% reduction. We've written about why this matters in more depth in [our Next.js AEO/GEO guide](/blog/nextjs-aeo-geo).

Why this matters for AEO right now: agents burn tokens on HTML noise. Nav, footers, scripts, classNames, hydration payloads. Hand them markdown and they ingest the actual content. More content per request, cleaner citations, better odds of being picked as a source.

How it works in Next.js:

- A rewrite rule in `next.config.ts` detects the markdown `Accept` header and routes the request to a dedicated markdown endpoint
- The route handler returns the body with `Content-Type: text/markdown`
- Both endpoints pull from the same Sanity GROQ query, so there's no drift between what HTML readers see and what agents consume

One thing NOT to do: markdown pair routes, where every page gets a separate `.md` twin URL (`/blog/post` plus `/blog/post.md`). [Google's generative AI guidance](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) says you don't need markdown versions of pages, John Mueller called the idea ["such a stupid idea"](https://searchengineland.com/google-bing-dont-recommend-seperate-markdown-pages-for-llms-468365), and Bing's Fabrice Canel pointed out the real cost: duplicate URLs double your crawl load, because Bing crawls the twins anyway to check similarity. Content negotiation avoids all of that. The markdown lives at the canonical URL; no second URL exists for crawlers to waste budget on.

Two discovery aids to ship alongside it:

- A `<link rel="alternate" type="text/markdown" href="/llms.txt" />` tag in your HTML head for agents that don't send the `Accept` header
- A `/sitemap.md` alongside `/sitemap.xml`, giving agents a structured markdown index they can navigate

Wire this into every project from day one. It's a one-time setup that future-proofs the site as agent traffic keeps growing. Cheap to add now, expensive to retrofit later when half your traffic is bots that can't see your content.

## `llms.txt` and `sitemap.md`: yes, agents read them

There's a tedious crowd online insisting `llms.txt` is "made up" or that "no AI reads it." They're wrong about the reading. They're right that it won't grow your traffic, and those two claims get conflated constantly.

- **What `llms.txt` is.** A markdown file at the root of your site (`/llms.txt`) that gives agents a curated, structured index of your most important content. Titles, descriptions, links. Think of it as a hand-picked sitemap optimised for LLM consumption rather than crawler discovery.
- **What `sitemap.md` is.** The same idea but mirroring your full `sitemap.xml`. A markdown version of every indexable URL with titles and hierarchy. Agents traverse it instead of parsing XML.
- **Who reads them.** Anthropic's web fetcher consumes them. Perplexity's crawler does. Agents built on the Vercel AI SDK do. ChatGPT's browse tool uses them when you point it at a URL. Every coding agent (Cursor, Claude Code, Codex) pulls them when you point it at docs. The pattern is spreading fast. Stripe, Anthropic, Vercel, Cloudflare, and Sanity itself all ship them.

The cost to ship is one route handler and a GROQ query, so ship it. Just expect nothing back: Google Search has said it doesn't use the file and has no plans to, and nobody has shown it earns a citation. It's a courtesy index for agents already pointed at your domain, not a growth lever.

How to wire it up in Sanity:

- `/llms.txt`: hand-pick your top docs, pages, and guides. Group by section. Render from a dedicated GROQ query so editors can flag content for inclusion with a `featuredForLLM` boolean.
- `/sitemap.md`: derive it from the same query as `sitemap.xml`, with the same filters, rendered as markdown instead of XML.
- Both are static markdown responses. Cheap to serve, cacheable forever, easy to regenerate.

Don't overthink it. A 100-line file beats a 0-line file every time. Ship something, iterate.

## Image SEO from the Sanity pipeline

Sanity's image handling is one of the best parts of the stack, and most teams don't use it properly.

**Alt text lives on the asset, not the usage.** Install [sanity-plugin-media](https://www.sanity.io/plugins/sanity-plugin-media). It gives you a proper asset library inside the studio where editors can set alt text, title, tags, and credits *on the image itself*. Set it once, every usage across every document inherits it. No more wondering whether the editor remembered to write alt text on the card variant. It's hoisted onto the asset.

The compounding win: when you eventually swap out a hero image, the new asset already has alt text from the upload. Editors fill it in once, at the source of truth.

A few more rules:

- **Require alt text at upload.** Wire it as a required field in the plugin config so editors can't physically upload without it.
- **Filename hygiene at upload.** `hero-blog-seo-best-practices.png`, not `IMG_3421.png`. Google reads filenames as a weak ranking signal. LLMs absolutely do.

**The banger combo: Sanity's image pipeline plus `next/image`.** This is the move:

- Sanity's CDN handles transforms. `?w=800&fm=webp&q=80` gives you any size, any format, on demand.
- `next/image` consumes those URLs and emits a proper `srcset` for every breakpoint.
- You get responsive images, automatic AVIF/WebP, lazy loading, blur placeholders (from Sanity's LQIP), and zero CLS, all from a single `<SanityImage>` component.

Compared to hand-rolling `<picture>` elements with `<source>` tags for every breakpoint? Not even close. Write the component once, ship it everywhere, the pipeline does the rest.

- **`priority` on the LCP image** (hero, above the fold). Lazy on everything else. Next handles both with a single prop.
- **Explicit width and height.** Sanity gives you the asset dimensions for free via `asset->metadata.dimensions`. Pipe them straight into `next/image` to lock the aspect ratio and prevent CLS.
- **Preload the LCP image** in `<head>` when it's an above-the-fold hero. Next does this automatically when you set `priority`.

## Accessibility is AEO/SEO

This deserves its own section because most teams treat accessibility as an afterthought, when the same semantics that help a screen reader are what an agent parses.

Google has been candid that accessibility signals feed Core Web Vitals and ranking. Screen-reader-friendly markup is also LLM-friendly markup, since agents parse semantic HTML the same way assistive tech does. So when you optimise for accessibility, you're optimising for traditional SEO and AEO at the same time.

The non-negotiables on every Sanity build:

- **Required `alt` text at the asset level** (covered above). Make it physically impossible to upload without one.
- **Heading hierarchy is sacrosanct.** One H1 per page (the document title). H2 for sections. No skipping levels, no decorative H1s in the page builder. Validate it in Portable Text serializers: strip or downgrade any H1s authored inside rich text.
- **Semantic landmarks.** `<main>`, `<nav>`, `<article>`, `<aside>`, `<footer>`. Not `<div>`s with `role` attributes.
- **Focus states**: visible, high-contrast. Tailwind's default `focus-visible:` ring is fine. Don't disable it for aesthetics.
- **Colour contrast**: 4.5:1 for body text, 3:1 for large text. Build it into the design tokens.
- **Skip links** at the top of every layout. Keyboard users and screen readers both benefit.
- **Form labels**: every input wired to a `<label>`. Placeholder text is not a label.
- **`prefers-reduced-motion`**: respect it in your Motion for React components. Wrap big animated sections in a conditional that disables motion when the OS preference is set.

The payoff: Lighthouse accessibility scores correlate with rankings, AEO tools weight clean semantic structure when extracting answers for citations, and you stop excluding users who can't navigate poorly-built sites. Every box gets ticked at once.

## Internal linking discipline

Internal links are the cheapest ranking lever you have. The Roboto default:

- **Custom link annotations in Portable Text.** Internal links are *references*, not strings. When a slug changes, the link follows. No 404 link rot, ever.
- **Programmatic related-posts** from shared categories or tags. Don't ask editors to hand-pick three related links on every post; derive them from the data they've already entered.
- **Breadcrumbs derived from URL structure**, with `BreadcrumbList` JSON-LD attached.
- **Three internal links per blog post is a sensible baseline.** Editors should be linking *inside* prose, not just on related-content cards. If a post has zero internal links in the body, something's wrong with either the post or the rest of the site. For AEO-focused builds, linking from relevant posts into our [AEO agency](/services/geo) page is the kind of contextual internal link that compounds over time.

## Canonical URLs

- Self-referencing canonical on every page by default
- An `seoCanonical` override field for syndicated content (cross-posted to Medium? Point canonical back to your domain)
- Strip query params from canonicals: UTM tags should not dilute your canonical signal

This is a ten-line helper in `apps/web/src/lib/seo.ts`. Most projects never need to touch the override; it's there for the day a client cross-posts a thought leadership piece.

## Redirects as a Sanity document type

When editors change a slug, never leave the old URL dead. The Roboto stack handles this with a `redirect` document type. Old slug, new slug, automatic.

- The redirect schema is surfaced in the studio sidebar, so editors own it without dev intervention
- The list of redirects is queried at build time and piped into `next.config.ts` (or middleware for high-volume sites)
- For projects with hundreds of historical redirects, batch them. Don't expand the middleware on every request.

The wider point: SEO equity is fragile. Years of backlinks evaporate the moment a URL 404s. A redirect document type costs about an hour to build and protects the site indefinitely.

## Author entities and E-E-A-T

Every author gets a proper `Author` document type with:

- A bio (used in the byline and on the author archive page)
- A photo (used in the byline and on the author card)
- Social profiles (LinkedIn, Twitter, GitHub, personal site)
- Position and credentials

Why bother:

- Author bylines render a `Person` JSON-LD that Google reads for expertise signals. E-E-A-T is real, and identified authors carry more weight than anonymous content.
- Author archive pages (`/author/jono-alford`) collect every post, building topical authority and giving Google a clear signal about who writes about what.
- LLMs cite authors when they can identify them. Anonymous content gets cited less, especially for opinion-led topics where attribution matters.

This is the same set-and-forget principle from JSON-LD. Editors fill in the author document once. Every post by that author inherits the bio, the photo, the schema, the social links.

## Schema beyond `BlogPosting`

`BlogPosting` is the obvious one. Don't stop there. On every Sanity build we tend to wire up:

- `Organization` once, in the root layout
- `BreadcrumbList` on every nested page
- `FAQPage` when a block has FAQs (this post has one, look at the source)
- `HowTo` for tutorials with clear steps
- `Product` or `Service` on service pages
- `Person` for author bylines

All derived from existing Sanity content. Editors never touch schema markup. It's just generated.

## Robots and the boring infrastructure

The unglamorous stuff that bites you when it breaks:

- **`robots.txt`** generated from Sanity site config, not hardcoded. That way you can toggle staging vs prod indexing without a deploy: flip a boolean in the studio, redeploy if needed, done.
- **404 pages** with real internal links (popular posts, search, primary nav). Not a dead end. Genuinely useful 404 pages reduce bounce and recover SEO equity from broken inbound links.
- **Never serve 200 OK on "not found" content.** Use Next's `notFound()` properly. Soft 404s are one of the worst ranking signals you can send and Google is increasingly aggressive about flagging them.

## Open Graph image fallback generator

Editors are inconsistent about uploading social images. The fix: give them a default the moment the document is created, *and* generate one at render time when the slot is empty.

**Default at document creation.** Sanity's `initialValue` on the schema lets you pre-populate the `ogImage` field with a templated asset when a new document is created. Editors open a fresh blog post and there's already a usable OG image sitting in the slot. Most won't touch it; the few who care will override it. Either way you've removed the empty state.

```typescript
// apps/studio/schemaTypes/documents/blog.ts (simplified)
defineField({
  name: "ogImage",
  title: "OG image",
  type: "image",
  description: "Social sharing image. Defaults to a branded template; override when you want something custom.",
  initialValue: {
    _type: "image",
    asset: {
      _type: "reference",
      _ref: "image-default-og-blog-1200x630-png", // pre-uploaded brand template
    },
  },
}),
```

**Render-time fallback.** Use [`next/og`](https://vercel.com/docs/og-image-generation) to auto-generate a branded OG image from the document title when `ogImage` is still empty (or when you want a per-post variant). Brand-consistent template, always fresh, zero editor burden. Cache it aggressively: the URL is deterministic from the slug, so it never needs to regenerate after the first request.

The same set-and-forget principle, applied to social previews. Editors who care can override; editors who don't get something usable by default, both at creation time and at render time.

## AEO/SEO sanitisation: catch the drift before it eats you

Here's what happens on every codebase, including ones built by people who know better. You ship fast. You vibe-code a few sections. You let a junior developer wire up a new page builder block. You copy-paste a layout. The SEO debt piles up. Heading hierarchy is broken on three templates. Half your pages have duplicate H1s. The new "featured grid" component renders product titles as `<div>` because someone forgot. Meta descriptions are getting truncated. Four hundred pages share the same `og:image`.

You won't catch this by eyeballing the site. You need a feedback loop.

**Run a crawl weekly.** [Screaming Frog](https://www.screamingfrog.co.uk/seo-spider/) or [Sitebulb](https://sitebulb.com/) against prod. Export the issues, triage the top ten. Every Roboto client site has one of these running, and it surfaces things humans miss every single time: orphan pages, broken internal links, missing alt text, oversized HTML, redirect chains, duplicate titles. The licence pays for itself in one engagement.

**Wire it into Linear.** When the crawl finds issues, dump them into tickets with an `seo-debt` label. Treat them like bugs, not "nice to have."

**CI-level guards for the cheap ones:**

- Lint rule: no `<h1>` inside Portable Text serializers (only the page title gets H1)
- Test: every page returns a `<title>`, `<meta name="description">`, `<link rel="canonical">`, and an `og:image`
- Test: no `console.log` in production, no stray `noindex` in prod headers (you'd be amazed how often this ships)
- Test: `sitemap.xml` returns 200 and contains every published document

**Lighthouse CI on every PR.** Fail the build if accessibility drops below 95 or SEO drops below 100. Don't let regressions land. Catch them at the PR, not after deploy.

**Vibe coding is fine. Vibe coding without guardrails is what kills you.**

Shipping fast is genuinely good. Half the SEO patterns in this post exist because we vibed our way through a problem on a client project and codified what worked. The fix isn't to slow down, it's to set up validation that runs at the speed you're shipping.

The pattern we run on most projects now:

- **Wire up an agent that audits your site continuously.** [Vercel AI SDK](https://ai-sdk.dev/) makes this trivially cheap to build: a scheduled function, a couple of tool calls (fetch the page, parse the head, check the schema), and a structured output that flags regressions. We've got one running against robotostudio.com on a cron, and it catches things humans miss between deploys.
- **Validation at the schema level.** If a page builder block requires a heading, a [Zod](https://zod.dev/) schema or a Sanity validation rule should reject it without one. Don't let bad data ship and then fix it downstream.
- **Validation at the PR level.** Lighthouse CI, a Screaming Frog programmatic crawl, or an AI SDK script that diffs the rendered HTML against last week's. Anything that fails the build before merge.
- **Validation at the runtime level.** Log SEO-critical fields to PostHog or Sentry. If a page renders without a `<title>` or with a duplicate H1, you want to know about it the moment it happens, not next quarter.

The honest take: every shortcut you take to ship (the inline component, the hardcoded string, the "I'll fix the schema later") compounds. SEO debt looks invisible until you check Search Console and realise you've been bleeding impressions for two months. AI-driven validation is the cheapest way to keep moving fast without paying for it later.

What "good" looks like: zero critical Screaming Frog issues, Lighthouse SEO 100 on every template, an AI audit agent that catches drift before you do. If your manual audit surfaces surprises, your validation is broken. Fix the validation first, not just the surprises.

## Where to copy this from

The whole pattern is open source. Go to [turbo-start-sanity on GitHub](https://github.com/robotostudio/turbo-start-sanity). Open these three files:

- [packages/sanity/src/query.ts](https://github.com/robotostudio/turbo-start-sanity/blob/main/packages/sanity/src/query.ts): the GROQ queries with SEO filtering baked in
- [apps/studio/utils/seo-fields.ts](https://github.com/robotostudio/turbo-start-sanity/blob/main/apps/studio/utils/seo-fields.ts): the reusable SEO fields object
- [apps/web/src/lib/seo.ts](https://github.com/robotostudio/turbo-start-sanity/blob/main/apps/web/src/lib/seo.ts): the metadata generator and JSON-LD helpers

Copy them, adapt them, ship them. That's the entire AEO/SEO baseline for a Sanity project. Everything else in this post (content negotiation, `llms.txt`, accessibility, the sanitisation loop) is incremental. The three files above are the foundation.

If you're starting a new Sanity build, start there. If you've inherited an existing build and the AEO/SEO feels patchy, those three files are your refactor target.

> **Stuck on AEO/SEO for your Sanity build?**: We help teams audit and rebuild their Sanity AEO/SEO so they stop bleeding impressions and start showing up in AI answers. Drop us a line. [Get in touch](/contact)

---

## Our DeepSec audit and the future of infosec agents


> We pointed Vercel's DeepSec at our own site. Real timings, real token burn, real findings, and why agentic infosec is about to feel normal.

**TL;DR:** We pointed Vercel's DeepSec at our own production codebase. Here's the unedited play-by-play: how long it took, how many tokens it burned, what it actually found, and why scanning your own code with an agent is about to feel as routine as turning on Speed Insights.

**Published:** 2026-05-14 | **Updated:** 2026-08-24 | **Categories:** AI, Vercel
---

We ran Vercel Labs' new DeepSec against the codebase that powers this site. 176 files, 32 minutes of agent wall-clock, $43 in tokens, 17 confirmed findings worth fixing.

Below: the full run, the install-step gotcha that nearly ended the experiment ten minutes in, and what this workflow suggests about where security tooling goes next.

## What is DeepSec?

DeepSec is an open-source security harness, [announced by Vercel Labs](https://vercel.com/blog/introducing-deepsec-find-and-fix-vulnerabilities-in-your-code-base) and powered by coding agents. The pitch is short: instead of running pattern-matching SAST tools that surface a thousand "consider validating this" suggestions, you let an agent read your code, trace data flows, and tell you what's actually wrong.

It runs on your own infrastructure. Your code never leaves the box. The only thing that crosses the wire is the agent's reasoning, sent to whatever model provider you've configured. For most teams that's not new risk. If Cursor or Claude Code already touches your code, DeepSec is in the same trust bucket.

The core pipeline has five stages and they are worth knowing because each one represents a decision the team made about where agents are good and where they aren't:

1. **Scan**: fast regex over the repo, picking out files that touch security-sensitive surfaces. No agent. No cost. Just a list.
2. **Process**: an agent reads each flagged file, follows the data, checks for mitigations. This is where most of the token spend goes. (DeepSec's docs call this stage `process`; we'll use that name from here on.)
3. **Revalidate**: a second agent reviews the first agent's findings to kill false positives and re-rate severity. The model arguing with itself, basically.
4. **Enrich**: git blame metadata gets attached to each finding, so when you import them downstream you know who wrote the offending lines. *Doubles as a starter list for the next round of layoffs.*
5. **Export**: markdown or JSON output, one file per finding or one big blob. Conversion into Linear tickets or GitHub Issues is on you, but the format is clean enough to script.

There's also an optional `triage` step that uses a cheaper model (`claude-sonnet-4-6` by default) to assign P0/P1/P2 priority before revalidation. We skipped it on this run and revalidated everything directly. Worth knowing it exists if your scan returns hundreds of findings and you want a cheap pre-sort.

The interesting bit is revalidation. The whole reason agentic SAST is plausible now and wasn't two years ago is that models are good enough to grade their own homework. Without revalidation you'd drown in the same noise that tanked every traditional SAST product.

One note on backends before we get into the run: we used DeepSec's default, Codex (`gpt-5.5`), because we wanted to see how OpenAI's coding agent reasoned about our code under the standard configuration. Claude is a first-class alternative via `--agent claude`. Pick the one your team is most comfortable with the data policy of, or front the whole thing with Vercel AI Gateway and stop worrying about either of them.

## Getting it running

We were on `npx deepsec init` to a finished report in roughly 25 minutes end-to-end. The setup itself took us less than 10 minutes, most of which was an agent reading our `CLAUDE.md` and a handful of representative files to fill in the project context document DeepSec injects into every batch.

```bash
npx deepsec init
```

That command drops a `.deepsec/` directory into your repo. Inside you get a config file (`deepsec.config.ts`), a default matcher pack, an `INFO.md` for project context, a `SETUP.md` walkthrough, and (importantly) its own `package.json` and `node_modules`. The `.deepsec/` directory is a self-contained pnpm workspace. You have to `cd` into it and run `pnpm install` before any of the CLI commands work.

```bash
cd .deepsec && pnpm install
```

We nearly screwed this up. First pass, we ran the scan command from the repo root, got a confusing error about a missing module, and spent ten minutes assuming our Node version was wrong. Re-read the README, spotted the install step, and everything worked. We chalk it up to the [trace lead in our Stanley cups](https://www.cnn.com/2024/01/26/health/stanley-cups-lead-wellness) finally catching up with us. Anyone who has set up ESLint or Biome will recognise the shape of the config once you're inside: opinionated defaults, escape hatches for when you don't like them. But the workspace-inside-a-workspace bit is a sharp edge for a quick-start.

The actual run is three commands, not one:

```bash
pnpm deepsec scan       # regex pre-filter; free and instant
pnpm deepsec process    # agent investigation; where the token spend lives
pnpm deepsec revalidate # second-agent review of the findings
```

A handful of `process` batches errored partway through (the Codex SDK occasionally drops a long-running session) and DeepSec marked those files for retry on the next pass. We re-ran `process` a second time, picked up most of the dropped files in another five minutes, and a small remainder are still tagged for the next run. The feedback loop is fast even when something breaks: failed batches are isolated, the rest of the run keeps going, and a re-run picks up exactly where it left off without re-spending tokens on files that already passed.

Then we walked away.

## The run, by the numbers

The whole thing took about 32 minutes of AI wall-clock, but it isn't spread evenly across the stages. Most of the time sits in one place. Here's the breakdown:

| stage | Minutes |
| --- | --- |
| Process (initial) | 18.5 |
| Process (retry) | 5.2 |
| Revalidate | 8.3 |

*Where the 32 minutes went. Wall-clock minutes per stage on the robotostudio.com run. Regex scan omitted: it finished in 1.2 seconds, indistinguishable from zero at this scale.*

Read this as "where the agent budget goes":

- **Process (initial)** is the heavyweight stage. The first agent reads every flagged file, traces data flows, and decides whether each regex hit is actually exploitable. 18.5 minutes, ~58% of the total wall-clock.
- **Process (retry)** is a second pass DeepSec ran automatically for batches that got dropped mid-session (Codex SDK timeouts, mostly). A 5-minute mop-up on top of the initial run.
- **Revalidate** is the second agent reviewing the first agent's findings to cull false positives and re-rate severity. 8.3 minutes, and the only reason the noise stays manageable.

The shape is the takeaway: more than two-thirds of the wall-clock is the initial AI investigation, and revalidation costs another third on top of process (about a sixth in dollars). If you wanted to halve a future run, the lever is parallelism on `process` (Vercel Sandboxes, mostly), not skipping `revalidate`.

| Metric | Value |
| --- | --- |
| Wall-clock duration | ~32 minutes across process + retry + revalidate; regex scan was effectively instant |
| Files scanned (regex stage) | 176 |
| Files processed (agent stage) | 171 (5 still pending retry) |
| Process tokens consumed | ~386,000 |
| Approximate cost (USD) | $42.51 ($34.23 process + $2.72 retry + $5.56 revalidate) |
| Findings (raw) | 25 |
| Findings revalidated | 19 of 25 (17 confirmed, 1 false positive, 1 uncertain) |
| Model used | `gpt-5.5` (OpenAI Codex), 150 max turns per batch |

### The funnel that matters

The numbers above are inputs and outputs, but the bit worth dwelling on is what happens between them. Here is the noise-reduction in one table:

| Stage | What it produces | Count |
| --- | --- | --- |
| Regex scan | Raw pattern matches | 349 |
| Process | Findings worth reading | 25 |
| Revalidate | Confirmed true positives | 17 |

That is a 95% reduction from "things to look at" to "things to actually fix". Every traditional SAST tool we have ever used stops at column one: you get the 349, you scroll, you give up. The agent stages are doing the work that a human would otherwise have to do by hand: opening each match, reading the surrounding code, asking "is this actually exploitable in this application?", and only escalating if the answer is yes.

### Cost per actual finding

If you divide $42.51 by 17 confirmed findings you get **about $2.50 per real bug found**, or **$8.50 per HIGH-severity vulnerability**. We are not going to pretend that maps cleanly to "human security engineer hour" (the comparison is unfair to humans, who can probe live systems and reason about business logic). The equivalent flesh API charges by the hour, ships nothing on weekends, and keeps asking for dental. But as a number to put in front of someone who needs to approve a security budget, it lands. Most engineering teams will not blink at $40 to remove a class of risk from their codebase.

### A few caveats

The token bill is not nothing. This is not the kind of tool you point at a five-million-line monorepo on a whim. But for a typical SaaS or marketing site (a few hundred files of meaningful application code) the cost lands somewhere between "a coffee" and "a team lunch". That's a price most teams will happily pay quarterly. Or weekly, if it actually catches things.

The wall-clock time matters less than you'd think. 32 minutes across all three AI stages is short enough to fit in a long lunch and long enough to do something useful with the screen first. If you scale across Vercel Sandboxes you can collapse this further (Vercel's own benchmarks claim 1,000+ concurrent sandboxes for large monorepos), but for a repo of this size sequential was fine.

One last thing on cost: if you're paying flat-rate for a coding agent (ChatGPT Pro, Cursor, whatever), rinse it while you can. We're still at the ["money printer goes brrr"](https://www.youtube.com/watch?v=WEMCYBPUR00) stage of AI funding, where the per-token rate on your receipt is subsidised by the next round and not by gross margin. Today's $43 scan is tomorrow's $200 invoice. Run it now, often, and on everything you can justify.

## What it actually found

This is the part everyone wants to read. We're not going to enumerate the individual findings. A list of issues with file paths next to them isn't a great look on a public blog. What we will share is the shape, both before and after revalidation:

| Severity | Count |
| --- | --- |
| CRITICAL | 0 |
| HIGH | 5 |
| MEDIUM | 11 |
| BUG (non-security correctness) | 9 |
| **Total** | **25** |

The post-revalidation breakdown (19 of 25 findings re-checked by a fresh agent):

| Verdict | Count |
| --- | --- |
| Confirmed true positive | 17 |
| Demoted to false positive | 1 |
| Uncertain / needs human review | 1 |
| Not yet revalidated | 6 |

A few notes on the shape:

- **Zero criticals.** Relief, but not surprising. This is a marketing site with a small image-generation API attached, not a fintech backend. The realistic threat surface for a site like this is the usual marketing-site shape: input handling at the edges, abuse-resistance on anything that costs money to invoke, and the standard web hygiene checklist.
- **The HIGHs were the interesting ones.** Several were the kind of finding a generic SAST tool can't produce: places where the agent had read our threat model and could reason about whether the code matched it.
- **The BUGs were a bonus.** DeepSec's matchers caught non-security correctness issues as a side effect: a React correctness issue, a couple of latent footguns in helpers, and a caching choice that needed tightening up. None would have shipped a vulnerability, but all are worth fixing. Four of these started life classified as MEDIUM and got correctly downgraded by the revalidation pass.
- **One false positive in 19.** That's roughly 5%. Vercel's launch blog quotes a "roughly 10–20%" false positive rate, and the current repo FAQ refines that to "~10–29% on `HIGH+` after revalidation". Either way our 5% is at the low end, and the one miss was defensible rather than garbage: the agent had identified a pattern that *would* be a vulnerability if our specific application context were different. That kind of failure mode is actually useful. It surfaces the assumptions you're relying on, even when they're correct.

There were findings worth fixing, and we worked through them. I suspect we're going to run this every time I get nervous looking at a spend cap.

## The wizard parallel

If you've used Vercel's [Speed Insights](https://vercel.com/docs/speed-insights) you've already seen the new shape of this. You click a button. An agent reads your codebase. It figures out the changes needed to wire up the tracking. It opens a PR. You review and merge.

You did not write any code. You did not edit any config. You did not even open the file. The tool decided what needed to happen, did it, and asked for permission to apply.

DeepSec applies the same move to security: an agent pointed at your repo, looking for class of issue X, returning a PR that fixes class of issue X. Today the issue is "missing performance tracking" or "unsafe data flow". Tomorrow it's "missing observability", "unhandled errors", "unindexed database queries", "missing rate limits", "leaking PII in logs".

The key shift is that the *user experience* of fixing things is no longer "read a report, write code, send a PR." It's "describe the class of problem, approve a PR." The work moves from doing the change to deciding which changes to accept.

This is going to be the dominant pattern for a long, boring tail of engineering tasks that nobody enjoys doing. Security audits. Dependency upgrades. Observability instrumentation. Migration from one library to another. Anything where the rules are well-known but the work is mechanical.

## Where this lands in 12–24 months

A few predictions, loosely held:

**1. Security scans become CI lint.** Right now you run DeepSec when you remember to. In a year, you'll run it on every push, the same way you run your linter and your typechecker. The cost will halve at least once between now and then. The latency will collapse via parallel execution. There will be no reason not to.

**2. Vulnerability triage becomes a queue.** Like dependabot for security findings. The agent opens a PR with a fix; you review and merge or reject. The bottleneck stops being "did anyone scan?" and becomes "did anyone read the PRs?", which is a much better problem to have.

**3. Pen-tests don't go away, they get more expensive.** A human red-teamer is now competing with an agent that's already found the easy stuff. Their value goes up because they're working on the problems agents can't touch: chained exploits, business logic flaws, social engineering vectors, infrastructure-level attacks. They charge more per engagement and do fewer of them.

**4. The "we'll get to it after launch" phase ends.** Teams don't suddenly become disciplined. The marginal cost of doing a security review just approaches zero, and skipping something with marginal cost zero starts to look genuinely negligent.

**5. Agentic tools eat the consultancy bottom of the market.** This is the uncomfortable one. There is a whole tier of security agencies whose entire value proposition is "we will run a tool against your code and write up the output." That tier is on borrowed time. The tools are now the users of the tools, and they don't bill by the hour.

We're in the awkward early phase where the tools work but the workflow hasn't caught up. The DX still feels like running a build tool. In a year it will feel like opening a tab in your IDE. In two years it will feel like nothing: invisible, ambient, on-by-default.

> **Want a security review on your stack?**: We've been pointing agents at production codebases since DeepSec dropped. If you'd like a second opinion on yours, drop us a line. [Get in touch](/contact)

## What to take away

Strip everything else and the numbers we keep coming back to are these: $43 for a full scan of 176 files, 32 minutes wall-clock, 5% false positives against the 10–20% Vercel publishes. Incremental PR scans via `--diff` cost pennies, so cost stopped being the reason not to scan. Those are nice. They aren't the point.

The point is that `INFO.md` works. Two paragraphs of plain English describing your threat model and intended posture, and the agent grades the code against them on every run. The agent's findings tracked the concerns we'd written into our threat model, which is the part no pattern matcher can do, no matter how many years of CWE rules it's accumulated.

And the CI integration is a one-liner. `npx deepsec process --diff origin/main` next to your typecheck step and you have an agentic security gate on every PR. That's the workflow change worth caring about. The next decade of "run a SAST tool, ignore the giant report" is being replaced by "review an agent's PR", and that workflow will eat its way through dependency upgrades, observability instrumentation, accessibility cleanups, and the rest of the long tail of work nobody wants to do by hand.

## What we're doing about it

A few concrete things, since this is a Roboto Studio blog and not a futurism column:

- **Adding DeepSec to our pre-launch checklist.** Every client project now ships with at least one full DeepSec run before launch and a baseline report stored alongside the project handover docs.
- **Building a custom matcher pack for Sanity + Next.js.** Our day-to-day stack has a recognisable shape: Sanity GROQ queries, server actions, validated env via `@t3-oss/env`, Next.js route handlers. DeepSec's plugin system means we can encode our own conventions as matchers, so the agent doesn't waste cycles re-discovering them on every project.
- **Sharing the pre-launch report with clients.** Same way we share Lighthouse and accessibility audits today. Clients should not have to take "yes, it's secure" on faith.

If you're running a Next.js application of any meaningful size, DeepSec is worth the 32 minutes and the $43. It's not perfect. The false positive rate is real, the setup has a few sharp edges. But it's the first agentic SAST tool we've used that we'd genuinely point at production code without flinching.

The bigger story is the workflow DeepSec represents. An agent read our threat model, opened the relevant files, and graded the code against the stated intent. That has never been possible before. Click a button. Agent reads your code. PR shows up in your queue. Review and merge.

That is going to be the default way you maintain software. We are watching it happen in real time.

> **We build agentic workflows for teams**: Background agents, automated pipelines, and custom tooling built around how your team actually works. [See our agentic workflows service](/services/agentic-workflows)

## A note on the methodology

For full transparency: we ran DeepSec against the `main` branch of this site in early May 2026. The repo is a pnpm monorepo with our Next.js app and a small image generation API. 176 source files survived DeepSec's regex pre-filter, and 171 of those completed the `process` (agent investigation) stage across two passes (5 are still tagged for the next retry). We then ran `revalidate` to re-check the resulting findings; 19 of 25 were re-evaluated by a fresh agent (17 confirmed, 1 demoted to false positive, 1 marked uncertain). We used the default matcher pack with a hand-written `INFO.md` describing the project context DeepSec injects into every batch. We did not run with parallel sandboxes: single sequential run, default concurrency, locally. The model was `gpt-5.5` via OpenAI's Codex SDK with a 150-turn budget per batch (that turn count is DeepSec's default at the time of writing). We stuck with DeepSec's out-of-the-box default backend, Codex (`gpt-5.5`); Claude is available via `--agent claude` if you'd rather run that side by side.

If you want to compare notes on a run of your own, or tell us we got the false-positive maths wrong, we'd love to hear about it.

---

## Automate Sanity page builder thumbnails with Claude Code


> Generate Sanity insertMenu thumbnails automatically with a Claude Code skill. Five to seven minutes per project, no Figma, no manual screenshotting.

**TL;DR:** We built a Claude Code skill that handles the entire page builder thumbnail workflow for you. Run it once, walk away for five to seven minutes, come back to a fresh set of thumbnails on every block.

**Published:** 2026-05-09 | **Updated:** 2026-07-23 | **Categories:** How To, Sanity, AI
---

Page builder thumbnails are one of those jobs nobody wants to own. Every time you ship a new block, you owe yourself another little screenshot at the right aspect ratio, dropped into the right slot in the schema, named the right thing in your CDN. Multiply that by twenty blocks across five projects and you're losing a real day to it every quarter.

We've written about this before. [Our last post](/blog/creating-the-perfect-array-thumbnail) shipped a [Figma community file](https://www.figma.com/community/file/1404904715260176924/arrayfield-template-for-sanity) with a 3:2 template to paste screenshots into. It's still a useful tool if you want to art-direct the result, but it's still you doing the work and the work itself is more painful than it looks. Skipping it isn't really an option, either, these small editorial polish moments are what make the CMS feel built-for-purpose to your client.

This post is the next step. We've built a Claude Code skill that handles the whole flow agentically, from reading your schema to uploading the final WebP files into your project. You run one prompt, wait five to seven minutes, and come back to a finished set of thumbnails.

## What page builder thumbnails are for

Page builder thumbnails show editors what's in each block before they add it to the page. The picker - Sanity calls it the `insertMenu` - is a grid of these previews on every page builder array in Sanity Studio v3 or v4. By default it's Sanity's stock icons. Fine in dev. Slightly grim once a client logs in. Real thumbnails turn the picker from a developer tool into a design one.

Polished thumbnails let editors visualise a block before they build with it:

![Sanity page builder insertMenu showing polished thumbnails for each block type](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/automate-sanity-thumbnails-blog-page-builder-insertmenu.png)

The setup looks like this in your schema:

```ts
defineField({
  name: "pageBuilder",
  type: "array",
  of: [/* your block types */],
  options: {
    insertMenu: {
      views: [
        {
          name: "grid",
          previewImageUrl: (schemaTypeName) =>
            `/static/page-builder-thumbnails/${schemaTypeName}.webp`,
        },
      ],
      groups: [/* your block groupings */],
    },
  },
});
```

The work is in producing the WebP files, naming them to match the schema type, and keeping them in sync as the design evolves. That's what we're automating.

## Automating Sanity page builder thumbnails: how the three approaches compare

There are basically three ways to keep this picker looking sharp. Here's the rough shape of each:

| Approach             | Time per project | Consistency                  | Drift on schema change |
| -------------------- | ---------------- | ---------------------------- | ---------------------- |
| Manual screenshots   | 60-90 min        | Designer-dependent           | High                   |
| Figma template       | 45-60 min        | Eyeballed scaling, varies    | High                   |
| Agentic (this skill) | 5-7 min          | High, rendered in-context    | Low                    |

The agentic option isn't faster because the screenshots themselves are quicker. It's faster because nobody has to remember to do them. Add a block on a Friday, re-run the skill, the new thumbnail looks identical to the rest of the set.

## The skill, in short

The skill lives as a [public gist](https://gist.github.com/sneroboto/a6352618399b9d95cfd521b59761828d) so you can drop it into any Claude Code project. It's designed against [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity), our open-source starter for Next.js and Sanity, but the steps are generic enough to adapt.

It does nine things, in order:

1. **Verifies prerequisites.** Playwright MCP is configured, Sanity Studio exists, the Next.js dev server can start, API credentials are present.
2. **Discovers blocks.** Reads your schema files to identify every page builder block type and what fields each one needs.
3. **Reads components.** Locates the section components, works out how each one renders images, checks for self-fetching behaviour.
4. **Obtains images.** Queries your existing Sanity assets first. Only uploads placeholders if you explicitly say yes.
5. **Generates a preview page.** Creates a client component that renders every block with a `data-block="{schemaTypeName}"` attribute, using real Sanity asset references and contextual mock data.
6. **Screenshots blocks.** Uses Playwright MCP to navigate to `/thumbnails`, verify images render, then capture each block at 1440px viewport width.
7. **Processes images.** Scales to 600px wide, crops or pads height to a 400px max, exports WebP at quality 85 using ffmpeg or sharp.
8. **Updates the schema.** Adds the `insertMenu.views` config and groups so the new thumbnails actually appear in the picker.
9. **Cleans up.** Deletes Playwright logs, raw screenshots, and the preview page. Optional: removes any uploaded placeholder assets.

The whole run takes about five to seven minutes. On a small page builder you'll see closer to four. On a big one with thirty blocks and a slow connection, expect closer to nine.

## What the demo looks like

We recorded a quick walkthrough on the channel. The clip below shows the full run on a Turbo Start Sanity project that already has thumbnails. The prompt deletes them, the skill regenerates everything, and the new set is live in the studio after a refresh.

The actual prompt is in the description of the video and pinned in the gist. There's nothing magical about it. It's a structured instruction that tells the skill what to discover, what to generate, and what to clean up afterwards.

## Running it yourself

Three prerequisites first:

- Claude Code with the [Playwright MCP](https://github.com/microsoft/playwright-mcp) server configured.
- A Sanity Studio with a page builder array. If you've cloned [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity), you already have one.
- The matching Next.js frontend with a working `pnpm run dev`.

Once those are in place, three steps to run it:

```bash
# 1. Add the Playwright MCP server to Claude Code
claude mcp add playwright -- npx @playwright/mcp@latest

# 2. Save the skill to .claude/skills/generate-thumbnails-agentic/SKILL.md
#    Source: https://gist.github.com/sneroboto/a6352618399b9d95cfd521b59761828d

# 3. Start your dev server, then in Claude Code:
#    "generate thumbnails"
#    (append "delete the existing ones first" for a clean regen)
```

The agent will spend the first thirty seconds or so reading your schema, then a couple of minutes building the preview page, then most of the rest of the time letting Playwright do its job.

Two things that catch people out:

**The preview page must be a client component.** The skill marks it `"use client"` because the mock data passes function props and server components reject those. If you skip that, you'll see a confusing serialisation error and lose two minutes debugging.

**Every mock array item needs a `_type` field.** Sanity's discriminated unions rely on `_type` to know which block to render. Forget it on a single mock and that block silently disappears from the screenshots.

Both rules are baked into the skill's instructions, so you only need to worry about them if you start adapting it for a new schema shape.

> **Need a Sanity Studio that doesn't fight your team?**: We build editor-friendly Sanity studios on Next.js with page builders, presentation, and the kind of tooling that makes shipping content boring in a good way. [See how we work with Sanity](/services/sanity)

## Why this beats the Figma file we built

We're not theorising about a Figma workflow. We [shipped one](https://www.figma.com/community/file/1404904715260176924/arrayfield-template-for-sanity) - a community file with a 3:2 artboard and clean export presets, free to clone. People use it. It's a fine tool. But it has four problems that the agentic version doesn't, and we ran into all four running it ourselves.

**It's slow.** The Figma flow looks light on paper: screenshot, paste, crop, export. In practice, every block takes you through opening Figma, scaling the screenshot to roughly fit the artboard, nudging it into place, exporting, then naming the file to match the schema type. Forty-five minutes per project, easily. The agentic version is five.

**It's inconsistent.** "Scale to roughly fit the artboard" is the bit that bites. Every developer eyeballs it slightly differently, so the picker ends up with twenty thumbnails that all look subtly off from each other. The headless browser renders the components in a real preview page instead, so the scale is identical by construction.

**It's chicken-and-egg.** You can't screenshot a block in Figma until it has real Sanity content in it. So a copywriter has to draft and populate every block before the thumbnail flow can even start - which is the wrong way round, because thumbnails exist so editors can pick a block before they build it, not after. The agentic version mocks contextual content from the schema itself.

**It drifts.** This is the killer. The moment you ship a new block or restyle an existing one, the Figma version is wrong. Nobody opens Figma after a Friday merge to redo the thumbnails. A few merges later, half your picker is stale. The agentic version is one command. Re-run the skill, the whole set is current again.

## Tradeoffs and limitations

This isn't a silver bullet. Two structural things to know up front.

**It's bound to your component layout.** The skill renders your real components in a real preview page. If your block looks bad in production, the thumbnail will look bad too. That's usually a feature, not a bug, but it does mean you can't fix the thumbnail without fixing the design.

**Vertex outpainting isn't part of this.** Some teams want a 16:9 thumbnail with extra art around the edges. The skill produces a tight 3:2 image of the block itself. If you want the marketing-style thumbnail, you'll layer that on top.

## When the skill stumbles

Three failure modes show up often enough to be worth flagging.

**Playwright times out on heavy blocks.** Hero blocks with autoplay video or stacked animations can blow past the screenshot timeout. We've had no issues on macOS with the official MCP server, but mileage varies on Linux CI runners. The skill catches the error and skips the block, so you'll see the default Sanity icon in the picker instead of a fresh thumbnail. Either bump the Playwright wait or simplify the block's preview-mode rendering.

**Asset references go missing on niche block types.** If a block expects an image type that doesn't exist anywhere in your dataset, the skill can't borrow a real reference. It'll ask permission to upload a placeholder. Say no and you'll see a broken image in the screenshot instead.

**The schema update step can't find your `insertMenu` config.** The skill expects your `pageBuilder` field in the standard Turbo Start Sanity layout. If you've moved it somewhere custom, the agent will tell you the file isn't where it expected and ask you to point it at the right one. A five-line tweak in the skill markdown makes the redirect permanent.

## The full skill

If you want the whole thing in one place (to fork it, tweak it, or just read it without bouncing to the gist), here it is. Drop this verbatim into `.claude/skills/generate-thumbnails-agentic/SKILL.md` in your project. Same content as the [gist](https://gist.github.com/sneroboto/a6352618399b9d95cfd521b59761828d), kept here so the post is self-contained.

````markdown
name: generate-thumbnails-agentic
description: Use when setting up Sanity Studio page builder array thumbnails using Playwright MCP for fully agentic browser-based screenshot generation. Use when the user says "generate thumbnails" and Playwright MCP is available. Requires a Sanity Studio with page builder blocks, a Next.js frontend, and the Playwright MCP server configured.
---

# Generate Sanity Studio Page Builder Thumbnails (Agentic)

## Overview

Fully agentic thumbnail generation for Sanity Studio's `insertMenu` grid view. You (Claude) read the schema, upload placeholder images to Sanity, generate a preview page with real asset references, use Playwright MCP to screenshot each block, process the images, and output optimized thumbnails. No scripts, no manual steps.

## Prerequisites

**STOP and check these before proceeding:**

1. **Playwright MCP is configured.** Run a Playwright MCP tool (e.g. `browser_navigate`) to verify. If unavailable, **STOP** and ask the user:

   > "This skill requires the Playwright MCP server for browser automation. Please run this command and restart Claude Code:"
   >
   > ```
   > claude mcp add playwright -- npx @playwright/mcp@latest
   > ```
   >
   > Do NOT proceed until the user confirms Playwright MCP is available.

2. **The project has a Sanity Studio** with page builder blocks (look for `schemaTypes/blocks/` or similar).

3. **The project has a Next.js frontend** that renders those blocks as section components.

4. **The dev server is running.** Check by curling `localhost:3000` (or the project's dev port). If not running, **ask the user for permission to start it** (e.g. "No dev server is running on :3000. Want me to start `pnpm dev:web` in the background, or will you start it yourself?"). Wait for explicit approval before launching anything — some projects have dev server quirks, port conflicts, or the user may prefer to run it in their own terminal. Do NOT auto-start without permission.

5. **Sanity project credentials are available.** Find the `projectId` and `dataset` from `sanity.config.ts`, `sanity.cli.ts`, or environment variables. Also locate a write API token (check `.env` files for `SANITY_API_WRITE_TOKEN` or similar).

## Process

```dot
digraph generate_thumbnails_agentic {
  "Verify Playwright MCP" [shape=diamond];
  "Tell user to install" [shape=box];
  "Discover blocks from schema" [shape=box];
  "Read section components" [shape=box];
  "Get placeholder images into Sanity" [shape=box];
  "VERIFY: have asset refs?" [shape=diamond];
  "Generate preview page WITH images" [shape=box];
  "Verify dev server running" [shape=diamond];
  "Ask permission to start dev server" [shape=box];
  "Navigate to /thumbnails" [shape=box];
  "VERIFY: images visible?" [shape=diamond];
  "Debug image rendering" [shape=box];
  "Screenshot each block" [shape=box];
  "Process images (resize + WebP)" [shape=box];
  "Update pageBuilder schema" [shape=diamond];
  "Add insertMenu config" [shape=box];
  "Clean up placeholder assets" [shape=box];
  "Done" [shape=doublecircle];

  "Verify Playwright MCP" -> "Tell user to install" [label="missing"];
  "Tell user to install" -> "Verify Playwright MCP" [label="retry"];
  "Verify Playwright MCP" -> "Discover blocks from schema" [label="available"];
  "Discover blocks from schema" -> "Read section components";
  "Read section components" -> "Get placeholder images into Sanity";
  "Get placeholder images into Sanity" -> "VERIFY: have asset refs?";
  "VERIFY: have asset refs?" -> "Get placeholder images into Sanity" [label="no, retry"];
  "VERIFY: have asset refs?" -> "Generate preview page WITH images" [label="yes"];
  "Generate preview page WITH images" -> "Verify dev server running";
  "Verify dev server running" -> "Ask permission to start dev server" [label="not running"];
  "Ask permission to start dev server" -> "Verify dev server running" [label="retry"];
  "Verify dev server running" -> "Navigate to /thumbnails" [label="running"];
  "Navigate to /thumbnails" -> "VERIFY: images visible?";
  "VERIFY: images visible?" -> "Debug image rendering" [label="no"];
  "Debug image rendering" -> "Navigate to /thumbnails" [label="retry"];
  "VERIFY: images visible?" -> "Screenshot each block" [label="yes"];
  "Screenshot each block" -> "Process images (resize + WebP)";
  "Process images (resize + WebP)" -> "Update pageBuilder schema";
  "Update pageBuilder schema" -> "Add insertMenu config" [label="missing"];
  "Update pageBuilder schema" -> "Clean up placeholder assets" [label="exists"];
  "Add insertMenu config" -> "Clean up placeholder assets";
  "Clean up placeholder assets" -> "Done";
}
```

## Step 1: Discover Page Builder Blocks

Read the schema files to find all page builder block types:

1. Find the page builder definition (e.g. `schemaTypes/definitions/pagebuilder.ts`)
2. Find the blocks index that lists all types
3. Read each block schema to understand fields, types, and required vs optional

**Record for each block:**

- Schema type `name` (this becomes the thumbnail filename — must match exactly)
- All fields with types (string, text, image, richText, reference, array, etc.)
- **Which fields are image types** — mark these, they need real Sanity asset references
- Required vs optional fields

## Step 2: Read Frontend Components

Find the PageBuilder renderer and each section component:

1. Find the component mapping (which block type maps to which component)
2. Read each section component for:
   - Props interface (what data shape it expects)
   - Built-in default values
   - Whether it self-fetches from Sanity when no data is provided
   - **How it renders images** — find the `SanityImage` or image component. What exact prop shape does it expect? (Usually `{ _type: "image", asset: { _type: "reference", _ref: "image-xxx" }, alt: "text" }`)

## Step 3: Get Placeholder Images Into Sanity

<HARD-GATE>
DO NOT skip this step. DO NOT pass `null` for image fields. DO NOT use plain `<img>` tags.
Blocks with image fields MUST have real Sanity image asset references so the `SanityImage` component renders actual images in the thumbnails.
If you skip this step, the thumbnails will be text-only and look incomplete.

**ALWAYS check for existing images in the dataset FIRST.** Most projects already have image assets — use those. Only suggest uploading new placeholders as a last resort, and ALWAYS ask the user for permission before writing to their dataset.
</HARD-GATE>

**3a. Check for existing images in the dataset first:**

Use the Sanity MCP `query_documents` tool. If the MCP is not authenticated (common error: "project user not found"), fall back to a direct API call using the project's read token:

```bash
curl -s -G "https://PROJECT_ID.api.sanity.io/v2024-01-01/data/query/DATASET" \
  -H "Authorization: Bearer READ_TOKEN" \
  --data-urlencode 'query=*[_type == "sanity.imageAsset"][0...20]{ _id, originalFilename, metadata { dimensions } }'
```

Query at least 10–20 images, not just 5 — you need options to pick from.

<HARD-GATE>
**VISUALLY PREVIEW candidate images before picking — do NOT just grab the first landscape-shaped asset.**

The first landscape-shaped image in a dataset is often a partner/competitor logo, a branded marketing graphic, or something otherwise unsuitable as a generic placeholder. Picking it blindly means that logo ends up plastered across every hero thumbnail in Studio, which looks wrong and is confusing for editors. (This has happened — don't repeat it.)

For each candidate asset you're considering, download a small preview and view it with the Read tool:

```bash
# Extension (jpg/png/webp) MUST match the asset's _id suffix, else Sanity returns JSON error
curl -s -o "/tmp/preview-{hash}.{ext}" "https://cdn.sanity.io/images/PROJECT_ID/DATASET/{hash}-{width}x{height}.{ext}?w=400"
```

Then `Read` the downloaded file to see it. Reject any with visible third-party logos or brand marks.
</HARD-GATE>

**Pick 5–8 VARIED images covering different subject types** — e.g. product shots, scientific imagery, team photos, portraits, lab environments, abstract/data visuals. Assign them deliberately across block categories so the thumbnail grid feels visually distinct, not repetitive. One image reused across 15 blocks is a red flag.

Also check the project's `public/` or static-asset folder — some projects ship decorative background textures (hardcoded PNGs imported directly by specific components) that are the intended choice for `backgroundImage` fields.

If images exist and you've visually verified your picks, use their `_id` values as asset references and skip to 3d.

**3b. If no images exist, download placeholders:**

```bash
curl -L -o /tmp/placeholder-landscape.jpg "https://picsum.photos/seed/thumb-land/800/600"
curl -L -o /tmp/placeholder-portrait.jpg "https://picsum.photos/seed/thumb-port/600/800"
curl -L -o /tmp/placeholder-square.jpg "https://picsum.photos/seed/thumb-sq/600/600"
```

**3c. Upload each image to Sanity (ASK USER FIRST):**

<HARD-GATE>
**ALWAYS ask the user before uploading anything to their Sanity dataset.** Do not upload images without explicit permission — the user may not want placeholder assets in their production dataset.
</HARD-GATE>

Find the projectId, dataset, and API token from the project config files. Then upload:

```bash
curl -s -X POST \
  "https://PROJECT_ID.api.sanity.io/v2024-01-01/assets/images/DATASET" \
  -H "Authorization: Bearer API_TOKEN" \
  -H "Content-Type: image/jpeg" \
  --data-binary @/tmp/placeholder-landscape.jpg
```

Replace `PROJECT_ID`, `DATASET`, and `API_TOKEN` with actual values from the project.

The response JSON contains the asset document. Extract the `_id` field — it looks like `image-<hash>-800x600-jpg`.

**Repeat for each placeholder image variant** (landscape, portrait, square).

**3d. VERIFY — you must have at least one working asset reference before continuing.**

Confirm by querying:

```groq
*[_type == "sanity.imageAsset"] | order(_createdAt desc) [0...3]{ _id }
```

You should get back `_id` values. These are your asset references.

**Store them as variables for Step 4:**

- `LANDSCAPE_REF` = `image-<hash>-800x600-jpg`
- `PORTRAIT_REF` = `image-<hash>-600x800-jpg`
- `SQUARE_REF` = `image-<hash>-600x600-jpg`

## Step 4: Generate the Preview Page

Create the preview page at the app router path (e.g. `apps/web/src/app/thumbnails/page.tsx`).

**Page structure:**

<HARD-GATE>
- **MUST be a client component** — add `"use client"` at the top of the file. Many section components use client-side libraries (e.g. `DynamicIcon` from `lucide-react/dynamic` with function props like `fallback`, Radix UI primitives, `useFormStatus`). These function props CANNOT be serialized across the React Server Component boundary. A server component page will throw: `"Functions cannot be passed directly to Client Components"`.
- Do NOT add a `process.env.NODE_ENV` guard — it's unreliable in Next.js dev mode and this page will be deleted after screenshots anyway.
</HARD-GATE>

- Import section components directly (NOT through PageBuilder which needs Visual Editing context)
- Wrap each block: `<div data-block="{schemaTypeName}">`
- `data-block` value MUST exactly match the schema type `name`
- Do NOT add `style={{ background: "#CCC" }}` to wrappers — it adds visual noise to thumbnails

**Mock data rules:**

- **Contextual lorem ipsum** — content that makes sense for each block's purpose:
  - Hero: compelling headline, persuasive subtext
  - CTA: action-oriented copy
  - FAQ: realistic questions with helpful answers
  - Features: distinct capabilities with clear descriptions
  - Newsletter: enticing signup copy
  - Portfolio/work: creative project descriptions

- **Rich text / Portable Text** — use inline block format:

  ```typescript
  [
    {
      _type: "block",
      _key: "k1",
      style: "normal",
      children: [{ _type: "span", _key: "s1", text: "Your text", marks: [] }],
      markDefs: [],
    },
  ];
  ```

- **Image fields — MANDATORY, do not pass null:**

  ```typescript
  image: {
    _type: "image",
    asset: {
      _type: "reference",
      _ref: "LANDSCAPE_REF_FROM_STEP_3"  // e.g. "image-abc123-800x600-jpg"
    },
    alt: "Placeholder image"
  }
  ```

  Use landscape refs for hero/banner images, portrait for profile/avatar images, square for card thumbnails.
  Every block that has an image field MUST receive a real asset reference.

- **Self-fetching components — MUST pass mock items directly:**
  Some components (e.g. work lists, archive lists, project grids) will self-fetch from Sanity when no items are passed. On a fresh project this results in empty lists — the thumbnail shows only the heading with nothing below it.

  **ALWAYS pass mock items directly as props.** Read the component source to find what fields each item needs. Typical pattern:

  ```typescript
  // WorkList / project grid: pass `projects` prop
  projects={[
    { _id: "p1", title: "Brand Identity Redesign", year: "2025",
      thumbnail: { _type: "image", asset: { _type: "reference", _ref: "LANDSCAPE_REF" } } },
    { _id: "p2", title: "E-Commerce Platform", year: "2024",
      thumbnail: { _type: "image", asset: { _type: "reference", _ref: "LANDSCAPE_REF" } } },
    { _id: "p3", title: "Mobile App Design", year: "2024",
      thumbnail: { _type: "image", asset: { _type: "reference", _ref: "LANDSCAPE_REF" } } },
    { _id: "p4", title: "Marketing Campaign", year: "2023",
      thumbnail: { _type: "image", asset: { _type: "reference", _ref: "LANDSCAPE_REF" } } },
  ]}

  // ArchiveList: pass `items` prop
  items={[
    { _id: "a1", title: "Gallery Website", year: "2023", role: "Lead Designer",
      client: "Studio Co", description: "A minimal portfolio site",
      thumbnail: { _type: "image", asset: { _type: "reference", _ref: "LANDSCAPE_REF" } } },
    { _id: "a2", title: "Dashboard UI", year: "2022", role: "UI Designer",
      client: "Tech Inc", description: "Analytics dashboard redesign",
      thumbnail: { _type: "image", asset: { _type: "reference", _ref: "LANDSCAPE_REF" } } },
  ]}
  ```

  Replace `LANDSCAPE_REF` with the actual asset reference from Step 3.
  Include enough items to make the grid look populated (3-4 for grids, 2-3 for lists).

- **Reference fields (non-self-fetching)** — pass inline objects with the fields the component reads (`_id`, `title`, etc.)

- **Buttons** — include 1-2 with contextual labels

- **`_type` fields on mock items** — every mock item in an array must include its `_type` field matching the schema type name. For example, FAQ items need `_type: "faq"`, feature card items need `_type: "featureCardIcon"`. Read the component's TypeScript props to find the required discriminant. Missing `_type` causes type errors and can break rendering.

- Use `any` casts or `@ts-expect-error` for type mismatches — this is dev-only

- Give each mock item unique `_key` values

## Step 5: Screenshot Each Block with Playwright MCP

**Ensure output directory exists:**

```bash
mkdir -p apps/studio/static/thumbnails
```

**Use Playwright MCP tools in sequence:**

1. **Set viewport:** Use `browser_resize` or navigate with a wide viewport (1440x900)
2. **Navigate:** `browser_navigate` to `http://localhost:3000/thumbnails`
3. **Wait for render:** Allow the page to fully load (wait for network idle or a brief pause)

<HARD-GATE>
4. **VERIFY IMAGES ARE VISIBLE:** Take a full-page screenshot first and visually inspect it. Look for:
   - Are images actually rendering in hero blocks, card blocks, about sections?
   - Or are there blank/broken image areas?

If images are NOT visible: STOP. Debug the issue. Common causes:

- Asset reference is wrong (check `_ref` value matches an actual `_id` from Sanity)
- Image component expects different prop shape than what you passed
- The dev server needs to be restarted to pick up the new page
- CORS issue with Sanity CDN (check browser console via Playwright)

DO NOT proceed to take individual screenshots until images are confirmed visible.
</HARD-GATE>

5. **For each block:**
   - Scroll to the `[data-block="{name}"]` element
   - Take a screenshot of that element using `browser_take_screenshot`
   - Save the screenshot to a temp location

## Step 6: Process Images

Output: **600x400** WebP thumbnails that show the **full width** of each block.

<HARD-GATE>
**DO NOT use `fit: 'cover'` or `force_original_aspect_ratio=increase` with a center crop.** Blocks render at 1440px wide but thumbnails are 600px wide. A cover-crop zooms in and clips the sides — titles get cut off, cards disappear, centered content becomes unrecognizable.

**CORRECT approach:** Scale width to 600px first (height proportional), THEN crop height to 400 max from top, padding with white if shorter. This preserves the full block layout.
</HARD-GATE>

**Option A — ffmpeg (preferred, commonly available on macOS/Linux):**

```bash
ffmpeg -y -i input.png \
  -vf "scale=600:-1:flags=lanczos,crop=600:min(ih\,400):0:0,pad=600:400:0:(oh-ih)/2:white" \
  -quality 85 output.webp
```

This pipeline:
1. Scales width to 600px (height proportional) — full block width preserved
2. Crops height to 400px from top if taller (captures header + key content)
3. Pads with white and centers vertically if shorter than 400px

**Option B — sharp (Node one-liner):**

```bash
node -e "require('sharp')('input.png').resize(600, null).extend({bottom: 400, background: 'white'}).resize(600, 400, {fit: 'cover', position: 'top'}).webp({quality:85}).toFile('output.webp')"
```

**Batch processing example (ffmpeg):**

```bash
for f in /tmp/thumbnails/*-raw.png; do
  name=$(basename "$f" -raw.png)
  ffmpeg -y -i "$f" \
    -vf "scale=600:-1:flags=lanczos,crop=600:min(ih\,400):0:0,pad=600:400:0:(oh-ih)/2:white" \
    -quality 85 "apps/studio/static/thumbnails/${name}.webp"
done
```

**Final output:** WebP files in `apps/studio/static/thumbnails/` named `{schemaTypeName}.webp`

## Step 7: Update pageBuilder Schema

Check the page builder schema definition for `insertMenu` config. If missing, add the `views` config (and optionally `groups`):

```typescript
options: {
  insertMenu: {
    groups: [
      {
        name: "groupName",
        title: "Group Title",
        of: ["blockType1", "blockType2"],
      },
      // ... more groups
    ],
    views: [
      {
        name: "grid",
        previewImageUrl: (schemaTypeName) =>
          `/static/thumbnails/${schemaTypeName}.webp`,
      },
    ],
  },
},
```

**Groups** add category filter tabs above the grid view, letting editors filter blocks by type (e.g. "Hero", "Cards", "Media"). Each group has:
- `name`: unique identifier (camelCase)
- `title`: display label shown in the filter tab
- `of`: array of schema type names that belong to this group

Blocks can appear in multiple groups (cross-group membership). Blocks not assigned to any group still appear in the default "All" view. When adding new blocks, remember to assign them to at least one group.

**If `groups` already exist**, check whether new blocks need to be added to the appropriate group(s). If generating thumbnails for new blocks, update both the thumbnails AND the groups array.

The `views` path must match where the processed thumbnails were saved.

## Step 8: Clean Up

**8a. Delete Playwright MCP console logs:**

Playwright MCP automatically creates a `.playwright-mcp/` directory with console log files (e.g. `console-2026-*.log`). Delete the directory after screenshots are complete:

```bash
rm -rf .playwright-mcp/
```

Also add `.playwright-mcp/` to `.gitignore` if not already present — these logs should never be committed.

**8b. Delete raw screenshot artifacts:**

After processing images to WebP in Step 6, immediately delete the raw screenshot files (e.g. `*-raw.jpeg` or `*-raw.png`) from the output directory. These are intermediate files and are no longer needed.

```bash
rm apps/studio/static/thumbnails/*-raw.jpeg
rm apps/studio/static/thumbnails/*-raw.png
```

Only the final `{schemaTypeName}.webp` files should remain in the thumbnails directory.

**8c. Delete the preview page:**

The `/thumbnails` preview page was only needed to render blocks for screenshotting. Delete it now that screenshots are complete:

```bash
rm -rf apps/web/src/app/thumbnails/
```

This removes both `page.tsx` and any wrapper files (e.g. `pet-wrapper.tsx`) created for the preview. Do NOT keep the preview page — it adds dead code to the project and can be regenerated by running this skill again if thumbnails need updating.

**8d. Ask about placeholder images (if uploaded):**

If you uploaded placeholder images to Sanity in Step 3 (i.e. no existing images were available), ask the user:

> "Thumbnails are done. I uploaded placeholder images to your Sanity dataset for the screenshots. Want me to delete them, or keep them for future use?"

If deleting, use the Sanity API or MCP tools to remove the uploaded assets by their `_id`.

If existing dataset images were used (Step 3a), skip this — nothing was uploaded.

## Common Mistakes

| Mistake                                           | Fix                                                                                               |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Cropping thumbnails with `fit: cover` (most common)** | **Scale width to 600 first, then crop/pad height. Cover-crop clips wide blocks.**           |
| **Preview page as server component**              | **MUST be `"use client"` — function props (DynamicIcon fallback, etc.) can't serialize across RSC boundary** |
| **Missing `_type` on mock array items**           | **Every mock item needs `_type` matching its schema name (e.g. `_type: "faq"`, `_type: "featureCardIcon"`)** |
| **Uploading to Sanity without asking**            | **ALWAYS ask user before writing to their dataset — use existing assets when possible**            |
| Skipping image upload when images needed          | NEVER pass `null` for image fields. Use existing Sanity assets or upload placeholders (with permission) |
| Filename doesn't match schema type name           | Use exact `name` from schema (e.g. `featureCardsIcon` not `feature-cards-icon`)                   |
| Using PageBuilder component                       | Import section components directly — PageBuilder needs Visual Editing context                     |
| Generic placeholder text                          | Write contextual copy matching each block's purpose                                               |
| Missing `_key` on array items                     | Every array item needs a unique `_key` string                                                     |
| Rich text as plain string                         | Must use Portable Text block format with `_type: "block"`                                         |
| Using `NODE_ENV` guard on preview page            | Unreliable in Next.js dev — page will be deleted anyway, skip the guard                           |
| Adding `style={{ background: "#CCC" }}` to wrappers | Adds visual noise to thumbnails — let blocks render with their own backgrounds                  |
| Sanity MCP not authenticated                      | Fall back to direct API calls with project read/write tokens from `.env` files                    |
| Playwright MCP not available                      | Run `claude mcp add playwright -- npx @playwright/mcp@latest` and restart Claude Code             |
| Dev server not running                            | Ask user for permission to start it — don't auto-launch, but offer to run it (e.g. `pnpm dev:web`) in the background |
| Screenshots too large/small                       | Set viewport to 1440x900 before navigating, resize output to 600x400                              |
| Using plain `<img>` for SanityImage fields        | Components expect Sanity image props — upload to Sanity and use asset refs                        |
| Taking screenshots before verifying images render | Always take a full-page screenshot first and visually confirm images are visible                  |
| Leaving raw screenshots (`*-raw.jpeg`) behind     | Delete all raw/intermediate files after processing to WebP — only `.webp` files should remain     |
| Leaving the preview page in the codebase          | Delete `app/thumbnails/` after screenshots are taken — it's dead code and easily regenerated      |
| Adding new blocks without updating `groups`        | When generating thumbnails for new blocks, also add them to the appropriate `insertMenu.groups` in the page builder schema |

## Red Flags — STOP If You Notice These

- You're about to write `image: null` or `image={null}` — **STOP**, go back to Step 3
- You're about to use `<img src="https://...">` instead of SanityImage — **STOP**, that won't work with the component
- You're taking screenshots but haven't verified images are rendering — **STOP**, take a full-page screenshot first
- You're skipping Step 3 because "it's faster" — **STOP**, text-only thumbnails are incomplete
- The preview page renders but image areas are blank — **STOP**, debug the asset reference before screenshotting
- You're about to use `fit: 'cover'` or `force_original_aspect_ratio=increase` in image processing — **STOP**, this will clip wide blocks. Use scale-width-first approach.
- You're creating the preview page WITHOUT `"use client"` — **STOP**, function props in child components will crash the page
- You're about to upload images to Sanity without asking the user — **STOP**, check for existing assets first, and always ask permission before writing to their dataset
- You're passing mock items without `_type` fields — **STOP**, TypeScript discriminated unions require `_type` on every mock item
- You're adding thumbnails for new blocks but haven't checked the `insertMenu.groups` config — **STOP**, new blocks must be added to at least one group or they'll only appear in the "All" tab
````

## Where this goes next

A few things we're considering, in rough order:

- A Linear ticket type that triggers the skill on schema changes, so adding a block in a PR auto-regenerates the thumbnail in a follow-up commit.
- A flag on the prompt to keep existing thumbnails for blocks that haven't changed, so you only pay for the ones you need.
- Outpainting variants for marketing assets, using the same preview page as the source.

We'll write those up as they ship. For now, the skill is in the gist, the demo is on YouTube, and the underlying repo is on [GitHub](https://github.com/robotostudio/turbo-start-sanity). If you've got a Sanity project with a page builder and you've ever resented the time it takes to ship a thumbnail, this should be a five-minute win for you.

> **We build agentic workflows for teams**: Skills like this one, content pipelines, and background agents built around how your team actually works. [See our agentic workflows service](/services/agentic-workflows)

---

## Ode to cats: five years of Victorian cat mascots


> Every blog post on this site has a Victorian cat hero image generated by AI. Here's every single one, in full colour, from the earliest originals to today.

**TL;DR:** We've been generating Victorian cat hero images for every blog post since 2021. This is the complete collection, shown in original colour for the first time, with notes on the models that made them.

**Published:** 2026-03-27 | **Updated:** 2026-08-11 | **Categories:** AI, Hot Takes
---

If you've ever wondered why we've had cats for this many years, it's simple. We kept getting blocked by putting thought into a nice feature image at the start of a blog. It was a blocker, and lord knows how much we hate blockers.

On the blog index, you see them in grayscale with a halftone overlay. That's the brand treatment. But underneath, each one is a full-colour oil painting generated by whatever AI model we had access to at the time.

This post is every cat, in original colour, in chronological order. A retrospective of sorts. It actually makes me a little emotional, I'm embarrassed to say.

For the early years, we generated these outside the codebase entirely. Someone would hop into ChatGPT or the OpenAI API, generate a cat, and drop it into Sanity. We don't have exact records of which model produced which image. In March 2025 we added our [sanity-plugin-image-gen](https://www.sanity.io/plugins/sanity-plugin-image-gen) plugin to the studio, routing through **Replicate Flux**. That lasted until June 2025, when we [replaced Replicate with OpenAI's DALL-E 3](https://github.com/robotostudio/website/pull/88). Eventually we built the whole thing into our own imagen pipeline running GPT-Image-1.5.

## The early days (2021 to 2022)

These are the originals. Generated outside the codebase, probably through ChatGPT or the OpenAI API directly. DALL-E 2 was the only option for most of this period, and it had a distinctive softness. The paintings feel more impressionistic, less controlled. Prompt adherence was loose at best. You'd ask for a Victorian cat in formal wear and get something that was mostly cat-shaped, mostly Victorian, and occasionally wearing what might be a jacket. We loved them for it.

![Victorian cat from: How to transfer from WordPress to JAMstack fast](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-hero.png)

**[How to transfer from WordPress to JAMstack fast](/blog/how-to-transfer-from-wordpress-to-jamstack-fast)** (September 2021, DALL-E 2)

The very first cat. Our oldest blog post and the one that started the tradition. There's a charm to these early outputs that you can't replicate with newer models. The brushwork is loose, the details are approximate, and there's an ungodly abomination of a cat that's crawled directly from uncanny valley. We love them all the same.

![Victorian cat from: We are Sanity agency partners](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-are-sanity-agency-partners-blog-hero.png)

**[We are Sanity agency partners](/blog/we-are-sanity-agency-partners)** (October 2022, DALL-E 2)

A celebratory cat for a celebratory occasion. We'd just become official Sanity partners and needed a hero image that felt appropriately dignified. Whatever model generated this delivered something with gravitas, even if the details were a bit wobbly. There's something about the thousand yard stare that really sells the image of celebration.

![Victorian cat from: What Sanity Studio v3 means for clients](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/what-sanity-studio-v3-means-for-clients-blog-hero.png)

**[What Sanity Studio v3 means for clients](/blog/what-sanity-studio-v3-means-for-clients)** (November 2022, DALL-E 2)

Studio v3 was a big deal. The cat needed to look like it understood the significance of a major platform migration. Whether it actually conveys that is up for debate, but it certainly looks like it has opinions. Although I really like the big fluffy coat but tiny little legs. Pay close attention to whether the models draws them as 4 legged beasts, or eerily standing on their hind legs, because it often differs, and I love it for it.

![Victorian cat from: How Sanity handles your data](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-sanity-handles-your-data-blog-hero.png)

**[How Sanity handles your data](/blog/how-sanity-handles-your-data)** (December 2022, DALL-E 2)

The last of the DALL-E 2 cats. A data-themed feline for a post about content lakes and document storage. There's something fitting about the slightly abstract quality of early AI art being used to illustrate a post about data architecture. They're standing on their hind legs again.

![Victorian cat from: Dynamic open graph images with Sanity and Next.js](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/dynamic-open-graph-with-sanity-and-next-js-blog-hero.png)

**[Dynamic open graph images with Sanity & Next.js](/blog/dynamic-open-graph-with-sanity-and-next-js)** (January 2023, DALL-E)

A cat for a post about OG images. The irony of generating an AI hero image for a blog about dynamically generating images was not lost on us. Although we weren't actively trying to make the cats look worse, but somehow their forms progressively degraded over time. There's a subtle horror in that.

![Victorian cat from: Tips and tricks for building Sanity schema efficiently](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/tips-and-tricks-for-building-sanity-schema-efficiently-blog-hero.png)

**[Tips and tricks for building Sanity schema efficiently](/blog/tips-and-tricks-for-building-sanity-schema-efficiently)** (January 2023, DALL-E)

A studious cat for a studious topic. Schema design is one of those things that separates decent Sanity implementations from good ones. This cat looks like it knows the difference between `defineField` and `defineType`. It has a beret. This is not lost on me.

## The quality leap (2023)

This is where things got sharp. DALL-E 3 launched in October 2023, and ChatGPT's image generation got noticeably better around the same time. You could ask for a cat in specific Victorian clothing, holding specific objects, in a specific setting, and actually get something recognisable. The jump in quality was dramatic. These cats have personality. Like the earlier ones, they were generated outside the codebase and uploaded to Sanity manually.

![Victorian cat from: Sanity top tip, the Grandma test](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-top-tip-the-grandma-test-blog-hero.png)

**[Sanity top tip: the Grandma test](/blog/sanity-top-tip-the-grandma-test)** (January 2023, DALL-E)

Could your grandmother use the studio? If not, your schema needs work. This cat looks a lot higher quality, but I do appreciate the fact that the eyes are just a little off once again. Keep up the great work.

![Victorian cat from: Revolutionising visual content creation with Sanity.io and OpenAI](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/revolutionizing-visual-content-creation-with-sanityio-and-openai-blog-hero.png)

**[Revolutionising visual content creation with Sanity.io and OpenAI](/blog/revolutionizing-visual-content-creation-with-sanityio-and-openai)** (January 2023, DALL-E)

Now we're back to the old system. I think at this point, I had spent so long around the dodgy looking cats, I kind of missed them. This is the blog post about generating images with AI inside Sanity Studio, which itself has an AI-generated cat hero image. It's also where we first wrote about our [sanity-plugin-image-gen](https://www.sanity.io/plugins/sanity-plugin-image-gen) plugin. We're getting very meta.

![Victorian cat from: 11 top tips for SEO with Sanity and Next.js](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/top-tips-for-seo-with-sanity-and-nextjs-blog-hero.png)

**[11 top tips for SEO with Sanity & Next.js](/blog/11-top-tips-for-seo-with-sanity-and-nextjs)** (February 2023, DALL-E)

I really appreciate the right-hand cat and the way it somehow managed to get human hands. It looks unamused, but all so adorable at the same time.

![Victorian cat from: Getting the hang of Sanity's parameterised templates](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/getting-the-hang-of-sanitys-parameterized-templates-blog-hero.png)

**[Getting the hang of Sanity's parameterised templates](/blog/getting-the-hang-of-sanitys-parameterized-templates)** (February 2023, DALL-E)

Parameterised templates are one of Sanity's quieter features. This cat has the energy of someone explaining a feature that deserves more attention than it gets. You must pay attention to their cute little fur paws. They look like wooly mittens.

![Victorian cat from: Sanity CMS pricing, which plan is right for you](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-cms-pricing-which-plan-is-right-for-you-blog-hero.png)

**[Sanity CMS pricing: which plan is right for you?](/blog/sanity-cms-pricing-which-plan-is-right-for-you)** (February 2023, DALL-E)

Now you might be wondering, are these cats, or are these weasels? I can assure you I only put cat prompts in, but may be the missing link as the last of the "on all 4 paws" kind of cats.

![Victorian cat from: Headless CMS hot takes](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/headless-cms-hot-takes-blog-hero.png)

**[Headless CMS hot takes](/blog/headless-cms-hot-takes)** (March 2023, DALL-E)

This is one of my personal favourites and a cat that lets you know what you're about to read. If you haven't read the blog already, trust me, I still have enough venom built up about Prismic, that I could write 4 more like this.

![Victorian cat from: Who needs a head? Headless CMS and the race for content velocity](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/who-needs-a-head-headless-cms-and-the-race-for-content-velocity-blog-hero.png)

**[Who needs a head?](/blog/who-needs-a-head-headless-cms-and-the-race-for-content-velocity)** (March 2023, DALL-E)

The headless CMS cat. We didn't resist the urge to generate a headless cat. You're welcome.

![Victorian cat from: Sanity Scheduling](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-scheduling-probably-the-best-scheduling-tool-weve-ever-used-blog-hero.png)

**[Sanity Scheduling: probably the best scheduling tool we've ever used](/blog/sanity-scheduling-probably-the-best-scheduling-tool-weve-ever-used)** (May 2023, DALL-E)

It got a little calendar in its hands. At the sacrifice of all quality elsewhere.

![Victorian cat from: Our App Router setup with Next 13.4, Tailwind CSS and Sanity](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/a-seamless-experience-with-next-134-tailwind-css-and-sanity-blog-hero.png)

**[Our App Router setup with Next 13.4, Tailwind CSS and Sanity](/blog/a-seamless-experience-with-next-134-tailwind-css-and-sanity)** (May 2023, DALL-E)

Next.js 13.4 was the app router moment. This cat looks like it just figured out how server components work and is cautiously optimistic about the future.

![Victorian cat from: The state of Chakra UI and Next 13.4](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-state-of-chakra-ui-and-next-13-4-blog-hero.png)

**[The state of Chakra UI & Next 13.4](/blog/the-state-of-chakra-ui-and-next-13-4)** (May 2023, DALL-E)

Chakra UI was having a rough time with the app router transition. This cat has the expression of someone watching a library they depend on slowly fall apart.

![Victorian cat from: Red flags to avoid when hiring a Sanity agency](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/choosing-the-right-sanity-cms-agency-blog-hero.png)

**[Red flags to avoid when hiring a Sanity agency](/blog/choosing-the-right-sanity-cms-agency)** (May 2023, DALL-E)

A trustworthy-looking cat for a post about choosing the right agency partner. We may be biased, but this cat would absolutely choose Roboto. They do look like a sight for sore eyes.

![Victorian cat from: Setting up live preview for Sanity on Next 13.4](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/setting-up-live-preview-for-sanity-on-next-134-using-drafts-blog-hero.png)

**[Setting up live preview for Sanity on Next 13.4 using drafts mode](/blog/setting-up-live-preview-for-sanity-on-next-134-using-drafts)** (May 2023, DALL-E)

I like the hyper-realism in the cats face, and his outfit, much more abstract and soft. Don't pay attention to the right eye. He doesn't like that.

![Victorian cat from: How to deploy Sanity with GitHub Actions](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/github-action-for-sanity-deployment-simplify-your-workflow-blog-hero.png)

**[How to deploy Sanity with GitHub Actions](/blog/github-action-for-sanity-deployment-simplify-your-workflow)** (June 2023, DALL-E)

A DevOps cat. CI/CD pipelines aren't glamorous, but automating your Sanity Studio deployment is one of those changes where you wonder why you didn't do it sooner. I especially like the Helena Bonham Carter cat on the right.

![Victorian cat from: The best Next.js and Sanity Image component](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-best-nextjs-and-sanity-image-component-blog-hero.png)

**[The best Next.js & Sanity Image component](/blog/the-best-nextjs-and-sanity-image-component)** (June 2023, DALL-E)

Image optimisation is one of those things every project needs and nobody enjoys setting up. This cat looks like it has strong opinions about `next/image` configuration. *Actually*, it doesn't look like it has strong opinions about anything. It looks positively ghastly.

![Victorian cat from: Actually using Figma dev mode](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/actually-using-figma-dev-mode-is-it-any-good-blog-hero.png)

**[Actually using Figma dev mode: is it any good?](/blog/actually-using-figma-dev-mode-is-it-any-good)** (June 2023, DALL-E)

A design-savvy cat. Figma's dev mode had just launched and everyone had opinions. Ours was measured but honest, which is about all you can ask for with a v1 product.

![Victorian cat from: What we learnt updating the Roboto website V3](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/what-we-learnt-updating-the-roboto-website-v3-blog-hero.png)

**[What we learnt updating the Roboto website V3](/blog/what-we-learnt-updating-the-roboto-website-v3)** (July 2023, DALL-E)

To round off the horror-adjacent cats, we've finished with what we learnt updating the Roboto Studio website. I think this is a fitting final cat from the "abomination" era, and onto the far nicer future transition.

## The transition (2024 to early 2025)

2024 was still the manual era. We'd generate cats externally and upload them to Sanity. The quality kept improving as the underlying models got better. Some of these may be DALL-E 3, some could be earlier ChatGPT image generation. By early 2025, we'd moved the whole website to a new codebase and started integrating image generation properly.

![Victorian cat from: Making your editorial experience that little bit better](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/making-your-editorial-experience-that-little-bit-better-blog-hero.png)

**[Making your editorial experience that little bit better](/blog/making-your-editorial-experience-that-little-bit-better)** (November 2023, DALL-E)

This is the blog post that explicitly called out Victorian cats. We wrote: "We mostly just wanted to publish this article because ChatGPT 4 released the image update so that we could get higher resolution Victorian cats." At least we're honest.

![Victorian cat from: Our roundup of tools 2024](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-hero.png)

**[Our roundup of tools 2024](/blog/our-roundup-of-tools-2024)** (December 2023, DALL-E)

A well-equipped cat for a well-stocked toolbox. End-of-year roundups are a genre we enjoy because they force you to actually evaluate what you've been using rather than just defaulting to it.

![Victorian cat from: Get better at using Sanity Studio](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/get-better-at-using-sanity-studio-blog-hero.png)

**[Get better at using Sanity Studio](/blog/get-better-at-using-sanity-studio)** (January 2024, DALL-E)

A studious cat to kick off the new year. Studio mastery is an ongoing process, and this cat looks like it's been putting in the hours.

![Victorian cat from: Working with Formspark and Server actions in Next.js 14](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/nextjs-14-form-handling-mastery-unleashing-server-actions-and-formspark-integration-blog-hero.png)

**[Working with Formspark & Server actions in Next.js 14](/blog/nextjs-14-form-handling-mastery-unleashing-server-actions-and-formspark-integration)** (January 2024, DALL-E)

Server actions changed how we think about form handling. Double trouble cats, and nice spectacles.

![Victorian cat from: Gearing up with Sanity in 2024](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/gearing-up-with-sanity-in-2024-blog-hero.png)

**[Gearing up with Sanity in 2024](/blog/gearing-up-with-sanity-in-2024)** (January 2024, DALL-E)

A forward-looking cat. Sanity had a strong 2024 roadmap and this cat was ready for it. Bonus points for the cool piece of text on his head.

![Victorian cat from: Using Cursor to improve your Sanity DX](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/using-cursor-to-improve-your-sanity-dx-blog-hero.jpg)

**[Using Cursor to improve your Sanity DX](/blog/using-cursor-to-improve-your-sanity-dx)** (February 2024, DALL-E)

A tech-forward cat. Cursor was still new to most people and we were already using it for schema development. This one's saved as a JPEG rather than PNG, which tells you something about the pipeline evolving. We couldn't resist the terminator nod.

![Victorian cat from: How to migrate from WordPress to Sanity fast](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-migrate-from-wordpress-to-sanity-fast-blog-hero.png)

**[How to migrate from WordPress to Sanity fast](/blog/how-to-migrate-from-wordpress-to-sanity-fast)** (March 2024, DALL-E)

A migration cat. WordPress to Sanity is one of our most common project types. This cat has migrated enough content to know where the edge cases hide. We really like the box art behind him.

![Victorian cat from: Our initial thoughts on Sanity Create](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-initial-thoughts-on-sanity-create-blog-hero.jpg)

**[Our initial thoughts on Sanity Create](/blog/our-initial-thoughts-on-sanity-create)** (May 2024, DALL-E)

Sanity Create (now called Canvas) was ambitious. This picture, not so much. It's just a nice happy cat with a quill and appreciate the models attention to details with the little cat hands.

![Victorian cat from: Building a search bar with Sanity Embeddings Index API](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/building-a-search-bar-with-sanity-embeddings-index-api-and-nextjs-blog-hero.jpg)

**[Building a search bar with Sanity Embeddings Index API & Next.js](/blog/building-a-search-bar-with-sanity-embeddings-index-api-and-nextjs)** (May 2024, DALL-E)

Embeddings-based search was a proper surprise from Sanity. Semantic search inside a CMS sounds like a gimmick until you use it. We built a whole god damn search bar out of it, and it worked flawlessly. The model did a pretty good job of magnifying the cats face too. Props.

![Victorian cat from: The only Sanity page-builder guide you'll ever need](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-only-sanity-page-builder-guide-youll-ever-need-blog-hero.jpg)

**[The only Sanity page-builder guide you'll ever need](/blog/the-only-sanity-page-builder-guide-youll-ever-need)** (July 2024, DALL-E)

Our most comprehensive guide cat. The page-builder post is one of our longest and most referenced pieces. 4 legs! The cat is on 4 legs again.

![Victorian cat from: A really nice Mux video component](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/a-really-nice-mux-video-component-blog-hero.png)

**[A really nice Mux video component](/blog/a-really-nice-mux-video-component)** (August 2024, DALL-E)

A media-savvy cat. We built a Mux video component that we actually liked, which is harder than it sounds. Video on the web is still surprisingly fiddly. Not to harp on about it... But the cats on 4 legs again, watching cats on a TV.

![Victorian cat from: Creating the perfect array thumbnails](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/creating-the-perfect-array-thumbnail-blog-hero.png)

**[Creating the perfect array thumbnails](/blog/creating-the-perfect-array-thumbnail)** (August 2024, DALL-E)

A detail-oriented cat. Array thumbnails in Sanity Studio are one of those small UX touches that editors actually notice and appreciate. Like the subtle buttoning on his cute little waistcoat.

![Victorian cat from: How our studio uses v0](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-our-studio-uses-v0-blog-hero.png)

**[How our studio uses v0](/blog/how-our-studio-uses-v0)** (October 2024, DALL-E)

We loved using v0 for quick design mockups, and this cat looks like it's just shipped a prototype in record time. I'm not such a fan of the generation of such sharp features in this art style though.

![Victorian cat from: Thinking of jumping ship from WordPress?](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/thinking-of-jumping-ship-from-wordpress-blog-hero.jpg)

**[Thinking of jumping ship from WordPress?](/blog/thinking-of-jumping-ship-from-wordpress)** (October 2024, Replicate Flux)

A contemplative cat on the edge of a decision. WordPress migration posts are evergreen for us. There's always someone ready to make the leap. However, this particular type of cat using replicate flux, I really didn't like. There's a good reason there's only like 4.

![Victorian cat from: Optimized data fetching in Next.js 15](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/optimized-data-fetching-in-nextjs-15-blog-hero.webp)

**[Optimized data fetching in Next.js 15](/blog/optimized-data-fetching-in-nextjs-15)** (November 2024, Replicate Flux)

Next.js 15 changed how data fetching works in practice. This cat looks like it understands `async` components. Saved as WebP, which tells you the image pipeline was evolving.

![Victorian cat from: Hidden gems in Next.js](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/hidden-gems-in-nextjs-blog-hero.jpg)

**[Hidden gems in Next.js](/blog/hidden-gems-in-nextjs)** (November 2024, Replicate Flux)

A treasure-hunting cat. We love writing about features that exist in the docs but nobody seems to use. This cat though... Still not sold on this style. Soulless.

![Victorian cat from: Should I upgrade to Sanity Enterprise?](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/should-i-upgrade-to-sanity-enterprise-blog-hero.png)

**[Should I upgrade to Sanity Enterprise?](/blog/should-i-upgrade-to-sanity-enterprise)** (December 2024, DALL-E)

Enterprise pricing decisions require careful thought and a cat that looks like it manages a budget. Now we're back to a luxurious kitty with lots of soul.

![Victorian cat from: Our 2024 takeaways with Sanity and Next.js](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-2024-takeaways-with-sanity-and-nextjs-blog-hero.png)

**[Our 2024 takeaways with Sanity & Next.js](/blog/our-2024-takeaways-with-sanity-and-nextjs)** (December 2024, DALL-E)

The year-end cat. A reflective feline for a reflective post. 2024 was a good year for both Sanity and Next.js, and this cat looks satisfied with how things turned out.

## The pipeline era (2025 to 2026)

This is where image generation finally moved into the codebase. In March 2025 we added our [sanity-plugin-image-gen](https://www.sanity.io/plugins/sanity-plugin-image-gen) plugin to the studio, routing through **Replicate Flux** (flux-pro and flux-schnell). The cats from early 2025 have a different texture because of this. Flux has a painterly quality that's different from DALL-E.

In June 2025, we swapped Replicate for OpenAI's DALL-E 3. By late 2025, we'd built a dedicated imagen app running GPT-Image-1.5 with the full pipeline: generate, outpaint with Google Vertex for wider formats, apply halftone treatment, upload to Vercel Blob.

The two most recent cats were generated through this full pipeline, so their stored images already have the grayscale and halftone effects baked in. You'll spot them.

![Victorian cat from: Using markdown shortcuts with the Portable Text Editor](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/using-markdown-shortcuts-with-the-portable-text-editor-blog-hero.png)

**[Using markdown shortcuts with the Portable Text Editor](/blog/using-markdown-shortcuts-with-the-portable-text-editor)** (January 2025, DALL-E)

A writerly cat. Markdown shortcuts in Portable Text are one of those features editors discover and never stop using. This one predates the plugin integration by a couple of months. But it's when we started using sphinx cats for some unknown reason.

![Victorian cat from: Working with Turbo Start Sanity](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/working-with-turbo-start-sanity-blog-hero.png)

**[Working with Turbo Start Sanity](/blog/working-with-turbo-start-sanity)** (February 2025, DALL-E)

A getting-started cat. Turbo Start is Sanity's quick-start template. This cat looks like it's about to scaffold a project and has strong feelings about folder structure. One of the last cats generated before we brought image generation into the codebase.

![Victorian cat from: How to use Google Analytics and actually get something out of it](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-hero.webp)

**[How to use Google Analytics and actually get something out of it](/blog/how-to-use-google-analytics-and-actually-get-something-out-of-it)** (April 2025, Replicate Flux)

An analytics cat. Ironic, given that we later [dumped Google Analytics for PostHog](/blog/we-dumped-google-analytics-for-posthog). This cat was living its best life before we changed our minds. One of the first cats generated through our Sanity plugin using Flux.

![Victorian cat from: How we use .mdc rules](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-we-use-mdc-rules-blog-hero.webp)

**[How we use .mdc rules](/blog/how-we-use-mdc-rules)** (May 2025, Replicate Flux)

A rules-oriented cat. .mdc rules were our first step into structured AI instructions before we moved to Claude skills. This cat looks like it follows rules meticulously. Generated through the Replicate Flux pipeline. Looks god-awful, without a soul, but I won't hold it against her.

![Victorian cat from: Figma in 2025: hot takes](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-hero.png)

**[Figma in 2025: hot takes](/blog/figma-in-2025-whats-working-whats-not-and-where-its-heading)** (July 2025, DALL-E 3)

An opinionated cat. Figma had a complicated year and we had opinions about it. This cat shares them. By this point we'd switched from Replicate to OpenAI's DALL-E 3. Hence the cat drawing a cat.

![Victorian cat from: Sanity Canvas: a better way of writing content](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-canvas-a-better-way-of-writing-content-blog-hero.png)

**[Sanity Canvas: a better way of writing content](/blog/sanity-canvas-a-better-way-of-writing-content)** (July 2025, DALL-E 3)

A creative cat. Canvas was Sanity's answer to the "writing in a CMS feels like filling out a form" problem. However, this did actually break the lore of the cat kingdom we created, as it introduced the concept of cats having cats as pets. 

![Victorian cat from: How we migrate content without breaking stuff](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-we-migrate-content-without-breaking-stuff-blog-hero.png)

**[How we migrate content without breaking stuff](/blog/how-we-migrate-content-without-breaking-stuff)** (July 2025, DALL-E 3)

Content migration is one of those areas where being methodical pays off and being reckless costs you dearly. This cat is the methodical type.

![Victorian cat from: Our cookie banner prayers have been answered](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-cookie-banner-prayers-have-been-answered-blog-hero.png)

**[Our cookie banner prayers have been answered](/blog/our-cookie-banner-prayers-have-been-answered)** (July 2025, DALL-E 3)

Cookie consent is one of those problems that sounds simple and isn't. When we found a solution that actually worked, this cat's expression was the right match.

![Victorian cat from: Page-builders and spacing](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/spacing-in-page-builders-blog-hero.png)

**[Page-builders and spacing](/blog/spacing-in-page-builders)** (August 2025, DALL-E 3)

Spacing in page builders is the kind of topic that only matters if you've built one. This cat is so angry when somebody suggested that we should add toggle-able padding on page builders.

![Victorian cat from: Next.js 16 for dummies](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/nextjs-16-for-dummies-blog-hero.png)

**[Next.js 16 for dummies](/blog/nextjs-16-for-dummies)** (October 2025, DALL-E 3)

By this point the pipeline had moved to GPT-Image-1.5. This cat is so dumpy, it brings a smile to my face.

![Victorian cat from: We dumped Google Analytics for PostHog](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-dumped-google-analytics-for-posthog-blog-hero.png)

**[We dumped Google Analytics for PostHog](/blog/we-dumped-google-analytics-for-posthog)** (October 2025, DALL-E 3)

Sometimes you need to commit to a change. Swapping analytics platforms is one of those decisions that feels scary until you do it. This cat confessing his love to his sweetheart had an equally scary state of mind. But now, it just feels right.

![Victorian cat from: Ship AI, AI, AI](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-hero.png)

**[Ship AI, AI, AI](/blog/vercel-ship-ai-2025)** (October 2025, DALL-E 3)

A conference cat. Vercel Ship was wall-to-wall AI announcements. This cat attended and has thoughts.

![Victorian cat from: React Server Components CVE-2026-23864](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/react-server-components-cve-2026-23864-what-you-need-to-know-blog-hero.jpg)

**[React Server Components CVE-2026-23864: what you need to know](/blog/react-server-components-cve-2026-23864-what-you-need-to-know)** (January 2026, GPT-Image-1.5)

To say how much of a headache this was at the time, this happened to coincide with our new rendering tech. This is the latest version of the imagery we were working with, and paved way to pre-baked black and white on the next one.

![An extremely round Victorian cat inventor working on automation blueprints](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/how-we-use-claude-skills-to-automate-our-workflow-blog-hero-v3.png)

**How we use Claude skills to automate our workflow** (January 2026, GPT-Image-1.5, imagen pipeline)

The automation cat. This one was generated through our full imagen pipeline, so you're seeing it with the grayscale and halftone effects already baked in. It's "an extremely round Victorian cat inventor working on automation blueprints, looking very pleased with himself." One of our favourites.

![A chubby Victorian cat operating a steam train](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/nextjs-16-2-for-dummies-v2-blog-hero.png)

**[Next.js 16.2 for dummies](/blog/nextjs-16-2-for-dummies)** (March 2026, GPT-Image-1.5, imagen pipeline)

The steam train cat. A chubby Victorian cat operating a steam train, looking like it knows exactly where it's going. One of the rounder cats in the collection, and one of the more confident ones.

## The plugin that changed the workflow

In March 2025 we added [sanity-plugin-image-gen](https://www.sanity.io/plugins/sanity-plugin-image-gen) to our Sanity Studio. It's a plugin we built that routes image generation through Next.js API routes and Replicate, giving editors access to models like Flux and Stable Diffusion directly inside the CMS.

Before this, generating a cat meant leaving the studio, going to ChatGPT or the OpenAI API, generating something, downloading it, and uploading it to Sanity. With the plugin, you type a prompt and the image lands in the asset pipeline. It sounds like a small thing but it changed how often we'd regenerate images when the first attempt wasn't right.

The plugin initially used Replicate with Flux models (flux-pro and flux-schnell). The cats from March to June 2025 came through this route. In June we swapped the backend to OpenAI's DALL-E 3, and eventually the whole thing evolved into our dedicated imagen app.

We wrote about the original concept in [Revolutionising visual content creation with Sanity.io and OpenAI](/blog/revolutionizing-visual-content-creation-with-sanityio-and-openai), which started as a DALL-E 2 guide in 2023 and has been updated several times since.

> **Agentic workflow development**: Custom image pipelines, automated content workflows, and AI tooling built around how your team works. [Learn more](/services/agentic-workflows)

## Why Victorian cats?

We get asked this occasionally. The honest answer is that we needed hero images for every blog post and didn't want to spend time on each one. A Victorian cat in an oil painting style was distinctive enough to become a visual identity, weird enough to be memorable, and consistent enough to work across dozens of posts.

Once you've committed to the bit, you have to see it through. Fifty-six cats later, we're still committed.

The halftone treatment on the blog index gives them a unified look even though they were generated by at least four different models across five years: DALL-E (various versions), Replicate Flux, DALL-E 3, and GPT-Image-1.5. In full colour, you can see the evolution. The early cats are soft and impressionistic. The Flux cats have a distinctive painterly texture. The DALL-E 3 cats are sharp and detailed. The modern pipeline cats are the most controlled.

We like all of them. The rough early ones have charm. The detailed later ones have precision. And scrolling through the lot of them, you can actually see how AI image generation has changed since we started using it.

---

## Headless Shopify: what it costs and when it's worth it


> Headless Shopify sounds great until you see the bill. We break down when it makes sense, when it doesn't, and what it actually costs across vanilla Shopify, custom themes, Hydrogen, and Next.js builds.

**TL;DR:** Headless Shopify splits your store in two: Shopify runs checkout and inventory, you build the storefront in Next.js. It's worth it only when a themed store genuinely can't do the job. Custom builds run from roughly $20,000 to $130,000+, so for most stores it's an expensive answer to a question they don't have.

**Published:** 2026-03-27 | **Updated:** 2026-08-31 | **Categories:** Hot Takes
---

**Headless Shopify** means Shopify keeps running your checkout, inventory, and orders while you build the storefront customers see as a separate app, usually in Next.js. Should you? Only when a themed store genuinely can't do the job. For most stores it's an expensive answer to a question you don't have, with custom builds running from roughly $20,000 to $130,000+. Below is when [a headless Shopify build](/services/shopify) actually pays off, and when it doesn't.

Maybe you've heard the word "headless" thrown around. Someone mentioned "composable commerce" at you in a meeting and you smiled and nodded. Now an agency is pitching you a Shopify headless build and you want to know if _they're full of it_.

We get asked about this a lot. So here's everything we tell clients, including the bits that talk them out of paying us.

> From here on out, I am going to start firing from the hip and making some assumptions from what we've seen. *Expect to catch strays*.

## Regular Shopify build

Vanilla Shopify is the **default** experience, and for most stores, **it's the right one**. A couple hundred products, some collection pages, a decent theme. Done.

Look at these. If your store fits this mould, stop reading and go build it.

### Product listing page

This is a product listing page. As a general rule it has some kind of filter or search. If you're buying a theme, this page is the most important one to get right.

![COS menswear product listing page showing tailored shirts, shorts, and loafers with category navigation and filter controls](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/shopify-headless-guide-cos-product-listing.png)

Run it through [Google's structured data testing tool](https://developers.google.com/search/docs/appearance/structured-data) to check that products are getting listed properly with Google.

### Product details page

Same principle. This is a product detail page.

![COS product detail page for pinstriped relaxed-fit wide-leg trousers showing size selector, price, and add to bag button](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/shopify-headless-guide-cos-product-detail.png)

### Positives

- Cheap. You can run your entire site for the cost of a Wetherspoon's breakfast. Plans start at $39/month, themes are free or $150-450 one-off. *Just with less indigestion.*
- The preview is really nice. It works whatever you throw at it
- Somebody already did the hard work building the theme. You provide good product imagery and a decent logo

### Negatives

- Anything custom is probably a plugin, and that plugin will cost X% of your profits or a monthly fee that makes your eyes water. Average stores run 5-10 paid apps at around $60 each per month
- Performance is decent, not great. It degrades as your catalog grows into the thousands
- This option gets a bad reputation because of drop-shipping wankers on YouTube

## Fully customised Shopify theme

I'll be completely honest: _this is usually a waste of money_. You generally get a worse experience than a default theme. Why? Because that theme above has been used by hundreds if not thousands of stores, open sourced, or sold across multiple environments. Edge cases have been found and fixed. A custom Liquid template, built from scratch by an agency and never tested at scale? You're going to find those edge cases in production, and you'll be paying agency rates to fix them.

### Positives

- If you have complex filtering needs (faceted search, multi-attribute filters, custom product matrices) but still want Shopify's native checkout, apps, and payments, this is the sweet spot
- If your brand is so distinctive that no theme can contain it, this is the only vanilla option
- You're still in Shopify's ecosystem. Checkout, payments, and apps just work

### Negatives

- You're paying agency rates to reinvent wheels that theme developers already perfected. Expect $20,000-50,000 for a mid-range build, $50,000-130,000+ for something complex
- Liquid developers are harder to find than JavaScript developers. The talent pool is shrinking as React and headless pull developers away
- Every edge case is yours. Gift cards breaking on mobile Safari? Your problem
- The agency that built it becomes your permanent dependency. Retainers run $1,500-4,000/month
- Performance is still Shopify infrastructure. You're paying custom prices for theme-tier speed

## What "headless" actually means

Before we get into the headless options, a quick explanation for anyone who's been nodding along without fully knowing what this means.

A normal Shopify store is "monolithic." Shopify handles everything: the product data, the page templates, the checkout, the hosting. It's one system. When a customer visits your store, Shopify's servers render the page using Liquid templates and send it to the browser.

A headless Shopify store splits this into two pieces. Shopify still handles the commerce backend: products, inventory, pricing, cart, checkout, orders. But the frontend (what customers actually see and interact with) is a completely separate application. It talks to Shopify through the [Storefront API](https://shopify.dev/docs/api/storefront/latest), fetching product data and managing carts via GraphQL.

Your frontend can be built with anything. Next.js, Remix, Astro, SvelteKit, a native mobile app. It runs on its own hosting (Vercel, Cloudflare, Shopify's Oxygen). The only connection to Shopify is API calls and a redirect to Shopify's hosted checkout when the customer is ready to pay.

You get total control over the frontend. You also get to maintain two systems instead of one. And you lose access to most of Shopify's 8,000+ app ecosystem, because those apps inject into Liquid themes. Every review widget, loyalty programme, upsell tool, and search plugin needs an API-based replacement or a custom build.

Nobody talks about the app problem enough. It's where the budget blowouts happen.

## Hydrogen headless build

[Hydrogen](https://hydrogen.shopify.dev/) is Shopify's official headless framework. It's built on React Router (formerly Remix). Not Next.js.

Why did I specify that? Because the framework lineage is messy. Remix merged into React Router, and Hydrogen is built on React Router 7. Meanwhile, the Remix team announced that Remix v3 is replacing React with a fork of Preact. It's still a React-like API, but it's not React. The ecosystem splits, the libraries you relied on may or may not work, and the reference material on the web becomes unreliable. If you're building with AI agents or code generation, you'll be constantly correcting tools that assume "Remix means React."

Hydrogen deploys to Oxygen (Shopify's edge hosting), which is available on all Shopify plans from Basic upwards. It comes with Shopify-specific utilities baked in.

### When Hydrogen makes sense

- You want headless performance without wiring up the Storefront API yourself
- Your team knows React Router, or is willing to commit to learning it
- Shopify's metafields and metaobjects cover your content needs (blogs, basic landing pages, nothing complex)

### When Hydrogen is the wrong call

- You need a proper CMS beyond products. Metafields are not a content management system
- Your team already knows Next.js and you'd rather not context-switch
- You want Vercel's preview deployments, analytics, and edge network
- The site isn't primarily a storefront. If content and commerce share equal billing, Hydrogen will fight you

### Positives

- Storefront API integration is solid and well-documented
- Oxygen's edge caching is fast. Properly fast
- Customer accounts, cart, and checkout work without drama
- You're writing React, not starting from zero

### Negatives

- It's React Router. Next.js teams will need adjustment time, and the framework's future direction is uncertain
- Oxygen is not Vercel. Smaller ecosystem, fewer tools, limited logging, no monorepo support
- Locked into Shopify's checkout regardless
- Content management stops at metafields and metaobjects. For anything editorial, you're bolting on a CMS anyway
- When something breaks, you're debugging across React Router, Shopify's API, and Oxygen. Bring coffee

## Next.js + Sanity + Shopify build

This is the best option. I would say that.

It's also the most likely to go wrong. It relies on having [an agency that actually understands all three systems](/services/shopify), or an internal team that does. We've inherited builds where they didn't. It wasn't pretty.

### The architecture

Three layers:

- **Shopify** handles the commerce engine: products, inventory, orders, payments, checkout. It's the source of truth for anything with a price tag
- **Sanity** handles content: blogs, landing pages, the story around your products, SEO metadata. Everything your marketing team touches daily. [Sanity Connect](https://www.sanity.io/docs/apis-and-sdks/sanity-connect-for-shopify) syncs Shopify products into Sanity so editorial content can reference product data without duplicating it
- **Next.js** stitches them together. Server Components fetch from both APIs, Suspense streams content progressively, and Vercel's edge network handles caching and delivery

### This one's for the devs

If you're a marketer, skip to the next section. Devs, carry on.

Next.js is the best framework for this, but do not build account pages custom unless you absolutely have to.

Two approaches:

1. Custom build using Sanity Connect. Product data stays in Shopify. The story around the product lives in Sanity. Your frontend queries both and merges at the component level
2. Use Shopify's Storefront API directly with [`@shopify/hydrogen-react`](https://shopify.dev/docs/api/hydrogen-react/latest). This is a framework-agnostic React library that gives you cart management, product hooks, money formatting, and checkout redirects without committing to Hydrogen or Remix. It works in any React app

For data fetching, the pattern is: cache product pages with ISR, trigger revalidation via Shopify webhooks when products or prices change, and always validate price and stock server-side when adding to cart. Cached pages serve in under 50ms. Shopify Liquid themes run at 300-800ms.

### Positives

- You own the frontend. All of it
- Sanity's editing experience makes Shopify admin look like a spreadsheet
- Vercel's deployment pipeline, preview environments, and analytics
- The React ecosystem you already know
- ISR and streaming mean fast pages without painful build times
- SEO fully in your control. Structured data, meta tags, sitemaps, all yours

### Negatives

- Three systems. Three sets of docs. Three potential failure points
- You need a team that understands all three, or an agency that does
- Higher initial build cost than any other option on this list
- Shopify Plus required for checkout customisation. $2,300-2,500/month before you write a line of code
- Shopify to Sanity sync needs monitoring. Products change, prices change, webhooks occasionally fail
- If something goes wrong, you're debugging three platforms at once

## What the Next.js build unlocks

Faster pages are the easy win. The bigger one is that content can reshape commerce in ways a Liquid theme can't. Here's what that looks like on builds we've shipped.

### Compliance docs that update everywhere at once

Our clearest example is [Slingshot Bio](/case-study/slingshot-bio), a biotech company selling engineered cells. Every product carries regulatory paperwork: a Technical Data Sheet, a Safety Data Sheet, a Certificate of Analysis. Those documents change, and when they do they have to update everywhere the product appears.

We modelled each document once in Sanity and tagged it with the things it applies to: a product family, a brand, a purpose. The product page collects its own identifiers and pulls every document whose "applies to" set overlaps, resolved at query time:

```groq
// Every compliance doc whose "applies to" set includes
// this product, one of its brands, or its purpose.
// $ids = [productId, ...brandIds, ...purposeIds]
*[_type == "resource" && count(appliesTo[_ref in $ids]) > 0]
  | order(publicationDate desc) {
    title, docType, "url": file.asset->url
  }
```

Update one Safety Data Sheet and it propagates to every product that shares that family, brand, or purpose. Nobody re-edits a hundred product pages. [Sanity Connect for Shopify](https://www.sanity.io/docs/apis-and-sdks/sanity-connect-for-shopify) keeps the catalogue mirrored from Shopify into Sanity, so commerce data stays in Shopify while the editorial layer wraps around it.

The same problem shows up in any spec-heavy or regulated catalogue: industrial parts, chemicals, medical devices, B2B components. Shared documents that have to stay current across hundreds of products. References solve it once.

### Collection pages that filter on your own taxonomy

A stock Shopify collection filters on what Shopify knows about a product: vendor, type, tag, price, availability. That's enough until your catalogue has attributes Shopify was never built to hold.

Slingshot's products carry taxonomies that live in Sanity instead: brand, primary purpose, application, product family. The collection page filters on both sources at once. Shopify's Storefront API returns the products and their native facets, a GROQ query returns the handles that match the Sanity taxonomy, and the page intersects the two per request.

```ts
// 1. Products and native facets from Shopify
const { products } = await storefront(COLLECTION_QUERY, { handle, filters });

// 2. Handles that match the Sanity-side taxonomy
const matched = await sanity(productHandlesByTaxonomy, {
  brandIds, purposeIds, applicationIds,
});

// 3. Intersect
const filtered = products.filter((p) => matched.has(p.handle));
```

The customer sees one filter bar. Behind it, each system answers the half of the question it's good at. A Liquid theme can bolt a search app on top, but it can't filter a collection on data that lives outside Shopify. That ownership runs through the buying journey too: on a B2B catalogue you can turn a cart into a downloadable quote, which Shopify's hosted flow won't do for you.

### Structured data that stays correct

Because the storefront builds pages from synced data, the structured data comes from that same data. No plugin guessing at your markup. The `schema.org/Product` JSON-LD is generated from the exact product object the page renders:

```tsx
const jsonLd = {
  "@context": "https://schema.org",
  "@type": "Product",
  name: product.title,
  description: product.description,
  brand: { "@type": "Brand", name: product.vendor },
  offers: variants.map((v) => ({
    "@type": "Offer",
    price: v.price.amount,
    priceCurrency: v.price.currencyCode,
    availability: v.availableForSale
      ? "https://schema.org/InStock"
      : "https://schema.org/OutOfStock",
  })),
};
```

A price changes in Shopify, a webhook triggers ISR revalidation, and the page and its structured data update together. The version we ship does more than the snippet above (per-variant offer URLs, guards for variants with broken prices), but the principle holds: the markup and the page can't disagree, because they come from the same object. The same revalidation keeps Sanity-driven content current.

### Pages that machines can read

A growing share of your visitors are agents. ChatGPT, Claude, and Perplexity render JavaScript poorly, stumble on navigation and cookie banners, and work with small context windows.

Owning the frontend lets you serve them a clean version of any page through [content negotiation](https://vercel.com/blog/making-agent-friendly-pages-with-content-negotiation): the same URL returns markdown when an agent asks for it and HTML when a browser does. On our own site the markdown twin of a page is roughly 94% smaller than the HTML. For a regulated catalogue where an AI buyer is comparing specs, that means getting cited accurately instead of getting skipped. We wrote up the full pattern in [our Next.js AEO/GEO guide](/blog/nextjs-aeo-geo). On the Slingshot build we go a step further and publish a machine-readable API catalogue at `/.well-known/api-catalog`, so an agent can discover the storefront and content endpoints instead of guessing at them.

### Commerce an agent can shop

We pushed that idea further with Turbo Start Aisle, an AI shopping assistant built on top of our Shopify starter. It uses [Sanity's Agent Context](https://www.sanity.io/docs/agent-actions) over MCP to give the assistant structured, read-only access to the catalogue, so it can narrow products by brand, size, and colour and render real product cards inline.

None of that works when Shopify renders your pages. You own the frontend to decide what a machine sees.

### Two builds on the same stack

    The regulated-catalogue build. Compliance documents are modelled in Sanity and referenced through categories, so they surface across every product in a line automatically, with structured data and agent-readable pages on top. A standard theme wouldn't survive the first compliance review.

    A luxury antiques and lighting replatform on standard Shopify. We merged two legacy URL spaces into one and held the rankings through the cutover: every URL mapped before launch, redirects shipped on launch day, internal links wired through CMS references rather than hardcoded slugs.

One sells cells, one sells antiques, and both run on Next.js, Sanity, and the Storefront API. The [CMS migration service](/services/cms-migration) covers the replatform mechanics in depth.

## Do you actually need Shopify Plus?

This is the question nobody answers clearly. Shopify Plus costs $2,300/month on a three-year contract, $2,500/month on a one-year. That's up from the ~$2,000 figure you'll see in older blog posts.

You **don't** need Plus for:

- Using the Storefront API. It works on all plans, with no rate limits on storefront queries
- Building a headless storefront with any framework
- Hosting on Oxygen. Available on Basic and above
- Cart management via the Cart API
- The new Customer Account API with SSO

You **do** need Plus for:

- Checkout customisation. This is the big one. Checkout Extensibility (custom fields, layout modifications, upsells in checkout, Shopify Functions) is Plus-only. Without it, your headless checkout is Shopify's default, take it or leave it
- Running more than one headless storefront. Plus gets 25. Standard plans get one
- B2B and wholesale: company profiles, custom pricing, net payment terms
- Admin API rate limits that can handle heavy inventory syncs (500 points/second vs 50 on standard)
- Expansion stores for multi-region setups (up to 9 included)

The honest answer: if your headless store reads products, manages a cart, and sends customers to Shopify's standard checkout, you can do it on a Basic plan. The moment you need to customise the checkout experience, run multiple storefronts, or sell B2B, you need Plus.

One thing to watch: Shopify deprecated legacy customer accounts in February 2026. Multipass, the old way to maintain auth between your headless frontend and Shopify's checkout, is being phased out. The new Customer Account API with OAuth replaces it and works on all plans, but if you're on an older headless build using Multipass, migration is coming whether you want it or not.

## What it actually costs

Everyone says "it depends." Here are real numbers.

| | Vanilla Shopify | Custom theme | Hydrogen | Next.js + CMS + Shopify |
|---|---|---|---|---|
| **Initial build** | $0-6,000 | $20,000-130,000 | $50,000-250,000 | $65,000-300,000 |
| **Monthly platform** | $39-399 | $105-399 | $2,300-2,500 (Plus) | $39-399 without Plus<br/>$2,300-2,500 with Plus |
| **Monthly hosting** | Included | Included | Included (Oxygen) | $20-100 (Vercel) |
| **Monthly CMS** | N/A | N/A | N/A | $0-45 (Sanity) |
| **Monthly apps** | $60-200 | $60-200 | Less, but pricier | Less, but pricier |
| **Agency retainer** | $500-10,000 | $5,000-25,000 | $5,000-25,000 | $5,000-25,000 |
| **Year-one total** | ~$12,000 | ~$100,000 | ~$230,000 | ~$150,000 without Plus<br/>~$180,000 with Plus |
| **Year-two onwards** | ~$8,000/yr | ~$65,000/yr | ~$100,000/yr | ~$65,000/yr without Plus<br/>~$100,000/yr with Plus |

You don't always need Plus for a headless Next.js build. If you're sending customers to Shopify's standard checkout without customisation, a Basic or Grow plan works fine with the Storefront API. That saves you $2,000+/month.

These assume mid-range builds and a standard agency retainer. Your numbers will vary based on complexity, integrations, and where your agency is based.

> **Headless Shopify development**: Custom storefronts with Next.js, total design control, and Shopify backend integration. [Learn more](/services/shopify)

A few things the table doesn't show:

- **App replacement costs.** Going headless means losing access to most Shopify apps. Reviews, loyalty programmes, upsells, search. Each one needs an API-based alternative or custom build. Budget an extra $7,000-25,000 for replacements
- **Vercel overages.** Traffic spikes (flash sales, viral moments) can push hosting costs up unexpectedly. Set spend caps
- **Monitoring.** Distributed systems need proper observability. Sentry, OpenTelemetry, error tracking. Add $25-65/month

## Five questions before you go headless

Skip the "should I go headless" debate and answer these instead.

**1. Does your content need more than Shopify can give it?**

If your product pages are just photos, specs, and a buy button, Shopify's admin is fine. If you need editorial landing pages, product storytelling beyond a description field, blog content that ties into products, or marketing teams editing pages daily, you need a proper CMS. That's a headless signal.

**2. Is your team (or agency) comfortable with React and APIs?**

Headless means your frontend team owns everything. Routing, caching, SEO, performance, accessibility. If your team builds Liquid themes, this is a different discipline. If they build React apps, they'll feel at home.

**3. Can you afford the ongoing cost?**

The build is the cheap part. Headless stores need continuous maintenance: API version updates (Shopify ships quarterly), framework upgrades, cache invalidation debugging, webhook monitoring. Budget $5,000-25,000/month for ongoing care depending on complexity.

**4. Do you have fewer than 10,000 products?**

Headless shines for stores where the product story matters more than the product count. Luxury goods, bespoke items, complex configurators. If you're running a catalog with 50,000 SKUs and basic filtering, a good Shopify theme with Algolia search will outperform a headless build for a fraction of the cost.

**5. Do you need checkout customisation?**

If the answer is no, you can build headless on a Basic Shopify plan and save yourself $2,000+/month. If the answer is yes, you need Plus, and you should be very specific about what "customisation" means. Adding a gift message field is different from rebuilding the entire checkout flow.

## The Storefront API in plain English

This section is for the CTO briefing a team, or the founder trying to understand what their agency is building.

The [Storefront API](https://shopify.dev/docs/api/storefront/latest) is Shopify's customer-facing API. GraphQL-only, no REST. You query it for products, collections, and content. You mutate it to create carts, add items, apply discounts, and attach customer identity. When the customer is ready to pay, the cart object gives you a `checkoutUrl` that redirects to Shopify's hosted checkout.

**What it can do:** product browsing, collection filtering, cart management, customer auth, search, predictive search, metaobject queries.

**What it cannot do:** create or edit products, manage inventory, process orders, handle refunds, manage fulfillment, subscribe to webhooks. Those require the Admin API, which runs server-side and is subject to rate limits based on your plan.

**Authentication** comes in two flavours. Public access tokens are safe to use in browser code and scale per buyer IP. Private access tokens must stay on your server and should include the buyer's IP in a header so Shopify can differentiate traffic.

Shopify removed rate limits on the Storefront API entirely, so your storefront won't get throttled during flash sales regardless of your plan. The Admin API still has rate limits: 50 points/second on standard, 500 on Plus.

One practical note: the old Checkout API was shut down in April 2025. If you're reading tutorials that reference `checkoutCreate` mutations, they're outdated. Everything goes through the Cart API now.

## Things to consider

Before committing to headless, a few realities worth understanding.

### You don't own checkout

Hydrogen, Next.js, whatever you use: customers are redirected to Shopify's hosted checkout. You can customise it with Checkout UI Extensions on Plus, but you're not building a custom checkout from scratch. Your brand experience ends at the cart. Even with Plus and Checkout Extensibility, you're adding blocks and extensions within Shopify's checkout UI. You do not control the DOM.

If you need to own checkout completely, Shopify isn't the platform.

### Account pages are a rabbit hole

Shopify deprecated legacy customer accounts in February 2026. The old Multipass authentication (which let you pass authenticated users from your headless frontend to checkout without re-login) is being phased out.

The replacement is the [Customer Account API](https://shopify.dev/docs/api/customer/latest), which uses OAuth 2.0 with PKCE. It maintains sessions properly across your frontend and checkout, supports social login and email/phone OTP. It's more complex to implement but solves the "customer logs in twice" problem that plagued the legacy system.

Our advice: don't build custom account pages. Redirect account management to Shopify's hosted pages and spend your development budget on things that differentiate your store.

### The app ecosystem problem

This is the one that catches people off guard. Shopify's app store has 8,000+ apps. Reviews, loyalty programmes, upsells, live chat, search, email capture. The vast majority inject into Liquid themes and do not work with headless storefronts.

Going headless means auditing every app you use and finding API-based alternatives or building the functionality custom. Klaviyo and Yotpo have APIs. Smaller apps often don't. Budget for this.

### Before you go headless at all

Consider whether these solve your actual problem without the headless overhead:

**Checkout UI Extensions.** Custom fields, upsells, loyalty points injected into Shopify's checkout. React components, no headless required.

**Shopify Functions.** Custom discount logic, delivery restrictions, payment rules based on cart contents. Custom backend logic during checkout.

**Online Store 2.0 + metafields.** The newest Liquid themes are good. Better than most developers give them credit for. Combine them with metafields and metaobjects for custom content, and you can build surprisingly flexible storefronts without leaving Shopify.

## Steal our code

We've been building headless Shopify storefronts with Sanity and Next.js long enough to know what works and what's a waste of time. So we open-sourced it.

[`turbo-start-shopify`](https://github.com/robotostudio/turbo-start-shopify) is our production starter for headless Shopify builds. It uses [Sanity Connect for Shopify](https://www.sanity.io/docs/apis-and-sdks/sanity-connect-for-shopify) to sync product data into Sanity, pairs it with a full Sanity content layer (page builder, blogs, landing pages, product editorial), and runs on Next.js with the performance patterns we've covered in this post.

The focus is product story, not product volume. This isn't built for stores with 50,000 SKUs and basic grid layouts. It's built for brands where the narrative around the product matters as much as the product itself. Luxury goods, bespoke manufacturing, specialist retailers. Stores where a customer reads before they buy.

It's also the foundation for more unusual commerce needs, like the [Slingshot Bio](/case-study/slingshot-bio) build above, where regulatory compliance lives inside the product journey rather than bolted on after. A standard Shopify theme wouldn't survive the first stakeholder meeting.

The starter is public now. Go poke around, steal what's useful, and if you break something, open an issue.

If you're weighing up your options and want a second opinion, [we do this quite a bit](/services/shopify). We've built these storefronts, inherited ones that needed rescuing, and talked plenty of clients out of headless when it wasn't the right call. [Get in touch](/contact) and we'll tell you what we actually think.

---

## Next.js 16.2 for dummies


> Faster dev server, faster rendering, 200+ Turbopack fixes. Here's what actually matters.

**TL;DR:** Next.js 16.2 is a point release that punches way above its weight. Dev startup is ~87% faster, rendering dropped 25-60%, and Turbopack got 200+ fixes. We upgraded our own site and the whole thing took about five minutes. Here's what changed and why you should care.

**Published:** 2026-03-19 | **Updated:** 2026-07-23 | **Categories:** Next.js
---

A few months ago we wrote about [Next.js 16 for dummies](/blog/nextjs-16-for-dummies). That post covered the big stuff: Turbopack by default, opt-in caching, React 19.2. If you haven't read it, go do that first. We'll wait.

This is 16.2. A point release. You'd expect a handful of bug fixes and maybe a deprecation warning or two. Instead, Vercel shipped a release that genuinely changes how fast your dev environment feels. The kind of update where you notice the difference before you read the changelog.

## What's new and shiny

### Dev server startup (~87% faster)

The headline number is wild. Next.js 16.2 starts your dev server roughly **87% faster** than 16.1, or about a 4x speed ratio. Turbopack got lazier about compilation (in the good way) and smarter about module resolution, so it defers work until the browser actually requests a route instead of eagerly compiling everything on startup.

`next dev` goes from "let me grab a coffee" to "oh, it's already running." On large apps with hundreds of routes, the difference is obvious.

### Rendering is faster (25-60%)

This isn't even a Next.js change. It's a React core optimization. The previous implementation used a `JSON.parse` reviver callback, which crosses the C++/JavaScript boundary in V8 for every key-value pair. Even a trivial no-op reviver makes `JSON.parse` roughly 4x slower. The new approach uses plain `JSON.parse()` followed by a recursive walk in pure JavaScript, eliminating the boundary-crossing overhead entirely. Pages render **25-60% faster** depending on complexity.

Real numbers from the Vercel benchmarks:

- **Server component table:** 19ms → 15ms (26% faster)
- **Payload CMS homepage:** 43ms → 32ms (34% faster)
- **Payload CMS rich text page:** 52ms → 33ms (60% faster)

If your app is heavy on server components (and it should be), you get this for free just by upgrading.

### Server fast refresh

Browser-style HMR for server code is now the **default behavior**. In 16.1 this was behind an experimental flag; now it just works.

When you edit a server component, Next.js now only re-executes the changed module and its dependents, not the entire import chain. That's **67-100% faster app refresh**. Internally, Vercel measured **400-900% faster compile times** on the Next.js codebase itself.

If full-page reloads when editing server code have been annoying you, this is the fix.

### ImageResponse is dramatically faster

The `ImageResponse` API (for generating OG images) is now **2-20x faster**. Not a typo. The range depends on image complexity, but even 2x is worth having.

What else changed:

- **More CSS support**, including flexbox gaps, text decoration, and more border properties
- **Geist Sans as the default font** instead of whatever system font your server happened to have
- **Better error messages** that actually tell you why your OG image JSX broke

We use `ImageResponse` in [turbo-start-sanity](https://github.com/robotostudio/turbo-start-sanity) for every project's OG images, so this one hits close to home.

### Browser log forwarding

Errors thrown in the browser are now **forwarded to your terminal by default**. No more switching between browser DevTools and your terminal to piece together what went wrong.

You can configure the level of forwarding with `logging.browserToTerminal` in `next.config.ts`:

```typescript title="next.config.ts"
const nextConfig = {
  logging: {
    browserToTerminal: true,
    // 'error' — errors only (default)
    // 'warn'  — warnings and errors
    // true    — all console output
    // false   — disabled
  },
}
```

Sounds small, but not having to switch between browser DevTools and your terminal is one of those things you didn't know you wanted.

### Turbopack: 200+ fixes

This is the bulk of the release by commit count. Over 200 bug fixes and improvements to Turbopack. The highlights:

- **Tree shaking for dynamic imports**: `import()` expressions now get tree-shaken properly, reducing bundle sizes
- **SRI (Subresource Integrity) support**: for apps that need content security policies with integrity hashes
- **Web worker origin fix**: workers now correctly inherit the app's origin
- **`postcss.config.ts` support**:TypeScript PostCSS configs finally work without the `.js` workaround
- **`turbopack.ignoreIssue`**: suppress noisy warnings from third-party packages that spam your terminal
- **Lightning CSS configuration**: more control over CSS processing

If Turbopack felt slightly rough around the edges in 16.0, this release sands them down considerably. We haven't hit any Turbopack issues since upgrading.

### Debugging tools

A grab bag of DX improvements that make debugging less painful:

- **Server function logging**: see exactly which server functions are being called and when
- **Hydration diff indicator**: when a hydration mismatch occurs, you get a visual diff showing exactly what the server rendered versus what the client expected
- **Error cause chains**: errors now preserve and display the full `cause` chain, so you can trace the root issue instead of just seeing the surface error
- **`--inspect` for `next start`**: attach a debugger to your production server
- **New default error page**: the development error overlay got a redesign that's easier to read and navigate

### AGENTS.md in create-next-app

Next.js now ships an `AGENTS.md` file in every new project created with `create-next-app`. This gives AI coding agents (Cursor, Claude Code, Copilot, whatever you're using) contextual information about the Next.js APIs and conventions.

The docs are bundled directly in the npm package, so agents always have access to the correct version's documentation. Vercel reports a **100% pass rate on their internal evals** with this context in place.

We've been doing this manually in our projects for months (you're reading the output of one such agent right now), so it's good to see it baked in.

> **Next.js app development**: Next.js performance tuning, dev server optimization, and production builds. [Learn more](/services/nextjs)

### Adapters are stable

The `adapterPath` config option is now **stable** (was alpha). Build adapters let you customize how Next.js packages your app for different hosting platforms.

New in this release is the `onBuildComplete` hook, which lets platforms run custom logic after the build finishes, like generating platform-specific manifests or uploading assets.

> Our opinion hasn't changed: just use Vercel. But if you can't, at least the adapter API is now stable enough to trust.

### `transitionTypes` on `<Link>`

The `<Link>` component now accepts a `transitionTypes` prop, an array of strings that specifies the types of view transitions to apply when navigating. Each type is passed to `React.addTransitionType` during the navigation transition, letting you trigger different animations based on direction or context:

```tsx
<Link href="/about" transitionTypes={['slide']}>
  About
</Link>
```

This is a stable API, not behind an experimental flag. Only works with App Router since Pages Router doesn't use React transitions for navigation.

### Experimental bits

A few things landed behind experimental flags:

- **`unstable_catchError()`**: catch errors in server components without an error boundary
- **`unstable_retry()`** in `error.tsx`: programmatic retry that calls `router.refresh()` and `reset()` within a `startTransition()`, re-fetching data instead of just clearing the error state
- **`prefetchInlining`**: bundle all segment data for a route into a single response instead of per-segment requests

These are `unstable_` prefixed, so don't build your production app around them yet. Worth keeping an eye on, though.

## Our upgrade experience

We upgraded this site (a pnpm monorepo with two Next.js apps) from 16.1.6 to 16.2.0. The process was exactly one command:

```bash
pnpm add next@16.2.0 --filter=web --filter=imagen
```

No breaking changes. No config updates. No code modifications. The whole thing took about five minutes, most of which was waiting for `pnpm install` to finish.

### Where you actually feel it

The honest answer is that 16.2 is a **dev experience release**, not a build performance one. When we benchmarked clean production builds across both versions, the numbers were effectively identical:

| App | Next.js 16.1.6 | Next.js 16.2.0 | Change |
| --- | --- | --- | --- |
| Web (full site) | 21.9s | 22.4s | Within noise |
| Imagen (API) | 5.8s | 5.4s | Within noise |

But our site was already building stupidly fast. When we [upgraded to Next.js 16](/blog/nextjs-16-for-dummies), Turbopack cut our build times dramatically. There just isn't much left to shave off for an average-sized site. If your production build already finishes in under 30 seconds, don't expect 16.2 to change that.

Where 16.2 *really* shines is in the day-to-day. The dev server starts faster, server components hot-reload without blowing away the whole page, and browser errors show up in your terminal without you having to context-switch. None of that shows up in a build benchmark, but you feel it every time you save a file. You only notice how good it is when you go back to an older version and wonder how you put up with the lag.

Here's a rough benchmark of the experience difference we've had since updating. It's not scientific, but it captures what the day-to-day actually feels like:

For large apps with heavy server component trees, the 25-60% rendering improvements will show up in production too. For sites our size, the win is almost entirely about how it **feels** to develop.

If you want to see what this stack looks like in practice, our open-source starter [turbo-start-sanity](https://github.com/robotostudio/turbo-start-sanity) runs Next.js with Turbopack for dev, Turborepo for monorepo orchestration, React Compiler, `ImageResponse` for OG images, and experimental CSS inlining. It's the same foundation we use for every [Next.js project](/services/nextjs) we ship. We dogfood every release on our own site first, usually breaking something in the process so our clients don't have to. The starter's getting bumped to 16.2 in the next day or two.

## Quick comparison

| Feature | 16.1.6 | 16.2.0 |
| --- | --- | --- |
| Dev startup | Baseline | ~87% faster |
| HTML rendering | Baseline | 25-60% faster |
| Server fast refresh | Experimental flag | Default |
| ImageResponse | Baseline | 2-20x faster |
| Browser logs in terminal | Off | On by default |
| Turbopack stability | Good | 200+ fixes better |
| Build adapters | Alpha | Stable |
| AGENTS.md | Manual | Ships with create-next-app |

## How to upgrade

### Option 1: automatic upgrade (recommended)

```bash
npx @next/codemod@canary upgrade latest
```

### Option 2: manual upgrade

```bash
npm install next@latest react@latest react-dom@latest
```

### Option 3: start fresh

```bash
npx create-next-app@latest
```

## Closing thoughts

Nothing breaks, everything gets faster. The dev server startup improvement alone is worth the upgrade, and the rendering gains are free just by bumping the version. If you're coming from an older release, read our [Next.js 16.1 post](/blog/nextjs-16-1-for-dummies) first to catch up on what you missed.

Need help upgrading, or want us to [build your Next.js project](/services/nextjs) from scratch? We pair it with [Sanity](/services/sanity) on most projects, and the two together are hard to beat. [Get in touch](/contact).

---

## Clean your GROQ


> How to structure GROQ queries that stay readable as your Sanity project grows. Fragment-based patterns with code examples.

**TL;DR:** GROQ queries have a way of becoming the scariest file in your repo. Fragment-based architecture fixes that by breaking queries into atomic, composable building blocks that stay clean, testable, and onboarding-friendly.

**Published:** 2026-03-16 | **Updated:** 2026-07-28 | **Categories:** Sanity, How To, Hot Takes
---

Have you written a GROQ query that felt like Walter White cooking in an RV? Powerful, slightly dangerous, and held together with hope and duct tape. The moment your queries go from "simple" to "nested twelve levels deep with filters, joins, conditionals, projections, and vibes," you feel it. But GROQ isn't the problem. It's your architecture. Here's how to turn unmaintainable queries into code your future self won't want to git blame.

## Modern GROQ query optimization

GROQ is Sanity's open-source query language, and it's basically what you get when you ask, "What if querying content didn't feel like wrestling a REST endpoint?" It lets you filter, sort, transform, and reshape data. You can filter October events, stitch together five document types, and reshape data before your frontend even wakes up, but at scale, it becomes the spiritual successor to "that one regex nobody wants to touch."

It's genuinely good at pulling together complex, multi-document structures and turning them into neat little JSON objects. For big datasets and intricate content models, GROQ feels like cheating.

The thing is, GROQ gives you total freedom. You can ask it precisely what you want, and it gives you exactly that. No overfetching, no REST gymnastics, no GraphQL boilerplate sermons. Just raw, precise querying. Which is great… right up until your query becomes a 70-line monster that nobody wants to maintain.

## GROQ complexity starts with scaling

As we said before, the moment you scale past a couple of tidy queries, things go from "elegant data language" to "who wrote this and are they okay?" You end up with dense, repetitive query chains that stretch across half your screen, nested filters you're scared to touch, and projections so long they need their own scroll bar. Modify one line and you feel like you're making a Jenga move in front of your entire engineering team.

We obviously don't work like this, but you definitely don't want this kind of chaos spreading across your repo or onboarding a new developer into this cinematic universe of pain.

Consider this nightmare scenario:

```typescript
const pageQuery = groq`
*[_type  "page" && slug.current  $slug][0]{
  ...,
  pageBuilder[]{
    ...,
    buttons[]{
      ...,
      url{
        ...,
        internal->{
          slug
        }
      }
    },
    categories->{
      title
    },
    richText[]{
      ...,
      markDefs[]{
        ...,
        customLink{
          ...,
          internal->{
            slug
          }
        }
      }
    },
    link{
      ...,
      internal->{
        slug
      }
    },
    image{
      ...,
      "alt": coalesce(asset->altText, asset->originalFilename, "Image-Broken"),
      "blurData": asset->metadata.lqip,
    },
    "faqs": faqs[]->{
      title,
      richText[]{
        ...,
        markDefs[]{
          ...,
          customLink{
            ...,
            internal->{
              slug
            }
          }
        }
      }
    },
    "members": members[]->{
      name,
      position,
      image{
        ...,
        "alt": coalesce(asset->altText, asset->originalFilename, "Image-Broken"),
        "blurData": asset->metadata.lqip,
      }
    }
  }
}`;
```

Now, this query is extremely difficult to comprehend, debug, and maintain. But we are here to say that there's a better way.

## The modern solution: fragment-based architecture

GROQ is just text. Plain JavaScript strings, which means we can actually structure them. Once that clicked, we rebuilt our entire approach around fragments. Small, and reusable building blocks that turn sprawling, uneditable query monsters into clean, modular pieces you can rearrange, extend, and fix without sweating. Here's the exact pattern or cheat sheet we now use to keep GROQ readable, scalable, and onboarding-friendly:

### 1. Start with atomic fragments

Begin by identifying the smallest reusable units in your queries. These become your atomic fragments:

```typescript
const imageFragment = /* groq */ `
  image{
    ...,
    "alt": coalesce(asset->altText, asset->originalFilename, "Image-Broken"),
    "blurData": asset->metadata.lqip,
    "dominantColor": asset->metadata.palette.dominant.background,
  }
`;

const customLinkFragment = /* groq */ `
  ...customLink{
    openInNewTab,
    "href": select(
      type == "internal" => select(
        internal->_type == "headlessCms" => "/migration/" + internal->slug.current,
        internal->slug.current
      ),
      type == "external" => external,
      "#"
    ),
  }
`;

const buttonsFragment = /* groq */ `
  "buttons": array::compact(buttons[]{
    text,
    variant,
    _key,
    _type,
    "openInNewTab": url.openInNewTab,
    "href": select(
      url.type == "internal" => url.internal->slug.current,
      url.type == "external" => url.external,
      url.href
    ),
  })
`;
```

Each of these fragments does one thing well. `imageFragment` handles image resolution with alt text fallbacks and blur data. `customLinkFragment` resolves internal and external links with smart routing. `buttonsFragment` maps button arrays into clean, frontend-ready objects. They're small, readable, and you'll reuse them everywhere.

### 2. Build composite fragments

Combine atomic fragments into more complex, reusable components:

```typescript
const markDefsFragment = /* groq */ `
  markDefs[]{
    ...,
    ${customLinkFragment}
  }
`;

const richTextFragment = /* groq */ `
  richText[]{
    ...,
    ${markDefsFragment},
    _type == "imageGrid" => {
      ...,
      columns,
      "items": array::compact(items[]{
        ...,
        ${imageFragment}
      })
    }
  }
`;

const blogAuthorFragment = /* groq */ `
  authors[0]->{
    _id,
    name,
    position,
    "socials": socials{
      linkedin,
      twitter,
      peerlist
    },
    ${imageFragment}
  }
`;
```

See how `richTextFragment` composes `markDefsFragment` and `imageFragment`? Each layer builds on the one below. You never repeat yourself, and when you update `imageFragment`, every query that uses it gets the fix automatically.

### 3. Create block-level fragments

For page builders and complex content structures, create block-level fragments that handle entire components:

```typescript
const heroBlock = /* groq */ `
  _type == "hero" => {
    ...,
    ${imageFragment},
    ${buttonsFragment},
    ${richTextFragment}
  }
`;

const ctaBlock = /* groq */ `
  _type == "cta" => {
    ...,
    ${richTextFragment},
    ${buttonsFragment},
  }
`;

const faqAccordionBlock = /* groq */ `
  _type == "faqAccordion" => {
    ...,
    "faqs": array::compact(faqs[]->{
      title,
      _id,
      _type,
      ${richTextFragment}
    })
  }
`;

const teamBlock = /* groq */ `
  _type == "team" => {
    ...,
    ${richTextFragment},
    "members": members[]->{
      _id,
      name,
      position,
      bio,
      "socials": socials{ linkedin, twitter, peerlist },
      ${imageFragment}
    }
  }
`;
```

Each block uses the `_type == "..." => { ... }` conditional projection pattern. This means a single `pageBuilder[]` array query can handle every block type polymorphically, no frontend switch statements needed.

### 4. Compose page-level queries

Finally, combine all fragments into clean, readable page queries:

```typescript
const pageBuilderFragment = /* groq */ `
  pageBuilder[]{
    ...,
    _type,
    ${heroBlock},
    ${ctaBlock},
    ${faqAccordionBlock},
    ${teamBlock},
    ${reviewsBlock},
    ${imageGridBlock},
    ${mediaBlock},
    ${newsletterBlock},
  }
`;

export const queryHomePageData = defineQuery(/* groq */ `
  *[_type  "homePage" && _id  "homePage"][0]{
    ...,
    _id,
    _type,
    "slug": slug.current,
    title,
    description,
    ${pageBuilderFragment}
  }
`);

export const queryBlogSlugPageData = defineQuery(/* groq */ `
  *[_type  "blog" && slug.current  $slug][0]{
    ...,
    "slug": slug.current,
    ${blogAuthorFragment},
    ${imageFragment},
    ${richTextFragment},
    overview,
    publishedAt,
    _updatedAt,
    "faqs": faqs[]{
      _key,
      question,
      "answer": answer[]{
        ...,
        ${markDefsFragment}
      }
    },
    ${pageBuilderFragment}
  }
`);
```

Look at that `queryBlogSlugPageData`. It pulls in author data, images, rich text, FAQs, and an entire page builder, and it's still readable. You can see exactly what data you're fetching at a glance. Try doing that with a 120-line inline query.

## Best practices for production GROQ

If you've made it this far, you already know GROQ can either be a joy or a long-term liability. A few production habits save you from debugging nightmares later, when no one remembers who wrote that query or why.

### Type-safe query definitions

Do yourself a favour and always wrap queries with `defineQuery` from `next-sanity`. It keeps your types in sync, catches silly mistakes before they hit prod, and stops your editor from acting like it has no idea what data you're asking for. If you're pairing Sanity with [Next.js](/services/nextjs), this is non-negotiable.

```typescript
import { defineQuery } from "next-sanity";

// Types are automatically inferred from the query
export const getPageQuery = defineQuery(/* groq */ `
  *[_type  "page" && slug.current  $slug][0]{
    title,
    description,
    ${pageBuilderFragment}
  }
`);
```

### Smart data transformation

GROQ gives you built-ins that can do half your cleanup before the data even reaches your frontend. Use them. Format dates, slice arrays, merge fields, and filter edge cases right inside the query. It keeps your components simple and stops you from writing 14 helper functions called `formatSomething()`.

```groq
// Let GROQ do the heavy lifting
"href": select(
  url.type == "internal" => url.internal->slug.current,
  url.type == "external" => url.external,
  url.href
),
"alt": coalesce(asset->altText, asset->originalFilename, "Image-Broken"),
"buttons": array::compact(buttons[]{...})
```

### Conditional block rendering

If your frontend is full of `if/else` to decide which block should show up, you're doing extra work for no reason. Push that logic into GROQ. Let the query decide what gets returned (and what doesn't), so your components only render what actually matters.

```groq
pageBuilder[]{
  _type == "hero" => { ..., ${imageFragment} },
  _type == "cta" => { ..., ${buttonsFragment} },
  _type == "faqAccordion" => { ..., ${faqFragment} },
}
```

### Always explicit projections

The `...` operator feels convenient, but what happens when shipping fields you didn't even know existed? Don't do that to yourself (or your build times). List every field you actually need. It keeps queries predictable, keeps payloads lean, and stops accidental "why is this field here?" moments.

```typescript
// Bad — fetches everything, including fields you don't use
const query = groq`*[_type == "blog"][0]{ ... }`;

// Good — explicit about what you need
const query = groq`*[_type == "blog"][0]{
  title,
  "slug": slug.current,
  description,
  publishedAt,
  ${imageFragment},
  ${blogAuthorFragment}
}`;
```

### Always use parameters, not string interpolation

String-interpolating variables into a GROQ query is how security bugs and broken queries sneak in undetected. Use `$params` every single time. It keeps your queries safe, predictable, and way easier to debug. If you ever catch yourself writing `${id}` for a runtime value, please, please stop.

```typescript
// Bad — string interpolation for runtime values
const query = groq`*[_type  "blog" && slug.current  "${slug}"][0]`;

// Good — parameterized query
const query = groq`*[_type  "blog" && slug.current  $slug][0]`;
// Then pass { slug } as params to your fetch call
```

> **Sanity CMS development**: GROQ optimization, schema design, and performance tuning for Sanity projects. [Learn more](/services/sanity)

### Use consistent naming conventions

Name your fragments so future-you (or your team) can understand them. Stick to a simple rule like suffixing reusable bits with `Fragment` and full components with `Block`. Just remember, the name should be as descriptive as possible.

```typescript
// Atomic — describes what it resolves
const imageFragment = /* groq */ `...`;
const buttonsFragment = /* groq */ `...`;
const customLinkFragment = /* groq */ `...`;

// Block-level — describes what component it powers
const heroBlock = /* groq */ `...`;
const ctaBlock = /* groq */ `...`;
const faqAccordionBlock = /* groq */ `...`;

// Page-level — uses defineQuery, prefixed with query verb
export const queryHomePageData = defineQuery(/* groq */ `...`);
export const queryBlogSlugPageData = defineQuery(/* groq */ `...`);
```

### Organize by complexity

Keep atomic pieces together, bundle mid-level components separately, and stash full page-level blocks in their own folder. Or at minimum, keep them in order within a single file, atomic at the top, page-level exports at the bottom.

### Use TypeScript comments

Use `/* groq */` before your queries so your editor highlights them instead of treating them like sad multiline strings. It makes scanning, debugging, and refactoring far easier.

## Performance benefits

Once you switch to a fragment-based setup, the performance difference is noticeable.

Instead of copy-pasting the same projection across seven queries (we've all done it, no shame), fragments keep everything DRY and predictable. That means the CDN can cache your responses properly instead of treating every slightly-different query as a new snowflake. You also stop over-fetching half your dataset "just in case," because each fragment forces you to be explicit about what you need. Smaller queries mean faster responses, which leads to fewer Slack messages asking "why is the page still loading?"

Development gets faster, too. When your queries are modular, page-level builds become Lego. Snap pieces together, ship, move on with your day.

## GROQ cheat sheet

Everything above is the architecture. This is the syntax you'll reach for while building it.

### Filtering

| Pattern | What it does |
| --- | --- |
| `*[_type  "post"]` | Every document of one type |
| `*[_type in ["post", "page"]]` | Several types at once |
| `*[_type  "post" && defined(slug.current)]` | Skip documents missing a field |
| `*[_type  "post" && slug.current  $slug][0]` | One document by slug, via a parameter |
| `*[title match "sanity*"]` | Wildcard match, case-insensitive |
| `*[references($id)]` | Documents pointing at a given document |
| `*[!(_id in path("drafts.**"))]` | Published only, no drafts |

### Projections and joins

| Pattern | What it does |
| --- | --- |
| `{title, "slug": slug.current}` | Pick fields, rename on the way out |
| `{..., "author": author->name}` | Everything, plus one dereferenced field |
| `author->{name, image}` | Follow a reference and project it |
| `categories[]->{title}` | Follow an array of references |
| `"total": count(posts)` | Name a computed value |
| `coalesce(seo.title, title)` | First non-null value |
| `select(featured => "hero", "standard")` | Conditional value |
| `pt::text(body)` | Portable Text down to a plain string |

### Ordering and slicing

These read left to right, and the pipe is part of the syntax rather than a shell-style pipe:

```groq
*[_type  "post"] | order(publishedAt desc)      // desc; asc is the default
*[_type  "post"] | order(publishedAt desc)[0...10]  // first ten, end-exclusive
*[_type  "post"] | order(publishedAt desc)[0..9]    // first ten, end-inclusive
*[_type  "post" && slug.current  $slug][0]        // an object, not an array
```

Two things worth internalizing rather than looking up. `[0]` changes your return type from an array to an object, which is where most "why is this undefined" bugs come from. And `^` is scope rather than parent document, so inside a nested projection it points at the enclosing scope and moves as you nest:

```groq
*[_type  "category"]{
  title,
  "posts": *[_type == "post" && ^._id in categories[]._ref][0...3]{ title }
}
```

## What you should actually do next

If there's one thing to take away from this entire breakdown, it's this: stop treating GROQ like a dumping ground for giant, unreadable queries and start treating it like a system you can actually maintain without sacrificing your weekends.

Fragment-based architecture gets you readable queries, less duplication, and smaller payloads. Your teammates will actually be able to onboard into your codebase without a guided tour.

Start small. Build atomic fragments. Compose them into blocks. Then treat page-level queries like Lego builds instead of archaeological digs. And if you want help untangling your current GROQ situation or setting this up the right way from day one, [you know where to find us](/services/sanity). Our [workshops](/services/workshops) ship with this exact fragment architecture pre-configured, so your team can skip the archaeology and start building.

---

## Why we built Satoru, our background coding agent


> How we built Satoru, a sandboxed background coding agent powered by Cloudflare Durable Objects and Modal to handle retainer backlogs across client codebases.

**TL;DR:** We built Satoru, a background coding agent that picks up low-complexity tickets from client Linear boards and ships PRs autonomously. Here's the business case, the technical architecture, and what we learned from Stripe, Ramp, Cursor, and Vercel along the way.

**Published:** 2026-03-02 | **Updated:** 2026-08-11 | **Categories:** AI, Hot Takes
---

We run a studio. We have retainer clients. Those retainer clients have backlogs. *And if I'm being honest*, a lot of what sits in those backlogs isn't hard. It's just time-consuming.

"Change this button color." "Update the hero copy." "Fix the padding on mobile." "Add a new team member to the about page." These are real tickets from real clients, and every single one requires a context switch. Pull up the repo. Read the ticket. Find the file. Make the change. Open the PR. Wait for CI. Merge. Deploy. For a change that took 10 seconds of actual thinking, the process took 20 minutes of faff.

**That's the throughput tax of agency life.** Not the complex architectural work. Not the system redesigns or the tricky state management bugs. Those are the tickets we're here for. The small stuff is what buries the team.

So we built **Satoru** as part of our [agentic workflows](/services/agentic-workflows) practice. It's a background agent that picks up low-complexity tickets from client Linear boards and ships PRs without a human touching the keyboard. It runs in a box. Here's why we built it, what I learned from companies doing this at much larger scale, and why I think the agency might change rapidly.

Also clients, if you're reading this, R&D isn't free, [hire us for consultancy](/call). Nobody else is going to throw a background agent in as a sweetener...

## The retainer problem nobody talks about

Every agency I know runs into the same pattern. You sign a retainer client. The first few months are great. Big builds, meaty features, architectural decisions that need your full attention. Then maintenance mode kicks in.

The backlog fills up with small stuff. *Not **unimportant** stuff*. The client needs these things done. But they're not the kind of work that justifies pulling a senior engineer off a complex build. So they sit. They accumulate. The client gets frustrated. You get frustrated. The backlog becomes a source of tension in every standup and every monthly review.

We tried the obvious solutions. Junior devs dedicated to small tickets. Batching amends into dedicated sprint days. Multi-agent orchestration. They all have the same problem: **a human still has to context-switch into each project, understand the codebase, make a small change, and context-switch out.** The overhead is constant regardless of the ticket size.

What we actually needed was something that could run in the background, pick up a well-specified ticket, make the change in a sandbox, and open a PR for review. No babysitting. No pairing. Just: here's the ticket, here's the codebase, **go**.

## Why off-the-shelf wasn't enough

There's a framework from Chris Weichel at [Ona](https://ona.com/stories/time-between-disengagements-the-rise-of-the-software-conductor) that nails this. He calls it "time between disengagements", how long an AI coding tool can operate before it needs human input.

Think of it as autonomy levels:

- **Seconds**: Tab completion, GitHub Copilot. You're steering constantly.
- **Minutes**: Cursor, Claude Code. Multi-step execution, but you're in the loop giving feedback every few minutes.
- **Hours**: Background agents. You hand off a task, go do something else, come back to a finished PR.
- **Days**: Doesn't exist yet. "...but what about [Ralph loops](https://ghuntley.com/ralph/)" ***shut up***

We were stuck in the minutes tier. Cursor and Open Code are great tools, and we use them daily for the complex work where you want to be in the loop. But "being in the loop" means someone is sitting at a keyboard. That someone has a finite number of hours, and those hours should go toward the work **where human judgment matters**, things like building the architectural foundation that agents and AI tools need to work effectively.

For a ticket that says "change the accent color from blue-600 to indigo-500 across the marketing pages," you don't need a human in the loop. You need a human to ***review*** the result. Big difference.

The off-the-shelf tools don't solve this because they're designed for interactive use. They assume a developer is present. We needed the opposite: something that runs while the developer is doing something else entirely.

## What the industry is building

I'll be honest, a bit more than a week before we started building Satoru I was publicly skeptical about all of this. The background agent spiel felt like marketing. Everyone announcing their agent, nobody showing real world examples of both the good and bad. Even less so, most folks *left out the blueprint to build one*.

![LinkedIn post from a week earlier expressing skepticism about background agent claims](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/why-we-built-our-own-background-agent/linkedin-skepticism.png)

Well guess what? *I was partially wrong*. I now believe the data from the companies below is within the realm of realism. But I still think the risk of turning these into slop cannons is underrated. Shipping volume means nothing if the code is garbage. More on that in the lessons section.

### Stripe's Minions: 1,000+ PRs per week

[Stripe's internal agent system, called Minions](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents), now merges over 1,000 PRs per week. One-shot, end-to-end coding agents. The human writes the spec, the agent writes the code, the human reviews the PR. That's it.

Published by Alistair Gray on Stripe's internal tooling team. The numbers are wild. They're not using agents for side projects or internal tooling experiments. This is production code getting merged at scale, across Stripe's main codebase.

The model is simple: agents write, humans review. The review step isn't going anywhere. But the writing? That's increasingly automated for well-defined tasks.

### Ramp's Inspect: 30% of all PRs

Ramp is actually the company that mostly inspired us to build Satoru. We love seeing some of the crazy AI stuff they've built, and frankly, *anybody that makes taxes and expenses simpler is a friend of ours.*

[Ramp built an agent called Inspect](https://builders.ramp.com/post/why-we-built-our-background-agent) that, within months of deployment, was producing roughly 30% of all pull requests to their frontend and backend repositories. **Thirty percent.**

Their architecture is worth studying. They run sandboxed VMs on Modal, each with a full dev environment: Vite, Postgres, Temporal, the works. Pre-built images get refreshed every 30 minutes so agents start with a warm cache. They use [OpenCode](https://opencode.ai) as the underlying coding agent.

Developers can kick off agent tasks from Slack, a web interface, or a Chrome extension. It's multi-surface by design, because if the agent only lives in your IDE, you're back to the "someone has to be sitting there" problem.

The line that stuck with me from their writeup: **"Owning the tooling lets you build something significantly more powerful than off-the-shelf."** That's been our experience exactly.

### Cursor's long-running and self-driving agents

Cursor has published two pieces of research that, taken together, paint a picture of where this is headed. Their [long-running agents](https://cursor.com/blog/long-running-agents) can execute for 36+ hours, producing much larger PRs with merge rates comparable to shorter runs. Theo Browne shipped two architecture overhauls running five agents in parallel. Zack Jackson compressed a quarter's worth of planned work into days: a 52-hour run, 151,000 lines touched.

Their [self-driving codebase experiment](https://cursor.com/blog/self-driving-codebases) pushed further with a multi-agent hierarchy. A root planner breaks down the task, recursive subplanners decompose further, and workers execute in isolated repo copies. At peak throughput: roughly 1,000 commits per hour, 10 million tool calls over one week. The system accepts some error rate in exchange for throughput, with a final "green branch" fixup pass that resolves conflicts and broken tests.

The problem is, I'm skeptical as to how well this could be implemented in a real-world project, but I'd like to believe it's more than smoke and mirrors.

## Our architecture: Linear-native, multi-tenanted, agency-first

Here's where our story diverges from Stripe and Ramp. They're product companies building agents for their own codebases. We're an agency building agents that work across dozens of client codebases simultaneously.

*That changes everything about the architecture.*

### The multi-tenant Linear application

*So we kind of cheated by saying we built the vast majority of this in a week*. The truth is we built a multi-tenanted Linear application that gives each retainer client their own board a *while back*. That is pretty important for our model. Actually, it's basically the coal for the steam engine.

**Clients add tickets directly**. Then our team assesses complexity. If a ticket is straightforward (well-specified, low risk, doesn't touch shared infrastructure), **Satoru** can pick it up.

No time billed. No human context-switch. The client gets faster turnaround on the small stuff. We get to spend our hours on the work where agency expertise actually matters.

The flow looks like this:

1. Client adds ticket to their Linear board
2. We triage and tag complexity
3. Low-complexity tickets get assigned to Satoru
4. Satoru clones the repo, spins up a sandbox, makes the change
5. Satoru opens a PR with the ticket linked
6. Engineer reviews, approves, merges
7. Deployment happens through the existing CI/CD pipeline ([Just use Vercel](https://vercel.com/))

Here's what that looks like in practice. A ticket gets assigned to Satoru in Linear, it picks it up, and about 20 minutes later there's a PR ready for review.

## Satoru's first ticket

The engineer reviews every PR. That's non-negotiable. But reviewing a clean PR takes five minutes. Writing it from scratch, with all the ceremony, takes thirty.

### Why "personalised software" matters here

If you haven't heard this term floating around, you're obviously not soullessly scrolling X all day, *good job*. "Personalised software" is not a generic project management tool with AI bolted on. It's a purpose-built system designed around exactly how our studio operates.

We control the full loop: ticket intake, triage, sandbox execution, PR, review, deploy. Every step is built for our workflow because we built it. The agent slots into the pipeline naturally because the pipeline was designed with the agent in mind from the start.

Every general-purpose tool we evaluated assumed a single team working on a single codebase. Agency life doesn't work that way. We'd rather build the tool that fits our workflow than cram our workflow into someone else's assumptions about how software gets made.

### Context is the hard part

Getting an agent to write code is, honestly, the easy part. The hard part is giving it enough context to write the *right* code.

A ticket that says "change the button color to indigo-500" is useless without knowing: Which button? Which component file? Is the color defined as a CSS variable, a Tailwind class, or hardcoded? Does the project use a design token system? Are there dark mode variants?

The Linear integration solves part of this. Tickets carry project context: which repo, which framework, which conventions. Satoru gets a brief that includes the project's architecture notes, component structure, and any relevant style guidelines. This is the same principle behind our Claude skills: encode the conventions once, and every AI interaction benefits from that context.

But the thing that actually makes it work is the sandbox. Satoru doesn't guess about the codebase. It clones it, runs the dev server, and can actually verify that its changes work before opening the PR. A sandboxed environment with a running dev server catches the obvious mistakes that would otherwise waste a reviewer's time.

Linear is clearly building with AI context at the forefront.

> Linear → Your AI coding tool. Open any issue directly in Claude Code, Codex, Conductor, Cursor, GitHub Copilot, OpenCode, Replit, v0, or Zed – preloaded with full context and a custom prompt.
>
> [Linear, Feb 2026](https://x.com/linear/status/2027080353685307739)

## Under the hood: Open-Inspect

That's the workflow layer (how tickets flow from client boards to merged PRs). Here's what powers it. We call the platform Open-Inspect. Satoru runs inside it.

### Architecture overview

```
User --> Web Client --> Control Plane (CF DO) --> Modal Sandbox
            ^               | WebSocket             | WebSocket
        Slack/GitHub/     D1 Database           Satoru
        Linear Bots                            (sandboxed env)
```

Three tiers connected by WebSockets: a web client, a control plane, and sandboxed compute. Bot integrations let you kick off sessions from Slack, GitHub, or Linear.

### Web client

**Stack:** Next.js 16, React 19, deployed to Vercel or Cloudflare Workers (via OpenNext)

GitHub OAuth handles authentication. The dashboard lets you list, create, and monitor coding sessions. A persistent WebSocket connection to the control plane streams Satoru's output in real time as it works through a task. No polling, no refreshing.

### Control plane

**Stack:** Cloudflare Workers, Durable Objects, D1 (SQLite)

This is the brain. Every coding session is its own Durable Object with dedicated SQLite storage.

- **Session lifecycle**: create, run, pause, resume, stop
- **WebSocket hub**: bridges the web client and the sandbox bidirectionally
- **D1 database**: session index, repo metadata, encrypted repo secrets
- **GitHub App integration**: repo access tokens, cloning, PR creation
- **Auth and permissions**: controls who can do what

Durable Objects are the right primitive here. Each session needs isolated state, its own WebSocket connections, and the ability to hibernate when idle. D1 gives you a lightweight relational store without managing infrastructure.

### Data plane

**Stack:** Modal (Python), FastAPI

This is where Satoru actually runs. Modal spins up isolated sandbox environments on demand.

- **Sandbox creation**: each session gets its own containerized dev environment with the repo cloned, dependencies installed, and a dev server running
- **Warm pool**: pre-warmed sandboxes so there's no cold boot penalty
- **Snapshots**: save and restore session state for persistence across runs
- **WebSocket bridge**: streams agent events back to the control plane in real time

Satoru has access to the full repo inside the sandbox. It can run tests, start dev servers, and verify its own changes before opening a PR. The container boundary is the security model. Nothing inside the sandbox can reach anything outside it.

### Bot integrations

All built as Cloudflare Workers with Hono.

**Slack Bot**: listens for messages, classifies intent, and routes to the right repo to kick off a session. Engineers can trigger Satoru from a Slack channel without opening the dashboard.

**GitHub Bot**: handles PR review assignments and responds to `@mention` commands. You can ask Satoru to pick up work directly from a PR comment.

This goes beyond rubber-stamping, too. During a spam protection implementation, Satoru flagged a honeypot security regression that would have gone to production: the refactored code returned a 422 error on honeypot fields instead of a silent 200, which tells bots they've been caught and defeats the entire purpose. It also caught that BotID client initialization only loaded in production while the server-side check ran unconditionally, meaning local dev would hang or fail. Both were the kind of subtle integration bugs that slip past a quick human review.

![Satoru reviewing a spam protection PR on GitHub, catching a honeypot security regression and a BotID initialization issue](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/blog/why-we-built-our-own-background-agent/satoru-github-review.png)

The agent catches what tired eyes miss. That's the point.

**Linear Bot**: receives Linear agent webhooks and creates coding sessions from issues. This is how the triage flow connects to the execution layer. Tag a ticket for the agent in Linear and it flows through to a running sandbox automatically.

### Shared foundation

**`@open-inspect/shared`**: a TypeScript package that every other component imports. Shared types, auth utilities, and model definitions. It builds first. Everything else depends on it.

### Infrastructure

**Terraform** provisions everything: Workers, Durable Objects, D1 databases, secrets, Modal deployments. One config to rule them all. No clicking around in dashboards.

**D1 migrations** handle schema versioning. Applied automatically in integration tests and on deploy.

**CI/CD** runs on GitHub Actions. Push to `main` auto-deploys changed services. Terraform handles the control plane and D1 migrations. Modal deploys the data plane. Every PR gets lint, typecheck, and tests.

| Component     | Tech                              | Role                              |
| ------------- | --------------------------------- | --------------------------------- |
| Web Client    | Next.js 16 + React 19             | Dashboard, OAuth, real-time UI    |
| Control Plane | CF Workers + Durable Objects + D1 | Session management, WebSocket hub |
| Data Plane    | Modal + Python + FastAPI          | Sandboxed coding environments     |
| Slack Bot     | CF Workers + Hono                 | Slack-triggered sessions          |
| GitHub Bot    | CF Workers + Hono                 | PR review and @mention commands   |
| Linear Bot    | CF Workers + Hono                 | Linear webhook-triggered sessions |
| Shared        | TypeScript                        | Types, auth, models               |
| Infra         | Terraform + GitHub Actions        | Provisioning and CI/CD            |

## Early lessons

We shipped Satoru's first PR about a week ago. It's early. We're testing it against our own internal codebases before pointing it at client work, and every PR still gets a senior engineer's eyes on it before merge.

But even at this stage, a few things have already become obvious.

### Don't ship slop

Cursor's self-driving codebase experiment peaked at 1,000 commits per hour. They got there by accepting breakage and running a fixup pass at the end. That works when you own the whole codebase and can afford to clean up after yourself and have passionate developers submitting issues like they're going out of fashion.

We can't afford to do that. **These are client codebases**. A sloppy PR that gets merged because a reviewer was in a hurry is a bug report next week and a trust problem next month. So Satoru doesn't get to be "close enough." Every PR goes through the same review bar as human-written code. If the agent misses an import or gets a style convention wrong, it doesn't ship. It gets sent back.

### The review step is the bottleneck, not the writing

Ona's essay on [industrialising software development](https://ona.com/stories/industrializing-software-development) makes a point about factory floors: optimising one station doesn't help if the bottleneck is somewhere else.

For background agents, the pipeline is: ticket, code, test, review, integrate, deploy. The agent speeds up the code-writing station. But if reviews take two days or the deployment pipeline takes 45 minutes, faster writing barely matters.

We've spent as much time on making PRs easy to review (clear descriptions, linked tickets, before/after context) as we have on making the agent write better code. That's where the actual time savings show up.

### Build your own, but only if you have to

If off-the-shelf tools cover your workflow, **use them**. Building agent infrastructure is real work and ongoing maintenance.

Our workflow is specific enough that we had no choice. We need:

- Multi-tenanted client access across dozens of repos
- Per-project conventions and architecture notes fed to the agent
- Triage-based routing between humans and agents
- Client-facing visibility into agent-generated work
- Billing integration (agent tickets aren't billed as engineer hours)

None of that exists in Cursor or Claude Code. We built it because our business model requires it, not because building it was fun. (It was fun. But that's beside the point.)

## Where this goes for agencies

Satoru is on training wheels. We're running it against internal projects, building confidence in the output, and learning where it falls over. The plan is to roll it out to client codebases once we trust the review loop enough. That trust gets built one PR at a time.

Ramp hit 30% of all PRs within months. I don't know if we'll hit the same number, but we don't need to. Even 10% of ticket volume handled by the agent frees up meaningful engineering time for the work clients actually hired us to do: system architecture, performance audits, migration planning. Not "change this button color."

The agency model has always had a tension between "we're experts you hire for hard problems" and "we also need to update your blog page title." Background agents dissolve that tension. Hard problems get the humans. Blog page titles get the agent. We run our [AI SEO agency](/services/geo) the same way: the agent watches citation share, drafts the metadata fixes, and a human reviews the PR.

I'm watching what this means for retainer pricing too. If a chunk of ticket volume isn't billed as engineer time, clients get more value per dollar spent. That shifts the conversation from "how many hours do we get" to "how many outcomes do we get." *I'd rather sell outcomes anyway, leave timekeeping for Casio.*

> **We build agentic workflows for teams**: Background agents, automated pipelines, and custom tooling built around how your team actually works. [See our agentic workflows service](/services/agentic-workflows)

*If you're an agency or engineering team thinking about building your own background agent setup, we're happy to talk shop. We've made plenty of mistakes already. Might as well save you a few.*

---

## We exorcised Ghost CMS from CoinTracker's content stack


> Another story of a blog turning into a full content platform and Ghost quietly tapping out halfway through.

**TL;DR:** CoinTracker's content needs outgrew Ghost, so we migrated the entire blog stack to Sanity and rebuilt it around structured, scalable content.
This is the story of why we moved, what broke, and what we learned fixing it.

**Published:** 2026-02-12 | **Updated:** 2026-08-03 | **Categories:** Sanity, CMS, How To
---

If you needed to spin up a blog quickly at any point in the last few years, there's a very high chance you reached for [Ghost](https://ghost.org/). It's fast, clean, especially for writing and publishing, it does exactly what it says on the tin. The problems usually start when the site stops being just a blog. Suddenly, you need structured content, different content types, reusable sections, and a headless frontend that doesn't feel like it's negotiating with your CMS every time you ship a page.

We've seen this happen on a few projects, including a migration we worked on for CoinTracker. This post is not a [Ghost vs Sanity](https://robotostudio.com/migration/ghost-to-sanity) rant but a straightforward look at when Ghost starts to hit its limits, why teams move to Sanity, and what that migration actually involves once you decide to stop pretending your blog is still just a blog.

## No shade, Ghost is fine

Before we start throwing it under the bus, Ghost is genuinely excellent at the thing it was designed to do.

If you need a blog, a publication, or a newsletter setup, it's hard to beat. You spin it up, pick a theme, start writing, and you're live. The editor is clean, publishing is also fast, and SEO basics are handled. For a single content stream, it stays out of your way, which is exactly what most teams want in the early days, but it is **kind of the point.**

Ghost is a publishing tool first. As long as your world fits neatly into that shape, it works really well. The moment you start needing content that doesn't behave like a blog post, that's when you start noticing the edges.

### Where Ghost breaks

It's not built for structured content modeling. You don't get custom schemas, reusable content blocks, or visual editing for things like landing pages, product storytelling, or multi-section marketing pages. Everything starts getting squeezed into the same post-shaped box. [Headless CMS](https://robotostudio.com/blog/state-of-cms) support is there, but it's not exactly native. If you're trying to run a proper React Router setup, the APIs can feel rigid, and real-time collaboration isn't really part of the story. It works, but it's not what the system was designed around.

Customization also has a ceiling. Theme work means getting comfortable with Handlebars and HTML, and once you move beyond basic tweaks, you're writing more custom code than you expected. There's no schema-as-code approach, so you're not really modeling content. You're styling it. At scale, things get a bit more fragile. Self-hosted setups can get twitchy around updates, caching dynamic content takes effort, and the ecosystem is smaller, which means fewer ready-made solutions when you hit a wall.

And if you're thinking about e-commerce, that's where it really shows its focus. There's no native Shopify sync, no advanced querying layer, and the product is still very much centered around publishing and newsletters, not omnichannel content. But we have to say, none of this makes Ghost bad. It just means it's very good at one job, and we saw the same issue when we were working on [CoinTracker](https://www.cointracker.io/)'s website.

## CoinTracker Ghost breakdown

At CoinTracker, blogs were the core product surface and not just a side marketing effort. It consists of updates, tax guidance, education, and integrations, which are read by millions of users. For a long time, they were fine with Ghost, but when the blog grew to 200+ posts, 20+ authors, 30+ tags, 200+ integration guides, and over 100 learn pages spread across different systems, they were no longer fine with Ghost. The blog lived in Ghost, other content lived elsewhere, and keeping things in sync slowly became a part-time job nobody signed up for.

The bigger problem was structure. CoinTracker needed:

- Call-to-action sections inside articles
- Highlight blocks for important notes
- Integration content that didn't look like a blog post
- Rich text that needed some shape to it

Editors felt it too. Previews were also limited, validation was minimal, and anything slightly custom meant pulling in developers. Not the end of the world, just consistently inconvenient. Nothing broke overnight. The site didn't crash. Ghost didn't fail. It just slowly became obvious that what started as a publishing setup had turned into a full content platform, and it was still being treated like a blog.

That was where it made sense to move to something built for structure, not just publishing.

## Why Sanity made sense

Trying to model all of it inside a flat post editor started to feel like storing your entire codebase in a single `index.js` file and telling everyone you'll "clean it up later." It works for a bit. Then it becomes a personality trait. Once it was clear we needed a more structured CMS approach, [Sanity](https://www.sanity.io/) was the obvious move.

[With Sanity](/services/sanity), we could finally stop pretending everything was a "post" and actually model content properly:

- Define different post types that aren't just posts.
- Create reusable sections that editors can drop into pages without the need for a developer.
- Design a single place where blogs, learn content, integrations, authors, and tags live together

Instead of forcing everything into a post, we could define schemas for exactly what we needed, that is, blogs, guides, authors, and integration pages. Each with their own fields, validation, and layout blocks. Second, we created one content layer. Before, content was spread across systems. After the move, everything lived in one place.

Sanity is built to sit behind any content delivery stack. Queries are flexible, previews are proper, and collaboration is real-time. We were not trying to bend a publishing tool into being an API. Its quieter benefits are what always push us for any migration. You have seen our other projects (if not, just check our [case studies](https://robotostudio.com/case-study)).

- Schema-as-code with TypeScript support.
- Validation at the content level, not just the UI.
- Reusable blocks for CTAs, highlights, videos, and tables.
- Editors can move faster without filing tickets for every layout tweak.

## Migration scope of CoinTracker

When people hear "[Ghost to Sanity migration](https://robotostudio.com/migration/ghost-to-sanity)," they usually picture a quick export/import job. This wasn't that. We weren't just moving a blog. We were consolidating an entire content layer that had grown across multiple systems:

- 100+ blog posts from Ghost
- 20+ authors
- 30+ tags
- 200+ integration guides from internal APIs
- 100+ learn pages from a separate Astro setup

Each content type had its own source, format, and edge cases. Some came from the [Ghost API](https://docs.ghost.org/content-api), some from internal services, some from static HTML. None of it lined up neatly. So the job wasn't just migrating content. It was pulling everything into one structured system, without breaking URLs, losing media, or upsetting SEO. The usual fun.

### The architecture we set up for migration

Before, it looked something like this:

- Ghost handled the blog
- Learn pages lived somewhere else
- Integration content came from internal APIs
- Frontend had to stitch everything together manually

It worked, but it wasn't exactly clean. Every new content type meant another system, another integration, and another thing to remember when something didn't update properly. After the move, the setup became a lot more sensible:

- **Sanity** became the content layer
- [**React Router**](https://reactrouter.com/) handled the frontend
- **Internal APIs** continued to power product-specific data

Everything had a clear role. Sanity stored and structured the content. React Router (v7 in framework mode, basically the Remix successor) handled rendering with server loaders pulling content directly from the CMS, plus SSR on Cloudflare Workers. APIs handled the dynamic bits. In simple terms, we stopped treating the CMS like a website and started treating it like a proper content backend. Once that clicked, everything became a lot more composable.

## How we actually did the migration

This wasn't a lift-and-shift. Ghost stores content as HTML blobs. Sanity expects structured content. So the job was less "copy paste" and more "carefully take this apart and rebuild it without losing anything important." We split the migration into scripts per content type, all written in [TypeScript](https://www.typescriptlang.org/) and sharing a common utility layer. Each script followed the same pattern:

1. Fetch from the source (Ghost API, internal APIs, or scraped HTML)
2. Transform it into the Sanity schema
3. Upload assets (images, OG images, author photos)
4. Write everything in batches into Sanity

Simple in theory. Slightly less simple once you start doing it hundreds of times.

### The HTML problem

Ghost stores posts as HTML. Sanity uses [Portable Text](https://robotostudio.com/blog/using-markdown-shortcuts-with-the-portable-text-editor) (structured JSON). If you convert HTML naively, you lose meaning. Tables turn into messes. Images become random `<img>` tags. Videos disappear into the void. So we built a conversion pipeline using `@portabletext/block-tools` that understood Ghost's markup and mapped it to proper Sanity blocks:

- **Image cards:** image blocks with asset references. Just an FYI **Ghost's image cards** come wrapped in specific markup:

  ```html
  <figure class="kg-card kg-image-card">
    <img class="kg-image" src="..." alt="..." loading="lazy" />
    <figcaption>Optional caption text</figcaption>
  </figure>
  ```

- **YouTube embeds:** **Video embeds** were appearing as iframes inside container divs:

  ```html
  <div class="video-container fluid-width-video-container">
    <iframe src="https://www.youtube.com/embed/VIDEO_ID"></iframe>
  </div>
  ```

- **Tables:** proper row/cell data
- **Random divider elements:** actual divider blocks

We also filtered out empty paragraphs, which Ghost happily generates and nobody asked for.

### Images needed a second pass

Feature images were easy. The Ghost API gives you those directly. Inline images were not. Those only exist in the rendered HTML, not cleanly in the API. So we fetched the live Ghost page, parsed it with Cheerio, extracted every inline image, uploaded them to Sanity first, built a map of `old URL -> new asset reference` and then ran the HTML conversion using that map.

Two passes, but it meant every image became a proper Sanity asset instead of a broken link.

### Batching so nothing explodes

Migrating hundreds of documents means a lot of network calls. And networks fail. Often at the worst time. So we built in some guardrails:

- Batched writes (5-10 items at a time)
- Transactions per batch
- Retries with backoff
- `Promise.allSettled` so one failed image didn't kill an entire post

### URL consistency

Ghost and Sanity don't share URL structures, so we defined a clear mapping:

- Blog: `/blog/[slug]`
- Author: `/author/[slug]`
- Learn: `/learn/[slug]`
- Integrations: `/integrations/[slug]`

That made reverse lookups easy and kept links intact. We rebuilt the entire system into something structured, asset by asset, block by block, without breaking pages, images, or URLs. Which is exactly as fun as it sounds.

## What we did differently in this migration

We could've treated this as a straight 1:1 migration. Move the posts, keep the structure, and call it done. It would've been faster, and also a complete waste of the opportunity. Instead, we treated it as a reset. Before writing any scripts, we designed the [Sanity schemas](https://www.sanity.io/docs/studio/schema-types) around what the content needed to become, not what Ghost happened to give us. That meant adding proper structure, field-level validation, and cleaner content models so we didn't just carry old limitations into a new system.

We also built every script to run in dry-run mode by default. It would show exactly what was going to change before committing to anything. That alone saved us from pushing bad data more than once. Because no migration is perfect on the first pass, everything was designed to be rerun safely. Idempotent writes, targeted fixes, and the ability to reprocess content without tearing the whole thing down again.

## Ghost vs Sanity

As we have said before, Ghost is great at being a blog engine. That's not an insult, if your site is mostly posts, newsletters, and the occasional landing page. Sanity is built for the second phase. Structured schemas, flexible queries, real-time collaboration, and native headless delivery mean you're not trying to force a publishing tool to act like a content platform. You just build the content model you need and move on with your life.

Performance and scale are also where the difference shows up. [Sanity's API](https://www.sanity.io/docs/http-reference) responses are typically sub-150ms globally and auto-scale. Ghost performance depends heavily on how it's hosted and tuned. Self-host it badly, and you'll discover new and exciting ways to shell out more money.

<table>
  <thead>
    <tr>
      <th>Category</th>
      <th>Ghost</th>
      <th>Sanity</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Core model</td>
      <td>Monolithic CMS for blogs/newsletters</td>
      <td>Headless CMS for structured content</td>
    </tr>
    <tr>
      <td>Content flexibility</td>
      <td>Posts, tags, basic pages</td>
      <td>Unlimited schemas, relations, custom types</td>
    </tr>
    <tr>
      <td>Headless support</td>
      <td>Possible, but rigid</td>
      <td>Built for Next.js and headless from day one</td>
    </tr>
    <tr>
      <td>Editor experience</td>
      <td>Clean writing interface</td>
      <td>Real-time preview + structured editing</td>
    </tr>
    <tr>
      <td>Performance</td>
      <td>Depends on hosting and setup</td>
      <td>Globally distributed, auto-scaling APIs</td>
    </tr>
    <tr>
      <td>Collaboration</td>
      <td>Basic workflows</td>
      <td>Real-time multi-user editing</td>
    </tr>
    <tr>
      <td>E-commerce/content sync</td>
      <td>Manual workarounds</td>
      <td>Native integrations (e.g., Shopify)</td>
    </tr>
    <tr>
      <td>Dev experience</td>
      <td>Handlebars themes, limited APIs</td>
      <td>Schema-as-code, GROQ, TypeScript-friendly</td>
    </tr>
    <tr>
      <td>Scaling</td>
      <td>Needs manual tuning</td>
      <td>Scales automatically</td>
    </tr>
    <tr>
      <td>Pricing</td>
      <td>Cheaper early on</td>
      <td>Usage-based, grows with you</td>
    </tr>
  </tbody>
</table>

## Closing thoughts

If you're outgrowing Ghost, moving toward a headless stack, or trying to consolidate content spread across five different systems, that's exactly the kind of problem we spend most of our time solving. We help with [content migrations](/services/cms-migration), schema design, and setting up [headless CMS architectures](/services/headless-cms) that don't fall apart down the line. Check out our [Ghost migration page](/migration/ghost-to-sanity) for a full breakdown of the process.

> **Sanity CMS development**: Schema design, migration pipelines, and ongoing CMS support. [Learn more](/services/sanity)

---

## React Server Components CVE-2026-23864: What you need to know


> A high-severity DoS vulnerability is affecting Next.js 13-16 and other RSC frameworks. Here's how to fix it fast.

**TL;DR:** React Server Components had a nasty DoS bug (CVE-2026-23864). Tons of React/Next.js versions are vulnerable. Fix = upgrade React/Next, not "trust the WAF." If your app dies, that's on you for not reading this sooner and patching.

**Published:** 2026-01-28 | **Updated:** 2026-07-23 | **Categories:** Next.js, Vercel
---

If you woke up this morning to a Slack message from your security team, you're not alone. CVE-2026-23864 just dropped, and it's affecting pretty much every Next.js project running Server Components.

Before you panic: **no, attackers can't run code on your server**. But they *can* crash it. Let's break down what's happening and how to fix it.

## What's the vulnerability?

The CVE addresses multiple denial of service vulnerabilities in React Server Components. A malicious actor can send specially crafted HTTP requests to your Server Function endpoints that cause:

- Server crashes
- Out-of-memory exceptions
- Excessive CPU consumption

What makes this particularly nasty is the attack profile. According to the [GitHub security advisory](https://github.com/facebook/react/security/advisories/GHSA-83fc-fqcc-2hmg):

- **Attack Vector**: Network (remotely exploitable)
- **Attack Complexity**: Low
- **Privileges Required**: None
- **User Interaction**: None

Translation: anyone on the internet can crash your server without authentication, without tricking a user into clicking anything, and without much effort. The CVSS score is **7.5 (High)**, which is the security equivalent of "fix this before lunch."

## This isn't the first RSC vulnerability

Here's the uncomfortable truth: this CVE is part of a pattern.

Back in December 2025, [CVE-2025-55182](https://www.akamai.com/blog/security-research/cve-2025-55182-react-nextjs-server-functions-deserialization-rce) dropped with a **CVSS 10.0** - a full-blown Remote Code Execution vulnerability in React Server Functions. That one let attackers run arbitrary code on your server. The React team patched it, but security researchers kept digging.

CVE-2026-23864 is the result of that continued scrutiny. The initial DoS fixes were incomplete, and multiple denial of service vectors still existed. When a critical vulnerability gets disclosed, researchers probe adjacent code paths looking for variant exploits. This is standard practice across the industry, and it's why we're seeing follow-up CVEs.

The takeaway? RSC security is still maturing. If you're running Server Components in production, you need to stay on top of patches.

  We monitor CVEs affecting Next.js and Sanity so you don't have to. When something drops, you'll know.

## Am I affected?

You're affected if your project uses any of these packages:

- `react-server-dom-webpack`
- `react-server-dom-parcel`
- `react-server-dom-turbopack`

Quick way to check:

```bash
# npm
npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

# pnpm
pnpm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

# yarn
yarn why react-server-dom-webpack
```

If you see any of these packages in versions **19.0.0 through 19.2.3**, you're vulnerable.

**Not affected?** If your app doesn't use React Server Components or Server Functions, you're in the clear. Traditional client-side React apps without SSR aren't impacted.

## What's affected?

### React packages

| Package | Vulnerable | Patched |
| --- | --- | --- |
| `react-server-dom-webpack` | 19.0.0 – 19.2.3 | 19.0.4, 19.1.5, 19.2.4 |
| `react-server-dom-parcel` | 19.0.0 – 19.2.3 | 19.0.4, 19.1.5, 19.2.4 |
| `react-server-dom-turbopack` | 19.0.0 – 19.2.3 | 19.0.4, 19.1.5, 19.2.4 |

### Frameworks

- **Next.js**: 13.x, 14.x, 15.x, and 16.x
- **React Router** (with RSC)
- **Waku**
- **RedwoodSDK**
- **Vite** (with `@vite/rsc-plugin`)
- **Parcel** (with `@parcel/rsc`)

If you're running React Server Components on any of these, assume you're affected until you verify otherwise.

## The fastest fix

Stop reading and run this:

```bash
# For Next.js projects
npx @next/codemod@canary upgrade latest
```

One command, and your coffee's still hot.

### If you can't upgrade immediately

Vercel and [Akamai](https://www.akamai.com/blog/security-research/2026/jan/cve-2026-23864-react-nextjs-denial-of-service) have both deployed WAF rules to protect hosted projects. If you're on either platform, you've got some breathing room while you schedule the upgrade.

But here's the thing: **WAF rules are a temporary mitigation, not a fix**. The React team and framework maintainers are clear on this - you still need to update. Don't let the safety net become an excuse to delay.

If you're self-hosting without a WAF... well, you're on your own. Prioritise the upgrade.

## Patched versions

| Framework | Patched versions |
| --- | --- |
| React | 19.0.4, 19.1.5, 19.2.4 |
| Next.js 15.x | 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10 |
| Next.js 16.x | 16.0.11, 16.1.5 |

Pick the one that matches your current minor version and upgrade.

## What if you're stuck on an older version?

We get it. Not everyone can upgrade on a whim. Legacy codebases, pending migrations, that one feature flag nobody wants to touch because "it works."

Here are your options:

1. **Upgrade to the nearest patched version** - This is the path of least resistance. A patch version bump *shouldn't* break anything. (Famous last words, but still.)

2. **Hide behind a WAF** - Vercel and Akamai have automatic protection. If you're on either platform, you're covered temporarily.

3. **Rate limit your Server Functions** - Add aggressive rate limiting to your Server Action endpoints. Won't stop a determined attacker, but raises the bar.

4. **Actually, just upgrade** - We've helped clients upgrade hundreds of Next.js projects. It's usually less painful than you think. [We can do it for you if you're short on time](/services/nextjs).

If you're upgrading anyway, [Next.js 16.2](/blog/nextjs-16-2-for-dummies) includes the patched React versions and a bunch of performance improvements worth having.

> **Next.js app development**: Security patches, framework upgrades, and ongoing Next.js maintenance. [Learn more](/services/nextjs)

## Why this matters for agencies

If you're an agency or consultancy, now's a good time to audit your client projects. A quick `npm ls next` or `pnpm ls next` will tell you where you stand.

For each affected project:
1. Check the current Next.js version
2. Identify the nearest patched version
3. Test locally, then deploy

If you've got dozens of projects to update, this could take a while. Or you could reach out and [let us handle the heavy lifting](/contact).

## TL;DR

| What | Details |
| --- | --- |
| CVE | 2026-23864 |
| Severity | High (7.5) |
| Impact | DoS via memory exhaustion - server crashes, not RCE |
| Attack profile | Network, low complexity, no auth required |
| Fix | Upgrade to patched React/Next.js |
| Fastest command | `npx @next/codemod@canary upgrade latest` |

## Further reading

- [GitHub Security Advisory (GHSA-83fc-fqcc-2hmg)](https://github.com/facebook/react/security/advisories/GHSA-83fc-fqcc-2hmg)
- [Vercel Changelog](https://vercel.com/changelog/summary-of-cve-2026-23864)
- [Akamai Technical Analysis](https://www.akamai.com/blog/security-research/2026/jan/cve-2026-23864-react-nextjs-denial-of-service)
- [React Blog: DoS and Source Code Exposure in RSC](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components)
- [Next.js Security Update (December 2025)](https://nextjs.org/blog/security-update-2025-12-11)

---

## Next.js 16.1 for dummies


> Turbopack caching goes stable, a new bundle analyzer, and 20MB lighter installs. The boring release that makes everything faster.

**TL;DR:** Next.js 16.1 stabilises Turbopack file system caching, ships a new bundle analyzer, and trims 20MB from your node_modules. It's a stability-focused release that makes your dev server restart 5-14x faster. We upgraded in about two minutes.

**Published:** 2025-12-20 | **Updated:** 2026-07-23 | **Categories:** Next.js
---

Back in October we wrote about [Next.js 16 for dummies](/blog/nextjs-16-for-dummies). That covered the headline act: Turbopack as the default bundler, opt-in caching, React 19.2. Big energy.

16.1 is the follow-up that nobody gets excited about but everybody benefits from. Turbopack's file system caching went from beta to stable, installs got 20MB smaller, and there's a new bundle analyzer that shows you exactly which dependency is bloating your client bundle. Not glamorous. Extremely useful.

## What's new and shiny

### Turbopack file system caching is stable

In our [16 post](/blog/nextjs-16-for-dummies), we talked about Turbopack's file system caching as a beta feature. We even joked that we'd run it on prod and if you could read the post, it was working.

It's now **stable and enabled by default**. No config needed.

What it does: when you run `next dev`, Turbopack caches compiled artifacts to disk. The next time you start your dev server, it skips all the work it already did. Restarts go from double-digit seconds to under a second.

Vercel's benchmarks across real apps:

| Site | Cold start | Cached | Speedup |
| --- | --- | --- | --- |
| react.dev | 3.7s | 380ms | ~10x faster |
| nextjs.org | 3.5s | 700ms | ~5x faster |
| Large internal Vercel app | 15s | 1.1s | ~14x faster |

For a large app with hundreds of routes, going from 15 seconds to just over a second on restart is the difference between staying in flow and checking Twitter. If you're building something at that scale, [we can help](/services/nextjs).

This has been dogfooded internally at Vercel for about a year. If you want the technical deep-dive, [Luke Sandberg's talk at Next.js Conf](https://nextjs.org/conf/session/are-we-turbo-yet) covers how they built it. File system caching for `next build` is coming next.

### Bundle analyzer (experimental)

Next.js now has its own built-in bundle analyzer. No more installing third-party packages or squinting at webpack stats files.

```bash
next experimental-analyze
```

This launches an interactive UI where you can:

- **Filter bundles by route**: see exactly what each page pulls in
- **View the full import chain**: understand *why* a module is included, not just that it is
- **Trace server-to-client boundaries**: see where your "use client" directives actually cut the bundle
- **View CSS and asset sizes**, not just JavaScript
- **Switch between client and server views**, because they have very different bundle profiles

It's still experimental, but it's already more useful than most third-party alternatives we've tried. If you've ever wondered why your client bundle is 400KB when your actual code is 30KB, this is the tool that answers that question.

### Easier debugging with `next dev --inspect`

You can now attach the Node.js debugger to your dev server with a simple flag:

```bash
next dev --inspect
```

Previously you had to set `NODE_OPTIONS=--inspect`, which attached the inspector to *every* process Next.js spawns, not just the one running your code. That meant breakpoints hitting in the wrong process and a generally confusing debugging experience.

The new flag does the right thing. It attaches the inspector only to the process running your application code. If you actually use the Node.js debugger, you'll appreciate this one.

### Transitive `serverExternalPackages` fix

This one's a pain in the ass if you've hit it, and invisible if you haven't.

The `serverExternalPackages` config lets you keep certain dependencies unbundled on the server. Previously, this only worked for **direct** dependencies. If you used a library that internally depended on something like `sqlite`, you had to add `sqlite` to your own `package.json` and your `serverExternalPackages`, even though it's not your dependency.

This leaked implementation details into your `package.json` and could cause version conflicts when multiple packages needed different versions of the same transitive dependency.

Turbopack now **resolves transitive dependencies automatically**. If a package in `serverExternalPackages` depends on something else, that something else gets externalised too. No more workarounds.

### 20MB smaller installs

Next.js installs are about **20MB lighter** thanks to simplifications in the Turbopack file system caching layer. That adds up if you're running CI pipelines, or if you're just tired of `node_modules` being the heaviest object in the universe.

### The `next upgrade` command

There's now a dedicated command for upgrading:

```bash
next upgrade
```

It bumps Next.js to the latest version and handles any migrations. This replaces the `npx @next/codemod` workflow for simple version bumps.

### MCP improvements

The Next.js DevTools MCP server (which we covered in the [16 post](/blog/nextjs-16-for-dummies)) got a new `get_routes` tool. It returns the full list of routes in your application, which is useful for AI agents trying to understand your app's structure.

If you're using Cursor, Claude Code, or similar tools, this means the AI can now enumerate your routes and reason about them without grepping through your file system.

## Other bits worth mentioning

- **`generateStaticParams` timing**: time spent generating static params is now logged in dev, so you can see if your static generation is a bottleneck
- **Build worker logging**: `next build` now logs how many worker threads it's using for page data collection and static generation
- **Improved async import bundling**: Turbopack produces fewer chunks for async imports in dev, avoiding some pathological cases we'd seen in real projects
- **Relative source map paths**: server-side source maps now use relative paths, which plays nicer with Node.js tooling

> **Next.js app development**: Next.js upgrades, Turbopack builds, and performance optimization. [Learn more](/services/nextjs)

## Quick comparison

| Feature | 16.0 | 16.1 |
| --- | --- | --- |
| Turbopack FS caching | Beta | Stable (default) |
| Bundle analyzer | Third-party | Built-in (experimental) |
| Dev server debugging | `NODE_OPTIONS` hack | `--inspect` flag |
| Transitive externals | Manual workaround | Automatic |
| Install size | Baseline | ~20MB smaller |
| Upgrade path | `npx @next/codemod` | `next upgrade` |

## How to upgrade

### Option 1: the new way

```bash
next upgrade
```

### Option 2: automatic upgrade

```bash
npx @next/codemod@canary upgrade latest
```

### Option 3: manual upgrade

```bash
npm install next@latest react@latest react-dom@latest
```

### Option 4: start fresh

```bash
npx create-next-app@latest
```

## Closing thoughts

16.1 is a stability release. Nothing flashy, nothing breaking. Turbopack caching going stable is the headline, and it does exactly what it says on the tin: faster dev server restarts, no config required.

If you're still on 16.0, there's no reason not to upgrade. It's a version bump and a `pnpm install`. If you're on something older, read our [16 post](/blog/nextjs-16-for-dummies) first and make the jump. Already on 16.1? See what's new in [Next.js 16.2](/blog/nextjs-16-2-for-dummies).

We dogfood every Next.js release on our own site first, usually breaking something in the process so our clients don't have to. Our open-source starter [turbo-start-sanity](https://github.com/robotostudio/turbo-start-sanity) runs the same stack: Next.js 16 with Turbopack for dev, Turborepo for monorepo orchestration, React Compiler, `ImageResponse` for OG images, and experimental CSS inlining. It's already on 16.1 and it's the foundation we use for every [Next.js project](/services/nextjs) we ship.

If you want to skip the setup and get straight to building, clone the starter. If you want us to build the whole thing, we pair Next.js with [Sanity](/services/sanity) on most projects. [Get in touch](/contact).

---

## The state of headless CMS


> By the time you read this, another CMS will have pivoted to AI, announced a beta, and promised to 'reimagine how teams create.' Keep up.

**TL;DR:** CMS for 2026 If your CMS lacks real-time preview, AI, and smart caching, you're behind. Sanity is still our frontrunner, and you probably want to use AI more. Just read the article, we have videos.

**Published:** 2025-11-21 | **Updated:** 2026-09-01 | **Categories:** Hot Takes, CMS
---

Let's start by assuming you've seen the latest takes from [Lee Robinson](https://leerob.com/agents) (Cursor) and [Knut Melvær](https://www.sanity.io/blog/you-should-never-build-a-cms) (from Sanity) on the relevance of a headless CMS. The heart of the debate is that a headless CMS must solve everyday content problems, not create complexity.

We judge a modern content management system by how much manual work it removes and how fast it lets a team ship at scale: AI automation, less management overhead, shorter build times.

We are firmly in the camp of **_pro_**-headless content management systems, but we'd be lying if we didn't say we've bumped into a lot of the points Lee makes in his blog. We'll give our take on the whole ordeal at the end of the blog, so feel free to skip to the end if you're as impatient as we are.

Here is a list of features that we implement for our clients to ship content at speed and without pain.

## Agentic editorial experience
The industry as a whole is [dramatically shifting towards AI automation and workflows](/blog/vercel-ship-ai-2025), with the ultimate goal of helping us ship faster. We build [agentic workflows](/services/agentic-workflows) that automate entire editorial pipelines, from research to publish. Dynamic, scalable content defines how websites perform, look, and grow on the web.

With the latest agentic features, larger teams can automate content generation, polish, and publish faster than ever. Marketing teams can prompt and generate repeatable features (e.g., SEO fields) without having to do them manually in every instance. 

In our case, we use automation to ***move fast without producing slop***; for example, generating FAQs from a blog post. 

We also utilize built-in AI features such as [Sanity's Content Agent](https://www.sanity.io/content-agent) to map and improve content, make global tweaks, and read patterns. It's pretty clever and comes in handy for keeping content up to date. See example below.

### Use cases we use this with
These are vanilla versions of the ones we generally implement for clients, but feel free to take them and reword them for yourself.

```markdown title="first-draft.md"
Write a first draft blog post about [TOPIC]. Include an engaging introduction, 3-5 main sections with H2 headings, and a compelling conclusion with a call-to-action. Target word count: 1200-1500 words.
```

```markdown title="basic-seo-analysis.md"
Analyze this content for the target keyword "[KEYWORD]". Check for:
- Keyword in title, H1, first 100 words
- Keyword density (aim for 1-2%)
- Semantic/LSI keyword opportunities
- Suggest improvements with specific placement recommendations.
```

```markdown title="competitive-gap-analysis.md"
For the topic "[TOPIC]", what subtopics, questions, or angles might competitors be covering that this content is missing? Suggest additions to make this the most comprehensive resource.
```

```markdown title="meta-title-description-review.md"
Review my title tag and meta description for SEO. Current title: "[TITLE]" Current meta: "[META]". Suggest optimized versions that include the keyword "[KEYWORD]" while maximizing click-through rate.
```

## Preview should be a first-class citizen

If we had a dollar for every time an enterprise client came to us with a broken preview, we wouldn't be writing blogs; we'd be sitting on a yacht off the coast of the Bahamas. Most CMS on the market offer **no real-time updates**, live content context, or even an instant visual validation. Just "save and pray."

If your CMS is not showing editors what they’re changing as they’re changing it, you don’t have a headless CMS… you have a glorified JSON file.

And to be honest, we really don't think publishers should need to speak to a dev to push a change to the page title. [Sanity’s Presentation](https://www.sanity.io/blog/introducing-presentation) has shown everyone how editing content ***should*** feel, with changes visible as you edit. The expectation is simple:

- Real-time updates without having to refresh the page, for both you and your users
- Instant validation that allows editors to see the result before hitting publish
- Preview environments that don’t fall apart when content models change

### Visual editing
This is a fancy way of saying a layout editor, where you can stack blocks that your developers have built into any order to create things like landing pages, PPC pages, and services pages.

This differs from something like [Webflow](/migration)/Framer as it's closer to "design on rails". What that means is that you **don't have to rely on a designer**. Something like Webflow excels if you have a designer constantly creating new pages, but the larger it gets, the more of a pain in the ass it is to maintain. 

That's why Visual Editing is such a boon for the marketing team. You drop and drag blocks like pre-defined LEGO, and focus on getting conversions, not correcting padding and proximity.

- Your blocks map directly to real frontend components
- What you drag is what actually renders
- You don’t need to imagine spacing anymore, although spacing [can become a problem if you are not careful](/blog/spacing-in-page-builders)
- Multi-user edits happen instantly 
- Change something, and preview updates before your brain finishes the thought

## Stale cache

You’d think by late 2025 we’d all be past the era of "hit purge-all and pray nothing explodes," but somehow… here we are. We still meet teams who invalidate their entire site because one intern updated a product description. And yes, we judge you. Lovingly, *but we judge you*.

Smarter route-level validation should be the norm now. You change one document, and only its related routes rebuild. You touch one component, and only the pages using that component refresh. The CMS should understand dependencies, not treat every change like a meteor heading for Earth. And yet every time we onboard a new project, we still find teams doing one of these:

- Hitting "purge all routes" like it’s a life philosophy
- Deploying five times because "the preview isn’t updating"
- Wondering why the homepage still shows data from 2022
- Blaming the CMS when the real culprit is, you guessed it, your caching layer.

[Next.js](/blog/nextjs-16-for-dummies) has predictable cache behaviour, granular control, and components that refresh exactly when you need them to. Your CMS fires a webhook, Next.js receives the signal, the exact route gets purged, and your frontend updates instantly. Read more about [how cache components work](https://robotostudio.com/blog/nextjs-16-for-dummies#cache-components).

Here’s the kind of snippet we end up wiring for most teams:

```typescript title="route-revalidate.tsx"
// Automatic route-level cache purge from CMS webhook
import { revalidatePath, revalidateTag } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(req: NextRequest) {
  try {
    const { slug } = await req.json();
    if (typeof slug !== "string" || !slug) {
      return Response.json(
        { success: false, message: "Missing or invalid slug" },
        { status: 400 }
      );
    }
    revalidateTag(`slug:${slug}`);
    revalidatePath(slug);
    return Response.json({ success: true, revalidated: true });
  } catch (error) {
    return Response.json(
      {
        success: false,
        message:
          error instanceof Error ? error.message : "Unknown server error",
      },
      { status: 500 }
    );
  }
}

```

Route-level purging is the baseline. If your CMS is not able to trigger precise revalidation hooks, or your hosting forces you into full-site busts, you’re basically speed-running "How to DDoS Yourself with Good Intentions." Next.js solved most of this pain already. You just need a CMS that can actually talk to it properly, **like Sanity**.

## DAM or don’t bother

Most CMS "media libraries" are just glorified Dropbox folders wearing a badge, and that is just embarrassing. A CMS should be able to handle licensing, orientation, search, filtering, versioning, and basic batch actions. Media management today means *actual* management.

***That being said***, as much as I would like to say that Sanity has a perfect score, this is the only thing I think they could handle better natively, and we'd love to see their hat in the ring with more integration functionality out of the box. It's a small blip on an otherwise perfect score. ***B- See me after class.***

This is where we think [Contentful](/migration) shines: its default media library is very good at handling many of the above requirements. An alternative is simply running something like Cloudinary to handle this as soon as licensing is involved.

Currently, the best solution in Sanity is the [media browser plugin](https://www.sanity.io/plugins/sanity-plugin-media), which is solid for tagging and filtering, but you're going to need to build out your own licensing logic if you need it.

## Scheduling

When you *really* want to move fast, you need to be able to batch publish and even schedule a couple of weeks in advance. Marketing teams should be able to just pick a date, press publish, and trust the system not to break down. If you still need a developer, a CRON job, and a prayer just to publish a page next Tuesday, your CMS is from the wrong decade. You should be able to:

- Publish a single page,
- Drop 200 pages at once,
- Switch on a full seasonal takeover

…without waking up a developer at 11 PM. [Sanity’s Releases](https://www.sanity.io/content-releases) already does this properly with group releases and predictable scheduling. It's really, **_really_** good. Just take the time to learn it. Some of the UX could do with some polishing. Until recently, we thought we had broken the unpublish button, but it's hidden ***really*** well.

## Native AI

Most headless CMSes are rushing to slap some AI in the product, which is usually a tiny chatbot shoved in the corner that rewrites a paragraph and then begs for a tip, nowhere near what is actually needed.

Generally, whenever you're using AI, you're always fighting the "ejection point." This is the point where you eject out of the tool and use something completely separate. The more **integrated** the AI, the better.

Without going too deep, we've already used the [Sanity](/services/sanity) AI assistant for:

- Alt text generation
- SEO cleanup and population
- Image classification + tagging
- Brand-tone rewriting
- Query generation that respects your schema
- One click first draft of a blog in a new language

Frankly, Sanity is far too modest about how far ahead they are with AI. It's literally the frontrunner as far as we're concerned, and it [released an MCP](https://www.sanity.io/blog/introducing-sanity-model-context-protocol-server) months before any other content management system we know of.

When everyone else is giving you "rewrite this paragraph." [Sanity content agent](https://www.sanity.io/content-agent) gives you "scan 10,000 pages to fix outdated content, update metadata, and translate everything to Arabic" in one conversation.

## Publishing, unpublishing, and rollback

Editors break things, that’s part of the job description, so why can’t more platforms let you undo mistakes the same way you undo a typo in Notion? 

Publishing needs simpler controls and not an open Jira ticket. What we are saying is that rollback should be instant. If someone accidentally unpublishes the homepage at 4:59 PM on a Friday, you hit undo, it rolls back, and life goes on. Anything slower than that isn’t headless, it’s *helpless*.

And rollback is only half the story. As we’ve **already said**, workflows inside a CMS now need actual operational brains that handle multi-environment syncing, release candidates you can test safely, and schema guardrails. 

## Instant search

Search used to be a tiny checkbox in a CMS settings panel with "Enable search? Yes/No." If your search still uses this, you're losing customers, revenue, and your team’s sanity *(great pun, never been used before)*.

Today's users expect search to feel instant, smart, and creepily good at guessing intent. And if you’re running an e-commerce site, this is the difference between "Add to cart" and "I’ll check Amazon instead." Here’s what "normal" looks like now:

- Fuzzy search
- Intent-aware search (yes, users don’t always know what they’re actually looking for)
- AI-embedding search that understands meaning, not strings
- Federated search across products, blogs, documentation, and FAQs
- Image-based search

Slow or dumb search is a quiet revenue killer. And yes, we’ve been shouting about this for a while. We were one of the first teams to build a production-ready search tool on top of [Sanity’s embeddings index](https://www.sanity.io/docs/content-lake/embeddings-index-api-overview). When everyone is still talking about AI search now, we were already shipping it.

If you're looking at building [e-commerce, talk to us](/services/shopify), because there's some pretty nifty stuff you can do with Algolia + Sanity + Shopify. If you want the full breakdown first, we wrote [the honest guide to headless Shopify](/blog/shopify-headless-guide).

## Dev's favourite CMS
A good CMS must be easy for the content team to use, yes, we have heard this time and again. However, there is a special demographic that feels quite passionate about the craft itself. And they are eager to re-create if the existing one doesn't acknowledge the pain points. 

We are referring to devs and dev communities. If they are getting blocked and not happy with the product they are implementing, you are overlooking a major group. 

From open-sourcing to building plug-ins, dev communities nourish tools and make them easier to use for everybody else. So a dev-friendly CMS must be the first choice if you want your brand to do well in the long run. 

## The bottom line for 2026
The platforms that thrive now are the ones removing friction, not adding new knobs for teams to babysit. 

Editorial teams want instant previews, real-time collaboration, clean media libraries, and scheduling that doesn’t require cron-jobs. Developers want fewer cache mysteries, smarter routing, and APIs that don’t collapse under load. **Everyone wants less duct tape.**

To summarise:

> Don't build your own CMS, don't roll your own media libraries, focus on finding something that marketing likes and devs don't hate. We always recommend Sanity, but there are lots of good options out there like: [Payload](https://payloadcms.com/), [Contentful](https://www.contentful.com/) and [Tina CMS](https://tina.io/). If you're stuck on a platform that's holding you back, we have [migration guides](/migration) for most major CMSs. Or the hell with it, go use markdown if your team is ***just*** developers and you feel brave.
 If you want help picking the right platform or escaping the wrong one, [we’re here to help](/call). No question is too big or too dumb; we've heard it all.

> **Headless CMS service**: Platform selection, content modelling, and migration support. [Learn more](/services/headless-cms)

---

## Ship AI, AI, AI


> Everything Vercel announced at Ship AI, starting with AI SDK 6, plus our take on which releases matter if you want to start shipping AI features.

**TL;DR:** AI Gateway, Fluid Compute, Sandboxes, Workflows, AI SDK 6, Observability, and BotID. We've dropped in a couple links to fully built OSS lead and data agents. There's a bunch more stuff that launched too but you should have just read the article.

**Published:** 2025-10-28 | **Updated:** 2026-07-23 | **Categories:** Vercel, AI
---

You've read the title, and I'm sincerely hoping you didn't miss the [developers, developers, developers reference.](https://www.youtube.com/watch?v=8fcSviC7cRM) We're bringing the same energy to [Ship AI](https://vercel.com/ship/ai) with this blog.

We're going to start with what we think are the most important releases and wrap it up with our two cents on the future of AI transformation and how you can start shipping.

## AI SDK 6 (beta)
For a quick preface, if you don't know what the AI SDK is, it's a unified way of calling *near enough* every AI model without needing to change the way the code is written. It's also a unified language, so if you know how to write TypeScript, you know how to create a chatbot. We'll be covering this in-depth soon, but for the time being, this is dedicated purely to the latest release.

### Release notes
> [**this release is not expected to have major breaking changes**](https://vercel.com/blog/ai-sdk-6#why-ai-sdk-6)
Don't worry, you can breathe easily *until AI SDK 7.*

If you're looking for human approval, reliable structured outputs, and more granular control over complex multi-stepped tasks, this beta is definitely worth upgrading to. If you’re happy with v5, moving to v6 should be straightforward when you’re ready or when it's stable towards the end of 2025.

Or... *to hell with it*... Push it to prod, *infosec haven't had a code red in a couple of days.*

![0 days without accident](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-0-days-without-accident.png)

#### Loops are smarter
As AI gets smarter, they use apps for you, think about the results, and keep going until they're done. However, this can get expensive as hell as the context grows and the tools get more vast.  `ToolLoopAgent` helps. You can set the number of loops the agent will go through; it defaults to 20, so you don't go broke.

#### Human-in-the-loop approvals
This helper asks permission before risky actions. Example: payments only run if you **approve** via `needsApproval`. Super helpful for dangerous updates or steps with money involved.

  Keep in the loop

  Subscribe at robotostudio.com

#### Structured outputs (and streaming)
Force answers into a fixed shape (like a form): `Output.object`, `Output.array`, `Output.choice`, `Output.text`. Show partial results live with `partialOutputStream`.

#### Reranking for better search
After you find results, rerank reorders them so the most relevant show up first. Control the result count with `topN`. It's a better way of tweaking and tuning search results.

#### Easy upgrade from v5
If you used v5, most code still works on v6. It's a nice, simple bump.

### Key takeaways
Whilst most features of Next.js are self-explanatory because we've pretty much nailed down the usual expectations out of "what a website is", AI is the **complete opposite**.

It's the wild west and people have only really cared about it for 2 years... *No AI didn't exist prior to 2 years ago, I don't believe you, ChatGPT invented it.*

## Workflows
Workflows are our personal favourite from the conference. They're a way of taking a traditional set of processes and organizing them one after another. It's a difficult concept to understand at first, but the more you think about it, the more powerful it is.

Let's start with what you expect out of an AI agent's functionality. It is no longer limited to a simple chat response. They have to:

- Call tools
- Fetch data
- Wait for humans
- Retry on failure
- Pause for a week
- Wake back up like nothing happened

Basically, everything [Neo](https://x.com/1x_tech/status/1983233494575952138) failed at.

This is where every dev team quietly cries, because building that has always meant a spaghetti bowl of queues, cron jobs, retries, broken state, and a prayer you don’t lose tokens mid-execution. So Vercel introduced the **[Workflow Dev Kit](https://vercel.com/blog/introducing-workflow)**, enabling developers to build long-running, reliable AI agents without manually wiring tons of infrastructure.

You write one TypeScript function, mark steps inside it, and Vercel turns it into a durable workflow. This allows agents to:

- Call models and tools
- Respond to webhooks or events
- Wait for human approval
- Resume exactly where they left off
- You can literally `await sleep("365d")` see example below

```typescript
import { sleep } from "workflow"

// thanks UK gov
async function payTaxes() {
    "use workflow"
    await sleep("365d")
    let companyValue/2
}
```

I honestly implore you to go read through it and try and get your head around the mental model, because this is going to shape the way you use AI in the future. Or you can [just let us build it for you](/services/agentic-workflows) and pretend you built it.

## AI gateway
This isn't really a AI ship release per-say, but to be frank, **you should be using this already**. It's a one-stop-shop to use all the different AI models. It also means that you have a unified way of interacting with them and a universal way of paying for tokens.

The alternative is signing up for every single model provider and creating like 5 different API keys.

Now you can stop duct-taping your backend together with ChatGPT responses. 

### More reasons to use it
- Unified billing
- Better rate limits
- More intelligent routing
- Failover when your favorite model has a meltdown
- Observability
- No infra changes when somebody releases their new weekly model

*Probably should have just lead with that.*

## Fluid and active CPU pricing
I'm not even going to start to pretend I know how this works, but I can tell you the effect it has. *It's going to cost you less to run AI functionality.*

This is the official statement from some boffin from Vercel

> Fluid intelligently orchestrates compute across invocations. Multiple concurrent requests can share the same underlying resources. Teams saw up to 85% cost savings through optimizations like in-function concurrency.
It means your paying less for the compute you don't *actually* use

![Diagram: an AI function waits for something to happen, and you don't pay for the wait](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-body-image-2.png)

For those of you that don't understand unless you have a Marvel reference, like a well adjusted adult.

> Imagine the Avengers are facing a massive threat, and instead of each hero fighting with their own separate gear, they have access to a shared arsenal of super gadgets. Iron Man’s suits, Thor’s hammers, and Black Widow’s tech are all pooled together, allowing each hero to grab what they need when they need it. This way, they don’t need to carry everything themselves, and they can respond to threats more efficiently.
> In the tech universe, "Fluid" acts like Nick Fury, orchestrating the use of computer power. When multiple tasks come in, it ensures they can share the same resources, just like the Avengers sharing their gear. This teamwork saves a lot of resources, like saving the world without needing extra gadgets for every hero.

## Vercel Sandboxes
> [Vercel Sandbox is an ephemeral compute primitive](https://vercel.com/docs/sandbox)
*No, I didn't understand either. Let's try again*

Vercel sandbox is a way to run potentially unsafe or user generated code without this happening.

![xkcd Exploits of a Mom comic about little Bobby Tables and SQL injection](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-body-image-3.png)
*Exploits of a Mom https://xkcd.com/327/*

LLM models can generate code, and the codes are used to deploy programs. But sometimes it can break catastrophically. The Sandbox is created to solve it, and here is how:

- Every execution runs inside an isolated micro-VM
- No access to prod environments
- No "oops we just deleted our own database" moment
- Perfect for validating agent-generated fixes before a human approves them

> **Next.js app development**: Next.js builds on Vercel with edge functions, AI integration, and production performance. [Learn more](/services/nextjs)

## Marketplace of Agents & AI tools
Vercel "just works" with most apps out of the box. In short, you choose the tools you need, you hit the "add" button, and rather than going off to manually configure databases and blog storage, it's all done for you. It means your focus can be purely on shipping features **instead of micro-managing infrastructure.**

If you don't know what I mean, go deploy the [Next.js AI Chatbot](https://vercel.com/templates/next.js/chatbot). It uses the AI gateway, Neon database, Vercel blob storage, Upstash and a bunch more to config with .env variables.

![Product marketplace on Vercel, showing a range of different software you can one click install](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-product-marketplace-on-vercel-showing-a-range-of-d.png)

You can do it all in one go by pressing a couple of buttons and setup the entire infra to create a chatbot. If you've ever tried doing this manually, it's roughly saving a couple of hours of your time and at least one annoying bug fix when you forget to add an .env variable.

## AI Agents for enterprises
Building AI for SMEs is one thing, but for enterprise, you're entering a whole new world of pain. We're going to help you fast-track getting your first agent out, and cover the topics that infosec will want to *have a word with you* about.

### Observability
We've mentioned this briefly before, but observability is going to be your lifeblood for debugging niche issues with your agent. You can step through prompts literally message by message with Vercel and see what tools did or ***didn't*** fire. It's also a great way of understanding failover with models like Gemini and Claude, which have been notorious for choking.

### BotID
Now this especially applies if you're running the agent publically. BotID is going to save you from those 5 figure bills if somebody decides to try and hit your agent with a brute force prompt.

If you haven't seen it before it's basically Google's reCAPTCHA, but doesn't suck and doesn't put a label at the bottom right of your screen. It's invisible, and has one of the most comprehensive and impressive Bot detection databases. It also has active AI in there somewhere, so it can do some crazy [stuff like this](https://vercel.com/blog/botid-deep-analysis-catches-a-sophisticated-bot-network-in-real-time). 

### Agents in observability
Nothing like a 2007 meme to really set-off an enterprise section, but it's actually an accurate portrayal of what agents in observability does.

![Yo dawg meme: an agent in your observability that observes your agent](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-body-image-5.png)

It's effectively an agent that helps you make sense of what the errors are telling you. It's incredibly helpful because 5XX errors don't really help you debug a problem.

However, suppose the agent investigates and tells you that there was an auth failure from the **vendor's side.** In that case, you can save all the time investigating it and instead bring it up as a bargaining chip the next time you're negotiating enterprise contracts.

Here's an example below.

![Vercel observability agent investigating a spike in /api/auth 5xx error rate](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/vercel-ship-ai-2025-blog-body-image-6.png)

### What to build
With all these gems we've dropped so far about how to keep infosec happy and procurement up to date with bargaining points, you surely don't expect us to spoon-feed you an idea of what to build?

Well, lucky for both of us, we don't need to tell you, Vercel did it for us. I'll just let [Malte take it away](https://www.youtube.com/watch?v=mZzAuFq5C6Q&t=2444) with some OSS tools you can start your agent builds with.

#### [OSS lead agent](https://vercel.com/templates/ai/lead-processing-agent)
It's a way of enriching your sales flow to stop you from copy pasting manual information about inbound leads. It can be tweaked exactly the way you quantify leads, e.g, research most recent funding rounds, research where the business is located, whether they have any outstanding lawsuits, you name it, you can tweak it.

#### [OSS data analyst agent](https://www.youtube.com/watch?v=mZzAuFq5C6Q&t=2793)
This is an agent that can sit on top of your data warehouse and effectively create SQL queries to find deep insights about it.

Speaking of deep dives on analytics data, this is also something [PostHog does a great job with](/blog/we-dumped-google-analytics-for-posthog) and is a prime example of what this agent could help with.

### Let us build you something
We've already been implementing a ton of agents for our clients, and [we'd love to add you to the list](/services/agentic-workflows). We've done everything from data enrichment, AI overviews of performance optimisation, and even SEO/AIO workflow audits. Give us a shout.

## Wrap it up

If you haven't guessed already, the AI Cloud is designed to remove infrastructure from the equation, allowing teams to ship faster. We're great believers of this as a business, and it's been wildly successful for us when it comes to building websites. Why not do the same for AI?

We'll leave you with this handy little list of what everything does if you need to refer back in the future

- **AI Gateway:** With this, you can pick any LLM model and switch it anytime you want
- **Fluid Compute:** Only pay when CPU is actually used
- **Sandboxes:** Run *unsafe* code *safely*
- **Workflows**: Durable and resumable implementations
- **Observability:** See every step, every token, and every failure
- **Zero config:** Deploy and forget
- **BotID:** better reCAPTCHA

With all this amazing tooling, there's never been a better time to build an agent. We'd love to hear about what you're working on, and if you have any questions, we're more than happy to answer them. 

> You can bet your AaaS we're building something too (sorry)

---

## Next.js 16 for dummies


> Wait, I’m sure it was only just in beta. Guess we’re production ready, baby.

**TL;DR:** Next.js 16: It's faster, smarter, and you can control caching. Turbopack speeds up builds, and React 19.2 cleans your code. If you read the long version, congrats on wasting time. Just upgrade and enjoy the perks. You're welcome.

**Published:** 2025-10-22 | **Updated:** 2026-07-23 | **Categories:** Next.js
---

Every few months, Next.js drops a new release, and honestly, I usually understand about *half of it*. For the other half, we comb through the docs until we figure out all the fancy bits and experimental flags.

We created this guide to make some of the more complex aspects of Next.js easier to understand and something I'd *actually* want to read.

## What’s new and shiny
### Model Context Protocol (MCP) 
Model Context Protocols is a way for Cursor to get fed with useful contextual information. Next.js getting its own MCP is like having a conveyor belt of current best practices fed directly into your IDE. It's slowly but surely removing the human from the loop and ensuring your slop code is a little bit more cohesive and follows the docs.

> Fun fact: [v0](https://v0.app/) has done this for a long time; we even wrote a blog post [about it](/blog/how-our-studio-uses-v0).
Next.js MCP can:

- Understand routing, caching, and rendering behavior.
- Unify browser logs and server logs in one place.
- It reads stack traces for you, which literally means that it explains the errors, which means you don't have to spend 20 minutes guessing which error belongs to which requests.
- The AI actually knows the route you are looking at. So instead of vague "something broke," it can say, "your /pricing page exploded because of something right here."

Basically, now you can point an AI Agent in your app and let it diagnose issues, weird behavior, and propose fixes with real context, without you having to do it manually. Don't know about you, but we definitely hate doing this. If you want to take this further, we build [agentic workflows](/services/agentic-workflows) that wire MCPs into full automation pipelines. Here's a list of MCPs we use.

![MCP servers list in a coding tool, warning that 132 enabled tools exceed the limit](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/nextjs-16-for-dummies-blog-body-image-1.png)
*If you're not using 99% of your coding context from MCP alone, you're not doing it right*

> If you're not using 99% of your coding context from MCP alone, you're not doing it right.
### Cache components
If you've been around Next.js for long enough, I guarantee you've experienced your website getting cached unexpectedly. You might think it's a design flaw, but it usually occurs for a good reason. 

Cache makes everything faster without actually making your code smarter. It basically remembers things. Instead of regenerating the same data or response every time, cache stores it temporarily, so your app can deliver results instantly.

When a user hits a page or API repeatedly, your server doesn’t need to re-run all the logic, database queries, or rendering steps; that stuff is expensive. It simply serves the saved result. That means lower latency, less CPU strain, and happier users. 

#### How to use it?
Just throw a "use cache" at the top of your file, component, or function. Here's where it gets interesting:

- **You're in control:** Unlike before, caching is now opt-in. You decide what gets cached and what doesn't. No more debugging "ghost pages" that turn out to be from a stale cache from three deploys ago. 
- **Works everywhere:** You can cache only what you need, like pages, components, and functions.
- **Automatic keys:** The system automatically figures out what to remember, so you don’t have to play "guess the cache key".

[Or just get us to build it for you](/services/nextjs). We're not above shameless plugs.

#### Configuration
First, enable it in your configuration:

```javascript
const nextConfig = {
  cacheComponents: true,
};

export default nextConfig;
```

Then, use the "use cache" directive in your code:

```typescript title="stealing-next-example.tsx"
// File level
'use cache'

export default async function Page() {
  // ...
}

// Component level
export async function MyComponent() {
  'use cache'
  return <></>
}

// Function level
export async function getData() {
  'use cache'
  const data = await fetch('/api/data')
  return data
}

```

#### Why it matters
The new cache in Next.js 16 makes performance predictable. It's more of an **opt-in** with granular control and less of an **opt-out** with smart defaults.

Website loads instantly because its main parts are cached and don’t change often. Only elements unique to each user, like discounts or saved items, load as needed. This cuts down on server work and internet use, making the site run much faster.

Remember the time you went from casually browsing clothes online to "thanks for your purchase"? Well, that's partly because the checkout never made you wait and partly because of a lack of impulse control. *Hisss.*

#### Don't blame us
Because it's **opt-in**, make sure you're always conscious of caching things correctly. We don't want any hate mail about a $10k bill your new intern racked up after reading this.

If you want our hot take, for most developers, I would actually advise ***against*** using this, because I've seen your code and I know the slop you write.

### Turbopack is enabled by default
Turbopack is the long-awaited bundler that you can use instead of Webpack. What is a bundler? It's like Stonehenge or the Egyptian Pyramids. Nobody knows how they got built, but it's probably some nerd who figured it out somewhere.

Simply put, it compiles code.

#### It's on from day one
In Next.js 16, Turbopack is now the default bundler for all apps. You don't need to set up or configure anything special. It just works, and it's faster.

#### Numbers to show your boss
##### 5-10x faster refresh
When you make changes to your code, the browser will update them instantly, before you can even sip your coffee.

##### 2-5x faster builds
Production builds that finish before you lose focus. In previous Next.js versions, you had time to stretch, refill your coffee, and reconsider your career choices.

### Turbopack file system caching (beta)
Remember how we talked about caching? This is caching at a deeper level. Turbopack now remembers what it's already compiled, so the next time you start your development server, it doesn't have to do all that work again.

#### How it works?
Think of it like this:

- **First time:** Turbopack compiles everything and saves it to disk.
- **Second time:** Turbopack says, "*Here's one I made earlier.*"

#### The benefits
You’ll notice the difference the moment you start a project. Next.js 16 boots up faster than ever, reducing the wait time drastically. When you make changes, the compiler reacts instantly. You write, save, and see it update.

If you’re working on a massive app with hundreds (or thousands) of files, Turbopack processes and optimizes them instantly. More importantly, it doesn't choke and give you 16-second response times to change pages.

That said, **it’s still in beta**. Which means we're undoubtedly going to run it on prod for our own website. If you're able to read this, it's working.

### Optimized navigation and prefetching
The prefetching is now much smarter. What it does is, when it thinks you might click a link, it starts loading that page in the background before you even click it. So when you do click, boom. It's already there.

#### Layout deduplication
You no longer need to reload the same layout every time you switch pages. Shared elements, such as headers, sidebars, or navigation bars, remain intact, resulting in smoother transitions and fewer unnecessary re-renders. It’s a small change that’ll make a big difference in how fast your app *feels, especially* in e-commerce.

#### Incremental prefetching
Instead of pulling in everything upfront, Next.js now fetches content gradually. You get faster interactions, less wasted bandwidth, and a smarter way to handle data loading.

#### Faster page transitions
With these optimizations working together, navigating between pages feels nearly instantaneous. There is no lag or any flicker, resulting in just a clean, continuous experience that makes your app feel truly dynamic.

We can't wait to test this across larger applications. If it holds up the way the release notes suggest, navigation in Next.js might finally feel as smooth as it always looked in the demos.

### Improved caching APIs
Simply speaking, you now get precise control over when and how your data cache updates. Instead of guessing when Next.js will refresh something, you can tell it directly. It’s cleaner, predictable, and finally makes cache invalidation feel less like an engineering choice.

#### More tags
There are two new tags and one tag improvement:

##### revalidateTag() - now with profiles

This function tells Next.js to refresh cached data. Now it's even smarter:

```
// Use built-in profiles for common scenarios
revalidateTag('blog-posts', 'max');      // Cache for a long time
revalidateTag('products', 'days');       // Cache for days
revalidateTag('comments', 'hours');      // Cache for hours

// Or set a custom time
revalidateTag('user-data', { revalidate: 3600 }); // 1 hour

```

##### 2. updateTag()
This is brand new and super useful. It lets you update cached data immediately when something changes:

```
// When a user updates their profile, refresh it right away
updateTag(`user-${userId}`);
```

##### 3. refresh()
This refreshes only uncached data, leaving your cache alone:

```
// Refresh data without touching the cache
refresh();
```

If you’ve ever tried managing cache logic in older versions of Next.js, you know it could be a pain. Half of the time, it was guesswork, and the other half superstition.

Now, with the new caching APIs, you’re in control. Removing all-or-nothing refreshes or overzealous invalidation data nuking. You can revalidate, update, or refresh only what actually needs attention. 

### Build adapters API (alpha)
A build adapter is like a plugin for your build process. It lets you customize how Next.js prepares your website for the internet. You control *how* your app gets packaged and deployed, instead of relying on the default "one-size-fits-all" flow. This means you can tailor builds for different environments or platforms, like Vercel, to on-prem setups. It’s still in alpha, but the idea is solid.

> Please don't output your Next.js build onto a janky-ass $5 Hetzner VPS.
#### What can you do?
With build adapters, you can finally shape the build process to fit your stack and not the other way around.

- Adjust how your assets and code are packaged to suit different deployment targets or performance needs.
- Slot in extra tasks before or after the main build.
- Connect your build with CI/CD pipelines, analytics, or external frameworks without hacking around the defaults.

Let's say you want to add specific optimization for a specific hosting platform. Instead of waiting for Next.js to add it, you can create a build adapter to do it yourself.

```
// This is a simplified example
export const myCustomAdapter = {
  name: 'my-custom-adapter',

  async build(context) {
    // Your custom build logic here
  },
}

```

> You know our opinion: *Just use Vercel*

> **Next.js app development**: We build and upgrade Next.js apps. Server components, app router, and production performance. [Learn more](/services/nextjs)

### React 19.2
You know that React is the library that powers the interactive parts of your website. Version 19.2 brings a handful of upgrades that make building dynamic interfaces faster, cleaner, and a lot less painful.

We’re particularly interested in seeing how these updates play with Next.js 16’s new caching and navigation improvements. If it all clicks (pun intended), we’re looking at smoother state management, fewer rerenders, and cleaner data flows across components.

#### New stuff
##### useEffectEvent() - cleaner code
This hook helps you write cleaner code when you need to do something in response to user actions:

```
import { useEffectEvent } from 'react';

function ChatRoom({ roomId, theme }) {
  // This function won't cause the effect to re-run
  const onConnected = useEffectEvent(() => {
    showNotification('Connected!', theme);
  });

  useEffect(() => {
    const connection = createChatConnection(roomId);
    connection.on('connected', () => {
      onConnected();
    });
  }, [roomId]); // Only depends on roomId, not theme
}

```

You can use values like theme without causing unnecessary re-renders.

##### View transitions
This makes page transitions smoother and more visually appealing. It's like adding a fade or slide effect between pages automatically. If you want to see a demo of it in action, [check this out](https://view-transition-example.vercel.app).

##### Activity component
This new component lets you hide and show parts of your UI while keeping their internal state:

```
import { Activity } from 'react';

<Activity mode={isShowingSidebar ? 'visible' : 'hidden'}>
  <Sidebar />
</Activity>

```

When you hide the sidebar, it remembers its state. When you show it again, everything is exactly as it was!

## Quick comparison
Nerds love tables. Here's one for you.

| Feature | Before | After |
| --- | --- | --- |
| Bundler | Webpack | Turbopack |
| Caching | Implicit (automatic) | Explicit (if enabled) |
| Build speed | Slower | 2-5x faster |
| Refresh speed | Slower | 5-10x faster |
| React features | 19 | 19.2 with new hooks |

## How to get started with Next.js 16
Ready to upgrade? Here are your options:

### Option 1: Automatic upgrade (recommended)
```plaintext
npx @next/codemod@canary upgrade latest
```

### Option 2: Manual upgrade
```plaintext
npm install next@latest react@latest react-dom@latest
```

### Option 3: Start fresh
```plaintext
npx create-next-app@latest
```

## Closing thoughts
Next.js 16 feels like a very good QOL release and polish. It's got lots of functionality to support even wider vendors other than Vercel. It's basically

> Better DX, with more compatibility. Ship slop faster than ever before.
We’ve been testing the beta prior to this release on a few projects, and if the early results hold up, Next.js 16 might be the calmest build cycle we’ve had in years. What a time to be alive. If you’re already on 16, check out what landed in [Next.js 16.1](/blog/nextjs-16-1-for-dummies).

We dogfood every major Next.js release on our own site and our open-source starter [turbo-start-sanity](https://github.com/robotostudio/turbo-start-sanity), a Next.js + Sanity monorepo running Turborepo with Turbopack, React Compiler, and OG image generation out of the box. We break our own stuff so you don't have to. If you want to skip the learning curve entirely, we build [Next.js projects](/services/nextjs) paired with [Sanity](/services/sanity) for a living. ***Go get in touch below***.

---

## We dumped Google Analytics for PostHog


> Our relationship with Google Analytics has ended, and we're even throwing away our mix CDs. PostHog is the new bad boy in town.

**TL;DR:** Switched from Google Analytics to PostHog. Setup was slick. Don't record EVERYTHING. Find UI errors through rage clicks. Don't bother learning SQL, just use MCP instead. Stick with Google Analytics if you're a sadist. Probably should've just read the blog instead, huh?

**Published:** 2025-10-22 | **Updated:** 2026-08-24 | **Categories:** Performance
---

Have you ever looked at your Google Analytics dashboard and thought, "this is exactly what I needed from my analytics tool"? **_If you have_**, don't bother reading the rest of the blog.

However, if you are like us and feel a little confused and have trust issues with the tool, find out why we vouch for PostHog, a top-tier analytics tool with a cute little hedgehog (that's the main selling point).

## Say hi to PostHog

To all the developers, analysts, and marketers reading this blog, nice to ***see*** you here, ***literally***, [read more later](#were-always-watching). We recently transitioned from Google Analytics to PostHog, and trust me, *it was worth it*.

I think it's worth starting with our chequered history of Google Analytics. We've never actually understood what the hell is going on with the tool, and I'm fairly certain we're not the only ones.

We weren't looking for a miracle; we simply wanted to find out how many people came to our website, from what platform, and ultimately what made them want to buy a website. Because surely, it couldn't be from *just a blog post*. 

The big difference here is the setup required to get Google Analytics working. Yes, there's the [third-party Next.js library](https://nextjs.org/docs/app/guides/third-party-libraries#google-analytics), but that's only half of the battle. Once this is added, you need to start looking at firing off specific events, which you then need to link up in one of the many panels in the dashboard. It's hellish. 

Compare this to Posthog. You run `npx -y @posthog/wizard@latest --region us` (change region to EU if you enjoy bureaucracy) and you're basically good to go. The startup wizard correctly guessed the two most important events on our site, and we were up and monitoring those events in less than an hour. End-to-end, yes, really.

One piece of advice we'd start with for anybody looking into analytics is:

> Start with just one or two events, no more
It's going to be easier to measure, without murkying your data with superfluous events. Start by picking the thing that makes you money and double down on understanding the user flow.

Now that you know the analytics is tracking correctly, we want to move on to querying data and presenting beautiful dashboards. 

## Dashboards
> This is my dashboard. There are many like it, but this one is mine.
With that out of the way, trust us when we say this: **keep your most important metric on your dashboard's homepage**. In our case, it looks like this.

![PostHog dashboard insights tracking booked meetings and form submissions over 30 days](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-dumped-google-analytics-for-posthog-blog-body-image-1.png)

The reason why? Well, those spikes are almost directly correlated to client calls that have led to projects. [Don't worry, you can join those spikes](/contact). But it's what keeps the lights on and leads us to being able to write half-baked articles like this.

Just kidding, but the point still remains, don't create too much data from the get-go, as you'll want to focus on the metrics that count.

## We know you didn't rage-click on this blog
Exploring PostHog, you will come across an event named $rageclick. This single event helped us fix so many of our UI bugs and enhance user experiences. In theory, the event will look like this.

![PostHog $rageclick event entry with no description set](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-dumped-google-analytics-for-posthog-blog-body-image-2.png)
*Rageclick event illustration *

In case you didn't know, you can press `CMD+K/CTLR+K` to see the magical command palette, and literally do anything that is on your mind. 

Moving forward with rage clicks, let me show how we created our dashboard and caught the UI bugs in our products, our way.  

Click on the little + icon on the '*Product analysis*' button, go to trends, in the 'Series' dropdown, select Rageclicks, and choose Unique users in the dropdown beside it, and you are good to analyse all the session recordings of the rageclicks. Too much information? We made a video to simplify it. 

### We're always watching
In case you didn't notice, you can see **the user's session recording by pressing on the tip of the graph patterns**. Yes, creepy, *we know*.

The next task, after filtering out rage-click recording sessions, is to determine whether the event was a genuine rage-click or just the user being impatient.

If your developers did a ***bad enough*** job of the user experience on your website, you'll see a whole host of rage clicks. Here's a breakdown below of all the different events firing off from just one user session inside the screen recording section.

## Heatmaps in action 
Although in beta right now, heatmaps have already helped us find interesting, actionable insights. To use heatmaps, you can launch the toolbar directly, which will take you to your product/website. 

You get a load of options to select from, including clicks, dead clicks, rage clicks, and scrolling depth analysis, all according to your needs.

But how are we finding the useful insights that matter? For us, it takes a little bit of figuring out, looking for misclicks around buttons, or interacting with non-interactive parts of the site. Essentially, find the misclicks and rage-clicks, and start from the simplest issues to solve, all the way up to complex ones.

## Steal our Sanity code
As you've probably guessed, we're using this with Sanity, and we're being very intentional about how we track our data. If you're looking to do the same and want a way of identifying who submits your forms, here's a very stripped-down version using [Shadcn/ui](https://ui.shadcn.com/).

```typescript title="form.ts"
export default {
  name: "form",
  title: "Form",
  type: "object",
  fields: [
    {
      name: "eventName",
      title: "Event Name",
      type: "string",
      validation: (Rule) => Rule.required(),
    },
  ],
};
```

You can improve this with Typescript and better previews, but this is the bare bones, same principle for the frontend, we'd obviously recommend Zod and Typescript and all that jazz, but this is barebones to get you started. If you want to head down the rabbit hole, [I've got just the guide for you](https://ui.shadcn.com/docs/forms)

```typescript title="form.tsx"
"use client";

import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import posthog from "posthog-js";
import { useState } from "react";

export function FormBlock({ eventName }: { eventName: string }) {
  const [success, setSuccess] = useState(false);
  const [email, setEmail] = useState("");
  const [fullName, setFullName] = useState("");
  // TODO: Bring your own form library (react-hook-form, formik, etc)

  function onSubmit(e: React.FormEvent) {
    e.preventDefault();
    posthog.identify(email, { email, name: fullName });
    posthog.capture(eventName);
    setSuccess(true);
    setEmail("");
    setFullName("");
  }

  return success ? (
    <>
      <p>Thank you!</p>
      <Button onClick={() => setSuccess(false)}>Submit another</Button>
    </>
  ) : (
    <form onSubmit={onSubmit}>
      <label>Name</label>
      <Input
        placeholder="Your name"
        value={fullName}
        onChange={(e) => setFullName(e.target.value)}
        required
      />

      <label>Email</label>
      <Input
        type="email"
        placeholder="your@email.com"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        required
      />

      <Button type="submit">Submit</Button>
    </form>
  );
}
```

If you struggle getting any of this setup, [get in touch](/contact), we always like to hear somebody is actually reading one of our guides, and we're not just screaming into the void.

> **Next.js app development**: Analytics integration, event tracking, and Next.js platform development. [Learn more](/services/nextjs)

## Should I learn SQL?
If you're already a nerd, you might actually know how to use SQL. It's great that you took all that time to learn, but now that learning is redundant because of MCP (Model Context Protocol).

If you've been living under a rock and don't know what MCP means, it's essentially a way for companies to extend their functionality to be able to talk to AI. This is important for you because instead of having to learn all the syntax to write the query below, we can simply prompt an AI to do it instead.

![PostHog SQL editor with a session events query and results panel](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-dumped-google-analytics-for-posthog-blog-body-image-3.png)
*SQL query demonstration*

So if you're familiar with Cursor, Claude, or any of the other AI IDEs, you can connect Posthog in one command. `npx @posthog/wizard mcp add`

This then allows you to talk directly to PostHog in normal sentences to get dashboards set up exactly the way you want. E.g.:

```plaintext
Please provide a list of all the different data sources that are being tracked on my website. Additionally, create a pie chart that visually breaks down the contributions of each data source to the overall data collection.
```

You would ensure the MCP was active and drop the snippet above into whatever you would choose. Or if you're exceptionally lazy and already use Cursor, you could just press this [button](https://cursor.com/link/prompt?text=Please+provide+a+list+of+all+the+different+data+sources+that+are+being+tracked+on+my+website.+Additionally%2C+create+a+pie+chart+that+visually+breaks+down+the+contributions+of+each+data+source+to+the+overall+data+collection.).

> The first ones on the house
## More on PostHog
Here's a cliché line you hear everywhere: yes, this is just the tip of the iceberg when it comes to what we can do with this tool. We are in the process of mastering it, and will definitely document it as we ***really*** get the hang of it. Until then, happy learning, and see you guys soon. 

If you want to use an objectively worse analytics tool, you are more than welcome to read our blog on [how we use Google Analytics for valuable insights](/blog/how-to-use-google-analytics-and-actually-get-something-out-of-it).

---

## Page-builders and spacing


> Explore the chaos of page builders and 8px grids, the perils of spacing, and Tailwind CSS joys. A guide to save your sanity or at least make you laugh.

**TL;DR:** Page builders: love the 8px grid, hate user-defined padding. Avoid chaos by sticking to pre-defined values. Remember, consistency is key. You also missed a really good joke about a penguin in traffic. I hope you're happy.

**Published:** 2025-08-22 | **Updated:** 2026-08-24 | **Categories:** Sanity, How To
---

> If you've ever worked with page builders and padding, or worse-still, *user defined padding,* you'll know why we wrote this.
I'm going to start with a trip down memory lane, and later on, get into the technical, so if you're a dev, you'll probably want to skip the first section, or stay along for the ride.

## Standard spacing rule system
Ever wondered why we often use 8px inside design? Well, there isn't really a definitive reason, but I'm going to tell you why we harp on so much about it. It's because we design most websites for desktop. Yes, I know there was that whole "design for mobile first", but go walk over to your design team, ask them to show you a wireframe for your website, and I'll bet dollars to donuts they don't show you a mobile wireframe first.

So why desktop then? Well, as you probably know, most monitors aren't 4:3 anymore, they're nearly all 16:9, unless you're one of those weird "gamers" who have to go and get a 21:9 monitor and break the whole pattern. You know the interesting thing about 16:9 - it's divisible by 8. Why is that important? Well, it means you're never going to get a blurry line if you put a line on a **whole pixel.** Let's not get into sub-pixel rendering, because that's a whole different ball game. Let's go from here on out and assume 8px is the best, and people who use 10px in their designs should get replaced by AI, sooner than later.

Another handy part of using an 8px grid, or more specifically, moving onto Tailwind CSS default setup, is that we can very easily work out visual rhythm, do you want something to be double the distance from X to Y? Well you just double the number.

Why is visual rhythm important? Well, let me show you:

![The old LINGsCARS website, a chaotic collage of clashing colours and banners](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/spacing-in-page-builders-blog-body-image-1.png)
*Old Ling's cars*

This is [Ling's cars](https://www.lingscars.com/). Funnily enough, this website didn't convert well because it ***lacks rhythm***. The content looks as though somebody accidentally kicked over a LEGO box and I personally thought it was a joke website (and younger me nearly ended up leasing a car).

**Here's what it looks like today**

![LINGsCARS today: a tidier car leasing homepage that keeps its loud personality](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/spacing-in-page-builders-blog-body-image-2.jpg)
*Ling's cars today*

Yes, boring, I know. However, there is a good reason it resembles all the other websites on the internet. It's because we're used to this rhythm. We start at the left and work our way across in a Z pattern.

One more part of understanding of visual rhythm is not screwing up the way you code page builders. Have you ever seen a conditional in JavaScript before? Well this little baby is going to save you from having varying spacing, and as a bonus, it's basically necessary if you don't want to break your preview with `Next/Image`.

```jsx
{title && <h1 className="mb-8">{title}</h1>}
```

With the above, if you don't have a title. You won't have the space and the margin bottom where that ``<h1>`` would have ultimately been. This is especially important when working with live previews. So heed my advice - most, if not all, of your `string` content should be rendered in a similar manner to the above code.

One last thing for those of you old enough to have remembered the glory days of using Bootstrap: base 8 works wonderfully with a 12-column grid. Now, if you use a 12-column grid in this day and age, there's something very wrong with your layouts... But at least it's nice to share that blast from the past.

## Never, ever, allow user-defined padding
Want to know the best way to ruin my day? ***User-defined padding***. If you so much as utter this word, I feel the vein in my forehead ready to burst

![Meme of a tense student hearing the words user-defined padding whispered](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/spacing-in-page-builders-blog-body-image-3.png)
*User-defined padding nearly pushing me over the edge*

Why would somebody be so upset over pixels you might ask? Well it's probably because once you add this god-foresaken functionality into your page builder, you will never know the concept of consistency ever again.

It all starts with something looking slightly off in a pagebuilder layout, and quickly spirals out of control until everything is 32px on the bottom, 72px on the top, and for some reason 12px on the right, overflowing.

Believe me when I tell you this:  we've seen folks change their website design three times. First with a colorful, brand-focused look, then with mostly white backgrounds, and finally with dark backgrounds. 

As you might imagine, by the time it was finished, there was black and white everywhere, with occasional pops of red... Like a penguin in a traffic accident. Guess what the next question was to resolve this?

> Can we add padding to our page builders?
### But we really want user-defined padding
So you ignored everything I said above and still wanted it anyway. That's fine, that's ok. I'll spell it out passive-aggressively for this next paragraph.

If you absolutely **have to do this** you will want to ensure you're using pre-defined strings... **never** number inputs. 

Here's the Sanity side of things

```jsx
// worst-schema-ever.tsx
// schemaTypes/blocks/standard-block.ts
import { defineType } from 'sanity';

export default defineType({
  name: 'standardBlock',
  title: 'Standard Content Block',
  type: 'object',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
      description: 'Optional heading for the content block',
    },
    {
      name: 'paddingSize',
      title: 'Vertical Padding',
      type: 'string',
      options: {
        list: [
          { title: 'None (0px)', value: 'none' },
          { title: 'Small (16px)', value: 'small' },
          { title: 'Medium (32px)', value: 'medium' },
          { title: 'Large (48px)', value: 'large' },
          { title: 'Extra Large (64px)', value: 'xlarge' },
          { title: 'Page Builder (128px)', value: 'pagebuilder' },
        ],
        layout: 'radio',
      },
      initialValue: 'pagebuilder',
      description: 'Choose the vertical padding for this content block',
    },
    // ... other fields (content, images, etc.)
  ],
  preview: {
    select: {
      title: 'title',
      paddingSize: 'paddingSize',
    },
    prepare({ title, paddingSize }) {
      const subtitle = paddingSize 
        ? `Padding: ${paddingSize}` 
        : 'Default padding';

      return {
        title: title || 'Standard Content Block',
        subtitle,
      };
    },
  },
});
```

And here's the component side of things

```jsx
// seriously-dont-do-this.tsx
// Padding mapping for user-defined values
const paddingMap = {
  'none': 'py-0',
  'small': 'py-4',   // 16px
  'medium': 'py-8',  // 32px
  'large': 'py-12',  // 48px
  'xlarge': 'py-16', // 64px
  'pagebuilder': 'py-pagebuilder', // 8rem (custom)
} as const;

type PaddingSize = keyof typeof paddingMap;

interface StandardBlockProps {
  title?: string | null;
  paddingSize?: PaddingSize;
}

export function StandardBlock({ 
  title, 
  paddingSize = 'medium' // Default to 32px
}: StandardBlockProps) {
  const paddingClass = paddingMap[paddingSize] || paddingMap.medium;

  return (
    <section>
      <div className={`container ${paddingClass}`}>
        {title && (
          <h2 className="mb-8 text-center text-2xl font-medium">
            {title}
          </h2>
        )}

        {/* Your content goes here */}
        <div>
          Content placeholder
        </div>
      </div>
    </section>
  );
}
```

[(or you'd never know this pain if you just used our workshops)](/services/workshops)

### So how do I do it correctly?
You'd be wrong in thinking we haven't already looked into finding the best solution for this. We've spent days and weeks testing this across a range of projects, and the simplest way of making sure this never happens is to simply add a pagebuilder value inside of Tailwind CSS and never break convention.

Here's how you can do it for Tailwind CSS v3

```jsx
// tailwind.config.ts
import type { Config } from "tailwindcss";

const config = {
  content: [
    // Add your content paths here
    "./src/**/*.{js,ts,jsx,tsx,mdx}",
  ],
  theme: {
    extend: {
      container: {
        center: true,
        padding: "2rem",
        screens: {
          "2xl": "1920px",
        },
      },
      spacing: {
        pagebuilder: "8rem",
      },
    },
  },
  plugins: [],
} satisfies Config;

export default config;
```

Or if you're using the latest Tailwind CSS v4

```css
// app.css
@import "tailwindcss";

@theme {
  --breakpoint-2xl: 1920px;
  --spacing-pagebuilder: 8rem;
}

@utility container {
  margin-inline: auto;
  padding-inline: 2rem;
}
```

> **Next.js app development**: Page builders, design systems, and component architecture built on Next.js. [Learn more](/services/nextjs)

So now you've got this, how do we use this for a page-builder block? Well, it's pretty simple. Here's how you would apply it to a regular page builder block.

```jsx
// standard-block.tsx
import { PortableText } from '@portabletext/react';

export function StandardBlock({ 
  title, 
  content // This should be portable text content from Sanity
}) {
  return (
    <section>
      <div className="container py-pagebuilder">
        {title && (
          <h2 className="mb-8 text-center text-2xl font-medium">
            {title}
          </h2>
        )}

        {content && (
          <div className="prose prose-lg mx-auto">
            <PortableText value={content} />
          </div>
        )}
      </div>
    </section>
  );
}
```

But as with anything padding-related, there's always a curveball. How do we handle page builder blocks when there's a background image, because then it's going to be flush to the block next to it? Well, that's nice and easy, we double the number of `py-pagebuilder` classes and add an additional div.

```jsx
// bg-image-block.tsx
import { PortableText } from '@portabletext/react';

export function BackgroundImageBlock({ 
  title, 
  content, // This should be portable text content from Sanity
  backgroundImage 
}) {
  return (
    <section 
      className="my-pagebuilder"
      style={{
        backgroundImage: backgroundImage ? `url(${backgroundImage})` : undefined,
        backgroundSize: "cover",
        backgroundPosition: "center",
      }}
    >
      {/* Inner container with its own pagebuilder spacing */}
      <div className="container py-pagebuilder bg-white/90 backdrop-blur-sm rounded-lg">
        {title && (
          <h2 className="mb-8 text-center text-2xl font-medium">
            {title}
          </h2>
        )}

        {content && (
          <div className="prose prose-lg mx-auto">
            <PortableText value={content} />
          </div>
        )}
      </div>
    </section>
  );
}
```

Again, you'll probably want to use `py-pagebuilder` or `my-pagebuilder`, depending on how you want to display your background image. You can figure that bit out; we're not going to spoon-feed you the whole way, or we wouldn't be in business.

### Wait, the client just said the blocks are too close together
Thank goodness, we built this whole spacing the way we did. Otherwise, we'd probably have to do a monster `find-and-replace` and break something as part of the process.

Because we set a global variant for this page-builder spacing, we can simply go ahead and change one value, and it will permeate throughout the entire project. 

```css
// app.css
@import "tailwindcss";

@theme {
  --spacing-pagebuilder: 8rem;
  --spacing-pagebuilder: 6rem; // client says too big
  --spacing-pagebuilder: 12rem; // client says too small
  *{
    display: none; // client says make it pop
  }
}
```

## What if I already screwed this up and built my project
Oh, didn't you know? We inherit ***way over*** half of the projects we maintain. Why do you think I put so much vitriol into these blogs? It's the only way I can vent after seeing the average agencies' code quality. Let me give you the quick-fire process with the help of AI.

Basically, you have to be careful of context windows, because that's what you'll be battling with as we have to migrate 20+ page builder blocks. So how do we handle that?

Use a markdown file to keep your AI agent in check. 

````markdown
// migration.mdc
---
description: Whenever a user is migrating a large chunk of content from one format to another
alwaysApply: false
---

Create a _migration.mdx file at the top of each respective folder, the content should be as follows:

# Schema Migration Checklist

This file tracks the migration status of schema files from the old Sanity structure to the new structure.

## Migration Rules

- Make sure the outermost container in each of these components is a <section>
- Make sure each `section` has the className <section className="py-pagebuilder"/>
- If there's a an image background, or absolutely positioned image inside of a relative container make sure there's two containers to ensure there's the correct amount of padding from the next respective page builder block. See example below.

```
<section className="container py-pagebuilder">
  <div className="py-pagebuilder relative">
    <Image fill .../>
  </div>
</section>
```

## Migration Status

List migration items in alphabetical order as a checklist

## Flag any irregularities or exceptions to the rule

If you come across pattern breaking files, flag them underneath a warning heading beneath and require user confirmation to make changes

## Notes

If you have any additional notes leave them here, otherwise remove heading above and leave off
````

Remember to read through the migration script to ensure you haven't missed anything you want to achieve. The one above is a simple template and needs a little tweaking specific to your project.

## Closing notes
The reason we get so flabbergasted by this kind of issue is that it's so avoidable, and effectively the only person that loses is the client, if you build it incorrectly. *Oh, and obviously us, when we inherit it and have to fix it*.

That being said, we want you to succeed, so if you're looking at building a solid page builder, we always advise the same thing. Take our [Turbo Start Sanity template](https://github.com/robotostudio/turbo-start-sanity/), and read an [opinionated guide to Sanity studio](https://www.sanity.io/docs/developer-guides/an-opinionated-guide-to-sanity-studio). You'll get more than enough information about how to structure everything. If you're still struggling, we also wrote a whole [Sanity learn](https://www.sanity.io/learn/course/page-building/an-introduction-to-page-builders) course to help with page builders.

If you'd rather just get it done perfectly the first time, you could always just pay us to build it. I heard Roboto Studio is pretty good at building Sanity websites or something. **Drop us a message below**.

---

## Our cookie banner prayers have been answered


> Most cookie consent banners drag down Core Web Vitals. Why we chose c15t, the developer-first consent tool, and what it did for our site's performance.

**TL;DR:** Cookie consent is a legal must, but most solutions are slow and clunky. Enter c15t: the fast, developer-friendly option that treats privacy as infrastructure, not an afterthought. It's like the Stripe of cookie consent, making your site faster and more compliant. We spend like 5 mins shilling this tool, why not actually read it?

**Published:** 2025-07-24 | **Updated:** 2026-08-24 | **Categories:** Next.js, Performance
---

Every modern website needs cookie consent. It's not optional - it's the law. But here's the thing: most cookie consent solutions are slow, clunky, and hurt your website's performance. They're built like afterthoughts, not core infrastructure.

At Roboto Studio, we've spent years building lightning-fast websites for our clients. We obsess over Core Web Vitals, optimize every byte, and pride ourselves on delivering experiences that feel instant. So when it came time to implement cookie consent on our own site, we weren't about to compromise on performance.

That's why we chose c15t, and why it's changing how we think about privacy infrastructure.

![c15t cookie consent banner on the Roboto Studio homepage](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-cookie-banner-prayers-have-been-answered-blog-body-image-1.webp)
*Cookie banner in the Roboto Studio landing page*

## Why consent infrastructure matters in 2025
Privacy isn't going anywhere. If anything, it's accelerating. GDPR was just the beginning. We're seeing new regulations rolling out across states, countries, and regions. We've even heard of a couple lawsuits ourselves regarding privacy.

But here's what most people miss: A *good privacy infrastructure is actually a competitive advantage*. When users trust your site, they engage more. When your cookie banner loads instantly, you don't lose visitors to slow performance. When your consent management is developer-friendly, you ship features faster.

The problem is that most cookie consent solutions treat privacy as a checkbox to tick, not infrastructure to build on. They're heavy, slow, and built for compliance teams, not for developers who need to ship fast, performant websites.

## What does the market say
The numbers tell the story: consent management is a compliance requirement that has become a **massive market opportunity**. Analyst estimates for the Consent Management Platform market in 2024 range from **$665.71M to $3.52B** depending on the report, with forecast growth rates between **12.63% and 21.9% CAGR**. The most bullish projection puts the market at **$11.59B by 2034**.

This growth is driven by real, fundamental shifts:

**Regulations are getting serious**: GDPR was just the opening act. CCPA, Brazil's LGPD, India's DPDP Act, China's PIPL, Australia's Privacy Act, and Canada's CPPA - new privacy laws are rolling out across the globe. And the penalties are real. Meta paid **€1.2B** in fines. Amazon got hit with **€746M**. These aren't slaps on the wrist; they're business-changing events.

**Users actually care**: 73% of consumers are more concerned about privacy than they were a year ago. They're not just clicking "Accept All" anymore. They want transparency, control, and trust. The companies that deliver this will win.

**Digital transformation demands it**: Every business is becoming a data business. AI, machine learning, personalization - they all run on user data. But *with great data comes great responsibility*. You need consent infrastructure that scales with your ambitions.

Consent management sits at the intersection of the **$4.4B Data Privacy Software Market** and the massive **$245.62B Cybersecurity Market**. Cookies are the visible part; the real work is building the infrastructure for the privacy-first internet.

## What is c15t and why it's different
[c15t](https://c15t.com/) is a new breed of cookie consent management platform. Instead of being an afterthought bolted onto your website, it's designed from the ground up as infrastructure. Think of it as the Stripe of cookie consent - developer-first, performance-obsessed, and built for the modern web.

You can see this philosophy in action at [c15t.com](https://c15t.com) - their landing page loads instantly, their documentation is crystal clear, and everything feels fast and modern. It's exactly what you'd expect from a performance-first privacy platform.

Here's what makes c15t different:

**Zero network cost**: Unlike traditional cookie consent platforms that load external scripts and slow down your site, c15t has zero network overhead. The consent banner runs entirely on your domain with no external dependencies.

**Next.js native**: Built specifically for modern frameworks like Next.js, c15t integrates cleanly with server-side rendering, static site generation, and edge functions. No more fighting with hydration errors or client-side-only solutions.

**Developer experience**: c15t feels like a tool built by developers, for developers. Clean APIs, TypeScript support, and documentation that doesn't make you want to tear your hair out.

**Performance first**: While other solutions add 50-100KB to your bundle size, c15t is lightweight and fast. It's designed to enhance your site's performance, not hurt it.

If you care about squeezing out every bit of performance from your Next.js stack, check out our deep dive into the [hidden gems in Next.js](/blog/hidden-gems-in-nextjs) - some of which pair beautifully with tools like c15t.

## Why Roboto Studio chose c15t
When we were evaluating cookie consent solutions for our own website, we had a few non-negotiables:

**Performance**: It had to be fast. No compromises.

**Developer experience**: We needed something that felt modern and well-designed.

**Compliance**: It had to handle GDPR, CCPA, and other regulations out of the box.

**Flexibility**: We wanted control over the design and user experience.

We tested the usual consent management platforms, and they all felt heavy and slow. They were built for a different era of the web, when adding another 100KB script didn't matter as much.

c15t was different. It felt like infrastructure we could build on, not a widget we had to work around. The integration was clean, the performance was excellent, and the developer experience was exactly what we wanted. Even if something was missing, it's open source, so we can contribute.

## CookieBench leaderboard performance results
The proof is in the performance. c15t consistently ranks at the top of the [CookieBench leaderboard](https://cookiebench.com/) - an independent benchmark that measures the real-world performance impact of cookie consent solutions. CookieBench is an open-source tool that provides transparent, unbiased performance measurements, making it the gold standard for evaluating consent management platforms.

Here's how c15t compares to other popular solutions:

![Benchmark table where c15t scores 95, ahead of Ketch, Usercentrics, Onetrust and Cookieyes](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-cookie-banner-prayers-have-been-answered-blog-body-image-2.webp)
*Performance metrics c15t*

These aren't synthetic benchmarks, they're real-world measurements. When you're competing for user attention in milliseconds, these differences matter.

## What this means for our clients
Adopting c15t for our own website wasn't just about solving our own problems - it was about understanding a tool we could recommend to clients. Here's what we've learned:

**Faster websites**: The zero network cost architecture means your website loads faster, not slower, when you add cookie consent. Your users get a better experience, and your Core Web Vitals scores improve.

**Better compliance**: c15t handles the complex legal requirements automatically. GDPR, CCPA, and other regulations are built into the platform, so you don't have to worry about staying compliant as laws change.

**Developer-friendly**: Integration takes minutes, not hours. The APIs are clean, the documentation is excellent, and it works cleanly with modern frameworks like Next.js, React, and Vue.

**Design control**: Unlike other solutions that force you to use their pre-built designs, c15t gives you complete control over the look and feel of your consent banner. It fits your brand, not the other way around.

We’ve applied this same mindset across our stack-from how we structure content with Sanity to how we optimize load times with Turbo Start. [Here’s a look at how we do it](/blog/working-with-turbo-start-sanity).

## The future of cookies
Cookie consent is just the beginning. The future of privacy infrastructure is about building trust through transparency, performance, and user control. Here's what we're watching:

**First-party data**: As third-party cookies disappear, first-party data becomes more valuable. The websites that build trust through good privacy practices will have a competitive advantage.

**Privacy as performance**: The best privacy tools make your website faster, not slower. c15t is leading this trend, but we expect to see more performance-focused privacy solutions.

**Developer-first privacy**: Privacy regulations are complex, but the tools to handle them don't have to be. We're seeing a new generation of privacy tools built for developers, not just compliance teams.

**Edge computing**: Privacy processing is moving to the edge, closer to users. This means faster responses and better privacy protection.

The websites that get this right will have a significant advantage. They'll load faster, convert better, and build more trust with their users.

![c15t highlights: first party data, performance, developer first privacy and edge computing](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-cookie-banner-prayers-have-been-answered-blog-body-image-3.webp)
*Features c15t for clients*

> **Next.js app development**: Privacy compliance, cookie consent, and Next.js integration done right. [Learn more](/services/nextjs)

## Bonus: working with YouTube & Sanity
Shoutout to the team at [Inth](https://inth.com/) (formerly Consent.io) for this. We were originally using a third-party script for YouTube on the Roboto Studio website; however, this still works even if you decline cookies and goes against the website's policies.

Here's a nice little snippet to handle all the different loading states of YouTube and also to add the code to your Sanity portable text component.

### Here's the portable text component
```typescript title="richtext.tsx"
  defineArrayMember({
    name: "block",
    type: "block",
    styles: [
      { title: "Normal", value: "normal" },
      { title: "H2", value: "h2" },
      { title: "H3", value: "h3" },
      ...
    ],
  }),
  defineArrayMember({
    name: "youtubeEmbed",
    title: "YouTube Embed",
    type: "object",
    icon: PlayIcon,
    fields: [
      defineField({
        name: "url",
        title: "YouTube URL",
        type: "url",
        description:
          "Enter a YouTube video URL (e.g., https://www.youtube.com/watch?v=dQw4w9WgXcQ)",
        validation: (Rule) =>
          Rule.required()
            .uri({
              scheme: ["http", "https"],
            })
            .custom((url) => {
              if (!url) return "YouTube URL is required";
              const isYouTube =
                /(?:youtube\.com|youtu\.be|youtube-nocookie\.com)/i.test(url);
              return isYouTube || "Please enter a valid YouTube URL";
            }),
      }),
```

Even left in the YouTube validation for you, you're welcome.

### Here's the YouTube embed
```typescript title="youtube-embed.tsx"
"use client";

import { useConsentManager } from "@c15t/nextjs";
import { Play } from "lucide-react";
import dynamic from "next/dynamic";
import { Suspense, useEffect, useState } from "react";

const ReactPlayer = dynamic(() => import("react-player"), {
  loading: () => (
    <div
      className="relative bg-zinc-100 dark:bg-zinc-800 overflow-hidden w-full border-2 border-dashed border-zinc-300 dark:border-zinc-600 flex items-center justify-center"
      style={{ aspectRatio: "16/9" }}
    >
      <p className="text-sm text-zinc-500 dark:text-zinc-500">
        Loading video player...
      </p>
    </div>
  ),
  ssr: false,
});

import { Button } from "@workspace/ui/components/button";

interface YouTubeEmbedProps {
  url: string;
  autoplay?: boolean;
  className?: string;
  description?: string;
  height?: number | string;
  requireConsent?: boolean;
  thumbnail?: string;
  title?: string;
  width?: number | string;
}

export function YouTubeEmbedComponent({
  url,
  autoplay = false,
  className = "",
  description,
  height,
  thumbnail,
  title,
  width,
}: YouTubeEmbedProps) {
  const consentManager = useConsentManager();
  const [hasInteracted, setHasInteracted] = useState(false);
  const [isMounted, setIsMounted] = useState(false);

  useEffect(() => {
    setIsMounted(true);
  }, []);

  // Get video ID from YouTube URL for thumbnail
  const getVideoId = (videoUrl: string) => {
    if (!videoUrl) return null;

    const patterns = [
      /(?:https?:\/\/)?(?:www\.)?(?:youtube\.com|youtu\.be)\/(?:watch\?v=|embed\/|v\/|.+\?v=)?([^&\n?#]+)/,
      /(?:https?:\/\/)?(?:www\.)?youtube\.com\/shorts\/([^&\n?#]+)/,
    ];

    for (const pattern of patterns) {
      const match = videoUrl.match(pattern);
      if (match && match[1]) {
        return match[1];
      }
    }

    return null;
  };

  const videoId = getVideoId(url);
  const defaultThumbnail = videoId
    ? `https://img.youtube.com/vi/${videoId}/maxresdefault.jpg`
    : undefined;

  const handlePlayClick = () => {
    consentManager.setConsent("experience", true);
    setHasInteracted(true);
  };

  // Check if user has given consent for experience cookies (which should include YouTube)
  const hasConsent = consentManager.consents.experience ?? false;

  // Show error state for invalid URLs
  if (!videoId) {
    return (
      <div className="flex items-center justify-center h-64 bg-zinc-100 dark:bg-zinc-800 border-2 border-dashed border-zinc-300 dark:border-zinc-600">
        <div className="text-center">
          <p className="text-zinc-600 dark:text-zinc-400 mb-2">
            Invalid YouTube URL
          </p>
          <p className="text-sm text-zinc-500 dark:text-zinc-500">
            Please provide a valid YouTube video URL
          </p>
        </div>
      </div>
    );
  }

  // Show loading state during SSR and initial hydration
  if (!isMounted) {
    return (
      <div className={`w-full ${className}`}>
        <div className="space-y-4">
          <div
            className="relative bg-zinc-100 dark:bg-zinc-800 overflow-hidden w-full border-2 border-dashed border-zinc-300 dark:border-zinc-600 flex items-center justify-center"
            style={{ aspectRatio: "16/9" }}
          >
            <p className="text-sm text-zinc-500 dark:text-zinc-500">
              Loading video player...
            </p>
          </div>
        </div>
      </div>
    );
  }

  // If consent is required but not given, show consent prompt
  if (!hasConsent) {
    return (
      <div className={`not-prose my-6 w-full ${className}`}>
        <div className="space-y-4">
          <div
            className="relative bg-zinc-100 dark:bg-zinc-800 overflow-hidden w-full border-2 border-dashed border-zinc-300 dark:border-zinc-600"
            style={{ aspectRatio: "16/9" }}
          >
            {(thumbnail || defaultThumbnail) && (
              // eslint-disable-next-line @next/next/no-img-element
              <img
                alt={title || "Video thumbnail"}
                className="w-full h-full object-cover"
                src={thumbnail || defaultThumbnail}
              />
            )}

            {/* Overlay */}
            <div className="absolute inset-0 bg-black bg-opacity-50 flex items-center justify-center">
              <div className="text-center text-white space-y-4 p-6">
                <div className="pb-3 space-y-2">
                  <p className="text-lg font-semibold">YouTube Video Blocked</p>
                  <p className="text-sm opacity-90">
                    You haven&apos;t consented to &quot;experience&quot; cookies
                  </p>
                </div>
                <Button
                  className="bg-white text-black hover:bg-zinc-100"
                  onClick={handlePlayClick}
                  size="sm"
                  variant="default"
                >
                  <Play className="w-4 h-4 mr-2" />
                  Load Video Anyway
                </Button>
                <p className="text-xs opacity-75 pt-2">
                  This will connect to YouTube&apos;s servers
                </p>
              </div>
            </div>
          </div>
        </div>
      </div>
    );
  }

  // If we need to show player (either consent given or user clicked to load)
  if (hasConsent) {
    return (
      <div className={`not-prose my-6 w-full ${className}`}>
        <div className="relative overflow-hidden">
          <Suspense
            fallback={
              <div
                className="relative bg-zinc-100 dark:bg-zinc-800 overflow-hidden w-full border-2 border-dashed border-zinc-300 dark:border-zinc-600 flex items-center justify-center"
                style={{ aspectRatio: "16/9" }}
              >
                <p className="text-sm text-zinc-500 dark:text-zinc-500">
                  Loading video player...
                </p>
              </div>
            }
          >
            <ReactPlayer
              src={url}
              controls
              playing={autoplay && hasInteracted}
              style={{ aspectRatio: "16/9", height: "auto", width: "100%" }}
              width={width}
              height={height}
            />
          </Suspense>
        </div>
      </div>
    );
  }

  // Fallback - should not reach here but just in case
  return (
    <div className={`w-full ${className}`}>
      <div className="space-y-4">
        {description && (
          <p className="text-sm text-zinc-500 dark:text-zinc-500">
            {description}
          </p>
        )}
        <div
          className="relative bg-zinc-100 dark:bg-zinc-800 rounded-lg overflow-hidden w-full border-2 border-dashed border-zinc-300 dark:border-zinc-600 flex items-center justify-center"
          style={{ aspectRatio: "16/9" }}
        >
          <p className="text-sm text-zinc-500 dark:text-zinc-500">
            Video player loading...
          </p>
        </div>
      </div>
    </div>
  );
}

```

## Let's build something together
Privacy infrastructure done well makes the whole website better, compliance included. At Roboto Studio, we help companies build [fast, modern websites](/services/sanity) that users trust and love.

If you're tired of slow cookie consent solutions that hurt your website's performance, let's talk. We can help you implement c15t or other privacy-first solutions that actually make your website better.

---

## How we migrate content without breaking stuff


> Ever wondered how Roboto Studio lifts and shifts hundreds of pages for website migration? Let's guide you through our process and share some tips along the way

**TL;DR:** Migrating CMS? It's like moving house but with more broken links. At Roboto Studio, we use both web crawlers and AI to condense and proofread content. We even helped the Bush Center escape WordPress.

**Published:** 2025-07-07 | **Updated:** 2026-09-01 | **Categories:** Sanity, How To
---

Moving from one CMS to another can be very nerve-wracking as a single broken link or lost redirect can hurt traffic. Content migration involves more than moving files from one location to another. Hence, we at Roboto Studio treat content migration as more than just a copy-pasting pages process, rather a process that blends dev rigor with a solid SEO migration strategy.

Whether one is migrating from WordPress to Sanity, upgrading to a headless CMS migration, or handling enterprise-scale projects, the goal is the same: keeping your content intact, SEO strong, and editors happy. It's about preserving stories, maintaining relationships, and ensuring that years of valuable content continues to serve its purpose in a modern, scalable environment.

Read along to see how we've refined our approach over the years to make these transitions clean, and more importantly, without breaking stuff.

![Infographic listing 5 reasons for content migration, from SEO preservation to future-proofing](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-we-migrate-content-without-breaking-stuff-blog-body-image-1.png)
*An infographic showing 5 reasons why websites need content migration: platform upgrades, SEO preservation, content consistency, better user experience, and future-proofing with scalable CMS migration.*

## The Challenge: Legacy content, modern expectations
We've taken on a lot of nuanced migration projects over the years. One of them was for the George W. Bush Presidential Center.

> **_"Your code is so neat and tidy, it's just lovely!"_** - Andrew Kaufmann from George W. Bush Presidential Center
Over time, its legacy WordPress site had grown unwieldy; slowed by plugins, difficult to scale, and limiting for editors tasked with managing thousands of interconnected pieces of content.

The stakes were high. This wasn't just content or another website migration project for bettering the performance with headless solutions for us. Their legacy website contained years of articles, author profiles, and interconnected content that needed to be preserved and made live on their new Sanity-powered platform, from that of the legacy WordPress one.

We migrated George W. Bush Presidential Center’s legacy WordPress site to Sanity CMS, preserving decades of historical content while boosting performance and scalability. They eliminated plugin fragility, cut load times by up to 13×, and enabled instant publishing with real-time previews. The result was a secure, future-ready platform their editors control directly, with an archive that stays fast, accessible, and adaptable for generations.

## Our comprehensive content migration plan

**Step 1**: Smart content extraction: Depending on how the client’s website is set up, we use tools for extraction. We begin by building custom scrapers using Node.js, with libraries such as Axios and Cheerio. For instance, if the website is predominantly SSR (server-side rendered), we use Cheerio as it excels at scraping HTML. However, if it is more client-side-focused, it is a poor choice of tool.

This automated approach eliminates the tedious and error-prone process of manual copying and pasting of data. More importantly, it ensures that we capture everything with perfect consistency, which is a critical component of any website migration checklist SEO teams rely on.

**Step 2:** Creating a single source of truth: Once we've gathered all the raw materials, we compile everything into our ‘SSOT’ (Single Source of Truth). While this could be a simple CSV file, we typically structure it as a JSON file instead.

Why? Because it gives us version control, static typing, and a rock-solid foundation for everything that follows.

This SSOT becomes our go-to file for passing updates along a stable, verifiable dataset that we can refer throughout the entire content migration process. It's an essential part of our SEO migration strategy that prevents data loss and ensures accountability.

**Step 3:** AI-powered content enhancement: Here's where things get exciting. Raw scraped data is often messy with inconsistent HTML, missing metadata, etc. We use AI to clean, enhance, and structure the content.

Using the AI SDK, our pipeline can:

- Summarise articles
- Generate SEO-friendly meta descriptions
- Suggest relevant tags and categories
- Identify key entities like people, organizations, and locations

Because AI is designed to excel at next-token prediction, it’s perfectly suited for the repetitive, detail-oriented tasks involved in **CMS migration SEO**.

**The result**? We save hundreds of hours of manual work while actually improving the quality and discoverability of the content that is essential for scaling headless CMS migration projects.

**Step 4:** The migration engine: With clean, enhanced data in hand, we fire up our core migration script – another Node.js application that connects directly to the Sanity API.

This is where the magic happens:

- Data mapping: We meticulously map fields from our master list to the corresponding fields in Sanity's content models. Every piece of data finds its perfect home, following the same principles we use for Sanity, Contentful, or even SharePoint if needed.
- Asset handling: The script downloads all images from the old site, uploads them to Sanity's high-performance asset CDN, and correctly links them within the new content.
- Relationship building: Perhaps most importantly, the script creates relationships between documents. Articles get linked to their authors, categories connect to related content, and we build a rich, interconnected content graph that makes everything more discoverable.
- SEO preservation: We automatically create redirects from old URLs to their new spots, so rankings hold and visitors never hit a dead link. This step is one of the most critical in any CMS migration SEO project, and it's where visibility gets lost if you skip it.

This entire process is transactional. We bundle all changes for a single article into one operation. It's all or nothing, which prevents partial or corrupted data from being entered into the new system.

**Step 5:** Human-powered quality assurance: No automated process is complete without the human touch. After the migration script finishes, our team conducts thorough QA which includes:

- Layout and visual regression checks
- Metadata and alt text validation
- SEO migration strategy checklist (titles, URLs, redirects)
- Live redirect testing across multiple environments

This final step is what makes the switchover clean: the content audiences see is accurate, meta-rich, and functional. This is standard for all website migrations, whether it’s a standard CMS setup or a headless CMS migration project.

**Step 6:** Post-migration monitoring: Our content migration process doesn't end at go-live. It's a living playbook that we continuously refine and adapt for future needs. Whether we're handling a complex Enterprise content migration or a straightforward CMS migration, we follow the same core principles: preserve what matters, enhance where possible, and build for the future.

After go-live, we track:

- Search Console metrics to ensure no indexing drops
- Performance analytics (Lighthouse & Vercel)
- Editorial feedback for any content issues

This monitoring step closes the loop on a strong SEO migration plan.

##  Ready to Migrate?
We've learned that the best migrations strike a balance between automation and human insight, and that taking the time to enhance content during the migration process pays dividends in the long run.

Our migration strategy has evolved to include comprehensive planning phases, detailed content audits, and thorough testing procedures. These elements are now standard parts of our website migration checklist, ensuring consistent results across all projects.

At Roboto Studio, we've built migrations that scale from [WordPress to Sanity](/blog/how-to-migrate-from-wordpress-to-sanity-fast) and beyond, without breaking stuff.

> **Headless CMS services**: Platform selection, content migration, and CMS architecture for teams moving off legacy systems. [Learn more](/services/headless-cms)

Whether you need to migrate from a janky platform that stopped being supported around the .com boom or a complete overhaul of your current website, we take care of it.

Got questions about your own content migration challenges? We're always excited to talk through complex technical problems.

---

## Sanity Canvas: a better way of writing content


> If you enjoy creating content with your team, you'll want to check out Sanity's new Canvas release. It's made for teams like ours who thrive on collaboration - imagine all your content being edited in one place, faster feedback, shared ideas, and direct integration with Sanity Studio.

**TL;DR:** Sanity's Canvas is a way to automate context, collaborate in real time, and let AI ghostwrite. Perfect for those who love less UX fluff. But hey, if you read the whole thing, congrats on wasting your time. Just use Canvas already.

**Published:** 2025-07-06 | **Updated:** 2026-08-03 | **Categories:** Sanity
---

If you enjoy shipping content and care about the UX nuances for a smooth editorial experience, you’ll want to check out Sanity’s new Canvas release. 

It’s designed for teams like ours that thrive on collaboration - imagine all your content being edited in one place, with faster feedback, shared ideas, and one-click integration with Sanity Studio.

This really marks a new era of writing where ideas and execution are closer than ever and there are [more reasons](/services/sanity) than *you can shake a stick at* as to why you should be choosing Sanity for your web-dev experience

## Most exciting features 
### Automated context extraction
Canvas allows users to add context in several ways; however, our favourite one is to add a link directly from a URL and watch the magic happen.

All you need to do is paste the associated link, and depending on the URL's accessibility, Canvas automatically pulls data in text format. Of course, you can manually add context. However, automatic data rendering from the URL saves a ton of time and feels great. It also keeps up to date if the context on the website changes.

See how we do this internally.

### Complete toolkit for modern content writing
With Canvas, you can create tone of voice guides, collect inspiration, and facts - all in one place. This helps you stay focused, so you don't have to switch between documents or platforms to organise your thoughts.

We expand on our previous example and show how you can utilise this below.

### AI that completes your thoughts
Once you have all of your thoughts collected in the notes, you can go ahead and start using the ghost writer for contextually accurate assistance when you hit a writers block and just need a gentle push to speed things up.

Bonus points, because your feeding it context, it doesn't typically hallucinate like other AI chat interfaces out there.

Check out how the auto complete works here.

### Write better, together
We love Canvas for allowing a shared creative space for every team member, from marketing to dev. We all have strong opinions on matters we share with the world, and sometimes it’s just nice to have a second pair of eyes reviewing your content.

See how you can collaborate with your colleagues.

If you are looking forward to [taking your visual content creation a step further using Sanity and OpenAI](/blog/revolutionizing-visual-content-creation-with-sanityio-and-openai), we got a perfect guide for you.

> **Sanity CMS development**: Sanity setup, Canvas integration, and editorial workflows for content teams. [Learn more](/services/sanity)

### Content mapped and ready for Studio
Once you have all this content ready, or *even before it's finished*, you can link up a document inside your Sanity Studio. This takes all the content you've written within canvas and maps it to the appropriate fields within your Sanity Studio.

It's very clever, as it can map fields to code examples, images, headings and everything in-between.

See the example below.

### Our final thoughts 
When it comes to writing tools, less really is more. With Canvas, you can focus on your ideas instead of getting distracted by flashy, often unhelpful UX.

Writing feels natural, and adding media or creative elements just works. However, that being said, there are still a couple of rough edges at the moment, which we know the Sanity engineering team is working hard to get flawless. If you do happen to come across any, feel free to get in touch with us or the Sanity team to help you get moving again. If you are looking for the [right Sanity CMS agency](/services/sanity), we've got you covered as well.

Hope you enjoyed this article, as much as we enjoyed writing it (in canvas).

---

## Figma in 2025: hot takes


> Figma has evolved into the go-to design tool in 2025. While it stands out, there is still room for improvement in support for designers.

**TL;DR:** Figma: once simple, now bloated. File management is a nightmare, UI3 looks cool but adds clicks, and AI features are hit-or-miss. Designers want better tools, not more features. We're probably never going to get sponsored by Figma now.

**Published:** 2025-07-02 | **Updated:** 2026-07-23 | **Categories:** Hot Takes
---

The early versions of Figma were notably simple and fast. File navigation was smooth, the interface was clean, and the core tools did what you clicked without ceremony. This simplicity was one of the platform's key selling points.

However, as Figma expanded its wings and added features, some aspects have become more complex than necessary, particularly around file management. God, I ***hate*** the file management.

## File management: our biggest pain point
Figma file management remains one of Figma's most significant challenges. Many designers report spending excessive time trying to organize files in Figma rather than focusing on actual design work. If I didn't know better, I might even call it a growth strategy, gouging users out of money for inviting people to view their work... But that would be cynical.

Navigating through projects sometimes feels cumbersome, especially when working on multiple projects simultaneously. The current Figma folder system is shallow: there's no good way to nest, tag, or group related work.

Given Figma's strength in other areas of the design experience, there's significant potential for improvement in file management. This is an area where better tooling could dramatically improve designer productivity, something the community has consistently raised through Figma feature feedback channels.

## UI3: modern design with accessibility trade-offs
The UI3 update introduces a fresh visual approach with floating panels that appear modern and clean. The design direction shows clear aesthetic improvements.

However, some frequently-used tools now require additional clicks to access. This creates friction for designers who rely on quick access to core functionality. *The most egregious being the scale panel hiding the export buttons.*

While UI updates typically involve learning curves, the increased steps to reach essential tools can impact workflow efficiency. The original interface's immediacy was particularly valuable for rapid wireframing and iterative design work. That being said, the new UI does ***look*** cool.

![Figma's redesigned UI3 interface with a landing page design open on the canvas](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-body-image-1.jpg)
*Modern feel of UI3*

## Feature expansion vs. core experience
Figma has significantly expanded its feature set, demonstrating ambition to serve broader use cases. Having multiple tools in one platform offers clear advantages for workflow consolidation.

However, the core design experience can feel cluttered with features that many designers don't use regularly. For example, the "copy to Figma slides" button appears prominently despite limited relevance to typical design workflows.

![Figma design panel showing the copy to Figma slides button on a selected frame](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-body-image-2.jpg)
*Copy to slides button in Figma*

More customization options allow users to prioritize features most relevant to their work. The challenge with expanding functionality lies in maintaining the clean, focused experience that originally differentiated Figma from competitors. Many designers have submitted Figma feature requests asking for better customization controls.

![Figma product buttons: Design, Figjam, Slides, Site, Buzz and Make](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-body-image-3.jpg)
*Current toolset of Figma*

## Performance optimization needed
Figma's responsiveness has declined compared to earlier versions. Users report increased lag and slower load times despite unchanged hardware specifications.

File opening and interactions can take longer than expected, interrupting design flow and reducing productivity. As features are added, performance optimization becomes increasingly complex, requiring dedicated engineering resources.

Performance issues are typically addressable with focused engineering effort. With proper optimization, Figma could maintain its expanding feature set while delivering the speed that made it initially attractive to designers. If you're dealing with slow load times in your CMS too, it might not just be your design tool-[cleaning up your GROQ queries](/blog/clean-your-groq) give your content layer a serious speed boost.

## AI implementation: strategic wins and losses
Figma has introduced several genuinely useful AI features that improve designer workflows. The standout implementations include:

- **Auto-renaming layers**: Eliminates the tedious task of manually naming dozens of elements

- **Intelligent interaction suggestions**: Automatically adds interactions like back buttons across frames

- **Content replacement**: Helps maintain design consistency when swapping similar elements

- **Background removal**: Performs reliably for quick image editing

These micro-features solve real daily frustrations. You no longer need to think about naming every layer or manually adding common interactions, because Figma's AI picks up the repetitive work for you.

The Figma community has developed several Figma AI plugins that sometimes handle these tasks more effectively than native features. A greater focus on AI features that remove real steps from design work would be more valuable than attempting to incorporate AI into every possible function.

Talking of AI, check out how we used generative AI to build a playful design feature for Synacti. For details, refer to [our case study](/case-study/synacti).

We are still curious to see what they do with the AI first draft builder that got cut, [but we're not holding our breath after the first roll out](https://www.theverge.com/2024/7/18/24201308/figma-make-designs-vet-apple).

## Text style management: missing batch operations
A common workflow issue highlights gaps in Figma's text style management. When updating properties like line height across multiple text styles organized in groups (xs, lg, xl), designers must edit each style individually.

The absence of batch editing capabilities for text styles creates time-consuming, repetitive tasks. For example, updating line height across 60 text styles requires 60 individual edits rather than group-level changes.

![Editing one text style at a time in Figma's typography panel, with no batch option](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-body-image-4.jpg)
*No batch editing option in text styles*

## PDF export needs some work
The PDF export functionality could use improvement. While it's not the most essential feature, many of us rely on it for sharing design documents and presentations, so better quality and reliability would be appreciated. Or at least some way to be able to optimise the images ***inside*** of a PDF.

## What's actually working well in Figma
Despite the challenges and our saltiness, Figma excels in several key areas that keep designers using the platform daily.

#### The plugin ecosystem: Figma's greatest strength
The Figma plugins community represents one of the platform's most valuable assets. The ecosystem thrives with designers building tools for other designers, consistently delivering high-quality solutions.

Many designers rely on the best Figma plugins daily, integrating them into core workflows. Notably, numerous Figma native features originated as community plugins. This demonstrates effective user-driven innovation: the Figma community identifies needs, builds solutions, and successful ideas become part of the core product.

#### Collaboration that just works
Figma's real-time collaboration capabilities remain top-tier. The effortless way multiple designers can work simultaneously on the same file, leave comments, and iterate together is genuinely impressive. This feature alone has transformed how design teams operate.

#### UI Design and Visual Innovation
Figma changed how creative software can look and feel without compromising functionality. Unlike Adobe's traditionally boring interfaces, Figma brought fresh visual design to professional tools. UI3 represents their take on modern design trends. Features like dividing tools into logical sections initially felt awkward, but they became intuitive with use. That's typical with rapid UI updates.

#### Keyboard Shortcuts and Speed
Figma's shortcut system enables remarkably fast workflows. Creating shapes, frames, images, or text through keyboard shortcuts becomes second nature. This speed advantage is particularly valuable during rapid wireframing sessions.

> **Next.js app development**: Design-to-code builds with Next.js, Tailwind, and modern component architecture. [Learn more](/services/nextjs)

#### Practical Design Tools
Several built-in features significantly improve daily workflows:

- **Rulers**: Essential for precise layouts without relying on grid systems for every design

- **Text contrast checker**: A recent but valuable addition for accessibility

- **Smart selection and alignment**: Makes organizing elements intuitive

#### Developer handoff through dev mode
What is figma dev mode? It's a feature that effectively bridges the designer-developer gap. Figma dev mode allows developers to inspect designs and extract specifications in formats they prefer (like CSS), eliminating guesswork and reducing back-and-forth communication.

While designers may not use dev mode Figma directly, it significantly improves collaboration with development teams. However, Figma dev mode pricing can be a consideration for smaller teams, as it requires a paid plan to access all features.

![Figma dev mode inspecting a heading and showing its CSS typography values](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-body-image-5.jpg)
*Dev mode Preview in Figma*

## What Designers Actually Need
- **Offline mode**: Even with limited functionality, offline access would significantly improve workflow flexibility

- **Relative sizing and units**: Percentage-based sizing would enhance responsive design capabilities

- **Improved folder structures**: Better file organization tools are essential for project management

- **Interactive form fields**: Enhanced prototyping capabilities for realistic user interactions

- **Advanced prototyping controls**: Current options limit complex interaction design

- **Contextual AI assistance**: AI focused on design-specific questions rather than broad feature integration

- **Native animation support**: Basic animation tools would reduce dependency on external software

- **Batch editing for text styles**: Group-level changes instead of editing 50+ text styles individually

- **Better PDF export quality**: More reliable output for design documentation and presentations

If you’re using Sanity and looking to turn your designs into structured, editable content, our [visual builder guide](/blog/the-only-sanity-page-builder-guide-youll-ever-need) is a great place to start.

## The Evolving Design Tool Ecosystem
Figma remains a solid platform with significant strengths; however, increased competition in the design space drives innovation and improves user experiences across all tools.

Emerging tools like Unicorn.studio, [paper.design](https://paper.design/), [Rive](https://rive.app/), [Subframe](https://www.subframe.com/), and [v0](https://v0.app/) bring different approaches to design tooling. Some focus on specific use cases while others attempt to reimagine entire workflows.

This diversity benefits the entire ecosystem. Competition pushes all platforms to improve and innovate, creating better options for designers regardless of their primary tool choice. It also encourages platforms to listen more closely to Figma feature feedback and implement new feature requests that users actually need.

![Logos of emerging design tools: Unicorn.studio, Paper, Subframe, Rive and v0](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/figma-in-2025-whats-working-whats-not-and-where-its-heading-blog-body-image-6.jpg)
*New upcoming tools/replacements*

## Looking to improve your design flow?
We've had [countless hours in UI design tools](/blog/the-state-of-chakra-ui-and-next-13-4) over the years, and as you can probably guess, fairly strong opinions. We can help with design systems, UI prototyping, and all of the bits and pieces that make up a first-class user experience. 

Designed in Figma? Let’s build it in Contentful. [Explore our Contentful website development process](/services/contentful).

---

## How we use .mdc rules


> How we use .mdc rules with Sanity and Next.js to try and one shot AI coding tasks. Now with extra frontend rules!

**Published:** 2025-05-04 | **Updated:** 2026-07-23 | **Categories:** AI, Sanity
---

Let's give you a quick guide on how and why we use Cursor `.mdc` rules. If you don't know what .mdc stands for, well...*neither do we*. But if I had to hazard a guess, I'd say it's probably **Misguided Decisions & Chaos.**

Moving quickly on from the Dad joke, I'm going to talk about why the rules are important, the specific things that this rule does, and why we would advise heavily tweaking it to your own preferences.

## Schema layout
We have a very rigid way of building schema because, in most situations, you don't want to be debugging a large website project with one giant index file with 300+ schema types imported. That's why we have pre-determined patterns for adding indexes and spread operators on a folder-by-folder level.

This way, it becomes far easier to debug at scale and quickly include new schemas from within the same folder. The only **trip hazard** with this is that if you do not update the import in the index, you will not see your page builder block, so please be aware of this.

## Typesafety
You'll notice a recurring theme in the way we build our Sanity websites... We hate having to manually type interfaces. We want to make as much typescript automated as physically possible, and for that reason, you'll notice it's heavily embedded within our `.mdc` file as well. Ultimately, you're making it easier for yourself in the long run, and the more you can automate, the easier you can scale.

## Predefined schema
You may also notice there are a couple of predefined schema titles, names and types. There's a good reason for this. Usually, we're not the biggest fan of the DRY (Don't Repeat Yourself) way of coding. Purely because we find it's very easy to create spaghetti code when one requirement's goalposts inevitably shift and mutate content.

However, you will notice we regularly recycle the same naming conventions on different blocks. This helps to reuse Tailwind CSS and ultimately increases your development momentum.

## Image recognition
Finally, there's a real advantage to screenshot wireframes within Figma and get a rough draft for your schema. That's why we included some standardisation that correlates the point above of matching certain UI layouts with certain schema types to ensure you create consistent, user-friendly fields with descriptions and icons.

## The rules themselves
```markdown
# Sanity Development Guidelines

## Sanity Schema Rules

When creating sanity schema make sure to include an appropriate icon for the schema using lucide-react or sanity icons as a fallback. Make sure it's always a named export, make sure you're always using the Sanity typescript definitions if it's a ts file.

### Basic Schema Structure

For TypeScript files, always import the necessary Sanity types:

```typescript
import {defineField, defineType, defineArrayMember} from 'sanity'
```

Always use `defineField` on every field and `defineType` throughout the whole type. Only import `defineArrayMember` if needed:

```typescript
defineType({
  type: 'object',
  name: 'custom-object',
  fields: [
    defineField({
      type: 'array',
      name: 'arrayField',
      title: 'Things',
      of: [
        defineArrayMember({
          type: 'object',
          name: 'type-name-in-array',
          fields: [defineField({type: 'string', name: 'title', title: 'Title'})],
        }),
      ],
    }),
  ],
})
```

### Adding icons

When adding icons to a schema, make sure you use the default sanity/icons first, and then if no icon is relevant, refer to any other iconset the user has installed - e.g lucide-react.

### Structuring files and folders

This is a rough idea of how to structure folders and files, ensuring you always have an index within the folder to create an array of documents/blocks. Do not use these as exact names, it's used purely for layout purposes.

    │   ├── studio/
    │   │   ├── README.md
    │   │   ├── eslint.config.mjs
    │   │   ├── location.ts
    │   │   ├── package.json
    │   │   ├── prettier.config.mjs
    │   │   ├── sanity-typegen.json
    │   │   ├── sanity.cli.ts
    │   │   ├── sanity.config.ts
    │   │   ├── schema.json
    │   │   ├── structure.ts
    │   │   ├── tsconfig.json
    │   │   ├── .env.example
    │   │   ├── .gitignore
    │   │   ├── components/
    │   │   │   ├── logo.tsx
    │   │   │   └── slug-field-component.tsx
    │   │   ├── plugins/
    │   │   │   └── presentation-url.ts
    │   │   ├── schemaTypes/
    │   │   │   ├── common.ts
    │   │   │   ├── index.ts
    │   │   │   ├── blocks/
    │   │   │   │   ├── cta.ts
    │   │   │   │   ├── faq-accordion.ts
    │   │   │   │   ├── feature-cards-icon.ts
    │   │   │   │   ├── hero.ts
    │   │   │   │   ├── image-link-cards.ts
    │   │   │   │   ├── index.ts
    │   │   │   │   └── subscribe-newsletter.ts
    │   │   │   ├── definitions/
    │   │   │   │   ├── button.ts
    │   │   │   │   ├── custom-url.ts
    │   │   │   │   ├── index.ts
    │   │   │   │   ├── pagebuilder.ts
    │   │   │   │   └── rich-text.ts
    │   │   │   └── documents/
    │   │   │       ├── author.ts
    │   │   │       ├── blog.ts
    │   │   │       ├── faq.ts
    │   │   │       └── page.ts
    │   │   └── utils/
    │   │       ├── const-mock-data.ts
    │   │       ├── constant.ts
    │   │       ├── helper.ts
    │   │       ├── mock-data.ts
    │   │       ├── og-fields.ts
    │   │       ├── parse-body.ts
    │   │       ├── seo-fields.ts
    │   │       ├── slug.ts
    │   │       └── types.ts

### Layout of page builder index example

This is an example of how the blocks index file would be structured, you would create multiple of these on multiple nested routes to make it easier to create an array of files at each level, rather than bundling a large number of imports in a singular index.ts on the root

```typescript
import { callToAction } from './call-to-action';
import { exploreHero } from './explore-hero';
import { faqList } from './faq-list';
import { htmlEmbed } from './html-embed';
import { iconGrid } from './icon-grid';
import { latestDocs } from './latest-docs';
import { calculator } from './calculator';
import { navigationCards } from './navigation-cards';
import { quinstreetEmbed } from './quinstreet-embed';
import { quote } from './quote';
import { richTextBlock } from './rich-text-block';
import { socialProof } from './social-proof';
import { splitForm } from './split-form';
import { statsCard } from './stats-card';
import { trustCard } from './trust-card';
import { rvEmbed } from './rv-embed';

export const pagebuilderBlocks = [
  navigationCards,
  socialProof,
  quote,
  latestDocs,
  faqList,
  callToAction,
  trustCard,
  quinstreetEmbed,
  statsCard,
  iconGrid,
  exploreHero,
  splitForm,
  richTextBlock,
  calculator,
  htmlEmbed,
  rvEmbed,
];

export const blocks = [...pagebuilderBlocks];
```

### Common Field Templates

When writing any Sanity schema, always include a description, name, title, and type. The description should explain functionality in simple terms for non-technical users. Place description above type.

Use these templates when implementing common fields:

#### Eyebrow
```typescript
defineField({
  name: 'eyebrow',
  title: 'Eyebrow',
  description: 'The smaller text that sits above the title to provide context',
  type: 'string',
})
```

#### Title
```typescript
defineField({
  name: 'title',
  title: 'Title',
  description: 'The large text that is the primary focus of the block',
  type: 'string',
})
```

#### Heading Level Toggle
```typescript
defineField({
  name: 'isHeadingOne',
  title: 'Is it a <h1>?',
  type: 'boolean',
  description:
    'By default the title is a <h2> tag. If you use this as the top block on the page, you can toggle this on to make it a <h1> instead',
  initialValue: false,
})
```

#### Rich Text
```typescript
defineField({
  name: 'richText',
  title: 'Rich Text',
  description: 'Large body of text that has links, ordered/unordered lists and headings.',
  type: 'richText',
})
```

#### Buttons
```typescript
defineField({
  name: 'buttons',
  title: 'Buttons',
  description: 'Add buttons here, the website will handle the styling',
  type: 'array',
  of: [{type: 'button'}],
})
```

#### Image
```typescript
defineField({
  name: 'image',
  title: 'Image',
  type: 'image',
  fields: [
    defineField({
      name: 'alt',
      type: 'string',
      description:
        "Remember to use alt text for people to be able to read what is happening in the image if they are using a screen reader, it's also important for SEO",
      title: 'Alt Text',
    }),
  ],
})
```

### Type Generation

After adding new Sanity schema, run the type command to generate TypeScript definitions:

```bash
sanity schema extract && sanity typegen generate --enforce-required-fields
```

## GROQ Rules

Whenever there is an image within a GROQ query, do not expand it unless explicitly instructed to do so.

## GROQ Query Structure and Organization

- Import `defineQuery` and `groq` from `next-sanity` at the top of query files
- Export queries as constants using the `defineQuery` function
- Organize queries by content type (blogs, pages, products, etc.)
- Group related queries together

### Naming Conventions

- Use camelCase for all query names
- Prefix query names with action verb (get, getAll, etc.) followed by content type
- Suffix all queries with "Query" (e.g., `getAllBlogIndexTranslationsQuery`)
- Prefix reusable fragments with underscore (e.g., `_richText`, `_buttons`)

### Fragment Reuse

- Define common projection fragments at the top of the file
- Create reusable fragments for repeated patterns (e.g., `_richText`, `_buttons`, `_icon`)
- Use string interpolation to include fragments in queries
- Ensure fragments are composable and focused on specific use cases

### Query Parameters

- Use `$` for parameters (e.g., `$slug`, `$locale`, `$id`)
- Handle localization with consistent patterns (e.g., `${localeMatch}`)
- Use `select()` for conditional logic within queries
- Define default parameters using `coalesce()`

### Response Types

- Export TypeScript interfaces for query responses when needed
- Use descriptive types that match the query structure
- Follow the pattern: `export type GetAllMainPageTranslationsQueryResponse = string[];`

### Best Practices

- Use explicit filtering (`_type == "x"`) rather than implicit type checking
- Prefer projection over returning entire documents
- Use `order()` for explicit sorting rather than relying on document order
- Check for defined fields (`defined(field)`) before accessing them
- Use conditional projections for optional fields
- Add pagination parameters (`[$start...$end]`) for list queries

### Code Style

- Use template literals for query strings
- Indent nested query structures for readability
- Keep related query parts together
- Maintain consistent whitespace and indentation
- Use comments to explain complex query logic

## File Naming Conventions

- Use kebab-case for ALL file names
  - ✅ CORRECT: `user-profile.tsx`, `auth-layout.tsx`, `api-utils.ts`
  - ❌ INCORRECT: `userProfile.tsx`, `AuthLayout.tsx`, `apiUtils.ts`
- MUST use `.tsx` extension for React components
- MUST use `.ts` extension for utility files
- MUST use lowercase for all file names
- MUST separate words with hyphens
- MUST NOT use spaces or underscores

## Screenshot Rules

When asked to produce schema from screenshots, follow these guidelines:

- Help describe types and interfaces using the provided image
- Use the Sanity schema format shown above
- Always include descriptions based on the visual elements in the image

### Visual Cues

- Tiny text above a title is likely an **eyebrow**
- Large text without formatting that looks like a header should be a **title** or **subtitle**
- Text with formatting (bold, italic, lists) likely needs **richText**
- Images should include **alt text** fields
- Background images should be handled appropriately
- Use reusable button arrays for button patterns
- If `richTextField` or `buttonsField` exists in the project, use them

> **Agentic workflow development**: AI-assisted development, custom rules, and automated workflows for Sanity and Next.js projects. [Learn more](/services/agentic-workflows)

## Do your homework
Naturally, this `.mdc` file is very specific to *our way* of building Next.js and Sanity websites. We want you to take this ruleset and chop and change it to exactly the way **you** develop websites.

I would highly recommend seeing how we do it with our own open-source [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity). The crux of our opinionation happens in the [Sanity queries file](https://github.com/robotostudio/turbo-start-sanity/blob/main/packages/sanity/src/query.ts). It's primarily around reusability in queries, especially when it comes to page builders. Inside of these, we want to nest things like rich text but don't necessarily want to figure out how to resolve internal links three blocks deep. That's where our query structure comes into play.

If you're new to Sanity and want something a little more chilled-out, we would highly recommend starting with [Sanity Learn](https://www.sanity.io/learn). When you're finished with that, we recommend reading Simeon's - [Opinionated Guide to Sanity Studio](https://www.sanity.io/docs/developer-guides/an-opinionated-guide-to-sanity-studio).

That being said, if you're looking to fast-track your team and get an incredible understanding of how to build enterprise Sanity & Next.js project, check out our [workshops](/services/workshops)

---

## How to use Google Analytics and actually get something out of it


> Google Analytics is hard. We're going to show you the fastest way to be able to read it and start acting upon the insights.

**Published:** 2025-04-29 | **Updated:** 2026-08-24 | **Categories:** How To, Performance
---

Google Analytics is a powerful tool for tracking conversions and website traffic, as well as gaining valuable insights into what people are doing on your website. It's just a shame that ***nobody knows how to read it correctly***.

These insights are helpful in creating marketing strategies, figuring out issues with the website, and determining other useful statistics. Setting up Google Analytics is the first and in itself an intricate task. We will cover the setup user behavior process in a separate post. For now, we’ll assume you’ve already completed the prerequisites. If not, assuming you're using [Next.js, click here and use this](https://nextjs.org/docs/app/guides/third-party-libraries).

[If you want this done for you without touching any dev work, click here.](/services/nextjs)

Having your Google Analytics set up with your website, we are good to go with the next step of analysing the data. Taking the data and example from a dummy website, we'll look at what the data signifies and how it helps us use it in our business. 

## Google Analytics dashboard 
![Google Analytics home dashboard with active users, key events and realtime panels](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-1.png)
*google analytics home dashboard *

This is the initial dashboard that appears when you open Google Analytics. Let's review the basic structure and try to understand what's actually happening. *This is more about theory than deep technical knowledge.*

### What to look for
The main indicators here are the graph, active users, key events, and average daily purchasers. The graph consists of one dotted line and one continuous line, along with a date picker for selecting the period for which the data is to be represented. It has currently been set to 1 year. On the right-hand side, we have the data of the active users, showing the active users of the last **30** days. 

### What this means
Imagine you own a business, the previous quarter of the year, the business was booming. Plenty of traffic on the website, a **large number of key events** being clicked, signifying the active user interaction with the website, and lots of sales because of the **purchases being made**. This year, the website is not doing great. There is a decline in the number of active users, as well as a decrease in interaction with the website and the number of purchases being made. This is what the data in the above picture indicates. 

The dotted lines are consistently above the continuous lines. When you hover over any of these lines, you can see the difference between the matrices of the previous period and the following period. A variety of matrices can be selected and studied, ranging from user details to key events, as well as bounce rates and the number of purchases. Users can study any of these according to their business needs but as a good rule of thumb, **we always want the solid line to be above the dotted line** for positive interactions.

We will focus mainly on the active users and dig deeper into the problems and what can be done to solve them. 

### What to take away
From what we have observed, the sudden dip in traffic can be attributed to various factors, such as the absence of new products or content updates, irrelevant products, reduced ranking in search engines, incorrect campaigns, and not optimizing keywords, among others. We need to identify these factors by exploring other sections in Google Analytics and address these issues before we go bankrupt. So what's next?

## Is your marketing strategy working?
Are you wondering if your marketing strategy is actually working? The best way to find out is to look at real data that shows how people are finding and interacting with your business.

The traffic acquisition report directly ties into your marketing strategy by showing you which of your marketing efforts are actually bringing visitors to your website. For example, if you’re running ads on Facebook and sending out email newsletters, the traffic acquisition report will break down how many visitors each channel is sending your way, how they behave once they arrive, and whether they’re converting into customers. This direct connection means you can see, in real numbers, whether your marketing strategy is working.

The next section explains how to set up a traffic acquisition report to translate your marketing moves into measurable results.

### Setting up the traffic acquisition report 
Hover to the left side of the screen, where a sidebar will slide up, showing a few options.

Go to `reports -> acquisition -> traffic acquisition` (Please note that the path and interface may vary, because Google changes their UI every couple of months).

You will see the traffic acquisition graph with an option to select the date range. Carefully, set the same date range that you had selected while observing the previous data. To compare the data of this period with the previous period, scroll down to the compare option and select the date range. Below is the visual path of setting it. 

![Setting custom comparison date ranges in the GA4 traffic acquisition report](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-2.png)
*Traffic acquisition data*

Notice how we set our comparison dates (1) and (2) after enabling the compare option(3). After successfully setting the date range, you will have an interface just like the visuals below

![GA4 graph of sessions by primary channel group over time, split by channel](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-3.png)
*Appearance of the graph*

Note: Ensure the date range aligns with the comparison we want to make. Now, this might not seem like it will help us in any insightful way, but wait - we've got something more. You can scroll down a bit to see what the data wants to convey. The data presented below is what we need to observe. 

![GA4 table comparing sessions and engagement by channel between two periods](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-4.png)
*dataset *

**Here's a spoiler:** the red text representing the percentage changes is what we need to work on.

### What to look for 
Multiple channels have been identified from which the traffic primarily originates, including direct, organic, paid search, and others. The negative percentage change is where we need to focus because it is where the marketing campaign is lagging. Let's make some observations and decide plan of action.  The only profitable action on the website is paid search; the rest are doing pretty terrible.

### What this means
Only by observing the sessions columns of the various matrices can we see where the dip in the regular traffic is coming from. 

Starting with the direct traffic, the dip of `-37.99%` may have several reasons, including technical ones. However, being skeptical that the dip is due to the marketing campaigns, we will assume that this dip is caused by a change in the marketing strategy or disruption of the brand awareness campaign.

Make sure to check if there were any changes in the direct marketing campaign to figure out the dip. The other reasons could be due to broken links, changed URLs, or a reduction in the number of direct users, so it may be necessary to consider these factors as well. We always advise running [Screaming Frog's SEO spider](https://www.screamingfrog.co.uk/seo-spider/) as a good first port of call to see how many technical errors there are on your website

Similar types of observations can be made for the other matrices, where the percentage change indicates the success or failure of traffic acquisition from that respective source. 

### What to take away
The decrease in traffic from various traffic sources matrices shows the failure of the overall campaign. A focus on improving direct traffic, enhancing email quality, elevating referral connections, website ranking, and better SEO keyword optimization is the way to go. 

As paid search is performing exceptionally well, this can be an indication to boost it for increased traffic acquisition further. An increase in traffic from any of the sources is a better investment for securing returning customers. In short:

> Line goes up, dump money into that traffic source

### Additional tips
Don’t overlook Google’s AI tools: they make it easy to spot big-picture trends in your data. They often give you good insights as to **if** a trend has changed, and **why** that may be.

With Google focusing on AI so heavily, this is *only going to get progressively more powerful*, until we make both marketers and developers redundant. Cheers Google.

![GA4 AI insight flagging that direct traffic fell short of its expected value](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-5.png)
*AI assistance in GA 2*

In the data above, the assistance indicated a change in the traffic and a possible reason behind it.

## Page Performance Review
The next section to be checked is which pages of the websites are underperforming, and if there is a need to change them. 

You can get the insights about the pages being visited, as well as the landing pages, from `reports->engagements->pages and screens/landing pages`. 

Follow the previous steps to set up the comparison between different periods. In our case, we will have an overview of the pages being visited and what the data conveys. 

### What to look for
Read the data given below and pay attention to how much red is at the top.

![GA4 landing page report comparing views, active users and engagement by page path](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-6.png)
*landing page data*

Pay close attention to the details, as they will yield valuable insights. The two significant columns to focus on are `Views` and `Active users`, because the rest of the data is directly proportional to them.

Notice the change in percentages. The percentage decrease in views varies from page to page. Since there is a reduction in website traffic, it is expected to see negative percentage changes. But the ***real*** concern is which pages are experiencing a significant loss in views. You can observe the following information in the `Active users` column.

- The home page / had a pretty hard impact with `-34%`
- The /checkout pages go down by `-44%`
- The /shop/apparel/mens with `-48%`
- The rest of the pages, too, had an impact, but not like these three. Those three tanked ***hard***

But which aspect should we focus on when everything is on the *down and down*? Let's figure it out.

### What this means
The reduction in active users on the home page may be associated with the failure of the marketing campaigns, which we discussed in the previous section. This is because most campaigns have the topmost priority to guide traffic to the main page of the website. There are slight to no changes required in the content of the homepage, as this is the most carefully written of all pages. *We're all guilty of never changing the homepage*.

The checkout or similar pages, such as the cart and purchase pages, are the pages where the most filtered traffic originates. So, if we look at the statistics, roughly 10% of the total viewers actually add the product to their cart or make a purchase. This makes them the most vulnerable of all pages when it comes to traffic depression; most likely, they are significantly affected by the reduction in viewership.

The two observations above do not require any direct actions; however, regarding the webpage `/shop/apparel/mens`, we can focus on a few interesting points.

The traffic was reduced by almost half for this particular men's section of the website. It cannot be entirely attributed to a "bad marketing campaign". There must be something that is driving away the audience from this page. The reason could be that the content or products available on this webpage do not align with the interests of the buyers/viewers, as either the content/product is outdated or is not attracting the viewers. 

These are our best guesses for what might be going on. Just keep in mind, with statistics, you’re making informed assumptions. There’s rarely a 100% certain answer. Factors such as the time of year, upcoming holidays, or economic fluctuations can all have a significant impact on your website traffic and sales. And *remember*, just because two things happen at the same time doesn’t mean one caused the other: correlation doesn’t always mean causation!

***E.g Here's a graph between drownings, and ice-cream sold***

![Spurious correlation graph of ice cream sales and drownings rising together](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-use-google-analytics-and-actually-get-something-out-of-it-blog-body-image-7.png)

### What to take away
As a general rule of thumb, ensure you always maintain good performance on your website. You've closed off any significant technical issues with the Screaming Frog SEO Spider, and your marketing keywords are well-defined and targeted for your specific audience.

However, above everything else, make sure you hire a marketer who actually cares.

> **Headless CMS services**: Analytics integration, CMS setup, and data-driven content architecture. [Learn more](/services/headless-cms)

## And there is more to come
Thank you for coming this far with us. The above use cases are just the tip of the iceberg. When it comes to getting insights from Google Analytics, there is much more to learn.

If there are any specific issues you're having with Google Analytics and want a second set of eyes to look at it, or write a blog post, get in touch, as we always want to make the learning curve a little bit less steep, with such a gigantic analytics tool.

Stay tuned for our next blog, which will cover how to implement `Google Analytics` and `GTAG` within a Next.js application. We also discuss the difference between the tools, when to use each, and how we can implement this with something like a [cal.com](https://cal.com) embed.

---

## Working with Turbo Start Sanity


> This week we launched Turbo Start Sanity. Here's how to get the most out of Roboto Studio's foundational Next.js and Sanity implementation.

**Published:** 2025-02-18 | **Updated:** 2026-08-17 | **Categories:** Next.js, Sanity
---

Turbo Start Sanity is our *best stab* at building a universal, opinionated starting point for an enterprise-grade Sanity, [Next.js](/services/nextjs) and Vercel website (a bit of a mouthful).

We wanted to open-source the same platform we use, which can scale to tens of thousands of pages without issue.

Alternatively, you could say that we want to improve the editorial experience for your average marketer so that they stop using WordPress.

## Getting started
To get started with Turbo Start Sanity, we recommend either running the `npm` command below or go directly to the Sanity Exchange page and hit the [one-click install](https://www.sanity.io/templates/turbo-start-sanity)

```sh title="getting-started"
npm create sanity@latest -- --template robotostudio/turbo-start-sanity
```

This will cover the entire setup process, including scaffolding out the project, populating content with Faker.js, and setting up your Sanity Studio with environment variables. [You can explore the repo here](https://github.com/robotostudio/turbo-start-sanity).

## Why pnpm and monorepo?
In short, because we cheaped out on the hard drive space on our Macbooks. That's where `pnpm` comes in, `pnpm` allows you to cache packages throughout all your different projects.

We work on a **lot** of different projects, and the last thing we need is to install 100 copies of the same Next.js package for each individual client. As a bonus, it also significantly speeds up installs by reusing these packages. Dropping that 2 minutes `npm i` to a 10 second `pnpm i`.

> Not bad for an extra `p` at the start of the command.
As for the monorepo, we've always been huge fans of siloing our headless CMS to ensure a separation of concerns. That's how we handle Turbo Start, and that's how we'd advise you to work with Sanity Studio.

## Using Sanity Live Content API
Hands down, the most significant upgrade to working with headless CMSs has been Sanity [Live Content API](https://www.sanity.io/live). It doesn't get that much publicity because it's pretty difficult to explain what it actually does. Even more so, explain why it's valuable unless you've accidentally pushed something to your live website that you want off ***immediately***.

## Building page-builder blocks with AI
The first thing you'll probably want to do is either build an additional schema or add another block to the page builder. Lucky for you, [we've built a prompt ](https://gist.github.com/jonoroboto/e9a3f0254057dc47b1fd9052988bdf84)[for ](https://gist.github.com/jonoroboto/e9a3f0254057dc47b1fd9052988bdf84)[exactly this here](https://gist.github.com/jonoroboto/e9a3f0254057dc47b1fd9052988bdf84).

If you're new to schema, here's how we recommend building it: Before doing this, *make sure you've added the prompt above within Cursor.*

If you want the unedited version, here's the full 15 minute run of us building page-builder blocks in Turbo Start. Schema, queries, and components, in the order we actually write them.

### Using v0.dev
Naturally, because the whole project is built with vanilla Next.js, Tailwindcss, and Sanity, v0 is a perfect fit for generating components on the fly. We personally recommend building them from Figma designs and providing a prompt that doesn't really split out too much `tsx` to avoid issues with overriding content.

Here's the prompt we used in the video

```markdown title="prompt"
Objective: Develop a component in isolation, to make it easy for a developer to implement within a large headless CMS project. The component should encompass all utilities, styles with Tailwind and functionality within a singular tsx file. There should be json at the top of the file that populate the text and images throughout the page so it can be easily rewired into a headless CMS at a later date.

File Naming Conventions:
	•	Use kebab-case for all file names.
	•	Correct: ⁠user-profile.tsx, ⁠auth-layout.tsx, ⁠api-utils.ts
	•	Incorrect: ⁠userProfile.tsx, ⁠AuthLayout.tsx, ⁠apiUtils.ts
	•	Use ⁠.tsx extension for React components.
	•	Use ⁠.ts extension for utility files.
	•	Use lowercase for all file names.
	•	Separate words with hyphens.
	•	Do not use spaces or underscores.
```

> **Sanity CMS development**: Turbo Start Sanity is our foundational Next.js + Sanity implementation. Get building fast. [Learn more](/services/sanity)

## Understanding fallbacks
When it comes to building a website with a live preview, you're going to hit a ton of edge cases. That's why we always recommend following the advice from [Sanity Learn](https://www.sanity.io/learn/course/seo-optimization) about title, seoTitle, and ogTitle and why we use each of those as a respective fallback.

> In short, you want your editors to do the least work possible to get the minimum working page (*maybe we should call it *`*MWP*`).
It also means you **only** have to fill out SEO for the pages that *actually* rank.

## Did you break something?
If you're working with Turbo Start Sanity and notice a significant error, [get in touch](/services/sanity). *Better yet*, open a PR. This is an open-source repo, after all. We are always working to upgrade and improve elements with the tool, and any help would be much appreciated.

Talking of which, shout out to the incredible efforts of [James Singleton](https://x.com/ThisIsSingleton), who already broke Turbo Start twice and added two PRs to fix it. MVP.

## Go build something
Honestly, *before I get too preachy*, there's never been a better time to start actually building. And if you'd rather have us walk your team through it hands-on, that's exactly what our [workshops](/services/workshops) are for. We'd love to see what you're creating, so feel free to reach out if you want to show off; we love to see it.

---

## Using markdown shortcuts with the Portable Text Editor


> It's finally here, we've been excited to type a little # before our titles and get that magnificent pop in heading size. Let's get started 

**TL;DR:** 2024's hot request: shortcuts in Sanity's Text Editor. Finally dropped! Update with 'npm i sanity@latest'. Cheat sheet: markdown shortcuts for headings, lists, and more. Don't forget keyboard shortcuts for bold/italic. Full-screen mode for focus. Should've read this sooner, huh?

**Published:** 2025-01-14 | **Updated:** 2026-07-23 | **Categories:** Sanity, How To
---

Throughout 2024, one of the top editorial requests has been shortcuts within the Sanity Portable Text Editor. 

It's been a bit of a pain point and the one QOL productivity feature we think was missing.

[Now, guess what dropped just before the end of the year](https://www.sanity.io/blog/a-block-content-editor-that-loves-you-back).

So you know what that means: if you're not already using the [auto-updating Sanity Studio](https://www.sanity.io/docs/studio/latest-version-of-sanity), make sure you run:

```sh
npm i sanity@latest
```

Now we've got that up and running, let's move on to the cheat sheet. Keep reading to find out a pitfall we fell into when testing it for the first time.

## Cheat Sheet

Here's a list of all the markdown shortcuts we've discovered so far. Everything highlighted on the left should be typed into the Sanity Portable Text field followed by a `space` to change the formatting.

### Headings
`#` - Heading 1

`##` - Heading 2

`###` - Heading 3

`####` - Heading 4

`#####` - Heading 5

`######` - Heading 6

### Blockquote
`>` - Blockquote

### Lists 
`1.` - Ordered list

`-` or `*` - Unordered list

## Pitfall to be aware of
If you're like us, you probably restricted ``<h1>`` when you set up your Portable Text Editor for SEO reasons. 

Naturally, the first thing you are going to test from the cheat sheet above is `#` and then see if a `Heading 1` appears...

This won't work if you're not including `Heading 1`'s in your configuration and you will get the same result as we did below.

![We all make mistakes - here's an example of us trying to get a `<h1>` to work](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/using-markdown-shortcuts-with-the-portable-text-editor-blog-we-all-make-mistakes-heres-an-example-of-us-trying.png)

> Make sure whatever markdown shortcut you're trying to use, actually exists inside of your Portable Text Editor.

> **Sanity CMS development**: Portable Text customization, editor shortcuts, and Sanity studio setup for content teams. [Learn more](/services/sanity)

## Keyboard shortcuts exist as well
You may be aware of a couple of Markdown shortcuts we missed from above, specifically **bold** and *italic*. The good news is that they're in there, but with keyboard shortcuts instead.

For example, highlight some text and hit:

`⌘ + B` - Make text bold

`⌘ + I` - Make text italic

## Bonus tip: full-screen Portable Text Editor
Things can easily become distracting if too many tabs are opened at once. For editorial zen, you can full-screen your Portable Text Editor.

You can do so by hitting the expand editor at the top right (or hitting `⌘ + ⏎ (enter)`) and clicking the top of each side panel to collapse them. 

## Thanks for reading
We've always said:

> "Little incremental improvements are far more significant to the editorial experience than a singular big release."
That's why we love [Sanity](/services/sanity) for their constant efforts with QOL improvements.

---

## Our 2024 takeaways with Sanity & Next.js


> What a year it's been. There's never been a year when we've seen more paradigm shifts, AI evolution and the state of dev is better than ever.

**Published:** 2024-12-31 | **Updated:** 2026-07-23 | **Categories:** Sanity, Next.js
---

What a year it's been. We've seen multiple new models from Open AI, Anthropic and Facebook. We've seen integrations of co-pilot throughout more and more of GitHub, and we've been first in line to speak about how [we've started shipping faster with v0](https://vercel.community/t/how-roboto-studio-ships-faster-with-v0/3127)

We want to avoid the clichés of a typical *'end of year' listicle.* Instead, we intend to compile how things have fundamentally changed this year, and how you can align yourself to ensure you're ready for the future.

## Start using AI
This particular point goes out to both developers, and *everybody else*.

**If you are a developer**, do not follow the contrarian route of dismissing the usage of AI, you are actively compromising your learning and productivity. That being said, do not overly rely on AI, but use it for mundane tasks, like creating large chunks of repeatable boilerplate.

If you haven't used it already, and you're building a Sanity & Next.js website - download [Cursor](https://cursor.com/), [steal our prompt](https://gist.github.com/jonoroboto/e9a3f0254057dc47b1fd9052988bdf84) and turn on the latest version of Sonnet (`claude-3-5-sonnet-20241022`). Just spend half a day looking at how to use composer. It's going to change how you build websites. It's not hyperbole.

**For everybody else**, you *can*, and you *should* be using AI today. The barrier is rapidly dropping, day by day, for being able to build primitive components for websites.

If you are a project manager without coding knowledge, you can use something like [v0](https://v0.app/) to generate components for your frontend team. If you're a marketer, go generate some calculators, some infographics, you can even build an interactive landing page with [v0](https://v0.app/). If you want to go further, have a look at how [agentic workflows](/services/agentic-workflows) can automate entire content pipelines. 

You're going to single-handedly reduce the turnaround for your team, and you can pretend it's entirely down to *your newly discovered development skills*...

## DDoS attacks are inevitable
We have always known DDoS attacks are relatively common, but we didn't know *how* common.

Take a couple of seconds out to [see how many DDoS attacks are happening right now](https://horizon.netscout.com/). Let that sink in for a second.

Here's an example of a real-life website. The graph shows 322k Web visits, 845 DDoS mitigation challenges, 55 DDoS **denied**. If you haven't noticed already, this in the past *day*, not in the last *month*.

![Website data that shows 333k users, 845 DDoS Challenges, and 55 DDoS blocked](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-2024-takeaways-with-sanity-and-nextjs-blog-website-data-that-shows-333k-users-845-ddos-challe.png)

Just in the last day alone, Vercel has blocked 55 DDoS attacks to this website. 

There's an inevitability that somebody will want to break your website, the more you scale, the more likely it's going to be. You need the infrastructure built-in to protect yourself from this.

## Just use Vercel
In the example above, there's a tremendous amount of traffic pouring into the  website daily. You would think that this would cost a fortune in hosting, to keep it up and running, especially seeing all the attempts to knock it down. 

Truth be told, the above website runs on the Vercel pro plan. Better yet, because of our optimisation changes, it doesn't even exceed Vercel pro plan quotas. Yes, you read that right.

If you are on the fence about where to host your website, ***just use Vercel***.

Now, you might be wondering why we have such strong opinions about this. To elaborate:

1. The majority of our business is [migrations](/services/cms-migration) from **legacy systems**
1. The majority of legacy systems have been **custom-built**
1. We have never encountered a custom-built solution that has **worked correctly**

If you're reading this, and suddenly, you've got cold-sweats thinking about when your custom-built architecture stops working, please don't hesitate to [reach out](/services/nextjs). We have migrated websites with 600k+ pages to Vercel, I'm sure we can manage yours.

## Presentation & Live Content API
If you have been following Sanity CMS changelogs, you may have noticed two massive updates in 2024 - [Live Content API](https://www.sanity.io/docs/content-lake/live-content-api) & [Presentation](https://www.sanity.io/docs/visual-editing/configuring-the-presentation-tool).

Why have we grouped them together? Because this should be table-stakes for building a website with Sanity. Why? Because they're such a significant improvement to the whole editorial experience, along with being relatively easy to implement on a greenfield project.

Presentation allows for a user to go to a website, click the text they want to edit, and immediately jump into that field. Drag and drop by default, with the ability to zoom out to get a perspective of the whole page.

With Live Content API you don't have to worry about caching or server-side rendering, or even some of the older methods of firing a webhook when your content changes. 

In other words, if you change something on your website, it reflects instantly. Whether that is changing a product from out-of-stock, to in-stock, or changing the inevitable typo's in your blog posts, it's *live by default*.

Both of these make the whole process of updating websites or changing content so much easier. There's no excuse to not implement it. If you're starting a new project, our [workshops](/services/workshops) ship with both of these configured out of the box.

> **Sanity CMS development**: Sanity and Next.js builds with performance, visual editing, and editorial experience baked in. [Learn more](/services/sanity)

## Performance is the #1 feature
Performance is central to user experience. It's easy to optimise for it at the beginning, but becomes much harder as the website scales.

Instead of going through all the reasons why you should improve performance, we are going to drop the common culprits of a slow website and how to fix them.

- Too many analytics packages
  - Assess what analytics packages you actually use, drop the rest. Make it a quarterly check-up to see if you're still using *that Hotjar library, or LinkedIn tracking pixel*.
- Material UI
  - *2014 called, it wants its design language back. *But seriously, Material UI is a behemoth, and it can be replaced by significantly smaller UI frameworks such as Tailwind and Shadcn/ui. [There's never been a better time to refactor with AI](https://codemod.com/).
- Font Awesome
  - If you're using this package with Next.js, make sure to run [Next.js bundle analyser](https://nextjs.org/docs/app/guides/package-bundling). We used to use this, and it made up half the size of our entire website. We always advise using [Lucide](https://lucide.dev/) instead.
- Google Analytics, YouTube, Google Tag Manager
  - Most devs we have spoken to are not aware that [Next.js third-party libraries](https://nextjs.org/docs/app/guides/third-party-libraries) exist. They are set-and-forget versions, with optimal loading strategies. Just swap them out and never look back.
- Huge DOM size
  - This often happens with large chunks of data. Check to see if you can offset some of this with [lazy loading and dynamic imports](https://nextjs.org/docs/app/guides/lazy-loading). If you're building page builders, this is especially important.

With all of the above, here is some advice regarding lighthouse tests and their respective performance in different environments.

If you're struggling to optimise your website, feel free to get in touch.

## The year ahead for Roboto Studio
As with every year, we want to thank everybody who took the time out to actually read this far, the folks that trusted in our ability to build some of the best editorial experiences on the web and especially the incredible team that makes all of this possible.

We're excited to make progress towards our ISO 27001 certification, we'll continue to share the discoveries along the way with bleeding-edge tech and enterprise-grade security.

Alongside this, we’re also expanding our team. We will be working with folks who share the same drive to design, develop and continue delivering the exceptional work you expect from us.

We're looking forward to a year filled with growth, fresh challenges, and even better results for our clients. Here's to an exciting and successful year ahead!

---

## Should I upgrade to Sanity Enterprise?


> A deep dive into Sanity Enterprise features and whether they make sense for your organization

**Published:** 2024-12-05 | **Updated:** 2026-08-24 | **Categories:** Sanity
---

If you're reading this, chances are you're already using Sanity and wondering if it's time to take the next step with Enterprise. We've been there - weighing the pros and cons of enterprise features against the investment. Let's break down what Sanity Enterprise actually offers, our opinions of what *we* think is worthwhile, and help you make that decision.

## The Basics: What Sets Enterprise Apart
First things first - Sanity Enterprise is not a bigger version of the [Growth plan](https://www.sanity.io/pricing). If you want a full breakdown of what each tier includes, check our [Sanity CMS pricing guide](/blog/sanity-cms-pricing-which-plan-is-right-for-you). Enterprise is a completely different beast, designed for organizations that need enterprise-grade features. We're talking about things like dedicated support, specific SLAs, and enhanced security measures that go beyond the standard offerings.

## The support
This is the most important thing. Sanity Enterprise enables you to have a dedicated point of contact for your account. This can range from a single point of contact to a team of people who are responsible for your success.

Now, if you've paid close attention to the [Sanity Exchange](https://www.sanity.io/exchange), you would have probably seen some of the success stories from folks like [Global Cycling Network](/case-study/global-cycling-network) and [Puma](https://www.sanity.io/customers/puma). A lot of that is thanks to the combination of efforts between the respective agency and the Sanity team.

The other part of this is the ability to have a dedicated Slack channel for your account. This is huge for us as it allows us to have a direct line of communication with the Sanity team and more importantly allows you to draw on any instance where there is historical context to your queries. For example, we had a good few conversations about the best way to implement a slug generation system for Global Cycling Network.

## Security that actually matters
Let's start with those TLA (three-letter acronyms), Sanity has all of the ones that are important. Sanity Enterprise comes with `SOC 2` compliance, `GDPR` & `CCPA` compliance, and 24/7/365 monitoring. But what does this actually mean for your organization?

Well, if you're handling sensitive content or operating in regulated industries, these certifications aren't just nice-to-haves - they're essential. We've covered this in more detail in our post on [how Sanity handles your data](/blog/how-sanity-handles-your-data). The platform maintains >99.9% uptime and offers custom access control with SSO integration. This means your content is not just secure, but also reliably accessible when you need it.

## Custom User Roles
Sanity Enterprise allows you to create custom user roles. This is something we've been requested, again and again. In short, if you're looking for something where you can assign a certain user the role of "Content Editor" and another user the role of "Content Approver", this is more than likely what you need.

If you are thinking of doing this, there's also an incredible plugin I would look into called [Sanity Workflow Plugin](https://github.com/sanity-io/sanity-plugin-workflow-example). There's also a respective example of [how it might work here](https://github.com/sanity-io/demo-custom-workflow?tab=readme-ov-file).

## Self-Serve vs Enterprise
I'll start by saying, we inherit a lot of projects, with clients that have had their websites built by other agencies. This means that we have to manage a lot of legacy code. One of the things that keeps us up at night is blowing your plan's quota. We've all seen the dreaded email - "You've used 90% of your quota". This is where the two plans wildly differ.

If you're on the Growth plan, you're going to need to find a developer to debug this, and that's not always easy. These kind of issues can range from, whoops somebody made everything client side, and we just had a million visitors, to, *whoops we have a memory leak, and we've just blown 9 million API requests* (true story).

This is where the Enterprise plan really shines. Because of the aforementioned dedicated support, you can quickly resolve this with one of the internal Sanity team members, that's able to shed more light on the issue and where it might be coming from. Not just that, but it plays to both teams advantage to not blow quotas, as the website won't be performing its best if it's firing off a million requests.

## The Shiny New Toys
Here's something that might tip the scales. There's already Sanity AI Assist, which is a great tool. But if you're on the Enterprise plan, you have access to some of the new releases before they're generally available. This gives you a real leg up, especially if you're looking to implement AI into your workflow.

We've been especially impressed recently with how they're creating their own authoring tool with Sanity Create, and having greater integration and functionality like "Live by default", we've noticed a massive up-tick with actually wanting to write content. Guess what this was written in...

> **Sanity CMS development**: Enterprise migrations, SSO setup, and Sanity architecture for large organizations. [Learn more](/services/sanity)

## Should you make the jump?
The decision to upgrade to Enterprise really comes down to a few key questions:

1. Are you operating at a scale where dedicated infrastructure would make a significant difference?
1. Do you need the enhanced security features for compliance or peace of mind?
1. Would your content team benefit from advanced collaboration tools and the latest and greatest features?
1. Is global content delivery a core part of your strategy?
1. Finally, do you want consistent, reliable growth from the Sanity Team, and your respective agency partner?

If you're answering yes to most of these questions, Enterprise might be worth considering.

I'll leave some of the marketing materials below, if you want to have somebody like g2 to validate what I've been saying above. However, it is worth knowing, I'm not actually getting paid by Sanity to say this, *I have better things to do on a Thursday evening*.

> According to recent surveys, Sanity was rated #1 in CMS satisfaction by over 7,000 developers, and they're ranked #1 out of 85 CMSes on G2 - particularly in the Enterprise space.

## The Bottom Line
Enterprise isn't for everyone, and that's okay. If you're a smaller team or your content needs are relatively straightforward, the Growth plan might be all you need. But if you're handling complex content operations across multiple markets, or if you need enterprise-grade security and performance, it's worth having a conversation with their sales team. They're one of the few sales teams, that aren't all that salesy - which is a huge plus.

If you're still weighing things up and want a second opinion, we're [Sanity agency partners](/services/sanity) and happy to talk through the trade-offs. And if you're just getting started with Sanity and want to move fast, our [workshops](/services/workshops) are a good place to begin.

---

## Hidden gems in Next.js: features you might have missed


> We spend far too much time trawling through docs, why don't we share some of those little gems with you with Next.js. Pull up a chair.

**Published:** 2024-11-20 | **Updated:** 2026-07-23 | **Categories:** Vercel, Next.js
---

## Introduction
If you're like us, you're probably using [Next.js](/services/nextjs) day in, day out. We typically use the same old packages and processes each time we start a new project. However, every so often, we find some weird or wonderful feature that we didn't know existed.

Grab yourself your 7th coffee of the day and blame the resulting jitters on this article. It's really that good.

## Vercel built a third-party package for this?
You might know about the Vercel Analytics package already, but for this entry we're going to completely overlook it and settle for the more commonly used, privacy encroaching alternative. Yes, we're talking about Google Analytics.

If you're like us, you probably didn't know that [this whole section](https://nextjs.org/docs/app/guides/third-party-libraries) of the next.js documentation existed. It's a great way of upgrading your wonky `dangerouslySetInnerHTML` to a nice, secure, and performant `next/script` tag. How about that? Well, it's either that or you could just ditch your analytics provider and use Vercel's instead...But I'm sure that won't fly with your marketing team.

## Codemods are your friend
So this is less of a hidden gem and more of a "why didn't I know this existed" moment. Did you know that Next.js has a built in codemod system? Well duh, you probably did. But did you know that you can use [v0](https://v0.app/) to help you with the appropriate codemod for the job? Yeah, us neither, it's only when we went to one of the conferences that we were introduced to this gem.

## Migrating to latest Next.js?
Following along from the previous point, one of the most common issues we notice is that a lot of folks are using some old version of Next.js. How about if we told you that in the same vein as above [v0](https://v0.app/) can actually help you migrate to the latest version?

It's also great for telling you common issues you might have with your current version, and pitfalls to avoid when upgrading. Essentially whenever you're focusing on next specific advice, you should be checking out v0 first.

> Pro-tip: Talking of migrations, one of the most common issues we notice is the old version of Next.js, is forgetting to add an `<a>` tag within your `<Link>` component, ultimately leading to the link not actually showing google the `<a href=...>` within the html. If you're using the `next/link` component in [Next.js 13 onwards](https://nextjs.org/docs/pages/guides/upgrading/version-13#v13-summary), you don't need to worry about this.
## Stop using Google Lighthouse
> "When a measure becomes a target, it ceases to be a good measure."
Now I'm going to tell you to stop using Google Lighthouse and instead use Vercels performance analytics, and completely miss the irony of the above quote.

But seriously, if you're looking for a more in depth analysis of your sites performance, Vercels performance analytics is a great tool for both feeding back on the performance of your site, and also for setting targets and monitoring improvements over time. We use it internally to debug performance throughout the Roboto Studio site, and know we *"shipped a little too fast"* if it suddenly starts to tank.

## Bundle analyzer, and how I learned to stop worrying and hate fontawesome
If you're anything like me, you'll probably have used Font Awesome at some point in your career. Hell, we backed it from the early, *early* days of Roboto Studio.

However, have you ever used the [Next Bundle Analyzer](https://nextjs.org/docs/app/guides/package-bundling)? If you have you'll know that unless you follow this ridiculous process to actually tree shake the icons you're bundling, you'll end up with a *huge* bundle size. We literally halved our bundle size by reading the [instructions here](https://docs.fontawesome.com/apis/javascript/tree-shaking). What I mean by that is, we read the instructions, and then we scrapped fontawesome and just went with [Lucide](https://lucide.dev/) instead.

## Next/font and CLS
You probably already know about the `next/font` system, but I just want to take a little time out to actually dig a little deeper.

What you might not have known is that it also provides advanced features like automatic subset loading, variable font support, and preload strategies. These optimizations can significantly improve your First Contentful Paint (FCP) and prevent layout shifts.

But if you're anything like us, you'll just want to know how to make it work with tailwindcss in the best way possible. Essentially this is it:

```typescript
import { Roboto } from "next/font/google";

const roboto = Roboto({
  subsets: ["latin"], // [!code highlight]
  variable: "--font-roboto",
});
```

Then inside of your `tailwind.config.js`, you can add the following:

```tsx
module.exports = {
  theme: {
    extend: {
      fontFamily: {  
        roboto: ["var(--font-roboto)"], // [!code highlight]
      },
    },
  },
};
```

If you add that to your outermost container, you'll find that your CLS will be significantly reduced and it *"just works"* like you'd expect. Just make sure you're using the variable part because you need that for the font to be applied correctly.

> **Next.js app development**: Performance-first Next.js builds with server components, edge functions, and Turbopack. [Learn more](/services/nextjs)

## Dev tools for CLS & beyond
Talking of CLS, wouldn't it be nice to have a tool that could help you identify the cause of your CLS issues? Well, you can do this too, and it's actually pretty simple.

You can test how much you're avoiding that pesky CLS by opening a preview deployment and clicking the little toolbar at the bottom of the page.

![A screenshot of the Vercel toolbar, yes, it's on the left hand side, rather than the bottom, don't question it](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/hidden-gems-in-nextjs-blog-a-screenshot-of-the-vercel-toolbar-yes-its-on-the-.png)

*Okay, so ours isn't on the bottom of the page, but yours probably will be*

## Checking if stuff caches
One of the most useful features of Next.js when deployed to Vercel is the ability to check if your pages are being cached correctly. Simply open up your browser's developer tools, head to the Network tab, and look for the `x-vercel-cache` header in the response. If you see "HIT", congratulations - your page is being served from the edge! If you see "MISS", then your page is being generated on-demand and we've probably just saved you a few hundred dollars on your next microservice bill.

![A screenshot showing how to access your network panel and check your headers to make sure it's a Vercel cache hit](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/hidden-gems-in-nextjs-blog-a-screenshot-showing-how-to-access-your-network-pa.png)

---

## Optimized data fetching in Next.js 15


> Data fetching patterns for Next.js 15, taken from our Vercel optimization talk: server components, caching choices, and real code from Turbo Start Sanity.

**Published:** 2024-11-15 | **Updated:** 2026-07-23 | **Categories:** Performance, Next.js
---

## Introduction
This blog post is a bit of an amalgamation of a talk we gave on [Optimising usage on Vercel](https://www.youtube.com/watch?v=V6Yd9wgY-uU), as well as snippets from our own code within [Turbo Start Sanity](https://github.com/robotostudio/turbo-start-sanity). We wanted to get the content out there, as a reference point as well as a cheeky way of capitalising on some nice SEO for dropping thousands of characters worth of Next.js code.

## Generic takeaways from Next.js
Some top-level advice I would advise following is to try to avoid `use client` until strictly necessary. If you have to use it, make it so that it's a smaller part of a component, rather than essentially wrapping a good chunk of your app within a client component. This differs if you're building something like Linear where it's almost all client side, and very dynamic.

Alongside this, we would emphasise that more than ever, it's worth jumping on the Tailwind CSS bandwagon. Because of the above, you really don't want something heavy like Material UI, as it's going to tank performance, especially as your app scales.

Moreover, if you're thinking of building an application with [Next.js](/services/nextjs) and [Sanity](/services/sanity), you probably want to get the data layer right from day one.

## Key Concepts in Next.js 15
Next.js 15 introduces several new features and improvements that enhance data fetching capabilities. These include server components, improved caching strategies, and more.

## Server Components
Server components allow you to render parts of your application on the server, reducing client-side JavaScript and improving load times.

```typescript title="app/page.tsx"
async function fetchPosts() {
  const posts = await client.fetch(`*[_type == "post"]{
    _id,
    title,
    slug,
    publishedAt
  }`)

  return posts
}

export default async function Page() {
  const posts = await fetchPosts()

  return (
    <section>
      <h1>Latest Posts</h1>
      <ul>
        {posts.map(post => (
          <li key={post._id}>{post.title}</li>
        ))}
      </ul>
    </section>
  )
}
```

## Fetching Patterns
### Route Segment Config for Cache Control
```typescript title="cache-control"
// Set cache behavior at the route level
export const dynamic = 'force-dynamic'
// Or use more granular settings
export const revalidate = 60 // Revalidate every 60 seconds
```

### Request-Level Cache Control (New in Next.js 15)
```typescript title="route-level-cache-control.tsx"
async function fetchPost(slug: string) {
  // New in Next.js 15: Request-level cache options
  // Always use parameterized queries to prevent GROQ injection
  const query = encodeURIComponent('*[_type  "post" && slug.current  $slug][0]')
  const params = encodeURIComponent(JSON.stringify({ slug }))

  return await fetch(`https://api.sanity.io/v2023-08-01/data/query/production?query=${query}&$slug="${params}"`, {
    next: {
      // Control cache behavior per fetch
      revalidate: 30, // Seconds
      tags: [`post-${slug}`], // Custom tags for on-demand revalidation
    },
  }).then(res => res.json())
}
```

### On demand
```typescript title="app/api/revalidate/route.ts"

import { revalidateTag } from 'next/cache'
import { NextRequest, NextResponse } from 'next/server'

export async function POST(request: NextRequest) {
  try {
    const { tag, secret } = await request.json()

    // Validate secret token
    if (secret !== process.env.REVALIDATION_SECRET) {
      return NextResponse.json({ error: 'Invalid token' }, { status: 401 })
    }

    // Revalidate the specific tag
    revalidateTag(tag)

    return NextResponse.json({ revalidated: true, tag })
  } catch (error) {
    return NextResponse.json({ error: 'Error revalidating' }, { status: 500 })
  }
}
```

## Advanced Caching Techniques
### Parallel Data Fetching
```typescript title="parallel-data-fetching.tsx"
// Fetch multiple resources in parallel without waterfall
async function DashboardPage() {
  // These run in parallel!
  const postsPromise = client.fetch(`*[_type == "post"][0...5]`)
  const usersPromise = client.fetch(`*[_type == "user"][0...5]`)
  const statsPromise = client.fetch(`*[_type == "stats"][0]`)

  // Wait for all data to be available
  const [posts, users, stats] = await Promise.all([
    postsPromise,
    usersPromise,
    statsPromise
  ])

  return (
    <Dashboard
      posts={posts}
      users={users}
      stats={stats}
    />
  )
}
```

### Suspense for progressive loading
```typescript title="suspense-for-progressive-loading.tsx"
import { Suspense } from 'react'
import { PostList, UserActivity, Stats, Skeleton } from '@/components'

export default function AdminPage() {
  return (
    <div className="grid grid-cols-12 gap-6">
      <div className="col-span-8">
        <Suspense fallback={<Skeleton type="posts" />}>
          <PostSection />
        </Suspense>
      </div>
      <div className="col-span-4">
        <Suspense fallback={<Skeleton type="stats" />}>
          <StatsSection />
        </Suspense>
        <Suspense fallback={<Skeleton type="users" />}>
          <UserSection />
        </Suspense>
      </div>
    </div>
  )
}

// These components can fetch their own data
async function PostSection() {
  const posts = await client.fetch(`*[_type == "post"][0...10]`)
  return <PostList posts={posts} />
}

async function StatsSection() {
  const stats = await client.fetch(`*[_type == "stats"][0]`)
  return <Stats data={stats} />
}

async function UserSection() {
  const users = await client.fetch(`*[_type == "user"][0...5]`)
  return <UserActivity users={users} />
}

```

## Error Handling and Fallbacks
### Error Boundary at the Route Level
```typescript title="app/posts/[slug]/error.tsx"
'use client'

import { useEffect } from 'react'
import { Button } from '@/components/ui/button'

interface ErrorProps {
  error: Error & { digest?: string }
  reset: () => void
}

export default function Error({ error, reset }: ErrorProps) {
  useEffect(() => {
    // Log the error to an error reporting service
    console.error('Posts error:', error)
  }, [error])

  return (
    <div className="flex flex-col items-center justify-center min-h-[50vh] p-6 text-center">
      <h2 className="text-2xl font-bold mb-4">Something went wrong!</h2>
      <p className="text-zinc-600 mb-6">
        We couldn't load this post. Please try again later.
      </p>
      <Button onClick={reset}>Try again</Button>
    </div>
  )
}

```

### Handling Errors with Error Boundaries per Component
```typescript title="component-level-error-boundary.tsx"
// Component-level error boundary
'use client'

import { ErrorBoundary } from 'react-error-boundary'

function ErrorFallback() {
  return (
    <div className="bg-red-50 border border-red-200 rounded-md p-4">
      <p className="text-sm text-red-700">
        We couldn't load this section. Please refresh the page.
      </p>
    </div>
  )
}

export function PostListWithErrorHandling({ children }) {
  return (
    <ErrorBoundary FallbackComponent={ErrorFallback}>
      {children}
    </ErrorBoundary>
  )
}
```

### Type-Safe Error Handling with tryCatch Pattern
Error handling is a critical aspect of reliable data fetching. Let's implement a type-safe utility function that elegantly handles asynchronous operations:

```typescript title="lib/utils/error-handling.ts"
// lib/utils/error-handling.ts

/**
 * A type-safe utility for handling promise rejections
 * Returns a tuple where:
 * - First element is the result (null if error occurred)
 * - Second element is the error (null if operation succeeded)
 */
export async function tryCatch<T, E extends Error = Error>(
  promise: Promise<T>
): Promise<[T, null] | [null, E]> {
  try {
    const result = await promise
    return [result, null]
  } catch (error) {
    return [null, error as E]
  }
}

```

Using this pattern in your data fetching functions:

```typescript title="server-component-version.tsx"
// Using the utility in a server component
async function PostPage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  const [post, error] = await tryCatch(getPost(slug))

  if (error) {
    // Log the error for server-side tracking
    console.error('Failed to fetch post:', error)

    // Return a graceful error state
    return (
      <div className="error-container">
        <h2>Could not load post</h2>
        <p>Please try again later</p>
      </div>
    )
  }

  // Happy path - post was fetched successfully
  return <PostDisplay post={post} />
}

```

1. This pattern has several advantages:
1. Type safety with generics ensures proper type inference
1. Consistent error handling across the application
1. No try/catch blocks cluttering component logic
1. Clear distinction between successful and error states
1. Can be extended to include specific error types

You can also create specialized variants for specific use cases:

```typescript title="api-route-try-catch.ts"
// Specialized version for API routes
export async function apiTryCatch<T>(
  promise: Promise<T>,
  errorMessage = 'An error occurred'
): Promise<NextResponse> {
  const [data, error] = await tryCatch(promise)

  if (error) {
    console.error(errorMessage, error)
    // Use type guard to safely access statusCode if it exists
    const statusCode = (error as Error & { statusCode?: number }).statusCode ?? 500
    return NextResponse.json(
      { error: errorMessage },
      { status: statusCode }
    )
  }

  return NextResponse.json({ data })
}

```

## Working with Sanity CMS
### Typed Queries with GROQ
```typescript title="lib/sanity/query.ts"

import { defineQuery } from 'groq'
import { imageFragment } from './fragments'

export const POST_QUERY = defineQuery(`*[\n  _type  "post"\n  && slug.current  $slug\n][0]{\n  _id,\n  title,\n  publishedAt,\n  excerpt,\n  "slug": slug.current,\n  mainImage{\n    ${imageFragment}\n  },\n  body,\n  "author": author->{\n    _id,\n    name,\n    "slug": slug.current,\n    image{\n      ${imageFragment}\n    }\n  }\n}`)

```

### Optimized Sanity Client
```typescript title="lib/sanity/client.ts"
import { createClient } from 'next-sanity'
import { POST_QUERY } from './query'

export const client = createClient({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID!,
  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET!,
  apiVersion: '2023-11-01',
  useCdn: process.env.NODE_ENV === 'production',
})

// Type-safe fetching function
export async function getPost(slug: string) {
  try {
    const post = await client.fetch(POST_QUERY, { slug })

    if (!post) {
      throw new Error(`Post with slug ${slug} not found`)
    }

    return post
  } catch (error) {
    console.error(`Error fetching post with slug ${slug}:`, error)
    throw new Error('Failed to fetch post')
  }
}

```

## Next.js 15 Performance Features
### Partial Prerendering (PPR)
```typescript title="partial-pre-rendering.tsx"
// app/page.tsx
import { unstable_noStore as noStore } from 'next/cache'

export default function Page() {
  return (
    <>
      <HeaderSection />
      <DynamicContent />
      <StaticFooter />
    </>
  )
}

function HeaderSection() {
  // Static content, prerendered at build time
  return <header>...</header>
}

async function DynamicContent() {
  // Opt out of caching for this section
  noStore()

  const data = await fetchFreshData()

  return <main>{/* Render data */}</main>
}

function StaticFooter() {
  // Static content, prerendered at build time
  return <footer>...</footer>
}

```

### React Cache with Infinite Nested Component Trees
```typescript title="react-cache-version.tsx"
import { cache } from 'react'
import { client } from '@/lib/sanity/client'

// Cached fetcher function
export const getCategory = cache(async (slug: string) => {
  return client.fetch(`*[_type  "category" && slug.current  $slug][0]`, { slug })
})

// This can be used throughout the app
// without duplicating requests for the same data
async function CategoryHeader({ slug }: { slug: string }) {
  const category = await getCategory(slug)
  return <h1>{category.title}</h1>
}

async function CategoryPage({ slug }: { slug: string }) {
  const category = await getCategory(slug) // Reuses the same request!
  // ...
}

```

### Background Prefetching and Preloading
```typescript title="background-prefetch.ts"
'use client'

import { useCallback, useEffect } from 'react'
import { useRouter } from 'next/navigation'
import Link from 'next/link'

export function PostCard({ post }) {
  const router = useRouter()

  // Preload the post page when user hovers
  const prefetchPost = useCallback(() => {
    router.prefetch(`/posts/${post.slug}`)
  }, [router, post.slug])

  return (
    <div
      className="group cursor-pointer"
      onMouseEnter={prefetchPost}
    >
      <Link href={`/posts/${post.slug}`}>
        <h3>{post.title}</h3>
        <p>{post.excerpt}</p>
      </Link>
    </div>
  )
}

```

## Headers and Edge Optimization
### Custom Cache-Control Headers
```typescript title="app/api/posts/route.ts"
import { NextResponse } from 'next/server'
import { client } from '@/lib/sanity/client'

export async function GET() {
  const posts = await client.fetch(`*[_type == "post"][0...10]`)

  // Use custom cache control headers
  return NextResponse.json(
    { posts },
    {
      headers: {
        'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=300',
      },
    }
  )
}

```

### Edge Runtime for Global Performance
```typescript title="app/posts/[slug]/page.tsx"
export const runtime = 'edge'

export default async function PostPage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  const post = await getPost(slug)
  return (/* Render post */)
}

```

If you're looking for more performance tricks beyond data fetching, we covered a bunch in our post on [hidden gems in Next.js](/blog/hidden-gems-in-nextjs).

> **Next.js app development**: Data fetching, caching, and Next.js performance optimization for production apps. [Learn more](/services/nextjs)

## Implementing ISR in Next.js 15
### Time-based Revalidation
```typescript title="app/blog/page.tsx"
export const revalidate = 3600 // Revalidate every hour

export default async function BlogPage() {
  const posts = await client.fetch(`*[_type == "post"] | order(publishedAt desc)[0...12]`)
  return (/* Render posts */)
}

```

### On-Demand Revalidation with Webhooks
```typescript title="app/api/revalidate/route.ts"
import { NextRequest, NextResponse } from 'next/server'
import { revalidatePath, revalidateTag } from 'next/cache'

export async function POST(request: NextRequest) {
  try {
    const { searchParams } = new URL(request.url)
    const secret = searchParams.get('secret')

    // Validate webhook secret
    if (secret !== process.env.REVALIDATION_SECRET) {
      return NextResponse.json({ error: 'Invalid token' }, { status: 401 })
    }

    const body = await request.json()
    const { _type, slug } = body

    if (_type === 'post') {
      // Revalidate specific post
      revalidateTag(`post-${slug.current}`)
      // Also revalidate the posts list
      revalidatePath('/blog')

      return NextResponse.json({
        revalidated: true,
        message: `Revalidated post: ${slug.current}`
      })
    }

    return NextResponse.json({ message: 'No action taken' })
  } catch (error) {
    return NextResponse.json({ error: 'Error revalidating' }, { status: 500 })
  }
}

```

## Measuring Performance
### Real User Monitoring with Vercel Analytics
```typescript title="app/layout.tsx"
import { Analytics } from '@vercel/analytics/react'
import { SpeedInsights } from '@vercel/speed-insights/next'

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />
        <SpeedInsights />
      </body>
    </html>
  )
}

```

### Server Timing for Request Analysis
```typescript title="server-timing-request-analysis.tsx"
async function fetchWithTiming(url: string, options = {}) {
  const start = Date.now()

  try {
    const response = await fetch(url, options)
    const data = await response.json()

    // Log timing info
    console.log(`Fetched ${url} in ${Date.now() - start}ms`)

    return data
  } catch (error) {
    console.error(`Error fetching ${url}:`, error)
    throw error
  }
}

```

## Image Optimization with Vercel
Next.js 15 with Vercel provides powerful built-in image optimization capabilities that significantly improve Core Web Vitals and user experience.

```typescript title="components/optimized-image.tsx"
import Image from 'next/image'
import { urlForImage } from '@/lib/sanity/image'

interface ImageProps {
  image: {
    asset: {
      _ref: string
    }
    alt?: string
    hotspot?: {
      x: number
      y: number
    }
  }
  width?: number
  height?: number
  sizes?: string
  priority?: boolean
  className?: string
}

export function OptimizedImage({
  image,
  width = 800,
  height = 600,
  sizes = '(max-width: 768px) 100vw, 800px',
  priority = false,
  className = '',
}: ImageProps) {
  if (!image?.asset?._ref) {
    return null
  }

  const imageUrl = urlForImage(image)
    .width(width)
    .height(height)
    .fit('crop')
    .auto('format')
    .url()

  return (
    <div className={`relative overflow-hidden ${className}`}>
      <Image
        src={imageUrl}
        alt={image.alt || 'Image'}
        width={width}
        height={height}
        sizes={sizes}
        priority={priority}
        className="object-cover"
        placeholder="blur"
        blurDataURL={`${imageUrl}&w=20&blur=30`}
      />
    </div>
  )
}

```

## Configuring Next.js Image Optimization
```typescript title="next.config.js"
/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    // Include project-specific domains for targeted optimization
    domains: [
      // Format: project-id.api.sanity.io
      'yourprojectid.api.sanity.io',
      'cdn.sanity.io'
    ],
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048],
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'cdn.sanity.io',
        pathname: `/images/${process.env.NEXT_PUBLIC_SANITY_PROJECT_ID}/**`,
      },
    ],
  },
}

module.exports = nextConfig

```

### Advanced Image Loading Strategies
```typescript title="components/image-gallery.tsx"

'use client'

import { useInView } from 'react-intersection-observer'
import { OptimizedImage } from '@/components/OptimizedImage'

export function ImageGallery({ images }) {
  // Implement progressive loading based on viewport visibility
  return (
    <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4">
      {images.map((image, index) => {
        // Use priority for the first visible image (LCP optimization)
        const isPriority = index === 0

        return (
          <LazyLoadedImage
            key={image._key || index}
            image={image}
            priority={isPriority}
          />
        )
      })}
    </div>
  )
}

function LazyLoadedImage({ image, priority = false }) {
  const { ref, inView } = useInView({
    triggerOnce: true,
    rootMargin: '200px 0px', // Start loading 200px before visible
  })

  return (
    <div ref={ref} className="aspect-w-16 aspect-h-9">
      {(inView || priority) && (
        <OptimizedImage
          image={image}
          priority={priority}
          sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
        />
      )}
    </div>
  )
}

```

### Integrating with Sanity CMS
```typescript title="lib/sanity/image.ts"
// lib/sanity/image.ts
import createImageUrlBuilder from '@sanity/image-url'
import { client } from './client'

// Create a configured Sanity image URL builder
export const imageBuilder = createImageUrlBuilder(client)

/**
 * Generates an optimized image URL from a Sanity image reference
 */
export function urlForImage(source) {
  if (!source?.asset?._ref) {
    return null
  }

  return imageBuilder.image(source)
}

/**
 * Helper to generate responsive image props
 */
export function getImageProps({ image, maxWidth = 2000 }) {
  // Calculate aspect ratio if dimensions are provided
  const aspectRatio = image.dimensions
    ? image.dimensions.width / image.dimensions.height
    : 16 / 9

  const width = Math.min(image.dimensions?.width || maxWidth, maxWidth)
  const height = Math.round(width / aspectRatio)

  return {
    src: urlForImage(image).width(width).height(height).url(),
    width,
    height,
    alt: image.alt || '',
    blurDataURL: urlForImage(image).width(20).height(20).blur(10).url(),
  }
}

```

### Runtime Optimization with Automatic Webp/AVIF Conversion
Vercel's Edge Network automatically serves optimized images in modern formats:

```typescript title="page.tsx"
// page.tsx
import { OptimizedImage } from '@/components/OptimizedImage'

async function fetchPostWithImage(slug: string) {
  const post = await client.fetch(`*[_type  "post" && slug.current  $slug][0]{
    _id,
    title,
    mainImage,
  }`, { slug })

  return post
}

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  const post = await fetchPostWithImage(slug)

  return (
    <article className="max-w-4xl mx-auto">
      <div className="aspect-w-16 aspect-h-9 mb-8">
        {post.mainImage && (
          <OptimizedImage
            image={post.mainImage}
            priority={true} // Optimize above-the-fold images
            sizes="(max-width: 1024px) 100vw, 1024px"
          />
        )}
      </div>
      <h1 className="text-3xl font-bold">{post.title}</h1>
      {/* Rest of content */}
    </article>
  )
}

```

---

## Thinking of jumping ship from WordPress?


> Ahoy, me hearties! Looking to jump ship from WordPress while the going's not so good, worried what the uncharted waters look like? Let's set your sail straight.

**Published:** 2024-10-21 | **Updated:** 2026-08-24 | **Categories:** Hot Takes, CMS
---

Right I'm not going to address the elephant in the room, there's obviously a lot of drama that's gone off, but I'm absolutely not going to address the actual drama, and I don't want to get dragged into it. That being said, I do want to give my opinions on WordPress after being a developer for over 10 years. A good few of those years were spent working with WordPress.

## What is WordPress?
If I had to hazard a guess, a lot of you would be on WordPress right now. It's the most popular CMS in the world, and supposedly makes up over 40% of all websites. I don't know if that's true, but it's probably close.

I'd also like to say, that to be fair to WordPress it was a very good tool *comparatively* to what was around when I started. It was far better than Joomla, Drupal, and even Typo3 *from my perspective*.

That being said, how many folks are still driving around in a horse and carriage?

## Why Consider a Change?
Before we start talking about my very opinionated hot-take and which route you should probably take, let's touch on why you might want to explore alternatives to WordPress:

### Plugins
Plugins are great, but they're also a massive security risk, and they also happen to be the reason the one remaining WordPress website we maintain (family friend's website) just stopped working.

They're non-standard, they're not really designed to be used in a modern tech stack, and they're a maintenance nightmare. You can guarantee that the moment you stop updating WordPress, your plugins will stop working and the more you have, the more likely it is that you're going to get a:

![It's a WordPress Error, it's the one that always comes up when you change the theme and it all goes to hell](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/thinking-of-jumping-ship-from-wordpress-blog-its-a-wordpress-error-its-the-one-that-always-come.png)

### Security
Have you ever seen a website, or hosting that has been utterly and truly hacked. Well we've never actually seen this outside of one occassion, guess what it was running.

## What should I change to?
Honestly, ***if you have a website that's under $10k***, then you're probably better off using something like Framer or Webflow. However, if you're looking at above $10k it's time to look at a tool like Sanity, [Next.js](/services/nextjs) & Vercel.

*Let's quickly brush over Framer/Webflow* so I can talk about the good stuff. Framer & Webflow are basically the same drag and drop website builders, but with Framer you get a bit more control over the code and from our testing, they typically perform better. The reason I recommend them under $10k is that they're easy to use and you can get a website up and running in no time and it's a pretty good result for what you're paying for. They won't necessarily scale, but they're great for getting something up and running quickly.

Now *if you're looking with a bit more of a budget*, this is where [Sanity](/services/sanity) really shines. Now let's get onto the good bit:

### Key Features
1. **Headless Architecture**: Sanity separates the content backend from the frontend. Why does this actually matter? Well because you pick what frontend you want to use. Much nicer than having to hack plugins on top of WordPress to get it to do modern development - I'm looking at you Timber.
1. **Customizable Content Studio**: Guess what, you don't have to see the regular WordPress dashboard. You can build your own editing environment tailored to your team's needs. Yeah, like actually. Fancy a full editing flow where it gets signed off at every stage? Yeah, you can do that.
1. **Real-time Collaboration**: Still get that warm little buzz when you see the little blue cursor going round editing your doc at the same time as someone else? Real deal, real-time editorial experience. It's almost like somebody built a CMS that was designed for the modern world.
1. **Powerful Query Language (GROQ)**: You might actually be looking into all the query languages right now. *Trust me, this one is it chief*. It's essentially GraphQL, but better. It scales really nicely as well.
1. **Versioning and History**: We've broken our own website a number of times, and we've been able to revert to a previous version. It's a godsend. You shouldn't be sweating bullets over making changes to key pages.
1. **Flexible Content Modeling**: Rememember the old adage of "measure twice, cut once"? Well, do that with your content models and thank us later. Think about how you'll scale them, enrich them with other documents and ultimately how you can repurpose and scale.
1. **API-first Approach**: Access your content via APIs, perfect for multi-channel publishing. Mobile app? Automation of emails? RSS feed? You better believe they're an API call away to integrate with your tech stack.

### There's a lot of buzzwords here, what does it actually mean?
Basically it's the best editorial experience on the web, as far as we're concerned. You're getting something where you can drag and drop content and get near instant feedback. You can scale it, you can customise it, you can basically do anything you want. ***But you have to build it right.***

This is where the real work comes in. You're going to need to build this with a good team. Here's the things to look out for, ask these questions:

1. Are you using the latest version of Sanity & Sanity Presentation?
1. Are you using the latest version of Next.js and the app router?
1. Are you using Tailwind CSS?
1. Are you using Typescript?

**If any of these are no, then run.**

With that said, if all the above are yes, then you're probably in a good place.

### Why is it more important than ever to get a good team?
Well a big distinction here is that WordPress is a monolithic framework, Sanity is a headless CMS. You can basically botch together a WordPress site with a few plugins and get something working, you can't do the same with Sanity & Next.js.

Truthfully, this isn't really a bad thing, but it's definitely worth knowing going in. The trade-off of this is that it's ultra resilient, and you can basically build and integrate anything you want. For perspective, we've got a website that we built when we first setup our business 7 years ago. It's fully functional, still scores in the late 80's/90's on lighthouse and we've never had to touch it.

## WordPress Cheat Sheet
*For things you've probably come across before, here's a quick reference guide for common WordPress features and their Sanity equivalents:*

- **Pages & Posts → Documents**: In Sanity, everything is a document that you can model however you want. No rigid distinction between pages/posts
- **Categories & Tags → References**: Use reference fields to create relationships between documents. More flexible than WordPress's taxonomy system
- **Featured Image → Image field**: Similar concept but with better image handling, cropping, and hotspot features built-in
- **Menus → Document type**: Create a dedicated document type for menus with references to your pages
- **Widgets → Components**: Build custom components instead of using widgets. More control, better performance
- **Plugins → NPM packages**: Instead of plugins, use NPM packages and custom code for functionality
- **Theme Customizer → Studio customization**: Build custom input components and validation in the Sanity Studio
- **Media Library → Asset Management**: Built-in CDN with image transformations, better organization
- **User Roles → Custom roles**: More granular control over permissions and roles
- **Comments → Not built-in**: Need to implement your own solution or use a third-party service like Disqus
- **SEO (Yoast) → Custom fields**: Create your own SEO fields or use packages like `sanity-plugin-seo-tools`
- **Forms → External service**: Use Formspark, or build your own solution (just use Formspark)
- **Search → GROQ queries**: Build powerful search functionality using GROQ, or integrate services like Algolia
- **Permalinks → Slugs**: Generate and manage slugs with more control and better internationalization support

Moving to a headless stack is a bigger shift than a one-to-one feature swap, but the performance and editorial benefits are significant. When you're ready to act, our post on [how to migrate from WordPress to Sanity fast](/blog/how-to-migrate-from-wordpress-to-sanity-fast) walks through the actual process step by step, and our [CMS migration service](/services/cms-migration) covers it end to end if you'd rather hand it off.

> **Headless CMS service**: Platform selection, migration, and training for teams leaving WordPress. [Learn more](/services/headless-cms)

---

## How our studio uses v0 to deliver quality, speed and performance


> Quality, Speed, Price. You used to only be able to pick two. I guess AI demolished that paradigm with the invention of v0

**Published:** 2024-10-02 | **Updated:** 2026-08-17 | **Categories:** AI, Vercel
---

## Introduction
We're going to let you in on a little secret. I think the days of building a website, completely from scratch, are numbered. I think, *in fact I know*, we're going to see a shift. Similar to what we've seen with frameworks taking away the need to write raw HTML, I think we're going to see the best development houses move towards a system where they can build websites using components and scaffold the fundamental routing. It's something we've done for the past few years at Roboto Studio, and I'm going to let you into another secret... We use AI extensively. *Oh, that wasn't really a secret, was it?*

## Give me the cliff-notes, I'm not going to read this whole thing anyway?
Okay, cool, go use Next.js, Tailwind CSS, Shadcn/ui, v0, and then you can pretty much build things like wildfire. *But stay tuned for the rest of the post, because I'm going to show you how we're using all of these tools to deliver projects that are not just good, but downright extraordinary.*

Vercel also had us on their first ever community session to talk through this exact workflow, with real examples: an investment firm site and a financial calculator, built without touching a traditional design tool.

## What is v0?
Oh did I get your attention? I'm sorry. v0 is the new tool, from the folks at Vercel. It essentially acts like a chatGPT interface for generating user interfaces. *That's really underselling it though* because it's a tool that can take your idea all the way through to a production-ready component. I'm serious, we've built the foundations for an entire website with this tool, and spent the time we would have spent on manually implementing the components on actually building new and innovative things.

The real beauty is that it goes beyond Next.js, Tailwind CSS, Shadcn/ui. It's able to pull in libraries, but anything it builds is accessible by default, and where possible server-side rendered if it suits. So you can actually rely on it to build things like charts, or even entire pages, and it'll be accessible and performant.

## How does it fit in your workflow?
Well, we've got a few different stages that it's pretty much removed days of work from. *I'm not joking.*

### Ideation
In the old days, we'd typically sit down with the client and discuss the requirements. We'd scribble down some sketches, bounce around some ideas and then start to form a picture of what the website was going to look like. We'd then go back to the office and start to put together a plan. All in all, this process takes a good few days and involves several people.

Now, we start with the same conversation but we use v0 to bounce around ideas. We'd actually build it right there and then with them, rule out ideas that aren't going to work and refine the ones that are. This process, while still requiring a human to some extent, is a fraction of the time it used to take.

### Prototyping
Multi-step forms? Mortgage calculators? Chat interfaces? You're shifting away from meticulously wireframing this inside of figma, manually dragging prototype components together. No, you're using v0 to generate the structure, and then you're using the component to build out the interactive prototype. This is where the true magic of v0 happens. You can generate entire user journeys, complete with custom logic - not the same bullshit where you end up having to make 4 different artboards to show success, failure, validation and hover states. No, you can just generate it all, and the kicker - it's accessible by default, so we don't even have to think about those states.

### Implementation
At this point you're actually taking the prototype and pulling in real-world data. For example a recent one was involving pointing a form into a real-world Formspark API, to see if multi-step forms actually worked. They did, and more impressively still, v0 actually one-shotted it.

The fact that you can pull in a damn good range of libraries and frameworks from elsewhere is a huge boon. Hell, we might even give away which website was built with v0 by saying "Wow, matter.js is so cool, I wonder if we can make it rain objects?".

## Let's talk design tokens
If you're not familiar with design tokens, they're a way of standardising design decisions across a website. Instead of having to manually set colors, font sizes, and spacing, you can use design tokens to ensure consistency. If you're already using Tailwind CSS or shadcn/ui, you're already using design tokens.

It's important because it actually takes decisions away from having to be made on a per-item basis. If you've ever asked your designer what hex code we use for the hover state and their response was "What hover state? Just a transparency on it", you've experienced the pain of not having design tokens.

We actually recommend a really nice tool from Simeon Griggs called [tints.dev](https://www.tints.dev/palette/v1:Ymx1ZXwzQjgyRjZ8NTAwfHB8MHwwfDB8MTAwfGE). This helps you to design accessible color palettes, and then you can just use the tokens in your code.

![Screenshot of a v0 theme generator interface. The left panel shows options to edit the theme, including font selection, color settings, and a button labeled "Generate Theme." ](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-our-studio-uses-v0-blog-screenshot-of-a-v0-theme-generator-interface-the-l.png)

> **Pro tip: **go and use the [old v0 theme builder](https://v0.dev/themes), and feed these design tokens into the generation of v0 UI to get a more custom-looking interface.

## What importance do these have in relation to v0?
Well, my expectation is that at some point there's going to be a shift towards storing these design tokens as a remote env token that can be pulled into your v0 prompts, your local cursor ai, and anything else that needs it. I think instead of having disparate tools, that each have their own variables or tailwind config, you'll just have one source of truth.

My guess will be at some point, v0 will get something similar to this, and we're going to really kick it up a notch with getting generative UI that looks exactly like the designers website. Hell, we may even be able to rip it straight from the website itself. *Man,* just writing this, is making me think we should build a scraper tool for this.

> **Next.js app development**: AI-assisted development, v0 workflows, and production Next.js builds. [Learn more](/services/nextjs)

## Okay, let's dispel some myths
Well, I'll keep it simple. I think you're literally missing out as a client or as an agency not utilising AI in web development.

> But surely you're paying money for old rope if the AI is just going to write the code for you?
No, you're not. What you're getting is the equivalent of a forklift. It takes away menial tasks as a developer and frees up your time to focus on more complex problems. Why would you ask a builder not to use a wheelbarrow when they're transporting bricks? You've got to do it manually one brick at a time.

## What do we spend our new found time on?
More user testing, for a start. When component assembly stops eating the budget, we can dig into how people actually use the site and build the UX details that normally get cut: better empty states, faster search, interfaces that make sense on the first visit.

Performance gets the same treatment. Caching strategy, asset optimization, and the fine-tuning that keeps load times quick on a mid-range phone, not just a dev machine. v0 gives you a decent accessibility baseline out of the box, and the saved hours go into pushing past it rather than scrambling to meet it.

The rest of the time lands on work clients can feel: custom features like site search or bespoke e-commerce flows, proper security testing, content strategy and SEO that's grounded in what their audience searches for, and enough training that the team we hand over to can run the site without ringing us every week.

## The future
If you haven't guessed it already, you're going to see a night-and-day shift between agencies that are embracing AI and those that aren't. If you aren't already generating internal content that can be used for training data for AI, you're already behind. It's going to create a flywheel effect, and those that get on board will be able to deliver websites that are not just good, but downright extraordinary.

If you're trying to position your clients or your agency for the future we would highly advise you start looking to migrate over to Tailwind CSS, as the first step. From that point implementing shadcn/ui, and then finally looking to v0 as the next step. If you're looking to do this migration, we're more than happy to help - just [drop us a message](/services/nextjs). There's some strategies we've developed that can make the process easier.

---

## Creating the perfect array thumbnails


> Are you using the new thumbnails for Sanity, and want to speed up your whole screenshot process. We've got the perfect tool for you.

**Published:** 2024-08-13 | **Updated:** 2026-08-24 | **Categories:** Sanity
---

You know some folks really get hell-bent on something minor, and it's very difficult to stop your brain from whirring away to try and find a better, faster, easier solution to a problem. Unfortunately, I am that person. We've been getting bothered by the perfect thumbnail for page builder arrays from as soon as they came out. Before I jump in the deep-end, I first want to dedicate this blog post, to a lovely comment on YouTube.

So you may or may not know we have a [YouTube channel](https://www.youtube.com/@robotostudio), it's only 20-something subscribers at the time of writing, but we really appreciate every comment and lovely message we receive (and we do read every one).

We got a great comment from [@amranmohamed377](https://youtube.com/@amranmohamed377) who told us about `3:2` being the perfect aspect ratio. With that being said, we wanted to throw some free stuff back and build something useful for the community. Which is why we created this [Figma community file](https://www.figma.com/community/file/1404904715260176924/arrayfield-template-for-sanity) to easily build.

## Quick note
You can build these thumbnails within Figma at the time of creating your wireframes. However, I do typically find that the easiest way and most accurate for clients to get a 1:1 representation of what it will look like is to use the website itself.

It also speeds the entire process up significantly and stops you from getting questioned on: *"why the hell did you spend a day and half to create pixel-perfect thumbnails for our page builder"*

## I got the community doc, now how do I use it
Well lucky for you we actually have a video in the section below, but for the sake of brevity, I'm going to list out the steps (and definitely not for SEO purposes).

1. [Clone the Figma community file](https://www.figma.com/community/file/1404904715260176924/arrayfield-template-for-sanity) to your local workspace
1. You open up the URL for your website development environment
1. You zoom out to a good size by pressing `⌘ -` or `⌘ +`
1. Take a screenshot of the block trying to get roughly 3:2 ratio
1. Go to the figma file
1. Click the checkerboard artboards and hit `⌘ + v`
1. If the image isn't good, retake the screenshot or play with [Figma crop](https://help.figma.com/hc/en-us/articles/360040675194-Crop-an-image)
1. Once you're happy export matching name of block in Sanity

## Now watch the video
Yes it was hot, yes we don't have an aircon in the recording room. The lengths we go to, to make sure you have good thumbnails.

## Update: there's now a Claude Code skill for this

Since this post went up we've automated the whole flow, no Figma step or manual screenshots required. If you'd rather skip the screenshotting altogether, read [How to automate creation of Sanity thumbnails](/blog/automate-sanity-thumbnails).

> **Sanity CMS development**: We set up schemas, page builders, and editorial workflows that your content team will actually enjoy using. [Learn more](/services/sanity)

---

## A really nice Mux video component


> Finding the best way to host video with Mux and Sanity? Well we've got the fastest possible way to get them working together

**Published:** 2024-08-08 | **Updated:** 2026-08-24 | **Categories:** How To, Next.js
---

You might have come across some of the videos on our website and thought: "Gee wowsers, they’re still hitting near perfect performance scores in Lighthouse". Well, let me tell you: ***it was a struggle***.

However, the good news is, today we want to share what took us far too long to perfect, and give you the opportunity to use Mux yourself, without tanking performance with the Mux Player.

It's also worth mentioning that the [Mux player](https://www.mux.com/player) has more compatibility and better video experience (see [Feedback from Dylan Jhaveri](#feedback-from-dylan-jhaveri) for more context) but frankly, I'm fairly certain folks aren't browsing our website on IE8, nor do we want to build for IE8, so this is the compromise we are willing to make (sorry dinosaurs).

## The code
```typescript
'use client';
// Swap these out for another icon set if you want
import { Loader2, PlayIcon } from 'lucide-react';
// To dynamically load the video player
import dynamic from 'next/dynamic';
import { FC, useState } from 'react';
import { preload } from 'react-dom';
// This is from Sanity type generation
import { MuxVideo, Video as VideoType } from '~/sanity.types';

const getVideoToPlayUrl = (muxId: string) => {
  return `https://stream.mux.com/${muxId}.m3u8?min_resolution=1080p&rendition_order=desc`;
};

const getPosterUrl = (muxId: string) => {
  return `https://image.mux.com/${muxId}/thumbnail.webp?fit_mode=smartcrop&time=0`;
};

const getMuxVideoProps = (muxId: string) => {
  return {
    poster: getPosterUrl(muxId),
    vidUrl: getVideoToPlayUrl(muxId),
  };
};

type VideoPlay = {
  poster: string;
  vidUrl: string;
  loop?: boolean;
  muted?: boolean;
  control?: boolean;
};

const VideoAutoPlay = ({ control, loop, muted, poster, vidUrl }: VideoPlay) => {
  const HlsVideo = dynamic(
    () => import('./hls-video').then((mod) => mod.HlsVideo),
    {
      loading: () => {
        return (
          <div className="relative size-full">
            {/* eslint-disable-next-line @next/next/no-img-element */}
            <img
              src={poster}
              // Pick your most commonly used video size to avoid CLS
              width={1920}
              height={1080}
              alt="a"
              className="mx-auto  size-full "
            />
            <div className="absolute left-1/2 top-1/2 -translate-x-1/2 -translate-y-1/2 transform ">
              <Loader2 className="animate-spin" size={112} strokeWidth={0.5} />
            </div>
          </div>
        );
      },
    },
  );
  return (
    <HlsVideo
      autoPlay
      poster={poster}
      vidUrl={vidUrl}
      loop={control ? loop : undefined}
      muted={control ? muted : undefined}
      controls={control}
      width={1920}
      height={1080}
      className="mx-auto size-full"
    />
  );
};

const VideoWithOutAutoPlay = (
  props: VideoPlay & { loading?: 'lazy' | 'eager' },
) => {
  const { poster, loading } = props;
  const [play, setPlay] = useState(false);

  return (
    <div className=" size-full">
      {play ? (
        <div className="relative size-full ">
          <div className="my-4">
            <VideoAutoPlay {...props} />
          </div>
        </div>
      ) : (
        <div className="relative size-full">
          {/* eslint-disable-next-line @next/next/no-img-element */}
          <img
            src={poster}
            width={1920}
            height={1080}
            loading={loading === 'lazy' ? 'lazy' : 'eager'}
            alt="a"
            className="mx-auto  size-full "
          />
          <div className="absolute left-1/2 top-1/2 -translate-x-1/2 -translate-y-1/2 transform ">
            <button
              className="grid place-items-center rounded-full bg-black p-8 hover:bg-hotpink-400"
              onClick={() => setPlay(true)}
            >
              <PlayIcon className="h-8 w-8 fill-white text-white" />
              <span className="sr-only">Play</span>
            </button>
          </div>
        </div>
      )}
    </div>
  );
};

export type VideoProps = VideoType & {
  videoEmbed: NonNullable<VideoType['videoEmbed']> & {
    video: MuxVideo & {
      asset: {
        playbackId: string;
      };
    };
  };
};

export const Video: FC<VideoProps & { loading?: 'lazy' | 'eager' }> = ({
  videoEmbed,
  loading = 'eager',
}) => {
  const { video, autoPlay, control, loop, muted } = videoEmbed ?? {};

  const { poster, vidUrl } = getMuxVideoProps(video?.asset?.playbackId);

  preload(vidUrl, {
    as: 'video',
    fetchPriority: 'high',
  });
  preload(poster, {
    as: 'image',
    fetchPriority: 'high',
  });

  const videoProps = { poster, loading, vidUrl, loop, muted, control };

  return (
    <div className="mx-auto flex max-w-7xl">
      {control && autoPlay ? (
        <VideoAutoPlay {...videoProps} />
      ) : (
        <VideoWithOutAutoPlay {...videoProps} loading={loading} />
      )}
    </div>
  );
};

```

## Performance improvements
Well remember how there was some bloke called Charles Goodhart said: "When a measure becomes a target, it ceases to be a good measure". Well we basically ignored everything that person said, and decided to optimise to see if it was possible to hit 100/100 on a website that still has a lot of images, fancy libraries and analytics.

If you're looking to try and get the perfect score on your website, get in touch with us. We sure as hell know a lot about this stuff after all the hassle we've been through.

> **Next.js development**: We build fast, well-architected Next.js apps. Performance included. [Learn more](/services/nextjs)

## A quick explainer what this is good for

## Feedback from Dylan Jhaveri
> We posted this on [Vercel Community](https://vercel.community/t/a-really-really-good-mux-component/547), and got some great feedback and better context. So, before you go ahead and straight up copy the code without knowing the tradeoffs make sure you read this bit.
"Love the work you’ve done in your example to optimize for lighthouse score. There is a fundamental tradeoff here that I think folks should think about:

web vitals (lighthouse score) vs. video performance

The biggest change that I can see, if I’m following correctly is waiting to load `<hls-video>` until after the user clicks play.

That’s going to make your lighthouse score great, (which is great!) – but the tradeoff is that when the user clicks play it’s going to take more time for playback to start and the user to see the first frame of the video.

For your use case on roboto.studio I think that probably makes perfect sense. For other use cases where you want the video to load fast you may want to lazy load the player 2 (https://www.mux.com/docs/guides/player-lazy-loading), which tries to balance the tradeoffs:

- Doesn’t block the initial page load (despite this, your lighthouse scores will be impacted negatively)
- Lazy loads the player without requiring the user to click play so that when the user does click play the video starts up immediately"

> Cheers Dylan, and thanks for the free content. [Go read his blog posts here](https://www.mux.com/team/dylan-jhaveri)

---

## The only Sanity page-builder guide you'll ever need


> Wake up, it's 2025 and we need to build the best page builder we possibly can, where do we start, what is the code. Can I just copy your code?

**TL;DR:** Page builders suck, but Sanity's don't. Organize blocks, see previews, collaborate in real-time, and use flexible APIs. Use ?? for null checks. Try array groups and views. Seriously, read the docs next time. Or just let someone else handle it if you're too lazy.

**Published:** 2024-07-09 | **Updated:** 2026-07-23 | **Categories:** Sanity, How To
---

I'm going to start this article by placing a bet that you've ***absolutely*** used a page-builder of some kind before. Let me fire off some quick opinions and tell me if they resonate.

- They're hard to maintain
- I can never find the block I want
- Surely this can be more efficient

**_Yeah_**, I know, that's basically most of the experiences we've heard from clients. We want to change that by putting together this [blog](https://robotostudio.com/blog) so I can scream at developers the next time I see a disorganised mess for a page builder.

## Why Sanity page builders don't suck
## The best opinion (my opinion)
I'm going to take a leaf out of [Simeon's book](https://www.sanity.io/docs/developer-guides/an-opinionated-guide-to-sanity-studio), and give you my opinions on page builders, and don't worry, they're unquestionably right and not to be disputed.

Here's how you should structure your previews in page builders

![Setting up previews with Sanity Studio](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-only-sanity-page-builder-guide-youll-ever-need-blog-setting-up-previews-with-sanity-studio.jpg)

### How does this look in code?
Well, assuming you've called the title: `title` and your image field `image`This is the exact way I would set up a preview inside the code.

```typescript
  preview: {
    select: {
      title: 'title',
      media: 'image',
    },
    prepare(selection) {
      const {title, media} = selection
      return {
        title: title ?? 'Currently no title, set one inside this block',
        subtitle: 'Split Image',
        media: media ?? ImageIcon,
      }
    },
  },
```

### What are those `??` about?
If you haven't seen those before, or you have seen them and you don't know what the difference is between those and `||` I'll let you in on a little secret *that's definitely not generated from ChatGPT*...

- `||` is the logical OR operator, returning the right operand if the left operand is falsy.
- `??` is the nullish coalescing operator, returning the right operand only if the left operand is null or undefined.

Use `??` to specifically check for null or undefined values, ensuring that other falsy values like `0` or `''` are not considered as missing values.

Or, in other words, because this asshole told me to use them.

![Some developer we let live in our head rent free from LinkedIn called Joey Clover](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-only-sanity-page-builder-guide-youll-ever-need-blog-some-developer-we-let-live-in-our-head-rent-free-f.png)

> Joey if you're reading this, I hope you're happy
## Let's start with the new stuff
Before going further, let's talk about some of the new stuff that [Sanity](/services/sanity) released that makes your page builder a bit better.

### Array groups
[Read the docs](https://www.sanity.io/docs/studio/array-type#4fb380bc3722)

This lets you split your page builder blocks (`arrays of blocks`) into groups. It means if you want to split out `Forms` and `Heros.` You can easily do it with some basic code.

Here's how it looks in the Sanity Studio:

![Showing the array groupings on light mode. Honestly who even uses light mode in this day and age](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-only-sanity-page-builder-guide-youll-ever-need-blog-showing-the-array-groupings-on-light-mode-honestly.png)

And here's the code to do that:

```typescript
{
  insertMenu: {
    groups: [
      {
        name: 'intro',
        title: 'Intro',
        // Here's where your blocks go to filter by intro
        of: ['hero'],
      },
      {
        name: 'storytelling',
        title: 'Storytelling',
        // Here's where your blocks go to filter by storytelling
        of: ['byTheNumbers']
      },
      {
        name: 'upsell',
        title: 'Upsell',
        // Here's where your blocks go to filter by upsell
        of: ['testimonials', 'hero'],
      },
    ],
  },
}
```

Fun fact: you can have a block in more than one grouping. It's pretty cool, for example, when you want a `form` block in both `Forms` and `Engagement`.

### Array views
[Read the docs](https://www.sanity.io/docs/studio/array-type#efb1fe03459d)

I know what you're thinking. Yeah, the above is pretty cool, but I still don't know what the ***hell*** my page builder block looks like, and it doesn't look like a 24px by 24px icon.

*Well, first of all*, you'd be right. Second of all, you now have something called `array views`. ***Yes***, they're everything you're asking for.

They allow you to see a whole bunch of blocks at once with thumbnails. Here's the visuals that ***aren't ripped straight from the docs***

Here's how it looks in the Sanity Studio

![Array thumbnails looking pretty darn slick - you can see what you're going to drop into the page because of the chunky thumbnail](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-only-sanity-page-builder-guide-youll-ever-need-blog-array-thumbnails-looking-pretty-darn-slick-you-can.png)

And here's the code to do that

```typescript
{
  insertMenu: {
    // You don't have to use groups, just left them in
    groups: [
      {
        name: 'intro',
        title: 'Intro',
        of: ['hero'],
      },
      {
        name: 'storytelling',
        title: 'Storytelling',
      },
      {
        name: 'upsell',
        title: 'Upsell',
        of: ['testimonials', 'hero'],
      },
    ],
    views: [
      {name: 'list'},
      // This is the important bit
      {name: 'grid', previewImageUrl: (schemaTypeName) => `/static/preview-${schemaTypeName}.png`},
      // Remember you can create a folder called 'static'
      // In the root of your Sanity folder
    ],
  },
}
```

> **Sanity CMS development**: Page builders, schema architecture, and editorial workflows your content team will actually enjoy. [Learn more](/services/sanity)

#### Pro tip: Use the same size canvas
Before you set this up, do everybody a favour and use the same size canvas for every screenshot, or else you're going to have a monstrosity of a visual representation of a block.

A nice, simple, and free way to handle this is to create a frame inside Figma and paste the screenshot into it, ensuring they are all the same height and width.

## See it in action
It's not recycling content if nobody watched the video the first time round... So here it is again, packaged into a [blog](https://robotostudio.com/blog). Please watch it.

## Closing thoughts
I don't want to take you away from actually trying this yourself, so I implore you to stop reading this content and actually spin up Sanity and do this for your clients today. You will not believe the UX improvement from just integrating these changes above. If you want to go deeper on schema organization, check out our [tips for building Sanity schema efficiently](/blog/tips-and-tricks-for-building-sanity-schema-efficiently), and if your GROQ queries are getting out of hand, we have a guide on [how to clean up your GROQ](/blog/clean-your-groq).

*If, on the other hand,* you can't be arsed and want somebody to "*just sort it out for you,"* you can get in touch with the form below and we'll get you looking ship-shape in no time.

---

## Building a search bar with Sanity Embeddings Index API & Next.js


> Learn how to build a search bar using Sanity's Embeddings Index API & Next.js. This tutorial guides you through creating a dynamic, API-driven search component.

**Published:** 2024-05-13 | **Updated:** 2026-07-23 | **Categories:** Sanity, Next.js
---

## Introduction
We've been wanting to tinker with Sanity's Embeddings Index API for a long time. We've also been toying with the idea of using it as a search bar too. So guess what we did.

Sanity Embedding is essentially a pretty powerful, AI-powered semantic search for your content. It uses embeddings, which are simplified vector representations of your documents, and  can retrieve content based on meaning and context rather than just keywords.

So with that out the way, let's walk through how to create a search bar in a Next.js application that utilizes Sanity's Embeddings Index API. We'll cover the key steps including:

- Setting up an embeddings index for your Sanity dataset
- Configuring the Embeddings Index API in your Sanity project
- Building a search bar component in Next.js that queries the embeddings index
- Displaying the relevant search results to users

By the end, you'll have a fully functional semantic search experience that allows users to find the most relevant documents based on their search queries.

Whether you want to provide an intelligent search interface for your [blog](/blog), documentation, or any other type of content, Sanity's Embeddings Index API makes it straightforward to implement.

## Setting up an embeddings index
To set up an embeddings index in Sanity, you have two main options:

1. **Using the Sanity Studio UI**:  
  - Go to your project's Sanity Studio.
  - Navigate to the "Embeddings" section.
  - Click on "Create new index".
  - Configure the index by specifying the dataset, projection, and other settings.
  - Save the index configuration.
1. **Using the Sanity CLI**:  
  - Install the Sanity CLI if you haven't already.
  - Run the command `sanity init` to initialise a new Sanity project or you can use an existing one
  - Use the `sanity embeddings create` command to create a new embeddings index.
  - Provide the necessary configuration options such as dataset, projection, etc.
  - The CLI will create the embeddings index based on your configuration.

For detailed instructions on setting up an embeddings index using the CLI, you can refer to the Sanity documentation.

Once you have created the embeddings index using either method, Sanity will process your documents and generate the embeddings. The index will be ready to use for semantic search and other applications.

In the next section, we will focus on configuring the Embeddings Index API in your Sanity project to enable querying the index from your [Next.js](/services/nextjs) application.

## Adding Search to Next.js
To add search functionality to your [Next.js](/services/nextjs) application using Sanity's embeddings index API, you need to implement three main components: 

1. Creating a search box.
1. Creating an API endpoint to handle the query.
1. Showing results to the client.

### Search Box
To create a search box component in your Next.js application, you can use a simple input field. Here's an example of how you can implement a basic search box component:

```typescript
// ~/components/search
export const SearchBox: FC = () => {
  const [query, setQuery] = useState("");
  return (
    <div className="ml-auto w-full md:w-auto">
      <div className="relative flex-1 flex-grow">
        <Search className="absolute left-2.5 top-2.5 h-4 w-4 text-muted-foreground" />
        <Input
          type="search"
          placeholder="Search..."
          onChange={(e) => setQuery(e.target.value)}
          className="w-full rounded-lg bg-background pl-8 md:w-[336px]"
        />
      </div>
    </div>
  );
};
```

### API Endpoint
To create an API endpoint you can start by creating `/api/search/route.ts` file and add business logic in it. The logic for the search endpoint consists of two main components:

1. Getting embeddings results from Sanity that match the vector of the search query and return the corresponding document IDs.
1. Retrieving the actual documents from Sanity using the obtained document IDs.

> **Security Note:** The Sanity API token used in these examples must be kept server-side only. Never expose it to the client. The token should be stored in environment variables and only accessed within API routes or server actions.

Here is the code snippets for both functions:

```typescript
const getEmbeddingResult = async (query: string, token:string) => {
  const response = await fetch(SANITY.SANITY_EMBEDDINGS_INDEX_URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${token}`,
  },
  body: JSON.stringify({
    query,
    maxResults: 5,
    filter: {},
  }),
});

  if (!response.ok) {
    throw new Error(response?.statusText);
  }

  const data = (await response.json()) as EmbeddingIndexResponse[] | undefined;

  if (!Array.isArray(data)) return [];

  return data.map((item) => item?.value?.documentId).filter(Boolean);
};

const getSanityDocuments = async (ids: string[], token:string) => {
  const groqQuery = `*[_type == 'article' && _id in ['${ids.join("', '")}']] {
    _id,
    title,
    "slug":slug.current,
    date
  }`;

  const queryUrl = `${
    SANITY.SANITY_DOCUMENT_QUERY_URL
  }?query=${encodeURIComponent(groqQuery)}&returnQuery=false`;

  const sanityDocs = await fetch(queryUrl, {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${token}`,
    },
  });

  if (!sanityDocs.ok) {
    throw new Error(sanityDocs?.statusText);
  }
  const sanityDocsData = (await sanityDocs.json()) as
    | SanityDocumentResponse
    | undefined;

  if (!Array.isArray(sanityDocsData?.result)) return [];

  const _docs = sanityDocsData?.result ?? [];

  // preserving order of the embeddings
  const documentMap = new Map<string, SearchEmbeddingResponse>();

  _docs.forEach((doc) => documentMap.set(doc._id, doc));

  return ids
    .map((item) => documentMap.get(item))
    .filter(Boolean);
};
```

> **Sanity CMS development**: Embeddings, search, and Sanity API integrations for content-rich applications. [Learn more](/services/sanity)

### Showing it to the user
To display the search results to users, in a user-friendly manner, we can use React Query. React Query simplifies the process of fetching, caching, and managing the state of the search results. It also takes care of the heavy lifting, allowing you to focus on presenting the search results in an intuitive and visually appealing manner.

When the search results are fetched from the API, React Query automatically caches them on the client-side. This means that if the user performs the same search again, React Query can serve the cached results instantly, providing a faster and more responsive user experience.

Here's a custom hook we made using react query

```typescript

const fetchArticleSearch = async (q: string) => {
  const response = await fetch('/api/search', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ query: q }),
  });
  if (!response.ok) throw new Error(response?.statusText);
  return ((await response.json()) as SearchEmbeddingResponse[]) ?? [];
};

type UseArticleSearchProps = {
  query: string;
};

export const useArticleSearch = ({ query }: UseArticleSearchProps) => {
  const debouncedQuery = useDebounce(query);
  const result = useQuery({
    queryKey: ['some-unique-key', debouncedQuery],
    queryFn: () => fetchArticleSearch(debouncedQuery),
    retry: 0,
    enabled: !!debouncedQuery,
    refetchOnMount: false,
    refetchOnWindowFocus: false,
  });
  return {
    ...result,
    debouncedQuery,
  };
};

```

Finally we can use data returned from  `useArticleSearch` on our search result.

## Search in action

---

## Our initial thoughts on Sanity Create


> Getting our hands on Sanity Create, and using it to actually structure the very article you're reading right in front of you.

**Published:** 2024-05-08 | **Updated:** 2026-07-23 | **Categories:** Hot Takes, Sanity
---

I'll let you in on a secret. Internally, we had a bet as to what this new tool was going to be. We had a whole bunch of wild theories and read some twitter threads that made us even more curious. We've graded each of the theories below to name and shame.

> "Schema generation through AI"
~Hrithik
- Not close at all, at least he mentioned something about AI
- **Grade: D-**

> "Document generation with AI"
~Shreyas
- Pretty much *bob on the money* great job
- **Grade: A+**

> "A Marketing tool that improves user experience when writing articles"
~Sne
- Somewhat close to the mark, but *no mention of AI*
- **Grade: B+**

> "Sanity notion type thing, away from publishing, more on planning, organising content better inside a tool"
~Jono
- Are you even trying? See me after-school for more homework
- **Grade: F-**

*Now that public shaming is out of the way*, let's move onto the actual experience of writing inside of Sanity Create.

## Hello world
The first time you setup an article you're greeted with this:

![Sanity Create quick start guide](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-initial-thoughts-on-sanity-create-blog-sanity-create-quick-start-guide.png)

This gives you a great primer into some of the functionality that Sanity Create gives you. Honestly, this is one of the few quick start guides that I actually would read from start to finish, it gives you a quick run down and, *more importantly*, gets you to actually action some of the functionality you would use.

## Ghostwrite
Okay, this is probably what you're all here for. Ghostwrite is an ever-present little dot to the right of your current line. Think HAL-3000 but for writers block. What's really cool about it is that if you're stuck on a specific sentence and struggle to finish it... `you can just place your cursor where you want the AI to continue from and it will generate a relevant continuation for you` (this was written by Ghostwrite).

I imagine you can already guess why this is so powerful. However, you may not know what AI models are powering this. Now I assumed it would be something  boring like GPT, but it's actually Anthropic's `opus` and `haiku` models. For those of you who don't recognise the two names, Opus is the smart but expensive one and Haiku is better for simpler tasks. My guess is they're using the simpler one for the ghostwrite expanding functionality (when you hit `CMD + .`) on a piece of text, and the more comprehensive one for significant chunks of AI generation.

## Notes
Notes are your method of opinionating the ghostwrite. For example you can throw together a note of currently six different categories.

1. No category
1. Fact
1. Context
1. Style
1. Inspiration
1. Ignore

From what we can tell there are two main functions of these notes:

1. For your ***human*** editors it's basically just a virtual sticky-note, which helps them organise and categorise the context of their writing
1. For your ***Ghostwriter***, it's a whole god-damn data bank of information that's going to opinionate the way it helps you with your writing, think better predictions, closer to your companies copywriting style. Scary.

There's more functionality you can squeeze out these notes, but realistically you'll probably use them to:

1. Write up a tone of voice document that you can feed into the AI itself so it sounds more like your company's brand
1. Referring back to company assets when stuck on a mental block
1. Virtual post-it notes for important points relating to the article
1. Office locations, company VAT numbers, who is the head of the IT department, boring stuff like that

> **Sanity CMS development**: Sanity Create, AI workflows, and content infrastructure built for your editorial team. [Learn more](/services/sanity)

## What we loved

I especially appreciate the "Zen Mode" functionality. You can either grab or click the sidebar and it'll shrink to leave you with near enough nothing on the screen. It's a nice touch. 

You can start Ghostwriting with `CMD + .`. It feels natural, and if you want to continue writing with AI all you have to do is hit tab.

Here's the notes in all their glory. Don't worry, your AI assistant read them before you did... They're also fluent in basically every language in the world. Feeling threatened yet?

## What we want improved
- Because we started writing this article on the way back, on a train from London, and the network was absolute garbage, I think some sort of continuity to retain data in patchy signal - wouldn't go amiss.
  - *Or you know - the UK could actually sort it's signal coverage out... But I know which one is more likely to happen.*
- We already know that it's on its way, but the sooner you can directly publish from Sanity Create to Sanity Studio, the happier I'm going to be as an editor.

![Publish to Sanity schema](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-initial-thoughts-on-sanity-create-blog-publish-to-sanity-schema.png)

## What the future holds
As Sanity Create continues to evolve, we expect to see a hell of a lot more integrations. I'm curious as to how they're going to solve media sharing between the two platforms. My guess is, that at some point this writing functionality is going to overhaul the portable text completely and we'll actually have this functionality directly inside of [Sanity Studio](/services/sanity).

Either way, the smoother the experience is between - writing, ideation and actually pushing it out there - the easier it is to adopt this as the baseline for all your content workflows. It's an incredible start towards a more contextually curated, less shallow AI editorial experience, *not just another ChatGPT wrapper*.

---

## How to migrate from WordPress to Sanity fast


> Migrating to a different tool can be hard to adopt, but we are here to make it easy for you. Get to know the fundamental changes and structure of using sanity and ship content faster

**Published:** 2024-03-05 | **Updated:** 2026-08-24 | **Categories:** How To, Sanity
---

It's 5:01pm, and you've just pushed a change to your [WordPress](/migration/wordpress-to-sanity) local environment. It all works, and looks lovely. This beauty is ready to be put out into the real world... You deploy it, you wipe the sweat off your brow and you're free to go for your weekend jamboree or whatever normal people do.

**Oh wait...**

![A dog who's soul has left his body at 5:02pm](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-migrate-from-wordpress-to-sanity-fast-blog-a-dog-whos-soul-has-left-his-body-at-502pm.jpg)

It's not your fault, it happens to the best of us. But shouldn't there be a better way? A way where you can run a fully functional CI/CD without the need for juggling multiple databases, in multiple environments. We think so, and we want to show you how.

## Covering some of the basics
Sanity **isn't** a monolithic platform, it's a "bring your own" frontend. What this means is you can throw in whatever frontend platform you want and the [headless CMS](/services/headless-cms) will play nice. Whether that's Next.js, Remix, Astro, it will all work (however this tutorial is specifically aimed at [Next.js](/services/nextjs) because it's our personal favourite).

## Why bother?
It could be that you just got fed up with all the bloat on your WordPress site, and you're itching to move away from it. Or you're testing the waters with a shiny new toy. Here's why I would migrate:

- No more database management in dual environments
- No more being locked out of documents, with real-time multiplayer document editing
- No more managing Localwp or MAMP
- Real time previews (like *real*-real-time)
- Faster development & better DX
- Less plugin proliferation
- No pay-for-plugins
- You don't have to act like a WordPress hosting reseller

*There's a lot more but I'm not going to bore you, *so just know that it has a slightly higher skill-floor, but a much, ***much*** higher pay-off if you're willing to learn.

Remember, the migration of the data is only one aspect of moving from your current stack. It's important to ensure you're structuring it well enough so your editors have a breeze editing and adding new content. Making sure your content team enjoys using it is going to pay dividends... Trust us.

Here are some useful tips to migrate your data, and an example of fundamental changes related to managing your site with Sanity.

## Say goodbye to Gutenberg
WordPress has a GUI *designer plus editor* approach where it can get confusing for a new editor on how to get something added, like a CTA section below a certain [blog](https://robotostudio.com/blog). It makes it difficult because there are massive in-built opinionations as to how something is laid out.

Unless you absolutely know what you are doing, this will not scale well down the line with hundreds of posts and different site pages.

In Sanity, we structure it in a different way. It's more of a directive approach. The editor declares what goes where and the frontend handles the rest. Albeit the editor does not have full design control of a section but for most cases that's a good thing. We like to call it "*designing on rails*".

We do not want someone to sit and think about designing a section and decide what goes where, having a design system ready and just toggling things on the CMS is effective enough to ship things faster.

In the **Page Builder **section we just select the components that go in for that particular post and add its related content. That's it, simple and effective.

Now that we are a bit familiar with how we will be structuring things on the CMS, let's try migrating data from WordPress to Sanity.

Before we get into it, feel free to play around with the REST API in the [developer console portal](https://developer.wordpress.com/docs/api/console/) provided by WordPress, it will save your time from messing up the end points.

## Different types of WordPress setup & how to migrate
There's a lot of different ways a WordPress website could be set up, trust us, we had to build a good few back in our days. However, I'll give you a brief rundown of what to expect and what process I would go about migrating, if I were in your shoes. 

### Classic Editor
First of all, this is going to be a race against time, because on the [plugins description](https://wordpress.org/plugins/classic-editor/#:~:text=Classic%20Editor%20is%20an%20official%20WordPress%20plugin%2C%20and%20will%20be,to%20change%20their%20default%20editor.):

> Classic Editor is an official WordPress plugin, and will be fully supported and maintained until 2024, or as long as is necessary.

**Note:** As of 2025, Classic Editor support has officially ended. If you're still using it, migration is now more urgent than ever.

That "***as long as is necessary***" didn't exactly fill us with confidence at the time.

With that being said, *boy you're lucky* if you've kept it pretty close to vanilla, this is the best case scenario when it comes to migration. It doesn't take a whole lot of work to migrate and more than likely this will just be large chunks of text and images on a page. You can [proceed to the migration section](#migration) and blast through the rest of the tutorial, or continue reading if you have other types of WordPress websites.

### Vanilla Gutenberg
Again, very similar to the classic editor, this is one of the best-case scenarios for migrating content. It means that you've probably got a set of clean articles, and clean pages with mostly text and image content.

Where this gets trickier is mapping content that's added via a plugin, or custom functionality. Our best advice is to export all the rich text content and images, but leave the extended functionality to manually migrate, as unfortunately there are so many different plugins without that much standardisation. *Probably one of the reasons you're reading this.*

If you're planning a more complex migration where these elements **have **to come along, then it's definitely worth dropping a message over to us to consult your team for a couple of days and point you in the right direction. [Get in touch here](/contact).

### Page builder tool (WPBakery)
Okay, I'm going to break this to you. This is going to be a real pain in the ass to migrate, and I would change our migration technique entirely at this stage.

Instead of trying to do it through the WordPress admin panel, you will have more success using a tool like [Browse AI](https://www.browse.ai) (we're not sponsored), or writing your own script. We've got a JavaScript-focused script in-house, we are more than happy to share, just [ping us a message](/contact) and we'll try and help.

### Custom
This one is hard to give a concrete answer to, as we've seen WordPress environments set up quite tidily, all the way to *"built like complete ass" *but I'll provide you with the steps we would take:

- Try [Step 1](#step-1-export-your-site-data-from-wordpress) in the migration process in the section below
- Follow the process and see if the export is successful
  - If it's successful, follow the rest of the tutorial below
  - If it's not successful, but has some useful information in it, try and clean it up using your own python skills, or ChatGPT.
  - If it's not successful and there's nothing useful exported, follow the Page Builder guide above and use [Browse AI](https://www.browse.ai)
- Test to see if the results work with step 2 below

## Migration
Brace yourself for a wild ride, get your coffee and let's jump in because this is a long one.

### Step 1 : Export your site data from WordPress
Go into your dashboard and find tools > export, you will find an export all option which will send an email with a download link for an xml file.

![Dashboard of WordPress](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-migrate-from-wordpress-to-sanity-fast-blog-dashboard-of-wordpress.png)

### Step 2: Clone this repo and add your XML file
[https://github.com/kmelve/wordpress-to-sanity](https://github.com/kmelve/wordpress-to-sanity)

This repo is built by one of the finest devs in the Sanity community (Knut didn't pay us to say this). It's a great repo to get you started Sanity but keep in mind that it's a bit old and some functions may break or not work without modifications. Add your xml file at the root of the directory and find **migrate.js** where you need to update **filename. **If the file is in the root of your directory then it will be something like this:

```javascript
const filename = '../blogpress.wordpress.2024-03-01.000.xml'
```

> For more content from Knut check out [his blog](https://www.knut.fyi/) & [Sanity profile](https://www.sanity.io/exchange/community/kmelve), it's worth a read and he's one of the core Sanity team, so he definitely knows a thing or two about building incredible content experiences.
### Step 3: Create sanity.js file
Under **src/lib** create a new file called **sanity.js **where we will be storing all our Sanity related configs like **projectId** and **token.**

```javascript
const {createClient} = require('@sanity/client')

const client = createClient({
  dataset: 'production',
  projectId: 'PROJECT_ID',
  apiVersion: '2021-06-09',
  useCdn: false,
  token:'SANITY_API_TOKEN',
})

module.exports = client
```

> **Note:** please make sure you install the relevant packages mentioned throughout the codebase.
### Final step: Modify migrate.js
Thanks to a huge help from our in-house magician Hrithik, we added some extra touch-ups with the **migrate.js **file to create documents on Sanity, based on the original WordPress posts, users and categories data that we got from our WordPress site.

```javascript
#!/usr/bin/env node

/* eslint-disable id-length, no-console, no-process-env, no-sync, no-process-exit */
const fs = require('fs')
const {log} = console
const XmlStream = require('xml-stream')
const parseDate = require('./lib/parseDate')
const parseBody = require('./lib/parseBody')
const client = require('./lib/sanity')
const slugify = require('slugify')
const {uuid} = require('@sanity/uuid')

function generateAuthorId(id) {
  return `author-${id}`
}

function generateCategoryId(id) {
  return `category-${id}`
}

function readFile(path = '') {
  if (!path) {
    return console.error('You need to set path')
  }
  return fs.createReadStream(path)
}

async function buildJSONfromStream(stream) {
  const xml = await new XmlStream(stream)

  return new Promise((res, rej) => {
    /**
     * Get some meta info
     */
    const meta = {}
    xml.on('text: wp:base_site_url', (url) => {
      meta.rootUrl = url.$text
    })

    /**
     * Get the categories
     */
    const categories = []
    const categorySet = new Set()
    xml.on('endElement: category', (wpCategory) => {
      const {nicename} = wpCategory.$
      categorySet.add(nicename)
    })

    /**
     * Get the users
     */
    const users = []
    xml.on('endElement: wp:author', (author) => {
      const user = {
        _type: 'author',
        _id: generateAuthorId(author['wp:author_id']),
        name: author['wp:author_display_name'],
        slug: {
          current: slugify(author['wp:author_login'], {lower: true}),
        },
        email: author['wp:author_email'],
      }
      users.push(user)
    })

    /**
     * Get the posts
     */
    const posts = []
    xml.collect('wp:postmeta')
    xml.on('endElement: item', (item) => {
      const {title, category, link: permalink, description} = item

      if (item['wp:post_type'] != 'post' && item['wp:post_type'] != 'page') {
        return
      }
      try {
        const post = {
          _type: 'post',
          _id: uuid(),
          title,
          slug: {
            current: slugify(title, {lower: true}),
          },

          ...(category?.$?.nicename
            ? {categories: [{_type: 'reference', _ref: generateCategoryId(category.$.nicename)}]}
            : {}),
          description,
          body: parseBody(item['content:encoded']),
          publishedAt: parseDate(item),
        }

        posts.push(post)

      } catch (error) {
        console.error(error)
      }
    })

    // there seems to be a bug where errors is not caught
    xml.on('error', (err) => {
      throw new Error(err)
    })

    xml.on('end', () => {
      const output = {
        users,
        posts,
        categories: Array.from(categorySet).map((category) => ({
          _type: 'category',
          _id: generateCategoryId(category),
          title: category,
        })),
      }

      return res(output)
    })
  })
}

async function migrateType(json) {
  if (!Array.isArray(json)) return
  const mutateArr = json.map((doc) => ({createIfNotExists: doc}))
  const result = await client.mutate(mutateArr)
  console.log('🚀 ~ migrateToSanity ~ result:', result)
}

async function migrateToSanity(json) {
  const {users, posts, categories} = json ?? {}
  console.log('🚀 ~ migrateToSanity ~ users,posts,categories:', users, categories)
  await migrateType(users);
  await migrateType(categories);
  await migrateType(posts);

}

async function main() {
  const filename = '../blogpress.wordpress.2024-03-01.000.xml'
  const stream = await readFile(filename)
  const output = await buildJSONfromStream(stream)
  await migrateToSanity(output)
}

main()

```

Once this is done all you need to do is run this command on your terminal:

```sh
cd src && node migrate.js
```

And hurray!

We have all the data onto our CMS, you will see an output on your terminal like this:

![Terminal output of the script on some ugly-ass theme](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-migrate-from-wordpress-to-sanity-fast-blog-terminal-output-of-the-script-on-some-ugly-ass-the.png)

The script provided above would create posts on Sanity from the WordPress site but there will be some hits and misses in terms of references and such.

You will still need to go through them and manually check these documents, but this gives you a great starting point.

If you're also evaluating other platforms to [move away from WordPress](/blog/thinking-of-jumping-ship-from-wordpress), we've written about the options. And if you want to see what the [WordPress migration](/migration/wordpress-to-sanity) process looks like end to end, we have a dedicated page for that, plus a full [CMS migration service](/services/cms-migration) if you'd rather we run it.

> **Headless CMS services**: WordPress migration, content restructuring, and modern CMS setup with zero downtime. [Learn more](/services/headless-cms)

## Final thoughts
The script provided is a **_work in progress_**. It may have some references missing on your CMS, and it may leave out chunks altogether. But that's the way it is with migration tooling, unfortunately there's no silver bullet (or we'd be rich). However, if you *really* get stuck we're always here to try and help, whether you're an aspiring dev, or an SME, we've probably seen it before, [so get in touch](/contact).

Once you are done with all the migration the real joy of editing with Sanity begins, we have a whole set of blogs dedicated for that:

- Not sure on how to use Sanity? [Read this post](/blog/get-better-at-using-sanity-studio) where we show you all sorts of cool tricks and tips on using it efficiently.
- Are you a developer who is new to the party? Here is a [mini guide](/blog/gearing-up-with-sanity-in-2024) to save yourself a heck load of time.
- You may have realised that every schema change you make on localhost has to be deployed via the terminal for it to reflect on the production site. We say just [automate that with github actions](/blog/github-action-for-sanity-deployment-simplify-your-workflow).
- *Oh and if you're lazy and you're just planning to speed-run learning Sanity, **[boy do we have a post to help you out](/blog/using-cursor-to-improve-your-sanity-dx)*.

We hope this blog helped you in your migration adventures! If you're struggling and need a hand, we offer [Sanity development and migration services](/services/sanity) for teams who'd rather skip the headaches. Happy migrating!

---

## Using cursor to improve your Sanity DX


> We're a little lazy, and frankly who wouldn't be with all this AI promising to replace us within 10 years? Why not use it to automate Sanity schema generation.

**Published:** 2024-02-15 | **Updated:** 2026-07-23 | **Categories:** AI, Sanity
---

So you've discovered Cursor and want to dip your toes into improving your Sanity DX with artificial intelligence? Well, let's take you on a trip and share you some cheat codes along the way!

## A bit of background
If you're brand new to Cursor and you want to start work with Sanity I advise a couple of things

- Indexing all of Sanity's documentation
  - This makes working with Sanity more contextually accurate (at least from our experience). It also allows you to @sanity within a prompt if you want to solve something specific to Sanity.
- Adding our code to the "Rules for AI"
  - This gives our opinionation to any future prompts you use. Just be aware we are very Sanity, Tailwind and Next.js focused, adjust accordingly for your projects.
- Enabling Co-pilot ++ beta
  - This was a little rough when first released, but now it has given us some great code improvement freebies, so we'd advise turning it on.

### Video of adding Sanity indexing to Cursor

### Video of adding our schema and enabling co-pilot ++ beta

## TL;DR let me steal your code
Alright, well at least you asked nicely. Here's the code we use for our cursor config:

```markdown
Always use tailwind to style if the codebase is using it. Always use functional react. 
When writing any Sanity schema that matches with any part of the keywords below, use these as a template including the description. Make sure description is always above type. Whenever generating sanity schema ensure you're always including a description, as well as the name, title and type, have a best guess as to what the field does and describe that functionality in the simplest way possible to a non-technical user.
{
	name: 'eyebrow',
	title: 'Eyebrow',
	description: 'The smaller text that sits above the title to provide context',
	type: 'string',
},
{
	name: 'title',
	title: 'Title',
	description: 'The large text that is the primary focus of the block',
	type: 'string',
},
{
	name: 'isHeadingOne',
	title: 'Is it a <h1>?',
	type: 'boolean',
	description:
	'By default the title is a <h2> tag. If you use this as the top block on the page, you can toggle this on to make it a <h1> instead',
	initialValue: false,
},
{
  name: 'portableText',
  title: 'Portable Text',
  description: 'Large body of text that has links, ordered/unordered lists and headings.',
	type: 'portableText',
},
{
	name: 'buttons',
	title: 'Buttons',
	description: 'Add buttons here, the website will handle the styling',
	type: 'array',
	of: [{type: 'button'}],
},
{
    name: 'image',
    title: 'Image',
    type: 'image',
    fields: [
      {
        name: 'alt',
        type: 'string',
        description:
          "Remember to use alt text for people to be able to read what is happening in the image if they are using a screen reader, it's also important for SEO",
        title: 'Alt Text',
      },
    ],
  },
```

## Why did you structure your code that way?
There's probably a lot that could be improved but it gives you a solid foundation to start with.

Let me break it down, and tell you why we use each section.

```markdown
Always use tailwind to style if the codebase is using it. Always use functional react.
```

This is a nice easy one, 9 times out of 10 we're using tailwind when we are styling a project. There's literally no reason not to use Tailwind outside of "It looks bad". It's cleaner, it's easier to revisit and if you're sick of it not wrapping and can't read lines longer than the London marathon [pick up our tailwind tips here](/blog/a-seamless-experience-with-next-134-tailwind-css-and-sanity)

```markdown
When writing any Sanity schema that matches with any part of the keywords below, use these as a template including the description. Make sure description is always above type.
```

Now we get into the actual Sanity content. The shorthand is. Our ***internal*** best practice is always including a description on core fields. What do we mean by "core fields". Titles, Descriptions, Images etc. Nothing more complicated than that.

**We also recommend including them in this order:**

1. **Title**
1. **Name**
1. **Description**
1. **Type**
1. Validation
1. Options

In this case, anything that's highlighted in bold above we would recommend using on **every **schema. It just helps to contextualise each field.

*We'll return to this at a later date though, because we'll end up waffling and I want to write more about **our** internal Sanity Best Practices, because we sure as hell have a lot of opinions on how to structure schema.*

```text
Whenever generating sanity schema ensure you're always including a description, as well as the name, title and type, have a best guess as to what the field does and describe that functionality in the simplest way possible to a non-technical user.
```

The reason we're doing this should be pretty self explainatary, but let me condescend you if I haven't already. You do this because users, clients & marketers find it difficult to be on the same wave length as a developer. Ninety percent of the time we're-six-feet deep in documentation so we often make assumptions how a user will use the CMS. In the real world, this never actually happens. So for the sake of the future UX of your team, make sure you document the hell out of your schema by using **descriptions. **Even if it's not perfect, it's a large step forward from a blank field without context.

This leads us onto the actual schema we use for the rest of the prompt.

```text
{
	name: 'eyebrow',
	title: 'Eyebrow',
	description: 'The smaller text that sits above the title to provide context',
	type: 'string',
},
{
	name: 'title',
	title: 'Title',
	description: 'The large text that is the primary focus of the block',
	type: 'string',
},
{
	name: 'isHeadingOne',
	title: 'Is it a <h1>?',
	type: 'boolean',
	description:
	'By default the title is a <h2> tag. If you use this as the top block on the page, you can toggle this on to make it a <h1> instead',
	initialValue: false,
},
{
  name: 'portableText',
  title: 'Portable Text',
  description: 'Large body of text that has links, ordered/unordered lists and headings.',
	type: 'portableText',
},
{
	name: 'buttons',
	title: 'Buttons',
	description: 'Add buttons here, the website will handle the styling',
	type: 'array',
	of: [{type: 'button'}],
},
{
    name: 'image',
    title: 'Image',
    type: 'image',
    fields: [
      {
        name: 'alt',
        type: 'string',
        description:
          "Remember to use alt text for people to be able to read what is happening in the image if they are using a screen reader, it's also important for SEO",
        title: 'Alt Text',
      },
    ],
  },
```

> **Sanity CMS development**: AI-assisted Sanity development, schema generation, and developer workflow optimization. [Learn more](/services/sanity)

I guarantee you, at least 50% of the fields you've just read, you repeat again and again. So guess what? It makes perfect sense to standardise your description text for each of them. We've started with our most common components but I could very much see this list expanding as we add future components consistently.

## Inspiration for the post
![Taureen Work tweet that inspired us to write this up. Cheers buddy!](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/using-cursor-to-improve-your-sanity-dx-blog-taureen-work-tweet-that-inspired-us-to-write-this-.png)

Thanks [@taureen.work](https://twitter.com/_Taurean) for the inspiration for this blog post. It's been something we've wanted to write about for a while as we've been using it fairly consistently in-house. Tell us how you get on with Cursor, we've got no shares in the tool, but we'd genuinely like to know for the developer experience of Sanity in general.

We're going to keep stalking the Sanity twitter (I'm not going to call it X), and if we find any more insightful comments, we're definitely going to give our *two cents*.

If you want to take AI-assisted development further than prompt engineering, we build [agentic workflows](/services/agentic-workflows) that automate entire development and content pipelines. And if you need a hand getting your [Sanity](/services/sanity) project set up properly in the first place, we can help with that too.

---

## Gearing up with Sanity in 2024


> A small guide on getting efficient with Sanity CMS's schemas and workflows with some top tips. Everything from efficiently managing schema to hotkeys.

**Published:** 2024-01-11 | **Updated:** 2026-08-24 | **Categories:** Sanity
---

Hey there! if you are here looking for some hacks on improving your Sanity-based JAMstack sites then we have a heck-ton of stuff for you.

In this blog we assume that you have some amount of familiarity in terms of sanity structure, schemas etc and if not then I personally got started with this YouTube video by the good folks at [sanity and freecodecamp](https://www.youtube.com/watch?v=OcTPaUfay5I)! 

But obviously not everything can be covered in a single video, so here’s a bunch of secret sauces we are spilling out.

### Naming Conventions and reusability
Despite our best efforts, sometimes reusability will come at a cost of complexity, it’s generally best to build stuff out & get your hands dirty to make a naming convention that would suit your project and style of programming. That being said, we find categorising our sanity schema into three folders / categories as the best way to keep things simple:

1. **Documents:** This is where our main categories go in, let’s say you are making a landing page for a company, here is where our pages like people, about, contact reside.
1. **Definitions:** This is where we store re-usable objects / array components like buttons, links etc.
1. **Blocks:** This is where actual building blocks like sections, carousels etc go in. They use definition components and give you a section of sorts that you use to build an actual page.

Here’s an example of a blog page:

![A simple blog structure explained in diagrams](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/gearing-up-with-sanity-in-2024-blog-a-simple-blog-structure-explained-in-diagrams.png)

Here, the **portableTextBlock** will be a reusable component under blocks (where we have a portableText type which goes in definitions) since we never know how many places / pages would require a rich text editing block, so we abstract it away like this:

```typescript
import {defineField} from 'sanity'
import {FileText} from 'lucide-react'

export const portableTextBlock = {
  name: 'portableTextBlock',
  title: 'Portable text block',
  type: 'object',
  icon: FileText,
  fields: [
    defineField({
      title: 'Title',
      name: 'title',
      type: 'string',
    }),
    defineField({
      title: 'portableText',
      name: 'portableText',
      type: 'portableText',
    }),
  ],
  preview: {
    select: {
      title: 'title',
    },
    prepare({title}: any) {
      return {
        title: title,
        subtitle: 'Portable Text Block',
        media: FileText,
      }
    },
  },
}
```

portable text / rich text schema:

```typescript
import {ImageIcon} from '@sanity/icons'
import {defineType} from 'sanity'

export const portableText = defineType({
  name: 'portableText',
  title: 'Rich Text',
  type: 'array',
  of: [
    {
      type: 'block',
      styles: [
        {title: 'Normal', value: 'normal'},
        {title: 'H2', value: 'h2'},
        {title: 'H3', value: 'h3'},
        {title: 'H4', value: 'h4'},
        {title: 'H5', value: 'h5'},
        {title: 'H6', value: 'h6'},
        {title: 'Quote', value: 'blockquote'},
      ],
      lists: [
        {title: 'Numbered', value: 'number'},
        {title: 'Bullet', value: 'bullet'},
      ],
      marks: {
        decorators: [
          {title: 'Strong', value: 'strong'},
          {title: 'Emphasis', value: 'em'},
        ],
      },
    },
    {
      name: 'image',
      title: 'Image',
      type: 'image',
      icon: ImageIcon,
      fields: [
        {
          name: 'alt',
          type: 'string',
          title: 'Alt Text',
        },
      ],
    },
  ],
})
```

If you need to add videos then we recommend reading through [this article](https://www.sanity.io/plugins/sanity-plugin-mux-input), mux video just makes everything simple and efficient.

Now with all of this in place, we can make a document called **article** which uses all of these to add articles with ease.

![Overview of the schema's structure](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/gearing-up-with-sanity-in-2024-blog-overview-of-the-schemas-structure.png)

By structuring and re-using some components like this in your schema, you have a plug and play system that can help you minimise the amount of GROQ queries that you write. Albeit it can get out of hand and make things more complicated, and that’s where your dev instincts will kick in and just do what’s best in your case.

Schema for the **article.ts**

```typescript
import { defineField } from 'sanity';

export const article = {
	name: 'article',
  title: 'Articles',
	type: 'document',
	fields: [
		defineField({
      name: 'title',
      title: 'Title',
      description:
        "Every page should have a title that isn't too long or too short. We recommend page titles are between 10 and 60 characters.",
      type: 'string',
      validation: (Rule) => Rule.required(),
    }),
		defineField({
      name: 'portableText',
      title: 'Portable text',
      type: 'portableText',
    }),
		// .... and so on
	]
}
```

Also, while we are at it, here are some utility packages for sanity schemas

- [Asset-utils](https://github.com/sanity-io/asset-utils): You can use this to generate aspect ratios and pull widths/heights from images (commonly asked question)
- [Sanity icons:](https://github.com/sanity-io/icons) These are bundled by default, can drop these in and out project to project without having to install an additional icon set.

### Auto-generate sanity schema types
> Little bit of a pre-face, this tool has [technically been put on hiatus but is open for sponsorship](https://www.sanity.io/plugins/sanity-codegen). If you're part of a giant conglomerate and reading this - do us all a favour and see if they'll throw some mulah his way.
Defining schema types will help you in a long way when building your web application, So we will be using this package called sanity-codegen. Here's the command to install it

```text
npm i -D sanity-codegen
```

and add a config file like this at a location like this:

root_dir/sanity_folder/sanity-codegen.config.ts

```typescript
import { SanityCodegenConfig } from 'sanity-codegen';

const config: SanityCodegenConfig = {
  schemaPath: './schemas', //path to all the schemas defined
  outputPath: '../web/src/schema.ts', //path to the shared schema file
  prettierResolveConfigPath: '../web/.prettier.js', //optional
};

export default config;
```

make sure to install these as a devDependency and if you run into any errors then [here’s a link](https://github.com/ricokahler/sanity-codegen/issues/272#issuecomment-1241092032) that most likely will fix your problem.

A bit of a hassle to setup these workflows but once they are done you will fly by your development, we highly recommend that you spend time in simplifying tasks like this.

> **Sanity CMS development**: Schema design, workflows, and Sanity configuration for teams who want to move fast. [Learn more](/services/sanity)

### Custom hotkeys
You just moved from notion, hashnode (etc..) and now you miss the keyboard shortcut keys while editing your article content. Guess what, sanity has got you covered. Here's a lazy mans version on how you can add custom hotkeys.

As of writing, I didn't find a hotkey to have a strike-through decorator on highlighted text content, so here we are defining one. 

This is in portableText file where I have added a customInput component to add this hotkey. Since we are importing react here, make sure you modify your file to **portableText.tsx **or** richText.tsx **

```tsx
import {useMemo} from 'react'
import {PortableTextInput, PortableTextInputProps, defineType} from 'sanity'

const customInput = (props: PortableTextInputProps) => {
  const {path, onItemOpen, onPathFocus} = props

  const hotKeys: PortableTextInputProps['hotkeys'] = useMemo(
    () => ({
        marks: {
          'Ctrl+Shift+s': 'strike-through',
        },
    }),
    [onPathFocus, onItemOpen, path]
  )

  return <PortableTextInput {...props} hotkeys={hotKeys} />
}

export const portableText = defineType({
  name: 'portableText',
  title: 'Portable text',
  type: 'array',
  of: [
    {
      type: 'block',
      styles: [
        {title: 'Normal', value: 'normal'},
        {title: 'H2', value: 'h2'},
        {title: 'H3', value: 'h3'},
        {title: 'H4', value: 'h4'},
        {title: 'H5', value: 'h5'},
        {title: 'H6', value: 'h6'},
        {title: 'Quote', value: 'blockquote'},
      ],
      lists: [
        {title: 'Numbered', value: 'number'},
        {title: 'Bullet', value: 'bullet'},
      ],
      marks: {
        annotations: [
          {
            name: 'customLink',
            type: 'object',
            title: 'Internal/External Link',
            fields: [
              {
                name: 'customLink',
                type: 'url',
              },
            ],
          },
        ],
        decorators: [
          {title: 'Strong', value: 'strong'},
          {title: 'Emphasis', value: 'em'},
          {title: 'Strike-through', value: 'strike-through'}
        ],
      },
    },
    {
      name: 'image',
      title: 'Image',
      type: 'image',
      fields: [
        {
          name: 'alt',
          type: 'string',
          title: 'Alt Text',
        },
      ],
    },
  ],
  components: {
    input: customInput,
  },
})
```

Here's the link to the [full article](https://www.sanity.io/docs/studio/customizing-block-content#a04e139d5731) where you can go deep into it.

Now with all these changes done, you will have to run **sanity deploy** for the changes to reflect on your main CMS domain / site. A bit of a hassle to do it every time innit? Lucky you, cause our in-house wizard hrithik got you covered with this [nifty blog](/blog/github-action-for-sanity-deployment-simplify-your-workflow) where a github action will auto deploy each time a change is pushed, make sure you check that out!

Thank you so much for reading through this article, we hope that it helps you in one form or the other! If you want to skip the setup and start with all of this pre-configured, check out our [workshops](/services/workshops). And if you have any thoughts or doubts then please feel free to [reach out to us](/services/sanity).

---

## Get better at using Sanity Studio


> Navigate Sanity Studio like a pro. Our guide offers simple and practical tips to enhance editing experience for the not-so-techy content editors.

**TL;DR:** Didn't read the blog? Shocker. Automate boring tasks with Sanity AI, copy-paste fields like a pro, and search with fuzzy logic. Preview changes instantly, manage media smartly, and schedule content without headaches. Drag, drop, and stop whining. Read next time!

**Published:** 2024-01-09 | **Updated:** 2026-07-23 | **Categories:** Sanity, How To
---

You might have noticed we mostly write technical-focused Sanity blogs, but we were thrown a complete curveball the other day by a client. "Do you have any practical tips we could use as content editors?"... Erm... No, we actually didn't.

Well, that's going to change today with this group of tips to improve your Sanity experience purely from a client perspective. We're talking about ways without any dev work to make it easier to find, generate, and publish content on a Sanity website.

## Sanity AI Assist

No one likes doing the boring, repeatable stuff. Not developers. Definitely not content editors or us. And yet, every CMS somehow makes you do the same SEO fields, image descriptions, summaries, and metadata over and over again, like it’s a character-building exercise. By using the latest [Sanity AI Assist,](https://www.sanity.io/ai-assist) you can automate all this, as it understands your content model, validation rules, and references out of the box. When you ask it to generate or update content, it puts everything in the right place automatically without you having to press Cmd+C again and again.

The real win is scale. Instead of manually checking dozens (or hundreds) of pages, the[ Sanity Content Agent](https://www.sanity.io/content-agent) can scan your content library in one go, surface gaps, flag outdated claims, and suggest improvements. What used to take days now takes minutes, and without introducing AI slop into your site.

## Adding on copy-paste fields
Another drag for us was creating fields from scratch. Obviously, the new AI feature simplifies it. But did you know you can just [copy a field](https://www.sanity.io/docs/user-guides/field-copy-and-paste) from one page and paste it into another page?

![Sanity Studio interface with a 'Copy field' and 'Paste field' menu open. ](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/get-better-at-using-sanity-studio-blog-sanity-studio-interface-with-a-copy-field-and-past.png)
*Sanity studio copy paste fields*

This one sounds obvious, but it’s criminally underused. Sanity lets you copy individual field values or entire documents directly inside Studio. Copy it once, paste it where it belongs, and move on with your day.

You can do this in two ways:

- Use the **Field Actions menu** on any supported field
- Or just **Cmd/Ctrl + C → Cmd/Ctrl + V** like a normal human

It’s a small feature that quietly saves hours, especially when you’re duplicating content across pages, locales, or document types without rebuilding everything from scratch.

## Make some space
Did you know that you can close the columns that make up the navigation panes within Sanity? You just have to press the text at the top of the column (or the title of the column), and it'll compact away to the left or right and give you more screen real estate to focus on important things. Check it out in the video below.

## Search the document list
Sticking to the **document list-**related tips, you can search for a document within Sanity by pressing the search at the top of the document list. Okay, pretty simple, yes. But did you know it's a fuzzy search that doesn't just check the title, it can query any of the fields inside the document.

E.g I remember talking about ChatGPT in the article I just wrote, but I can't remember the name of the article. Just type "ChatGPT," and up it'll pop.

## Search everywhere
Now that works perfectly fine if you know where your content lives. However, if you only remember a few details about your content, and you're looking to implement changes on the website. For example, if you're searching for a piece of text in the footer, you can hit CMD + K (Ctrl + K on Windows) from anywhere, and a helpful little search bar will appear, letting you search for a query with fuzzy search. This allows you to search every document type at once.

## Feels like a word doc
If you're looking at getting the ultimate feeling of "editing like a Word document," you can achieve that with one of the tips (make some space) discussed earlier in this post.

Yes, more space, less distraction, better editing experience. If you're opening up the portable text component at the top right, make sure you're also closing the columns to get a distraction-free writing experience. Clean space, clean mind, higher velocity... You get the idea.

## Preview and visual editing

With Sanity, previews aren’t guesses. You see your changes **as you’re making them in **[**Presentation**](https://www.sanity.io/docs/content-lake/presenting-and-previewing-content) directly on the page. Draft content stays safely in preview, published content stays public, and you can switch between the two without breaking anything or bothering a developer.

We've lost count of how many teams come to us saying, *"Preview doesn't match prod"* or *"Can you deploy so I can see my change?"*  which is frankly wild in this day and age.

Sanity gets this right. Drafts and published content live side-by-side in the [Content Lake, and with ](https://www.sanity.io/docs/content-lake/perspectives)[**Perspectives**](https://www.sanity.io/docs/content-lake/perspectives), we decide exactly what the frontend sees. Production only ever queries published content, while preview environments run the same queries against drafts (or release stacks) and hydrate them live.

[Visual Editing](https://www.sanity.io/docs/visual-editing/introduction-to-visual-editing) makes it even easier. You can click the exact section you want to change on the website, jump straight to the right field in Studio, edit it, and see the update instantly. Need to reorder sections on a landing page? Drag them. Want to sanity-check a headline, image, or CTA before publishing? It’s already there, in context.

> **Sanity CMS development**: Studio configuration, custom components, and editorial UX that editors enjoy using. [Learn more](/services/sanity)

## DAM or media management

In Sanity, you upload an asset once and reuse it everywhere. One logo across eight projects? Update it once, and it’s fixed everywhere it’s referenced. Finding images doesn’t rely on filenames anymore, either, like `final-final-v3.jpg.`

The [media library](https://www.sanity.io/media-library) understands what’s *in* an image. You can search by subject, scene, colours, or concepts, then layer on real-world context like licence type, campaign, approval status, or expiry date. Rights management lives with the asset, not in a spreadsheet someone forgot to update. Even bulk actions are smooth. Select images like files on your desktop, update licences, move collections, or clean out assets that aren’t used anywhere, and trust us when we say that you don't need a developer to do this. You can probably do it in 5 minutes without any knowledge of coding.

## Scheduling
If you’re working on a single page and want it to go live later, [**Scheduled Drafts**](https://www.sanity.io/docs/studio/scheduled-drafts)[ ](https://www.sanity.io/docs/studio/scheduled-drafts)lets you pick a date, lock it in, and forget about it. The document is clearly marked as scheduled, so other editors can see what’s happening and don’t accidentally change it. You don't need reminders or calendar events, and nobody has to ask who published what.

And when you’re dealing with bigger updates, [**Content Releases**](https://www.sanity.io/docs/studio/content-releases-configuration) let you group multiple pages together, preview them as one, and schedule the whole thing in advance. Think launches, campaigns, or seasonal updates. All queued up, visible to the team, and shipped cleanly at the exact time you chose.

## Drag & drop your blocks
So if you're lucky enough to have a page builder on your website, you may know that you can easily drag and drop those blocks in different orders. However, did you know you can press the little kebab menu (yes, that's what it's called) on the right-hand side and use the insert new block above/below, to add a new block in between the above/below blocks.

## Looking for more tips?
Well, if you're looking for more tips, we're in the process of writing up a chunky blog post about Sanity AI, or if it's something more technical, we have some great blog posts on:

- [Using Sanity Scheduling and what to care about](/blog/sanity-scheduling-probably-the-best-scheduling-tool-weve-ever-used)
- [The best Sanity image component (we reckon)](/blog/the-best-nextjs-and-sanity-image-component)

Or if you know something we don't, to make your Sanity content editorial flow faster, with minimal coding, [get in touch](/services/sanity), we'd love to add it to our list. And if you want your team trained up properly, our [workshops](/services/workshops) cover all of this and more.

---

## Working with Formspark & Server action in Next.js 14


> Build forms in Next.js 14 with Server Actions and Formspark. Working code using useFormState and useFormStatus hooks for handling submissions and loading states.

**Published:** 2024-01-09 | **Updated:** 2026-07-23 | **Categories:** Next.js, How To
---

### Server Actions
In Next.js, server actions, (the files started with a little 'use server' at the top), are asynchronous functions that simplify form management. They can be incorporated into both Server and Client Components, promoting code reuse and efficiency. Specifically, 'use server' is used in Server Components, while Client Components can employ Server Actions for form processing.

This can help manage form submissions and related data changes, offering features like pending submissions in Client Components. They also work with Next.js' caching and revalidation system, meaning you have **only** one trip and all your UI updates and data management is sorted.

### FormSpark
Formspark is an innovative solution that allows you to collect and save information from your website forms without setting up a server. If you want two great reasons to use it:

1. It's stupidly fast
1. It's stupidly cheap

Simply, it just takes managing the *data bit* of forms out of the equation. 

Implementing Formspark in Next.js with server action is quite straightforward so we thought we'd throw together a quick fix guide, because in our opinion this is the de facto method of setting up a ***simple*** form without breaking out the backend skills.

For all you out there thinking of trying to skip the frontend step as well, we actually built the following contact form from [V0.dev](https://v0.dev/t/lmS2qcBwxEr). It's basically precisely what this tool was made for.

```typescript
export const ContactForm: FC = () => {
  return (
    <Card className=" shadow-lg max-w-md mx-auto p-6 rounded-lg">
      <CardHeader>
        <CardTitle className="text-2xl font-bold text-center">
          Contact Us
        </CardTitle>
        <CardDescription className="text-gray-500 text-center">
          We would love to hear from you. Please fill out the form below.
        </CardDescription>
      </CardHeader>
      <CardContent>
        {/* Here's the form with the id from formspark */}
        <Form formId="1MtTF9c1l" />
      </CardContent>
    </Card>
  );
};

```

This is the code where all the magic happens we are using React’s new hooks

1. **useFormState** The **useFormState** hook in React allows for creating and managing component states in response to form actions. It pairs an action function with an initial state, returning a new action and the latest form state for use in forms. This enables dynamic updating of form state and supports server actions for immediate response display. more here
1. **useFormStatus** The **useFormStatus** hook in React provides status information about the last form submission, such as whether it's pending. It's used within a form component to dynamically enable or disable elements like a submit button based on the form's submission status. This hook returns an object containing properties like **pending**, **data**, **method**, and **action** to manage form interactions efficiently. more here

```typescript
const SubmitButton: FC = () => {
  const { pending } = useFormStatus();

  return (
    <Button
      disabled={pending}
      variant={"secondary"}
      className="bg-blue-500 text-white w-full flex gap-2"
    >
      {pending && <Loader2 className="animate-spin text-white" />}
      Submit
    </Button>
  );
};

const INITIAL = {
  message: "",
  hasError: false,
  isComplete: false,
};

const Form: FC<FormProps> = ({ formId }) => {
  const _action = formSparkFormAction.bind(null, formId);
  const [state, action] = useFormState(_action, INITIAL);

  if (!state.hasError && state.isComplete)
    return (
      <div className="flex w-full max-w-md" id="form">
        <div className="my-10 flex w-full items-center justify-center gap-4 rounded-lg bg-gray-200 p-4 text-black ">
          <CheckCircle />
          Form Submitted
        </div>
      </div>
    );

  if (state.hasError && state.isComplete) {
    console.error("Form submit error:", state.message);
    return (
      <div className="flex w-full max-w-md" id="form">
        <div className="my-10 flex w-full items-center justify-center gap-4 rounded-lg bg-red-200 p-4 text-black ">
          <CrossCircledIcon />
          something went wrong!!
        </div>
      </div>
    );
  }
  return (
    <form className="space-y-4" action={action}>
      <div className="grid grid-cols-2 gap-4">
        <div className="space-y-2">
          <Label htmlFor="first-name">First name</Label>
          <Input
            id="first-name"
            name="first-name"
            placeholder="Enter your first name"
          />
        </div>
        <div className="space-y-2">
          <Label htmlFor="last-name">Last name</Label>
          <Input
            id="last-name"
            name="last-name"
            placeholder="Enter your last name"
          />
        </div>
      </div>
      <div className="space-y-2">
        <Label htmlFor="email">Email</Label>
        <Input
          id="email"
          name="email"
          placeholder="Enter your email"
          type="email"
        />
      </div>
      <div className="space-y-2">
        <Label htmlFor="message">Message</Label>
        <Textarea
          className="min-h-[100px]"
          id="message"
          name="message"
          placeholder="Enter your message"
        />
      </div>
      <SubmitButton />
    </form>
  );
};
```

This code defines two components, SubmitButton and Form.

The SubmitButton enhances the user experience by displaying a loader during the form submission process. *Nice*

The Form state holds information about possible errors and the status of the form submission. Depending on this state, the component presents different user interfaces: if the form is successfully submitted without errors, a success message is displayed. If there's an error during submission, an error message is shown. When the form is still in the process of being filled out, the actual form is rendered.

```typescript
"use server";
import axios, { isAxiosError } from "axios";

export async function formSparkFormAction<T>(
  formId: string,
  state: T,
  form: FormData
) {
  if (!formId) {
    return {
      message: "Form field missing",
      hasError: true,
      isComplete: false,
    };
  }

  const extractData = Object.fromEntries(form.entries());

  try {
    await axios.post(`https://submit-form.com/${formId}`, extractData);
  } catch (error) {
    if (isAxiosError(error)) {
      return { message: error.message, hasError: true, isComplete: true };
    }
    return { message: "An unexpected error occurred", hasError: true, isComplete: true };
  }

  return { message: "done", hasError: false, isComplete: true };
}
```

This code is a server action function for form submission. It takes three parameters: the form ID, the state of the form, and the form data itself. It extracts the data from the form entries. and sends a POST request to the Formspark URL with the form data. If an error occurs during the request, it logs the error and returns an error message

Here’s the github link for the complete tutorial: [link](https://github.com/robotostudio/formspark-server-action)

### Outro
We hope you enjoyed the tutorial, and if there's anything that isn't clear, give us a shout. We're always trying to ensure we pass on knowledge in a way that doesn't feel like you're reading a dictionary front to back.

> **Next.js development**: We build Next.js apps with server actions, form handling, and solid architecture. [Learn more](/services/nextjs)

---

## Our roundup of tools 2024


> We just managed to squeeze this out by the skin of our teeth at the end of 2023. But guess what? We're still going to use 2024 as a clickbaity title.

**Published:** 2023-12-31 | **Updated:** 2026-07-23 | **Categories:** AI
---

The year 2023 has brought a breath of fresh air with advancements in AI tools threatening human incompetencies as well as new releases of some sophisticated tools (it was nice knowing you HR teams). In this post we will provide our honest takes on tools we've explored in depth, broken our own systems with and learnt a hell lot in the process. We are going to talk about the tools we can't live without and those we absolutely ***can do without***. 

## Tools our management team loves
### [Linear](https://linear.app/)
![Linear screenshot in a nice gradient background](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-linear-screenshot-in-a-nice-gradient-background.png)

First up, Linear. This tool is our personal favourite, we use it for all our projects and vouch for it’s reliability. It's incredibly fast, intuitive, and perfect for our team that loves to get things done without the fluff. Linear’s simple UI cuts down the extra noise which you find in other PM tools. It comes with various hot keys (for example: G+M, to take you to your tasks) and is highly customisable to suit your team’s requirements. Our personal favourite is how well it integrates with GitHub. Once the task is merged on GitHub, task status is updated on Linear, removing that extra hassle of going through each ticket and marking it done.

Both a benefit and a drawback is that Linear is fairly unopinionated in comparison to others on this list. What this means is that it takes time and customisation from your side to make it work the way you want it to (*which can be frustrating at times*). It’s important to find **your** way of keeping up with tickets, so we would advise spending half a day just setting up what you would like to see within Linear.

E.g

- My tasks
- Our teams tasks
- Tasks that are urgent split into team members
- Specific team members board views of tasks

Take the time out to do the above and you’re sure to have a good time, but don’t expect instant results, any tool that’s worthwhile using actually takes time investment.

> On our list of things we’d love to see are - *Hot Take*
Build a god damn iOS app. No, a PWA is not the answer.

Needless to say, I don’t believe in PWA apps, I don’t know whether we’re all living under a rock and we’ve decided that a hacky, non-native feel where the application is just a glorified safari window is the standard we should live up to, but I certainly hate it. Plus there’s a bug right now in Linear where if you scroll down a swimlane it breaks after about 300px, so I’m especially salty. That being said, even with these minor irritations, it’s still the best of the bunch.

### [GitHub Projects](https://github.com/features/issues)
![GitHub projects kanban board view, in light mode, however there's actually a dark mode](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-github-projects-kanban-board-view-in-light-mode-ho.png)

Next, GitHub Projects. It's a project management powerhouse built right into the code repository. The integration with codebase makes it a dream for tracking progress on software development projects. Its Kanban-style boards and automation features make it a winner for us.

> You’re going to notice an ongoing theme here - *Hot Take*
Guess who doesn’t currently have an iOS app, or any ability to manage swimlanes and tasks through the GitHub iOS app? Bingo. You have to… You guessed it, navigate manually to the website to view the swimlanes that don’t work properly on mobile.

It blows my mind in the year of (soon to be 2024) we don’t have a well optimised, hotkey enabled project management tool that has a native app. Or at least I haven’t found one yet.

### [Notion](https://www.notion.so)
![Notion homepage with quirky little black and white illustrations](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-notion-homepage-with-quirky-little-black-and-white.png)

Lastly, Notion. This tool is like the Swiss Army knife of project management. From notes to databases, task management to documentation, it's got it all. Notion is the go-to for teams that need a versatile, all-in-one platform for managing projects and content. It’s almost fun as a project management tool because of all the thought that’s gone into user experience.

For us, the real benefit of Notion is it’s ability to cover all bases when you build a kanban board. For example if you need a multitude of views, one gantt chart, one board and each of the tickets turns into a collaborative Google Docs-esque format, you can do that.

> Guess what, it actually has a mobile app - *Hot Take*
However, the issue is, it still feels weak when you’re working with Swimlanes inside the app and I’m not sure if it’s me, but very quickly the performance diminishes significantly when working with lots of tickets.

This leads me to nest this very heavily in the "works perfect as a weekend project kind of PM tool, but not so good as a long-term multi month project".

## Tools our dev team loves
### [Screen studio](https://screen.studio/)
![A screenshot of Screen Studio's website](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-a-screenshot-of-screen-studios-website.png)

I think one of our agency friends shared this once on LinkedIn, and I thought it was a bit of a weak offering for a native application: "It’s a very good screen recording system that makes your products look pretty". Okay, and what?

Well I cannot tell you how well it does the above. So much so that it's our **_only_** tool we use when uploading our screen recordings to the web. It eases, it zooms, it does some really nice blurring effects on the mouse when I’m shooting around the screen at 1000 pixels per second and doesn’t make it nauseating. Check it out, this we knocked up for a project in 30 seconds flat.

The other beautiful thing is that you can set up templates, which means the amount of border radius on your browsers, the background gradient, the amount of screen it takes up and the ratio of the video. These all combine to make it far easier than ever before to record something fast and get it out for the world to see.

If you’re looking for a screen recording app, this is the one. Seriously try it. It’s worth it.

> It’s actually good, and there’s nothing hot about this take - *Hot Take*
Oh, we’re not actually sponsored. Although I should have probably set myself up with an affiliate link to shill this app.

### [Clean shot](https://cleanshot.com)
![A screenshot of the Cleanshot X homepage... Shot with Cleanshot](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-a-screenshot-of-the-cleanshot-x-homepage-shot-with.png)

Basically take exactly what I’ve said above and apply it to screen shots within Mac. You can easily bind the same hotkeys and stylize it with the same gradient background. I’m going to save you some time and just re-read the review above again and take this recommendation.

> We’re two apps in and I haven’t got paid for either endorsement - 
### [Cursor](https://cursor.com/)
![A screenshot of Cursor the AI driven code editor](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-a-screenshot-of-cursor-the-ai-driven-code-editor.png)

I don’t want to talk too positively about Cursor, or clients are going to assume I sit around all day picking my nose. That being said, it’s improved our performance significantly. Crazily, it even suggested a fix for the Roboto Studio website which actually fixed the barrel file issue we ran into. We’ve tried GitHub Co-pilot and it’s far better than that, it’s actually integrated and the UX feels very nice, especially being able to step back, line by line with AI.

We primarily use it just to cut down on significantly time consuming an boring tasks… E.g generate me a select with all the countries of the world - then step away for a minute and get yourself a cup of tea. It’s also a banger when you’ve actually forgotten the syntax for a specific framework.

E.g: "Write me up a Sanit & Next.js image that optimises the image to be 60x60 and includes a blurhash for the blur effect". **_Yes this actually works._**

> I don’t think devs are going anywhere, but the gap will get larger between those that don’t use AI and those that do. Let’s just hope we don’t all get stupid-er in the process - *Hot Take*
Oh and if you’re considering using this, a couple of tips:

- By pressing CMD + Shift + L you can add custom commands to your editor
- You can add a custom command to always default to tailwindcss styling for example
- You can index entire documentation using the @ documentation feature
- You can also ask your entire codebase a question, this helps no-end at a dead end

### [Loom](https://www.loom.com/)
![A screenshot of the Loom homepage, showing off the video capabilities with a video](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-a-screenshot-of-the-loom-homepage-showing-off-the-.png)

I cannot tell you how many hours Loom has saved us. This is the tool that allows you to "tells the team what the issue is, without any: if’s, but’s or confusion". Our primary use cases fall into one of two:

- I want to describe an issue, but it’s too finicky to write it down
- I want to show off a feature to a client with some extra pizazz

But for solving these two issues, there really isn’t anything that beats it. Because it asynchronously uploads your video as your recording it, you don’t have to go through the arduous process of Recording → Go to YouTube → Upload it → Make sure you don’t close the tab. It also let’s you do quick and easy re-takes if you don’t like your face, or your cat decided to flaunt it’s butt to the camera mid-clip.

Something that’s also neat about it, that I actually recommend paying the little bit extra for is the AI functionality. It ultimately takes what you’ve said in the video and it generates a description, a transcription and a title. Most of the time (probably 80-90%) it’s actually correct with what it says, although we’ve had 1 or 2 blunders, so always check.

> **Next.js app development**: Modern web development with Next.js, Sanity, and the best tools in the ecosystem. [Learn more](/services/nextjs)

### [Shadcn/UI](https://ui.shadcn.com)
![Shadcn/ui fancy new homepage, compete with new components - good on you Shad](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-shadcnui-fancy-new-homepage-compete-with-new-compo.png)

This was a newcomer for us this year, and it's blown us away. Completely changed the paradigm for how we thought of component libraries, and in our opinion is the missing link for more complex Tailwind components. For those of you not in the know, it's essentially components built out of Tailwind, that range from simple, to "you actually built a datepicker, good job". There's no doubt in our mind it saves you about 10-100 hours on every project.

## Tools that we hope stop being used
### Jira
![Please don't use Jira, this is a screenshot of the garbage software](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-please-dont-use-jira-this-is-a-screenshot-of-the-g.png)

This is going to be the tool that gets me blacklist from working enterprise. I loathe this tool. I really hate it so much from the crappy optimisation that takes a solid 5-10 seconds load time to just see 200 tickets, to the fact that it’s taken them nearly 4 years to implement a dark mode.

Honestly Jira haunts my dreams. Every time I think about this tool I get acid reflux as it’s synonymous with never getting any work done. You want to know something beautiful too. I’ve never ***actually*** seen this tool improve accountability or velocity in any time it’s used in. It’s always a hindrance.

Oh, Jira. It's like that bulky, complicated gym equipment no one really knows how to use effectively. Sure, it's powerful, but its complexity often slows us down more than it helps. It's just too clunky for our taste.

### Asana
![A screenshot of Asana's homepage, nobody seriously uses this to ship projects, surely not](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-a-screenshot-of-asanas-homepage-nobody-seriously-u.png)

I honestly salute whoever built this originally. We feel as though it’s one long running joke where somebody took a to-do list application that you learn when you first start development and went: "We can make a full app out of this". There is one singular redeeming feature of this tool and that’s the unicorn that sometimes turns up if you complete a task. Well I’m a sucker for positive reinforcement and the little rainbow is like an endorphin shot.

### Microsoft Teams
![Teams homepage, you can tell a tool is a hot mess when even the primary image of the application is blurry. Shocking.](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-teams-homepage-you-can-tell-a-tool-is-a-hot-mess-w.png)

This is one tool we hope to never use again. Not only does the Teams: New edition **_completely_** lock us out of our accounts and get stuck in a loop, Teams **Classic** does the same, but we can at least still access our chats once it's crashed completely and reopened again.

Honestly I have no idea how this tool got out of QA. It's hacked together - seriously there's an 80px blank space between the chat box and chat history. The icing on the cake was the "Now you have to use Teams" to the Open AI guys during **_that_** fiasco.

![Musk throwing shade at Teams](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-musk-throwing-shade-at-teams.png)

## Honourable Mentions
We didn’t want to include on here, because we already unabashedly shill them, and really genuinely love them.

### Sanity CMS
This changed how we build every project, and every year it gets better and better. There isn’t a better content management system. If you’re looking for a headless CMS, just learn it. [Side note: we've torn down a lot of these here](/blog/headless-cms-hot-takes). We're also [Sanity agency partners](/services/sanity), so we might be a tiny bit biased.

### Vercel
This is always a huge time save, I know you can technically roll your own AWS instance or some weird infra that breaks every month, but just don’t bother. Just use this. It's not like we're [experts or anything](/services/nextjs)...

### Next.js
[Oh surprise, surprise, it’s not like it’s our go-to stack or anything.](/blog/a-seamless-experience-with-next-134-tailwind-css-and-sanity) React Server Components changed how we structure our apps and although I know it’s a divisive topic, overall they’ve been advantageous for us, with a little bit of a learning curve. So just use them.

### Tailwind
God, I absolutely didn’t want to like this, everything about it makes my skin crawl, but it’s incredible. Combine this with the newly released Shadcn/ui and you’ve saved more time than I like to think about. There’s no point in using any other frontend styling method, this is the one you’re looking for… Despite how ugly it makes your classNames look.

## Here's to another year
Well, if we're not the saddest of sad acts. Yes we actually did draft this just before midnight on New Years Eve, no this isn't scheduled. Here's to another year of fun, frustration and screaming at screens. We wouldn't be where we are without our incredible team, so thank you for all the hard work! Peace.

![A picture of a chunky British shorthair looking into the sky with a twinkle in his eye for another year](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/our-roundup-of-tools-2024-blog-a-picture-of-a-chunky-british-shorthair-looking-in.png)

---

## Making your editorial experience that little bit better


> Building content in a CMS shouldn't be a pain. That's why we're bringing you some primo, no-nonsense tips to make your editorial experience joyous

**Published:** 2023-11-14 | **Updated:** 2026-08-24 | **Categories:** Sanity
---

Honestly, in this day and age of "run it through ChatGPT and copy the output", who actually wants to write blogs? Well, *surprisingly*, we are enjoying the process more and more. Let me tell you about our journey into the world of editorial bliss.

## Closing the blinds
If you've used Sanity for a long enough time, you may be aware of the fact that the menu palettes on the left of the studio are collapsible. However, for those that don't know... You can close them by clicking the heading at the top of the column.

*Don't worry, the tips get better than this*

## Little tweaks make a big impact
This sounds a lot like the "Flywheel effect" and all of that marketing drivel, but let's take our cynic hats off for a second, and think about this. If you can save somebody 10 seconds by automatically ensuring when a user creates a new article, it sets the date to the current time, it'll cause a teeny weeny amount of dopamine, knowing that it's one less thing they have to tweak and change. That dopamine adds up, and encourages you and your team to write more, and ultimately "market" more.

There's a multitude of these that you can do - Do you have a primary marketer? Make it so that their name is immediately added as the author to every new article. Do you write your articles in a Word document first? Use [Sanity AI Assist](https://www.sanity.io/blog/sanity-ai-assist-announcement) to ingest this data and spit out a first draft of the page.

Rather than just pulling any of these out of thin air, a top tip is to actually *get off your chair*, and go speak to the marketing team to find out pain points.

I know this is the equivalent of telling a developer to *go touch some grass*

## Do not underestimate live preview
When you're writing content, you want predictability, you want empowerment. You want a damn good live preview. Why? Because not only does it reassure you that you're writing something that is actually tangible and exists, but it's also nice to see your content with the surrounding imagery, font and colors of your live site.

A live preview for a blog post is about a day's work... if that (if the site is built somewhat well), so what's your excuse, go out there and do it. [Just do it](https://www.youtube.com/watch?v=ZXsQAXx_ao0).

### Split panes & new tabs
Another ***simple*** tip that's worth sharing, if you're working with an article and your Sanity website already has live preview that looks like below, there's a good chance you can split it into two panes and work side by side. ***Even better***, if your application is setup correctly, you can open the preview URL on a new tab and switch between the two to see your content in real time. Check out the video for more information below.

## Image optimisation shouldn't be a thing
Hot take incoming... Optimising images shouldn't be an issue. [Nor should videos](https://www.mux.com) (but that's another story). I honestly think this has to be the number one pain point for most marketers we know. You shouldn't be thinking about pixels on a screen you should be focusing on your voice, your take, your opinions as efficiently as possible.

So when marketers work with Sanity, you should **expect** and ***allow*** them to upload an image so big, that when they open it, the fans on the laptop sound like they're going to take off.

It's **your** problem as a dev to optimise the hell out of it. **Not** the marketers'.

> **Sanity CMS development**: Editorial UX, custom components, and Sanity studio design that editors actually enjoy. [Learn more](/services/sanity)

### A note on Sanity & aspect ratio
I'm going to keep hammering this home until it's known more commonly. If you're using Next Image (or any image loader) and you want to know the image aspect ratio: [It's achievable with this util library](https://github.com/sanity-io/asset-utils). *It just works*.

## Sharing is caring
Who doesn't love oversharing. Whether it's your uncle telling you about his new ointment cream, or an auntie showing her trip to France and the 100's of out-of-focus pictures that follow...

For marketing, it's basically the same with finding your groove with target platforms. So here's a great tip. ***Make it easier***.

For example, for Roboto Studio, you'll find us cluttering up the Sanity exchange with all our *hopefully* helpful content. So how did we get our team to go the extra mile? Well, we generated our images for this ***programmatically*** using Open Graph Image Generation. We even made a little preview pane so that you can literally ***right click*** and copy the picture.

![Open Graph image generation surfaced inside of Sanity](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/making-your-editorial-experience-that-little-bit-better-blog-open-graph-image-generation-surfaced-inside-of-san.png)

## I hope you enjoyed reading this
Thanks for getting this far, and we hope you learnt something on the way. But in all honesty, besides wanting to share our top tips of improving editorial experiences...

*We mostly just wanted to publish this article because ChatGPT 4 released the image update so that we could get higher resolution Victorian cats.*

However, we do always talk about: [Sanity](/services/sanity), [Next.js](/blog/dynamic-open-graph-with-sanity-and-next-js), Vercel and web development as a whole, so if you're interested in learning more, there's a whole bunch of articles we've written prior. Or, if you want to get your website **grilled** and **improved**, get in touch with us below.

---

## What we learnt updating the Roboto website V3


> We know Next.js app router is catching more heat than the inside of a fresh McDonalds apple pie, but we wanted to test it out. Here's our honest thoughts.

**Published:** 2023-07-05 | **Updated:** 2026-08-03 | **Categories:** Next.js, Sanity
---

## Tailwind can be humbling
Well, I don't want to admit it, but I got irrationally mad at trying to work out how to center a div for the first time in about 4 years. Thanks to the naming convention of [justify-content](https://tailwindcss.com/docs/justify-content) and [justifyitems](https://tailwindcss.com/docs/justify-items) I ended up spending far more time than I would like to have simply aligned the navigation. As with any new tool, there are always growing pains, however, let me tell you about the extensions you **need.**

- [Tailwind Docs VS Code Extension](https://marketplace.visualstudio.com/items?itemName=austenc.tailwind-docs)
- [Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss)
- [Tailwind prettier plugin](https://tailwindcss.com/blog/automatic-class-sorting-with-prettier)

## Wait, I don't need to rebuild Sanity
You know the most beautiful aspect of a well-built Sanity environment... The fact that we built it once, about 3 years ago (from the time of this post), and we're still using it now, without rebuilding.

For anybody that's not in the agency realm, that's pretty much unheard of. It's nearly always a "full rebuild" - not because developers want to, but often because the CMS or Frontend has gotten out of control and scaled wildly without paying off the all-important development debt.

That's why it's such an achievement to say we've seen Roboto go through 3 refactors, and not once have we started again. That's the power of [headless](/services/headless-cms).

That being said, it's always worth [brushing up on your GROQ queries, we actually wrote about this here](/blog/clean-your-groq)

## Previews are as fast as ever
Sanity's Perspectives feature changes how content previewing works. It simplifies creating audience-specific views, letting developers customize content variations for distinct experiences. With Perspectives, a single parameter can be introduced to query content, making it extremely versatile for contextual content variations across devices, channels, and contexts. This increases the developer's capacity to build previews and improves the experience for both content teams and their target viewers.

There are three distinct perspectives available: "previewDrafts," which retrieves draught documents, "published," which returns just published versions, and "raw," which retains the existing query functionality. These views provide developers with flexibility and control while assuring a smooth transition. By simplifying complex queries and providing

## For the Code Part of live previews
It's quite handy in the field of content management and live preview setups to construct a reusable live preview component for larger applications. This method entails creating a versatile component named "PreviewWrapper," which aids in the management of live queries and effectively provides live-updated content to child components. The true magic here is enabled by @radix-ui/react-slot, a mechanism that allows components to effortlessly transfer props to their direct children, regardless of what those children are.

So, here's how it works: Based on the preview mode and query parameters, PreviewWrapper determines whether to display initial data or live-updated content. Meanwhile, PreviewData handles acquiring and updating live data, ensuring that the child components always have the most up-to-date information. more on this here

## Thoughts on Chakra UI
People that know me, know that I love Chakra UI. So what's my opinion after using Tailwind... Well, I still really like it. I would go as far as to say, that I would suspect you will probably be able to build a **website** faster with it than you would with Tailwind.

However, there's a huge difference we've noticed in performance, that isn't entirely down to tailwind, but because of the lack of "use client". [I've written an entire article on it here](/blog/the-state-of-chakra-ui-and-next-13-4), but the TL;DR is - more "use clients" worse performance, and Chakra UI uses a **lot** of "use clients".

So if you're wedded to the original [pages router](https://nextjs.org/docs/pages), I wouldn't use Tailwind.css and just use Chakra UI because it'll slip into your app easier than having to setup tailwind configs, and the extra rules around it.

However, if you're building greenfield in the new [app router](https://nextjs.org/docs/app/getting-started), honestly, just use Tailwind for now. It'll probably set you up for the future until all the issues relating to design tokens and "use clients" are solved. [More on this here](https://www.adebayosegun.com/blog/the-future-of-chakra-ui).

## Would I use app router to build a website right now?
***Yes.***

Long answer: Quick refreshes seems a little slower right now, from our experience, which wasn't really *game breaking*, as it's literally near imperceivable 100ms... But it's ever so slightly annoying.

However, the trade-off right-now is:

- Easier to achieve top-tier performance
- Simpler flow when fetching data
- Overall cleaner components (***if done correctly***)
- Anecdotally faster build speeds

But as an honest take - I think RSC React Server Components are here to stay, and they're a painful evolution to the React ecosystem. In the same way, everybody was split with hating/loving React hooks, I suspect the fuss will die down and it'll be the de-facto way to build modern React applications after a year or so of adoption.

## What about Vercel? You haven't mentioned Vercel?
Literally, just before pressing publish I realised we've come this far and not even spoke a peep about Vercel. Well, guess what? It was set and forget, and I didn't even have to touch a single setting.

We created one big PR and we worked through all the different aspects of the website, all whilst simultaneously keeping a version of the website in stasis. We just merged it in, and ***"it just worked"***

The most awe-inspiring reason to use Vercel, and the reason we so often hammer on about it is also probably the most mundane - **it just works**, whatever tool you're using, framework or headless content management system, it'll work flawlessly with image optimisation, CDN, CI/CD, Data Storage etc etc...

Best of all, **you're paying like $20 a user**. Don't complicate things, just keep it *easyyyyy*

## Quick update:
We're on the Sanity Exchange featured project - couldn't be happier. If anybody needs any help migrating over we would love to help. If you're a dev starting out with Sanity [hit us up](mailto:hello@roboto.studio), and if you're looking for [an effortless migration to Sanity](/migration)

> **Next.js development**: App router, server components, and performance-first builds. [Learn more](/services/nextjs)

---

## Actually using Figma dev mode - is it any good?


> Ever get frustrated with Zeplin, Figma Inspect, or other dev/design tools? Dive into our 24-hour deep-dive full of hard-hitting questions and raw insights. 

**Published:** 2023-06-22 | **Updated:** 2026-08-24 | **Categories:** Hot Takes
---

Well, that wasn't something we were expecting to see today. Usually, we're pretty clued up on product releases, but this hit us out of left field.

![Figma dev mode](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/actually-using-figma-dev-mode-is-it-any-good-blog-figma-dev-mode.png)

## How well does it work?
Well, at the time of writing this, it's probably been out for under 24 hours, but as a *tenacious* and frankly "no-life" web developer. I can confirm one thing: It's much better than it was.

If you've been following us recently, you'll know that we've begrudgingly started to adopt Tailwind because of the way that React Server Components are going. Why does this matter? Because coincidentally, it works pretty damn well with Tailwind.css.

Similar to Zeplin (if you ever used that), it allows you to add plugin-like extensions to what platforms it supports. So in our case, we were able to tap into the power of Figma dev, however, for Chakra UI... Not so much.

## Quick example
I'll give you the breakdown of a piece of code and design, and you'll quickly see some of the smart elements of the language extension that I absolutely thought it would *fall down* with.

![The Figma component](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/actually-using-figma-dev-mode-is-it-any-good-blog-the-figma-component.png)

### Oh boy, designers are going to be happy
Cue the extremely elegant and well-optimised code... Guess not.

So what went wrong, why is it massive and all over the place? Well it's due to inaccuracies with sizing and images being placed on non-whole-numbers and creating a huge amount of manually sized [404.11px].

```javascript
<div className="w-[404.11px] h-[455px] px-6 py-8 bg-slate-800 rounded-2xl flex-col justify-start items-center gap-6 inline-flex">
    <div className="w-[356.11px] h-[203px] pl-[33.77px] pr-[34.07px] pt-[29.90px] pb-[30.06px] justify-center items-center inline-flex">
        <div className="w-[288.27px] h-[143.04px] relative">
            <div className="w-[215.04px] h-[68.08px] px-[11.01px] py-4 left-[20px] top-[58px] absolute bg-white rounded-xl shadow border border border border border-slate-200 flex-col justify-center items-start gap-[11.01px] inline-flex">
                <div className="self-stretch p-[0px] justify-start items-center inline-flex">
                    <div className="grow shrink basis-0 h-[35.50px] p-[0px] justify-start items-start gap-[11.01px] flex">
                        <div className="p-[0px] opacity-0 justify-start items-start gap-[11.01px] flex">
                            <div className="w-[33.02px] h-[33.02px] p-2 bg-sky-50 rounded-[55.03px] justify-center items-center flex">
                                <div className="w-4 h-4 relative flex-col justify-start items-start flex" />
                            </div>
                        </div>
                        <div className="grow shrink basis-0 self-stretch py-[2.75px] flex-col justify-center items-start inline-flex">
                            <div className="text-slate-900 text-[16px] font-semibold leading-snug">Visit 2</div>
                            <div className="text-slate-500 text-[14px] font-normal leading-tight">Window ±7 Days • Week -1</div>
                        </div>
                    </div>
                    <div className="w-[11.01px] h-[11.01px] relative" />
                </div>
            </div>
            <div className="w-[225.83px] h-[67.25px] px-[11.01px] py-4 left-[55px] top-[0px] absolute bg-white rounded-xl shadow border border border border border-slate-200 flex-col justify-center items-start gap-[11.01px] inline-flex">
                <div className="self-stretch p-[0px] justify-start items-center inline-flex">
                    <div className="grow shrink basis-0 h-[35.50px] p-[0px] justify-start items-start gap-[11.01px] flex">
                        <div className="p-[0px] opacity-0 justify-start items-start gap-[11.01px] flex">
                            <div className="w-[33.02px] h-[33.02px] p-2 bg-sky-50 rounded-[55.03px] justify-center items-center flex">
                                <div className="w-4 h-4 relative flex-col justify-start items-start flex" />
                            </div>
                        </div>
                        <div className="grow shrink basis-0 self-stretch py-[2.75px] flex-col justify-center items-start inline-flex">
                            <div className="text-slate-900 text-[16px] font-semibold leading-snug">Visit 1</div>
                            <div className="text-slate-500 text-[9.631057739257812px] font-normal leading-3">Window ±7 Days • Week -3</div>
                        </div>
                    </div>
                    <div className="w-[11.01px] h-[11.01px] relative" />
                </div>
            </div>
            <div className="w-[91.07px] h-[91.07px] p-[0px] left-[0px] top-[1.90px] absolute bg-sky-50 rounded-[91.07px] shadow justify-center items-center gap-[9.11px] inline-flex">
                <div className="w-[36.43px] h-[36.43px] relative" />
            </div>
            <div className="w-[60.64px] h-8 p-[9.15px] left-[119.25px] top-[53px] absolute bg-white rounded shadow justify-start items-start gap-[4.58px] inline-flex">
                <div className="pt-[2.29px] flex-col justify-start items-center gap-[4.58px] inline-flex">
                    <div className="w-[9.15px] h-[9.15px] relative" />
                </div>
                <div className="text-slate-900 text-[10.297094345092773px] font-semibold leading-3">Cycle</div>
            </div>
            <div className="w-[123.57px] h-8 p-[9.15px] left-[164.70px] top-[111px] absolute bg-white rounded shadow justify-start items-start gap-[4.58px] inline-flex">
                <div className="pt-[2.29px] flex-col justify-start items-center gap-[4.58px] inline-flex">
                    <div className="w-[9.15px] h-[9.15px] relative" />
                </div>
                <div className="text-slate-900 text-[10.297094345092773px] font-semibold leading-3">Screening Period</div>
            </div>
        </div>
    </div>
    <div className="self-stretch h-[164px] p-[0px] flex-col justify-start items-start gap-2 flex">
        <div className="self-stretch text-white text-[20px] font-semibold leading-relaxed">Visits Made Simple</div>
        <div className="self-stretch text-white text-[18px] font-normal leading-relaxed">Visit by visit, the schedule of assessments makes it simple to walk through each procedure with confidence. Notes and guidance documents support adherence.</div>
    </div>
</div>
```

## So what does this all mean?
Well, the shorthand is that for designers, this means they're going to be highly accurate with building Figma files in the future - personally, I think UI designers have had an easy time for too long with this.

It also means that the slap-happy creative ideation will likely be crushed by the new wave of overly specific sizings requested by developers such as myself.

> **Next.js app development**: Design-to-code builds with Next.js, Tailwind, and modern component architecture. [Learn more](/services/nextjs)

## Our rating?
It's pretty good.

It's a great jumping-off point, and any steps further forward in wedding design & development have our vote. I don't think it'll be long before it gets added to job listings as an essential skill and improves handover overall.

---

## How to deploy Sanity with GitHub Actions


> Learn how to deploy Sanity Studio using GitHub Actions: a working workflow file, token setup, and fixes for the common deployment failures.

**TL;DR:** Tired of manual Sanity Studio updates? Automate with GitHub Actions for error-free, fast deployments. Skip the fluff, embrace efficiency. If you read this whole thing, congrats on wasting time. Get with the program and automate already!

**Published:** 2023-06-09 | **Updated:** 2026-07-23 | **Categories:** How To, Sanity
---

If you’ve ever pushed a small update to Sanity Studio only to realize you still need to manually deploy it, you know how frustrating it gets.

That’s where GitHub Actions comes in. Automate the Studio deployment and every push to main goes live on its own, with nobody waiting on a manual deploy.

With this setup, you stay focused on building features while GitHub Actions runs the same deployment steps on every push.

## GitHub Actions for faster, smoother deployment
GitHub Actions is GitHub’s built-in CI/CD (Continuous Integration/Continuous Deployment) tool. You define workflows in YAML files and trigger them on specific events, such as code commits, pull requests, or scheduled intervals.

Sanity CMS, meanwhile, is a headless content management system where developers model structured content for their applications. It has a real-time collaborative editing environment and a content API you can query from anywhere.

And with the latest updates from Sanity and GitHub, deploying your Studio is smoother and safer than ever.

## Why use GitHub Actions for Sanity CMS deployment?
Manual deployments eat up time and increase the chance of errors. Wire GitHub Actions and Sanity together and the Studio deploys itself on every merge: nobody forgets a deploy, nobody ships the wrong branch, and the person who wrote the change doesn’t need to remember a CLI command to get it live.

### Configuring workflow triggers
In the workflow file, it's paramount to define the triggers that will initiate the deployment process. GitHub Actions provides several event types that can trigger workflows, such as push events, pull requests, and scheduled intervals.

Here’s an example of how you can configure a workflow to trigger on a push to the ‘main’ branch:

```yaml
name: Deploy sanity studio

on:
  push:
    branches: [main]
```

In this e.g., the workflow runs whenever a push occurs on the ‘main’ branch. You can customize the triggers as per your needs.

## Getting started with GitHub Actions
Now that you know how triggers work, let’s create the actual workflow file in your repository. This file defines the steps GitHub Actions will run whenever your chosen event (like a push to ‘main’) occurs.

### Setting up a GitHub repository
Before utilizing GitHub Actions for CMS, you need a repository on GitHub (if you already have one, skip this step). Otherwise:

1. Log in to your GitHub account and navigate to the main page.
1. Click "New" near the top-left corner.
1. Provide a meaningful repository name and description (optional).
1. Choose public or private, depending on your needs.
1. Select "Initialize" with a "README" (it's optional but recommended).
1. Click "Create repository".

### Creating a workflow file
Once you’ve created your repository, create a workflow file to define the deployment process. The workflow tells GitHub Actions what to do when specific events (like a push to ‘main’) occur. Follow these steps:

1. In your repository, go to the "Actions" tab.
1. Click "Set up a workflow yourself", or pick a template.
1. Name your workflow file (e.g., deploy-sanity.yml).
1. Make sure it ends with .yml (YAML syntax).
1. Open the file in your editor and add the workflow instructions (we’ll show you an updated example in the next section).

Know more from[ GitHub Actions workflow tutorial](https://docs.github.com/en/actions).

## Configuring Sanity for deployment
Before deploying with GitHub Actions for CMS, make sure you have a few essentials ready:

1. Sanity project: Either create a new project or use an existing one. For a quick start, check out our [Working with Turbo Start Sanity](/blog/working-with-turbo-start-sanity) guide to bootstrap your project in minutes. Make sure your schema is defined. Read [Sanity CMS deployment guide](https://www.sanity.io/docs)
1. API token: Generate a token with ‘Deploy Studio’ permissions and add it to your GitHub repository secrets as *SANITY_AUTH_TOKEN*.
1. Add CI Specific secrets like
  1. *SANITY_STUDIO_PROJECT_ID*
  1. *SANITY_STUDIO_DATASET*
  1. *SANITY_STUDIO_TITLE*
  1. *SANITY_STUDIO_PRESENTATION_URL*
1. Deployment provider: Decide where your Studio will live Vercel, Netlify, AWS Amplify, or another provider. For insights on [Sanity and Next.js integration best practices](/blog/our-2024-takeaways-with-sanity-and-nextjs), check out our comprehensive takeaways from real-world projects.

Once that’s in place, here’s an updated workflow example using the latest Sanity GitHub Action:

```yaml
name: Deploy Sanity Studio
on:
  push:
    paths:
      - "apps/studio/**"
      - ".github/workflows/deploy-sanity.yml"
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    name: Build and Deploy Sanity Studio
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      SANITY_AUTH_TOKEN: ${{ secrets.SANITY_AUTH_TOKEN }}
      NODE_OPTIONS: "--max_old_space_size=4096"
      PNPM_VERSION: 10.12.2
      SANITY_STUDIO_PROJECT_ID: ${{ secrets.SANITY_STUDIO_PROJECT_ID }}
      SANITY_STUDIO_DATASET: ${{ secrets.SANITY_STUDIO_DATASET }}
      SANITY_STUDIO_TITLE: ${{ secrets.SANITY_STUDIO_TITLE }}
      SANITY_STUDIO_PRESENTATION_URL: ${{ secrets.SANITY_STUDIO_PRESENTATION_URL }}
      HOST_NAME: ${{ github.head_ref || github.ref_name }}  

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - name: Install pnpm
        uses: pnpm/action-setup@v2
        with:
          version: ${{ env.PNPM_VERSION }}
          run_install: false

      - name: Setup Node.js environment
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - name: Install dependencies
        run: pnpm install --frozen-lockfile --ignore-scripts --prefer-offline

      - name: Deploy Sanity Studio
        if: steps.check-dependabot.outputs.is_dependabot != 'true'
        working-directory: ./apps/studio
        run: |
          echo "Deploying Sanity Studio..."
          pnpm run deploy
        env:
          CI: true

```

This workflow:

- Uses the latest Sanity GitHub Action (v0.8-alpha)
- Supports custom studio paths for monorepos

> **Sanity CMS development**: Automated deployments, CI/CD pipelines, and Sanity infrastructure setup. [Learn more](/services/sanity)

### What’s new in Sanity Studio?
Sanity Studio is now at v4.9.0 (2025). With v4, the CLI is more powerful, sanity.cli.ts config is flexible, at the same time, some old commands or flags no longer work.

To avoid frustrating "command not found" errors, always check your Studio version and update your workflows accordingly.

### Security and token management
Security is critical in CI/CD. Here’s the safest way to handle it:

1. Create a "Deploy Token" inside Sanity
1. Store it in GitHub Secrets (Settings → Secrets → Actions) as SANITY_DEPLOY_TOKEN
1. Never hardcode tokens into your workflow file
1. For multiple environments (staging/prod), create separate tokens & datasets, and load them dynamically via secrets

Sanity now supports flexible sanity.cli.ts config, so you can pass environment-specific project IDs, datasets, and hosts cleanly.

## Troubleshooting your deployment
Even with a smooth setup, issues can happen. Here are some common ones and quick tips to fix them:

1. Authentication errors: Check that your API tokens are correct and stored in GitHub secrets.
1. Build failures: Review logs for missing dependencies or syntax errors, and fix them in your project.
1. Deployment timeouts: Large projects may exceed workflow limits, optimize your build or adjust timeout settings.

GitHub Actions provides detailed logs to help you pinpoint problems and debug efficiently.

### Best practices we’ve learned
Over time, here are a few things that has made our deployment easier:

1. Ignore clutter: Add .sanity to .gitignore
1. Monorepos made easy: Use studioPath or SANITY_STUDIO_CONFIG_PATH
1. Double check: Skim GitHub Action logs after each deploy, they catch 90% of issues early

## Conclusion
The days of manually pushing Sanity Studio builds are gone. Set the workflow up once and every merge to main ships the Studio for you, the same way, every time. The half hour it takes to configure pays for itself in the first week.

Recent Sanity CLI updates made this easier too: flexible `sanity.cli.ts` config and safer token handling mean the workflow file above is shorter than it would have been a year ago.

If your Studio still ships by hand, this is a good afternoon project.

---

## The best Next.js & Sanity Image component


> Think you know Sanity images in Next.js? Our guide sets the record straight, with code snippets for easy implementation. Get the definitive approach here. 

**Published:** 2023-06-09 | **Updated:** 2026-07-23 | **Categories:** Next.js, Sanity
---

We'll keep it short and sweet.

> This is the ideal **Next Sanity Image**. You may not like it, but this is what peak image performance looks like.
```jsx
import { ReactElement } from 'react';
import Image from 'next/image';
import { getImageDimensions } from '@sanity/asset-utils';
import { urlFor } from '~/lib/sanity';

export const IdealImage = ({ image }): ReactElement => {
  const alt = image?.alt ?? "image broke";
  const dimensions = getImageDimensions(image); 
  return (
    <div>
      ...
      {image?.asset && (
        <Image
          src={urlFor(image).url()}
          alt={alt}
          width={dimensions.width}
          height={dimensions.height}
          placeholder="blur"
          blurDataURL={urlFor(image).width(24).height(24).blur(10).url()}
          sizes="
            (max-width: 768px) 100vw,
            (max-width: 1200px) 50vw,
            40vw"
        />
      )}
      ...
    </div>
  );
};

```

So let's start by breaking down what each bit does, why it's useful, and why you're ***not going to break your entire website by trying to reference an image that doesn't exist*** within the preview.

### getImageDimensions
I'd put a fairly *hefty* bet on the fact you haven't seen this before. It's an absolute banger of a utility library that allows you to pull dimensions from an image.

*Why is that useful*? Well because one of the main features of using Next/Image is to avoid something called [Cumulative Layout Shift](https://web.dev/articles/cls). In short, that's the thing when you go on a website and it shifts and you end up clicking on a crappy ad instead of what you wanted.

### blurDataURL
You've all seen those lovely blur up effects on Next/Image, so we thought we'd build something identical using the [@sanity/image-url](https://www.sanity.io/docs/apis-and-sdks/image-urls). This essentially loads a much smaller version first and with added blur, makes it look elegant. Then moves onto the higher quality version when loaded

### Sizes="..."
This is pretty cool if you haven't seen this before. This is Next.js way of handling the different sizes for the different screen sizes. Essentially this is saying:

#### (max-width: 768px) 100vw
Up to a size of 768px, the maximum size will be 100% width of the screen. This means that when you're on a mobile or small tablet. The maximum size rendered will be the full width of that screen (as you mostly stretch images to the size of the screen in responsive views).

See below for how it looks on mobile - can you see how the image is nearly 100% of the width of the screen?

![Image on mobile screens](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-best-nextjs-and-sanity-image-component-blog-image-on-mobile-screens.png)

#### (max-width: 1200px) 50vw
This on the other hand is saying that below 1200px, the image will be a maximum of 50vw e.g. if the screen is 1000px wide, at most the image will be 500px.

The reason for the difference in change is that instead of the image being 100% width, we now stack the image on the right, and the text on the left.

Take a look at this now, it makes sense right?

![Image on the right, text on the left showing the screen on large tablet, small desktop mode](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-best-nextjs-and-sanity-image-component-blog-image-on-the-right-text-on-the-left-showing-the-sc.png)

#### 40vw
So everything above 1200px is now going to be at max 40vw. That's the easiest one to get. The reason for doing so is that the container progressively takes up less and less of the screen real estate and is going to probably be less than 40% of the overall size.

Again, pretty clever, and works like a charm

> **Sanity CMS development**: Image optimization, CDN setup, and Sanity + Next.js performance tuning. [Learn more](/services/sanity)

![The image and text showing how it takes up less than 40% of the screen real estate above 1200px](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-best-nextjs-and-sanity-image-component-blog-the-image-and-text-showing-how-it-takes-up-less-th.png)

## Aspect Ratio & Cumulative Layout Shift (CLS)
Aspect ratio (the proportional relationship between an image's width and height) is an essential aspect of web page design. Google highly values the optimal use of aspect ratio and static heights & widths, according to Cumulative Layout Shift (CLS) – a metric measuring the surprise positional changes of contents during page load. Heavy CLS often distorts user experience as it results in accidental clicks or difficulty in reading. If you want to actually see exactly how good/bad your current CLS [there's a great tool here](https://defaced.dev/tools/layout-shift-gif-generator/)

## Image Rendering Modes
There are typically four common ways to handle image displaying, especially considering responsiveness:

**1. `width: auto` and `height: auto`:** Both preserve the original aspect ratio within the parent container's dimensions. However, they may not cover its full extent.

**2. `width: 100%` and `height: auto`**: Forces the image to span the full width of its parent, self-adjusting its height to retain the original proportion.

**3. `objectFit: "cover"`**: Corresponding CSS's `background-size: cover`, it scales the image to cover its parent, potentially cropping parts due to aspect ratio differences.

**4. Static `width` and `height` values**: Ignores the parent size and original aspect ratio, rigorously sets the image's height and width.

## Any other parts?
Well, that's about it, it's using the latest version of Next/Image so be aware that there have been significant changes over the years, but as for the latest and greatest, this is what [Roboto](https://robotostudio.com) is using. If you want us to set this up for you as part of a wider [Sanity](/services/sanity) and [Next.js](/services/nextjs) build, give us a shout.

---

## Red flags to avoid when hiring a Sanity agency


> Looking for a Sanity CMS agency? Explore our complete guide covering pros, cons, and red flags. (Fair warning: we're an agency, but only slightly biased!) 

**Published:** 2023-05-23 | **Updated:** 2026-08-24 | **Categories:** Sanity
---

Are you looking for your next project? Already know what you want? A fresh new Sanity CMS-powered website... *[in that case, our Sanity CMS development agency has you covered](/services/sanity).*

But, *in all seriousness*, how do you know what the right agency is for you? We go through some top tips to find out what you should be looking for, and some red flags to know if things are awry.

## Define your project and budget
Clearly articulate the goals, scope, and budget for your project. This will help you narrow down potential agencies and ensure that you're considering options that fit your needs well.

If we were to write a brief, we would start with the most specialised and tricky subjects to try and get a handle on the budget. E.g if you know you want a multi-step authoring process, that's where a lot of time and money will be used - so write down the most important (and complicated) features to you.

If you want a quick *ballpark estimate*, most agencies will require approx **$20k+ budget** as a bare minimum. Some require far more, and the odd freelancer may be able to work with less than that. If you're looking at getting yourself out there on the web and don't really have that much of a budget, we've written an article with the price points & caveats here.

If you're not sure what your needs are or what's new in the latest version of Sanity, [we have a helpful primer available here](/blog/what-sanity-studio-v3-means-for-clients). If you just want to play around with a feature-rich Sanity environment we also have a [demo available here](https://robotodemo.vercel.app) - [get in touch for access](mailto:hello@roboto.studio).

## Research potential agencies
Look for agencies that have experience in your industry and a track record of delivering successful projects. You can use search engines, online directories, and industry associations to find potential options.

There are a few important things to remember (we must stress this is *in our opinion*)

1. Always opt for specialists instead of *Jack of all trade *agencies, as they typically output better work, and because they're only working with a few technologies, they will know more about the limitations.
1. Be careful of agencies that are trying to push a specific technology because of the kickback they might get. ***Some*** agencies push a specific technology not because they believe in it but because they get a £££ *"signing on"* fee for upselling you expensive tech; they don't believe in themselves. Needless to say, Roboto **uses the same tech we implement for clients.**
1. Check they're up to date with the latest technologies. Throw a curveball. If you want a real doozie to ask, ask: "I've heard about React Server Components; what impact does that have on building JAMstack websites?" - *that'll stump most people* and also give you a good understanding as to whether the agency can give a laymen's understanding of more complex functionality.

## Look for agency culture fit
This is the most overlooked factor in working with an agency, and one of the most important. Choose somebody you like because you're probably going to be spending the next two months+ communicating with them.

It's also worth mentioning that you want to ensure the person you are talking to, will be the project manager or a point of contact on the project.

## Evaluate their technical skills
Look for agencies with a strong technical team with experience in the technologies and frameworks relevant to your project. This will ensure they have the skills and expertise to deliver a high-quality product.

As mentioned earlier, don't pick generic technology agencies - choose the one that you're most interested in. E.g. don't get a WordPress agency to build you a Headless Next.js website.

> If you're looking at assessing technical skills, always ask for a real-time preview.
They're hard to build *well*, so it's a good benchmark for development skills

## Communication
Communication is a huge part of success when picking an agency, so ask about **how** you will communicate with the project manager or developers. Is it through Slack? Or do you operate with email? How often will we have catchup meetings?

Preview environments are extremely useful - it may not strictly be communications, but seeing your website grow and having a feedback loop is essential to a high-quality product.

## Negotiate budget
We always recommend being upfront with your budget for a web build, and it's a very simple reason why. An agency can give you a *ballpark estimate of what you can build* with a simple figure.

What's more important is what is and isn't possible. *For example* if somebody approached us with 40 unique pages, they need building with a strict set of components for each - we wouldn't be able to achieve that **with a £10k budget**... *However, *if the designs are fairly homogenous and only the data is being changed, that's far easier with something like a page builder.

By being transparent about the budget, an agency would be able to advise the best method of getting to the results that you want, even if it may be in a way that you hadn't initially thought of.

> **Sanity CMS development**: Schema design, migrations, and ongoing CMS support from an official Sanity partner. [Learn more](/services/sanity)

## Check their portfolio
Look at the agency's portfolio to see examples of their work and get a sense of their design style and technical capabilities. We are conflicted a little bit about this, because we have a lot of NDA's ourselves and would love to share some of the more complex projects, but it can be tricky.

That being said, there should be some internal tools present or something they can point to to say, "Look what we can do".

1. Consider their process and communication: Choose an agency that has a well-defined project process and good communication practices. This will help ensure that your project stays on track and that you're informed about progress and any issues that arise.
1. Get references: Ask the agency for references from past clients and follow up with them to get a sense of what it's like to work with the agency.
1. Negotiate the contract: Once you've found an agency that seems like a good fit, negotiate the terms of the contract, including the budget, timeline, and any other details that are important to your project.

## References
References are a great benchmark for understanding the pros and cons of an agency. They provide insight into the quality of work and level of customer satisfaction that can be expected from the agency. A development agency with a strong track record of positive references is likely to be more reliable and trustworthy than one without any, or with mostly negative, references.

Additionally, speaking with previous clients can help gauge the agency's communication and project management skills and their ability to deliver on time and within budget.

## Shameless self-promotion
If you're looking for a [Sanity CMS development agency](/services/sanity), we are always interested in hearing about your spec and what you would like to achieve. You can check out our [case studies](/case-study) to see how we've delivered for other teams, or jump straight into our [workshops](/services/workshops) if you want to move fast. Let us know if you want us to give you some pointers and an honest take on what makes a great Sanity project.

---

## Setting up live preview for sanity on next 13.4 using drafts mode


> Set up Sanity live preview with Next.js 13.4 draft mode. Step-by-step guide covering the draftMode API, preview routes, and real-time content updates.

**Published:** 2023-05-23 | **Updated:** 2026-07-23 | **Categories:** How To, Sanity, Next.js
---

## Using Live Preview on Sanity and Next 13.4
### Introduction
Have you ever found yourself wondering how your website will look before hitting the publish button? Do you want to make sure everything is perfect before presenting it to the world? Well, now you can with Live Preview on Sanity and [Next 13.4](/services/nextjs).

Live Preview is a feature that allows you to see how your website will look in real-time. It provides you with an interactive preview of your content, so you can make changes and see how they affect the overall design of your website. It is a handy tool for web developers, content creators, and anyone who wants to ensure that their website looks and functions as intended.

In this article, we will explore the benefits of using Live Preview on Sanity and Next 13.4, how it works, and how to get started.

### Understanding Sanity and Next 13.4
If you're new to Sanity and Next 13.4, it's essential to have a basic understanding of what they are and how they work together. Sanity is a headless CMS that allows you to create, manage, and distribute content to any platform or device. Next 13.4 is a popular React framework for building web applications. When used together, Sanity and Next 13.4 provide a powerful platform for creating dynamic, responsive websites.

One of the advantages of using Sanity and Next 13.4 is that they allow you to separate the content from the presentation layer. This means that you can focus on creating high-quality content without having to worry about how it will look on the website. The content is stored in Sanity, and Next 13.4 pulls the content from Sanity and uses it to generate the website.

### Setting up Live Preview
#### On the sanity side,
we use a custom preview component.

There are three things to take care of. 

1. Resolving preview URLs
1. sanity desk structure
1. preview component 

Resolving preview URLs 

```typescript
// resolveProductionUrl.ts
import type { SanityDocument } from 'sanity';

// Store secrets in environment variables, never in source code
const previewSecret = process.env.SANITY_PREVIEW_SECRET!;
const remoteUrl = process.env.NEXT_PUBLIC_SITE_URL!;
const localUrl = process.env.NEXT_PUBLIC_LOCAL_URL || 'http://localhost:3000';

function getSlug(slug: any) {
  if (!slug) return '/';
  if (slug.current) return slug.current;
  return '/';
}

export default function resolveProductionUrl(doc: SanityDocument) {
  const baseUrl =
    window.location.hostname === 'localhost' ? localUrl : remoteUrl;
  const previewUrl = new URL(baseUrl);
  const slug = doc.slug;
  previewUrl.pathname = `/api/draft`;
  previewUrl.searchParams.append(`secret`, previewSecret);
  previewUrl.searchParams.append(`slug`, getSlug(slug));
  return previewUrl.toString().replaceAll('%2F', '/');
}

```

Sanity Desk Structure

```typescript

// structure.ts
import { FaHome, FaFile, FaFileWord, FaQuestionCircle } from 'react-icons/fa';
import { StructureBuilder } from 'sanity/desk';
import { PreviewIFrame } from './component/preview';

export const structure = (S: StructureBuilder) =>
  S.list()
    .title('Content')
    .items([
      S.listItem()
        .title('Main Page')
        .icon(FaHome)
        .child(
          S.document()
            .views([
              S.view.form(),
              S.view
                .component(PreviewIFrame)
                .options({ test: 'ss' })
                .title('Preview'),
            ])
            .schemaType('mainPage')
            .documentId('mainPage'),
        ),
      S.divider(),
      S.documentTypeListItem('page').title('Page').icon(FaFile),
      S.documentTypeListItem('blog').title('Blog').icon(FaFileWord),
      S.documentTypeListItem('faq').title('FAQs').icon(FaQuestionCircle),
    ]);

export const defaultDocumentNode = (S: StructureBuilder) =>
  S.document().views([
    S.view.form(),
    S.view.component(PreviewIFrame).options({}).title('Preview'),
  ]);

```

Preview Component 

```tsx
// studio/component/preview.tsx
import {
  Box,
  Button,
  Card,
  Flex,
  Spinner,
  Text,
  ThemeProvider,
} from '@sanity/ui';
import { AiOutlineReload } from 'react-icons/ai';
import { BiLinkExternal } from 'react-icons/bi';
import { useEffect, useState, useRef } from 'react';
import resolveProductionUrl from '../resolveProductionUrl';

export function PreviewIFrame(props: any) {
  const { options, document } = props;
  const [id, setId] = useState(1);
  const { displayed } = document;
  const [displayUrl, setDisplayUrl] = useState('');
  const iframe = useRef<HTMLIFrameElement>(null);

  function handleReload() {
    if (!iframe?.current) return;
    setId(id + 1);
  }
  useEffect(() => {
    function getUrl() {
      const productionUrl = resolveProductionUrl(displayed) ?? '';
      setDisplayUrl(productionUrl);
    }
    getUrl();
  }, [displayed]);

  if (displayUrl === '')
    return (
      <ThemeProvider>
        <Flex padding={5} align="center" justify="center">
          <Spinner />
        </Flex>
      </ThemeProvider>
    );

  return (
    <ThemeProvider>
      <Flex direction="column" style={{ height: `100%` }}>
        <Card padding={2} borderBottom>
          <Flex align="center" gap={2}>
            <Box flex={1}>
              <Text size={0} textOverflow="ellipsis">
                {displayUrl}
              </Text>
            </Box>
            <Flex align="center" gap={1}>
              <Button
                fontSize={[1]}
                padding={2}
                icon={AiOutlineReload}
                title="Reload"
                text="Reload"
                aria-label="Reload"
                onClick={() => handleReload()}
              />

              <Button
                fontSize={[1]}
                icon={BiLinkExternal}
                padding={[2]}
                text="Open"
                tone="primary"
                onClick={() => window.open(displayUrl)}
              />
            </Flex>
          </Flex>
        </Card>
        <Card tone="transparent" padding={0} style={{ height: `100%` }}>
          <Flex align="center" justify="center" style={{ height: `100%` }}>
            <iframe
              key={id}
              ref={iframe}
              title="preview"
              style={{ width: '100%', height: `100%`, maxHeight: `100%` }}
              src={displayUrl}
              referrerPolicy="origin-when-cross-origin"
              frameBorder={0}
            />
          </Flex>
        </Card>
      </Flex>
    </ThemeProvider>
  );
}

```

### On the Next.js Side of things
creating an API route to configure the draft mode 

enabling drafts mode

```typescript
// src/app/api/draft/route.ts
import { draftMode } from 'next/headers';

import { SANITY_PREVIEW_SECRET } from '~/config';
import { nativeRedirect } from '~/lib/utils';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const secret = searchParams.get('secret');
  const slug = searchParams.get('slug');

  // SANITY_PREVIEW_SECRET is the same secret from above resolve preview url.
  if (secret !== SANITY_PREVIEW_SECRET || !slug) {
    return new Response('Invalid token', { status: 401 });
  }

  // Validate slug to prevent open redirects - must be a relative path
  if (!slug.startsWith('/') || slug.startsWith('//') || slug.includes('://')) {
    return new Response('Invalid slug', { status: 400 });
  }

  const draft = await draftMode();

  draft.enable();

  return nativeRedirect(slug);
}

```

disabling draft mode

```typescript
// src/app/api/disable-draft/route.ts
import { draftMode } from 'next/headers';

import { nativeRedirect } from '~/lib/utils';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);

  const draft = draftMode();

  draft.disable();

  return nativeRedirect('/');
  // there was a bug using redirect on this next version 
  // but now its patched up you can simply use 
  // redirect from "next/navigation";
}

```

As there was a bug on using redirects on next 13.4 which is fixed by the way, that made me use this custom redirect helper

> **Sanity CMS development**: Live preview, visual editing, and Sanity + Next.js integration for real-time content workflows. [Learn more](/services/sanity)

```typescript
// lib/utils

export const nativeRedirect = (path: string) =>
  new Response(null, {
    status: 307,
    headers: {
      Location: path,
    },
  });
```

using Preview on the route.

```typescript
import { Metadata } from 'next';
import { draftMode } from 'next/headers';
import { notFound } from 'next/navigation';
import { getMetaData } from '~/helper';
import { getClient } from '~/lib/sanity';
import { mainPageQuery } from '~/lib/sanity.query';
import { MainPage } from '~/schema';
import { MainPageBlock } from './component';
import { PreviewWrapper } from './preview';

const getMainPageData = (preview?: boolean) =>
  getClient(preview).fetch<MainPage>(mainPageQuery);

export const generateMetadata = async (): Promise<Metadata> => {
  const data = await getMainPageData();
  if (!data) return {};
  return getMetaData(data);
};

export default async function HomePageWrapper() {
  const { isEnabled } = draftMode();

  const mainPage = await getMainPageData(isEnabled);

  if (!mainPage) notFound();

  if (!isEnabled) return <MainPageBlock data={mainPage} />;

  return (
    <PreviewWrapper
      initialData={mainPage}
      query={mainPageQuery}
      queryParams={{}}
    />
  );
}

```

### Live Preview in Action

---

## The state of Chakra UI & Next 13.4


> Has Chakra UI's roundtable seat been jeopardised by Next & React's shift to Server Components? Dive into our analysis to see if it still reigns supreme.      

**Published:** 2023-05-22 | **Updated:** 2026-07-23 | **Categories:** Hot Takes, Next.js
---

We're approaching the renaissance of web development. Or if you've been around the forums on the web... The "PHP Part 2" days. You might be asking why the time is so fraught with discussion and why that awful language (PHP) has been brought up *once again*.

It's React Server Components. You've potentially heard of them, but here's the basic gist of what's happened. They're the new way of handling client/server-side rendering. Why is this important? Well, let me give you the rule of thumb.

> Just use "use client" less
Essentially for the purpose of this explanation, everytime a dev uses "use client", a decent chunk of Javascript is passed to the end user. A chunk of javascript is slow to load, and overall the more chunks of javascript get passed, the slower your website will be and the madder the *overseer* Google will be, and shove you to the bottom of the search results.

## What has this got to do with Chakra UI?
Well if you've been following so far, there's probably a good reason that I've filled the exposition of the first two paragraphs with a definition of "use client".

**You guessed it**. Chakra UI pretty much only works with "use client" and therefore ships a ton of Javascript to the end user. So not good.

Where does this leave us? Well, frankly, there are a couple of solutions how to *band-aid* fix this. See here. But none of them are actually all that convincing of a solution. So the next best thing is flagging this to the world for anybody considering using Chakra UI, such as ourselves.

!["use client" is fine dog](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/the-state-of-chakra-ui-and-next-13-4-blog-use-client-is-fine-dog.png)

## Our thoughts
We personally reckon this issue will be solved in the coming months, as [Next 13.4 (RSC became product-ready)](https://nextjs.org/blog/next-13-4) has only been out for 18 days. However, if you plan to build something using the Next.js app directory and server components, it would be *a safer bet* to use Tailwind.css for now. 

If you're looking for more in-depth takes and checking on progress, [there is a V3.0 roadmap](https://github.com/chakra-ui/chakra-ui/issues/7180). Part of that roadmap includes a static way of handling stylings - which, in theory, means you won't have the "use client" issue **if** they migrate to it. However, we're ultra-cynical at the best of times, so until we see a working prototype, it's probably not something we would rely on seeing the light of day.

> EDIT: Found out there's a [pretty damn good write-up available here](https://www.adebayosegun.com) from Segun Adebayo himself

> **Next.js development**: App router, server components, and Tailwind. Performance-first builds. [Learn more](/services/nextjs)

---

## Our App Router setup with Next 13.4, Tailwind CSS and Sanity


> Build web apps with Next.js 13.4, Tailwind CSS, and Sanity CMS. Our setup for the stable App Router, visual editing, and real-time content collaboration.

**Published:** 2023-05-18 | **Updated:** 2026-07-23 | **Categories:** Next.js, Sanity
---

### Why Next 13.4 matters
With Next 13.4, the App Router is finally stable. Pair [Next.js](https://nextjs.org/blog/next-13-4) with [Tailwind CSS](https://tailwindcss.com) and [Sanity CMS](https://www.sanity.io) and you've got the stack we now reach for on every new build. In this post, we'll look at what the integration actually gives you.

### The dynamic... trio: Next.js, Tailwind CSS, and Sanity
#### A match made in web development heaven
Next.js is the React framework we build everything on. It renders on the [server or the client](https://yudhajitadhikary.medium.com/client-side-rendering-vs-server-side-rendering-in-react-js-next-js-b74b909c7c51) as each page demands, with static site generation and server-side rendering both on the table.

Tailwind CSS is a utility-first CSS framework. Its ready-to-use utility classes let you prototype and build responsive interfaces without ever leaving your markup.

Then add Sanity CMS. It gives you a [flexible editing environment](/services/sanity), real-time collaboration, and precise content querying, and it becomes the content backend for the whole app.

The three cover each other's gaps: Next.js handles rendering and routing, Tailwind keeps styling in the markup, and Sanity owns the content. You spend your time on the product instead of the wiring.

![Fumbling along with Tailwind, Next.js & Sanity](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/a-seamless-experience-with-next-134-tailwind-css-and-sanity-blog-fumbling-along-with-tailwind-nextjs-sanity.png)

### What's new in Next 13.4
The stable App Router in [Next 13.4](https://nextjs.org/blog/next-13-4) brings a few additions worth knowing about:

#### App routing
The App Router is now stable. Navigation between pages happens client-side after the initial load, so moving around a site feels instant rather than triggering a full page reload each time.

#### Performance
Next 13.4 brings faster page loads and better responsiveness out of the box, without you touching a config file.

#### Code splitting and lazy loading
Gone are the days of loading bulky JavaScript bundles upfront. The router splits code per route and lazy-loads it, so the browser only downloads what the current page needs.

### The `page`-sized elephant in the room
If you're anything like our founder - Jono, you're the kind of person to live safely. You know the type: doesn't run with scissors, changes the smoke alarm batteries, all that responsible stuff.

Well, the good news is, that even though this is the de-facto pattern to build future apps, the old `/page` style directory will still work perfectly even in the latest version of Next.js. Let me reassure you that we have seen a lot of change in the frontend world over the many years we've been kicking about, and something we cannot understate, is how **well** Next.js/Vercel ensures every update is backwards compatible, meaning your site will last long into the future, even if you don't decide to optimise it and move to this new method of fetching data.

### Integrating Sanity CMS
#### Content creation and management
Sanity's content modeling is flexible enough to mirror however your project is actually structured. Editors work in the Studio, developers query the Content Lake, and neither blocks the other.

#### Real-time collaboration and version control
Multiple people can work on the same content simultaneously, and every change is tracked. You can compare revisions and roll back when someone publishes the wrong thing.

#### Click, edit, done: visual editing with Sanity and Vercel
Visual Editing, powered by Sanity and Vercel, lets you update content directly from your Vercel preview deployment. Click the section you want to change and you land on the exact field in Sanity Studio. Change it once and it updates everywhere it's referenced, with no front-end code changes.

### The developer experience
#### Rapid prototyping with Tailwind CSS
Tailwind's utility classes let you iterate on a design without writing custom CSS, which makes exploring layout options fast and cheap.

#### Simpler styling with Tailwind CSS
No more tangled CSS files and invented class names. The styling lives on the element it styles, so you can read a component and know exactly how it renders.

#### Developer experience with Next.js
Next.js ships hot module replacement, automatic code reloading, and error reporting that points at the actual problem. You iterate quickly and catch mistakes early.

### What I wish I would have known about Tailwind earlier
It's these two lines, add them into your Visual Studio code, and you're in for a much nicer time when working with Tailwind. It wraps after 80 characters, no matter the screen size, making it significantly easier to read for any horizonta-phobes such as myself.

```json
  "editor.wordWrap": "wordWrapColumn",
  "editor.wordWrapColumn": 80
```

### Conclusion
Next 13.4's stable App Router, Tailwind's utility-first styling, and Sanity's content tooling have earned their place in our default stack. If you're starting a new build, this combination is hard to argue with.

> **Next.js development**: We build production apps on Next.js, Tailwind, and Sanity. [Learn more](/services/nextjs)

---

## Sanity Scheduling: Probably the best scheduling tool we've ever used


> Sanity's approach to post scheduling? A total win, in our view. Check out our breakdown of the key features that make it stand out. 

**Published:** 2023-05-06 | **Updated:** 2026-07-23 | **Categories:** Sanity
---

*I'll level with you*, scheduling is hardly the most exciting subject to get excited about... Yet we *are* excited, so it probably has some merit.

The sleeper hit of last year was Sanity releasing a fully managed scheduling system that sits flawlessly within your Sanity environment without really having to do anything as far as installations are involved.

## Why does it matter?
I'll give you the quick lowdown: you're a marketer and writing a new blog post to be launched this Friday at 6pm. You're matching it with some social media posts, and you need to make sure it goes *flawlessly*.

So you start typing away and get it completed to the best state possible. It's insightful, witty, and, ultimately, *isn't* going to get swallowed up by the endless void of mediocre content on the web.

Now you need to schedule it. Do you trust a CRON job will work flawlessly or a custom function? How about that new video embed you added last week, does your stack account for that? It's not going to break midway through and leave your brand-new campaign release with a whimper and not a bang.

What if I told you there was a less anxiety-inducing way that's a quick install and a button click away?

## Introducing Sanity scheduled publishing
Sanity Scheduled Publishing swoops in to save the day (and your sanity - I'm sure nobody has made this joke already), by offering you the gift of time travel, sort of. With this trusty ally by your side, you can schedule your content to be published at precisely the right moment, all while you're sipping on a cup of coffee or having a dance party in your pyjamas. No more frantic last-minute changes, no more accidentally hitting the "publish" button, and no more late-night publishing marathons.

Never again shall you be tormented by the anxiety of releasing your carefully crafted content into the wild, praying that you didn't miss an important detail or deadline. Sanity Scheduled Publishing's got your back, ensuring your masterpieces enter the digital realm on time, every time.

## Some of the features
### Date picking
Well, first and foremost, you'd probably want to know how the date picker *actually* works and what it looks like. So here it is in all its glory. It's simple, it's robust, and guess what: **it picks dates**.

![Picture of Sanity Scheduling](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-scheduling-probably-the-best-scheduling-tool-weve-ever-used-blog-picture-of-sanity-scheduling.png)

### Different time zones
Moving on from there, you'd want to know whether it actually accounts for different time zones - as you probably know this is a gigantic pain in the ass. Luckily enough it does, and it does it with ease.

*Don't we all want to be in Hawaii*

![A picture of the time zone looking beautiful and easy to use](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-scheduling-probably-the-best-scheduling-tool-weve-ever-used-blog-a-picture-of-the-time-zone-looking-beautiful-and-e.png)

### Schedule list
What's the point of a sound scheduling system if you can't see all of this wrapped into a nice simple schedule of all upcoming blog posts? Well, luckily, Sanity has got you covered on that front too.

It actually breaks down the schedule into a list of "Upcoming", "Completed" and "Failed". Now you might be wondering why there's a "Failed" tab. Well imagine if you were going to publish a blog post, and it was promoting a brand new app, that unfortunately hadn't released yet... Well you probably don't want to release a PR on that... So it's really quite useful for when things 

![Completed schedule](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-scheduling-probably-the-best-scheduling-tool-weve-ever-used-blog-completed-schedule.png)

> **Sanity CMS development**: Scheduling, workflows, and Sanity studio configuration tailored to your publishing cadence. [Learn more](/services/sanity)

### User experience
It's great to see a little breakdown of each of these features, but the real magic comes when you pair all of these QOL (quality of life) fixes into a solid scheduling system.

## Conclusion
We'd be the first to admit, we didn't pay enough attention to how powerful a solid content schedule can be (there's more than enough gaps in our post history to prove it). However, we're huge believers in removing every possible obstacle to ensure you actually *want* to write an article for the business, rather than begrudgingly typing out clickbait.

[Get in touch](/services/sanity) if you would like to see first-hand how we schedule our posts, and how we can get your website into a content velocity, scheduled posting, mean machine!

---

## Who needs a head? Headless CMS and the race for content velocity


> Headless CMS explained: how separating content from presentation helps marketing teams publish faster across websites, apps, and multiple channels.

**Published:** 2023-03-15 | **Updated:** 2026-07-23 | **Categories:** CMS
---

Content teams are under pressure to publish faster. Marketing wants more landing pages, the blog needs weekly posts, and someone's asking about a mobile app. Traditional CMS platforms weren't built for this - they couple your content to a single website, making reuse painful.

[Headless CMS](/services/headless-cms) separates content from presentation. Your content lives in one place, structured as data, and you pull it into whatever frontend you need - website, app, email, kiosk, whatever comes next.

Here's why this speeds things up:

1. **Content and design move independently.** Developers can rebuild the frontend without touching content. Editors can publish without waiting for a deploy. No more blocked workflows.
1. **APIs handle distribution.** Your content becomes available via API, so pushing to a new channel means writing a fetch request, not migrating a database.
1. **Pick your own frontend.** React, Vue, Astro, whatever. The CMS doesn't care. You're not locked into a theme ecosystem or proprietary templating language.
1. **Easier to maintain long-term.** When you need to redesign or switch frameworks, your content stays put. We've migrated sites where the content layer survived three frontend rewrites.
1. **Teams can work in parallel.** Writers draft in the CMS while developers build components. Designers iterate on the frontend without breaking production content.

The tradeoff is complexity upfront - you need developers who understand APIs and a frontend framework. But if you're publishing at scale or across multiple channels, the investment pays off.

> **Headless CMS services**: CMS selection, content architecture, and migration support for teams moving to headless. [Learn more](/services/headless-cms)

If you're curious whether it makes sense for your team, [we're happy to talk it through](/contact).

---

## Headless CMS hot takes


> Get ready for some no-holds-barred opinions on today's headless CMS landscape. We're cutting through the hype, one review at a time.  

**Published:** 2023-03-02 | **Updated:** 2026-07-23 | **Categories:** Hot Takes, CMS
---

## Preface
We've been in business for *coming up to* 6 years by the time this article drops. We were one of the first agencies to adopt [headless content management systems](/services/headless-cms) before they were even commonplace (and mostly just a fringe tool). We've also worked with them almost exclusively on every project since that time.

We'd like to think we know enough about the subject to be able to give some good advice that, *quite frankly*, might get us into hot water. But we'd much rather you make an informed decision far before you've spent *five figures upwards.*

So here's one *long*, hot take, for you.

## Tina CMS
We've gone full circle, we started out on a content management system called Forestry right back in the glory days. This is their latest stab at building an interactive content management system focusing on real-time editing.

### Our hot take on Tina CMS
We actually quite like it. It's basically "dumb fun" the CMS. It's a git-backed content management system that's fairly solid. It's not going to win any awards for complexity because when we used it, it broke on a multi-item page.

E.g. multiple blog types on one page. But overall, it was pretty simple to implement, you can't *really* screw it up.

But we enjoyed using it; you can use it to build a **simple** page builder. It's literally just dumping markdown files into a directory with a live preview. What's not to like (for the right use case).

I'm fairly certain the team know what they've built, and fun-fact, one of the websites we built nearly five years ago is still running with little maintenance on an old Netlify host.

Good job Tina team. We're happy for you.

## WordPress
[WordPress](/migration/wordpress-to-sanity) is a blogging tool that's existed since the primordial soup days. It makes up a good chunk of the web and has made a name for itself, being synonymous with slow, bloated websites.

It has recently reinvented itself somewhat by splitting the entire dev community with Gutenberg (oof, look at those reviews) and creating a plugin for using it as a headless CMS.

### Our hot take on WordPress
You're probably expecting me to say lots of mean things with this, but I'm not going to **_about_** WordPress.

I think the platform is great for people trying to get themselves a **website** online using the traditional monolithic method. I'm also not the type of person that hates Gutenberg because it does what it needs to do. It creates an extremely simple experience for being able to edit pages.

**However,** I personally think WordPress headless is *utter garbage* and a surefire way of having the worst of both Monolithic and Headless. I also believe that if you are considering using WordPress to do e-commerce, in most cases, you shouldn't. You should opt for [Shopify](/services/shopify) vanilla instead, as it will save you a lot of time and pain maintaining the hosting, backups, stock management etc. And if you do outgrow vanilla, [headless Shopify](/blog/shopify-headless-guide) is the route we'd point you at, not a headless WordPress fudge.

So yes, WordPress is actually **great** for purely a **website** that you know you're going to throw away at some point but just use it as an interim to test an idea or sales concept.

## Strapi
Strapi is a weird one to recommend for us. It sits in an unusual position as, **by default, **you should probably be self-hosting this tool. It's also open-source, which we do encourage.

It's also a GUI-based schema builder.

### Our hot take on Strapi
We haven't personally used the tool on a project **_yet_**. But we have assessed it internally as we were considering this as one of the top 3 competitors for moving the content management system of Roboto.

Take that with a pinch of salt, but the same opinion as with any GUI-based schema builder is that unless your website is extremely simple, at some point, the validation will not cut it.

I'll give you a basic example. If you run a news blog and you only use specific sources, e.g., ***not Wikipedia***, there is no way to validate this using a GUI-based schema builder. It's just too complex without code.

The other issue is self-hosting.

If you're the sort of person that loves spending 20 minutes installing drivers for a printer that for *god-knows-what *reason stopped working, and now you're trying to debug to get access to your all-important printed documents.

**That is self-hosting**. Unless you have a couple of grand a year, you don't mind throwing at debugging why your CMS has gone down, we wouldn't recommend having to deal with this.

We are aware there are very specific use cases for this, but I would put a fairly large bet that if you're reading this, you're not going to need military-grade security etc.

However, we highly recommend checking out [Strapi Cloud](https://strapi.io/cloud) because this seems a great solution for smaller clients who don't want to deal with the headache.

## Webflow
Webflow is a kind of "do it yourself" option. It doesn't require any formal knowledge and isn't actually a headless CMS at all. But I thought I'd include it because a lot of people actually use this tool.

It's also worth mentioning we've worked with a good few sites using this tool.

###  Our hot take on Webflow
If you have the time to use it, you can make a pretty passable website without any coding experience, but it's always going to be just *"alright". *It won't be the fastest, it'll always be restricted to their proprietary hosting, and you'll get charged monthly on it for the privilege.

But... It gives people without coding experience the opportunity to be able to actually build something nifty.

I'd say it's the *buttered brown toast* of the website world: it's pretty average and easy to make, but it's going to make you consider your life choices while you're eating it.

## Prismic
We have had a long and bumpy relationship with Prismic that dates back to near the business's inception. We have spent countless hours trying to support, improve and provide feedback.

However, **we wouldn't touch this tool with a barge pole.**

### Should I use Prismic legacy or Prismic Slice Machine?
We will be reviewing mostly Prismic Legacy, although we spent extensive time using the beta of Slice Machine. If you're looking at building your site today, avoid the legacy system because all the documentation is geared toward the new system.

### Our hottest take on Prismic
Well, you've read so far, and you've got to the one that's probably going to land me in hot water...

We are unbelievably salty about this particular platform. Since using Prismic Legacy, not only has the [Gatsby plugin been deprecated](https://github.com/birkir/gatsby-source-prismic-graphql), mismanaged and [essentially outsourced to the community](https://github.com/birkir/gatsby-source-prismic-graphql/issues/240), but they've also deprecated [APIs with a day's notice](https://prismic.io/blog/a-change-to-how-the-prismic-api-handles-tags) (at first, we thought it was an April fool joke) and completely swapped their main product [without providing a migration plan](https://community.prismic.io/t/migrating-to-slice-machine/11130).

If you've read the above and it doesn't give you any red flags, and you do want to use the tool, I will be fair and say their product has improved over time.

They've recently moved away (sort of) from a GUI-based schema builder and more so into a code-based one. It's *still* nowhere near *Sanity good, *but it is a step in the right direction.

So if a client tasks you with building a page builder and you absolutely **cannot **use any other CMS, it's a non-negotiable, and they've taken your cat hostage... That would be the time to use Prismic.

> **Headless CMS services**: Platform selection, content modelling, and migration support for teams re-platforming. [Learn more](/services/headless-cms)

## Hot take on the state of headless content management systems
I'll level with you. I don't think the general landscape for headless systems isn't anywhere near where it should be. We wrote a more detailed breakdown in our [state of CMS](/blog/state-of-cms) post if you want the full picture. It doesn't surprise me at all that [Sanity](https://www.sanity.io) started out as an agency because we've thought a good couple of times, "why don't we build our own CMS because so many of these suck".

If you're thinking about building a website with a headless CMS, ask yourself: "Is this going to scale more than ten pages, or is the content going to be interlinked".

- If your answer is **yes**: pick Sanity,
- If it is **no**: pick any of the CMS above

Even with that said:* I still think* you're probably shooting yourself in the foot for scaling if you're not using [Sanity](/services/sanity)... And we know because we've had to [migrate so many headless CMS over](/migration).

---

## Sanity CMS pricing: which plan is right for you?


> Choosing the right CMS price bracket? We decode Sanity's pricing to help you decide between lean & budget-friendly or splurging for extra features. 

**TL;DR:** Sanity: Free is good for small stuff, Growth adds scheduling and AI Assist, Enterprise is for big shots. No discount codes, so don't ask. Should've read the long version if you wanted details. Now go decide

**Published:** 2023-02-17 | **Updated:** 2026-08-03 | **Categories:** Sanity
---

You're probably here for one of two reasons:

1. To find out if the Sanity tiers are worth their salt
1. To find out if we have a discount code

Well... sorry to disappoint but we don't have a discount code, however, we have a lot (and I mean a lot) of experience of working with different content management platforms, all with their individual pricing tiers.

This blog outlines all the different pricing points for the Composable Content Cloud - [Sanity](https://www.sanity.io)

Prefer watching over reading? Here's a quick video breakdown.

## Free

This is where Sanity shines; **their free tier is fantastic**. Something that isn't mentioned a lot is the ability to pay as you go.

For example, we had a website built for a small business in Nottingham that blew through its 10 GB bandwidth a month because of the sheer amount of traffic. Usually, this would soft-lock the content management system and force you to upgrade.

However, Sanity does not only have a fair use policy that gives you enough time to ensure you've paid, but they also allow you to pay granularly for each of the exceeded plans.

#### What you get for free

- **20 user seats** with 2 roles (Administrator and Viewer)
- **2 public datasets** for staging and production
- **10,000 documents** and 2,000 unique attributes per dataset
- **1M API CDN requests/mo** and 250K API requests/mo
- **100GB assets** and **100GB bandwidth/mo**
- **Content lake** with real-time collaboration, live previews, and visual editing
- **Customizable Sanity Studio** with GROQ and GraphQL APIs
- **Content Agent and AI features** including 100 AI credits/month
- **Unlimited content types and locales**

That's genuinely generous. Most CMS platforms gate you at 2-3 users on their free tier, and Sanity gives you 20. The 10,000 document limit is the main constraint you'll actually hit.

With that said, we only advise using this plan for small side projects and small businesses that are testing out Sanity. The collaboration and scheduling features that make Sanity a serious CMS for teams only show up in the paid plans.

#### What you'll miss out on

- **Scheduled drafts** for timed publishing
- **Content Releases** for coordinated multi-document publishing (Enterprise only)
- **Comments and tasks** for team collaboration
- **AI Assist** for translations and content generation
- **Private datasets**
- **Advanced user roles** beyond Administrator and Viewer

## Growth: $15/seat/month

The Growth plan is where Sanity becomes a proper team tool. At $15 per occupied seat (Viewers are free), it's competitively priced for what you get.

The biggest additions are **scheduled drafts** and **collaboration features**. Scheduled drafts let you lock a document and set it to publish at a specific time, which covers the most common scheduling use case: "I wrote this blog post on Tuesday and want it to go live Thursday morning."

If you need to coordinate publishing across multiple documents at once (think: launching a campaign where the landing page, three blog posts, and a pricing update all go live simultaneously), that's [Content Releases](/blog/should-i-upgrade-to-sanity-enterprise), and it's an Enterprise feature. For single-document scheduling, Growth has you covered.

You also get **comments and tasks** baked into the Studio, which is a massive quality-of-life improvement for editorial teams. No more Slack threads about "can you review paragraph 3 on the about page."

#### What's included

- **Up to 50 user seats** with 5 roles (Administrator, Editor, Developer, Contributor, Viewer)
- **25,000 documents** and 10,000 unique attributes per dataset
- **Private or public datasets** (2 included)
- **Scheduled drafts** for single-document timed publishing
- **Comments and tasks** for editorial collaboration
- **AI Assist** for translations, content generation, and summarization
- **90-day draft history and activity feed**
- Same API limits as Free (1M CDN requests, 250K API requests, 100GB each for assets and bandwidth) with pay-as-you-go overage

#### Pay-as-you-go overage pricing

If you exceed the included limits, Sanity doesn't cut you off. You pay for what you use:

- API CDN requests: $1 per 250K additional
- API requests: $1 per 25K additional
- Assets: $0.50 per 1GB additional
- Bandwidth: $0.30 per 1GB additional

#### Growth plan add-ons

If you need a specific enterprise feature but aren't ready for a full Enterprise contract, Growth offers a la carte add-ons:

- **Dedicated support**: $799/mo (direct access to Sanity's support engineers)
- **Increased quota**: $299/mo (bumps to 50K docs, 5M CDN requests, 1M API requests, 500GB bandwidth, 500GB assets)
- **Extra datasets**: $999/dataset/mo (up to 2 additional, so max 4 total)

Note that SAML SSO is no longer on the add-on menu. It used to be a $1,399/mo a la carte option on Growth; it's now Enterprise-only. Our honest take: if you need more than one add-on, the maths probably works out better on Enterprise anyway.

![Example of the versioning](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/sanity-cms-pricing-which-plan-is-right-for-you-blog-example-of-the-versioning.png)

## Enterprise

Enterprise is where the heavy-duty features live. The pricing is custom (you'll need to talk to sales), but two features in particular make it worth the conversation.

### Content Releases

This is the feature that teams actually want when they say "scheduling." Content Releases lets you bundle changes across multiple documents into a single release, preview everything together, and publish it all at once. You can schedule releases for a specific date, publish immediately, or leave them undecided until your team is ready.

Each release can contain up to 1,000 documents. You can also revert releases and duplicate them as templates for recurring workflows. If your content operations involve coordinated launches (product launches, campaigns, seasonal content updates), this is the feature that makes it practical.

### Media Library vs the free media browser

This is a distinction worth understanding because it trips people up.

**[sanity-plugin-media](https://github.com/sanity-io/sanity-plugin-media)** is a free, open-source plugin (MIT licensed) that works on every plan. It gives you a proper media browser inside your Studio: batch uploads, drag-and-drop, tagging, search, filtering by orientation/size/type, and bulk operations. For most teams, this is all you need.

**[Media Library](https://www.sanity.io/docs/media-library/introduction)** is an Enterprise add-on, and it's a different thing entirely. It's an organization-level asset management system that works across multiple studios and datasets. Your assets live in a shared organization dataset, not tied to any single project. You get aspects (custom metadata fields like usage licenses and copyright info), collections for team-based grouping, and rich previews for video, PDF, audio, and Lottie/Rive files.

If you're running one studio with one dataset, the free plugin is plenty. If you're an organization with multiple studios and you need centralized asset governance, that's what Media Library is for.

### Other Enterprise features

- **SAML SSO included** (not available on Growth at any price)
- **Dedicated support included** (vs $799/mo on Growth)
- **Custom user roles** beyond the 5 fixed roles on Growth
- **Dataset hot swap** for zero-downtime dataset migrations
- **Full audit trail** for compliance requirements
- **365-day draft history and activity feed** (vs 90 days on Growth)
- **Custom onboarding** with Sanity's team
- **500 AI credits/month** (vs 100 on Free/Growth)
- **Custom document, dataset, and usage quotas**

Having been in many of these Enterprise onboarding meetings ourselves, we can safely say they're incredibly useful. The platform knowledge from the Sanity team is top-notch. We've written a deeper breakdown of [whether upgrading to Sanity Enterprise is worth it](/blog/should-i-upgrade-to-sanity-enterprise).

> **Sanity CMS development**: Schema design, migration pipelines, and ongoing CMS support for teams at every stage. [Learn more](/services/sanity)

## AI credits

All plans include AI credits for Sanity's Content Agent features:

| | Free | Growth | Enterprise |
|---|---|---|---|
| Credits/month | 100 | 100 | 500 |
| Query cost | 4 credits | 4 credits | 4 credits |
| Action cost | 2 credits | 2 credits | 2 credits |
| Additional credits | $0.05 each | $0.05 each | $0.05 each |

100 credits gets you about 25 queries or 50 actions per month. For light AI Assist usage (generating alt text, translating a few fields), that's fine. If you're using it heavily, budget for the overage or go Enterprise.

## Key Sanity features across all plans

#### Developer experience

Every Sanity plan, including Free, gives you a fully customizable Studio, GROQ and GraphQL APIs, real-time collaboration, live previews, and visual editing. The developer experience doesn't degrade on lower tiers, which is rare for a CMS.

#### Content management

The content lake (Sanity's hosted database) is included on every plan. You get real-time syncing, revision history, and the ability to query your content however you want. The differences between plans are about team features (collaboration, scheduling, roles) and scale (document limits, API quotas), not about core functionality.

## Sanity pricing scenario tables

The canonical page renders an interactive calculator here. The tables below cover its full answer space, generated from the same pricing logic. Numbers checked against <https://www.sanity.io/pricing>.

### Plan limits

| Plan | Price | Seats | Documents | Asset storage | Bandwidth | API CDN requests | API requests |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Free | $0 forever | 20 (admin and viewer roles only) | 10,000 | 100 GB | 100 GB/mo | 1M/mo | 250K/mo |
| Growth | $15 per seat/mo (viewer seats free) | Up to 50 | 25,000 | 100 GB | 100 GB/mo | 1M/mo | 250K/mo |
| Enterprise | Custom | Custom | Custom | Custom | Custom | Custom | Custom |

Single sign-on (SSO), Content Releases, and the shared Media Library are Enterprise-only. Scheduled drafts, comments and tasks, and AI Assist are included from Growth up.

### Growth plan overage rates

| Overage | Rate | Example |
| --- | --- | --- |
| Bandwidth | $0.30 per GB | +10 GB = $3/mo |
| API CDN requests | $1 per 250K requests | +1M requests = $4/mo |
| API requests | $1 per 25K requests | +250K requests = $10/mo |
| Asset storage | $0.50 per GB | +50 GB = $25/mo |
| Documents | $299/mo add-on for 50K total | 25,001 to 50,000 documents = $299/mo |
| Extra datasets | $999 per dataset/mo | 1 extra dataset = $999/mo |

A Growth team going +1M CDN requests and +10 GB bandwidth over quota pays $7/mo in overages on top of seats.

### Recommended plan by team size and requirements

| Editors | Viewers | Requirements | Recommended plan | Monthly cost | Cost detail |
| --- | --- | --- | --- | --- | --- |
| 1 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 2 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 3 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 5 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 10 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 15 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 20 | 0 | Basic publishing, same access for everyone | Free | $0/mo | Everything needed is on the free plan |
| 30 | 0 | Basic publishing, same access for everyone | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | Basic publishing, same access for everyone | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | Basic publishing, same access for everyone | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 25 | Basic publishing plus 25 view-only seats | Growth | $15/mo | 1 editor seat x $15/mo = $15; 25 viewer seats (free) |
| 2 | 25 | Basic publishing plus 25 view-only seats | Growth | $30/mo | 2 editor seats x $15/mo = $30; 25 viewer seats (free) |
| 3 | 25 | Basic publishing plus 25 view-only seats | Growth | $45/mo | 3 editor seats x $15/mo = $45; 25 viewer seats (free) |
| 5 | 25 | Basic publishing plus 25 view-only seats | Growth | $75/mo | 5 editor seats x $15/mo = $75; 25 viewer seats (free) |
| 10 | 25 | Basic publishing plus 25 view-only seats | Growth | $150/mo | 10 editor seats x $15/mo = $150; 25 viewer seats (free) |
| 15 | 25 | Basic publishing plus 25 view-only seats | Growth | $225/mo | 15 editor seats x $15/mo = $225; 25 viewer seats (free) |
| 20 | 25 | Basic publishing plus 25 view-only seats | Growth | $300/mo | 20 editor seats x $15/mo = $300; 25 viewer seats (free) |
| 30 | 25 | Basic publishing plus 25 view-only seats | Growth | $450/mo | 30 editor seats x $15/mo = $450; 25 viewer seats (free) |
| 50 | 25 | Basic publishing plus 25 view-only seats | Growth | $750/mo | 50 editor seats x $15/mo = $750; 25 viewer seats (free) |
| 75 | 25 | Basic publishing plus 25 view-only seats | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $15/mo | 1 editor seat x $15/mo = $15 |
| 2 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $30/mo | 2 editor seats x $15/mo = $30 |
| 3 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $45/mo | 3 editor seats x $15/mo = $45 |
| 5 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $75/mo | 5 editor seats x $15/mo = $75 |
| 10 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $150/mo | 10 editor seats x $15/mo = $150 |
| 15 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $225/mo | 15 editor seats x $15/mo = $225 |
| 20 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $300/mo | 20 editor seats x $15/mo = $300 |
| 30 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | Multiple access levels (editors, contributors, admins) | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | Multiple access levels (editors, contributors, admins) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Scheduled publishing for individual posts | Growth | $15/mo | 1 editor seat x $15/mo = $15 |
| 2 | 0 | Scheduled publishing for individual posts | Growth | $30/mo | 2 editor seats x $15/mo = $30 |
| 3 | 0 | Scheduled publishing for individual posts | Growth | $45/mo | 3 editor seats x $15/mo = $45 |
| 5 | 0 | Scheduled publishing for individual posts | Growth | $75/mo | 5 editor seats x $15/mo = $75 |
| 10 | 0 | Scheduled publishing for individual posts | Growth | $150/mo | 10 editor seats x $15/mo = $150 |
| 15 | 0 | Scheduled publishing for individual posts | Growth | $225/mo | 15 editor seats x $15/mo = $225 |
| 20 | 0 | Scheduled publishing for individual posts | Growth | $300/mo | 20 editor seats x $15/mo = $300 |
| 30 | 0 | Scheduled publishing for individual posts | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | Scheduled publishing for individual posts | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | Scheduled publishing for individual posts | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Private content before publishing | Growth | $15/mo | 1 editor seat x $15/mo = $15 |
| 2 | 0 | Private content before publishing | Growth | $30/mo | 2 editor seats x $15/mo = $30 |
| 3 | 0 | Private content before publishing | Growth | $45/mo | 3 editor seats x $15/mo = $45 |
| 5 | 0 | Private content before publishing | Growth | $75/mo | 5 editor seats x $15/mo = $75 |
| 10 | 0 | Private content before publishing | Growth | $150/mo | 10 editor seats x $15/mo = $150 |
| 15 | 0 | Private content before publishing | Growth | $225/mo | 15 editor seats x $15/mo = $225 |
| 20 | 0 | Private content before publishing | Growth | $300/mo | 20 editor seats x $15/mo = $300 |
| 30 | 0 | Private content before publishing | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | Private content before publishing | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | Private content before publishing | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Comments and review tasks | Growth | $15/mo | 1 editor seat x $15/mo = $15 |
| 2 | 0 | Comments and review tasks | Growth | $30/mo | 2 editor seats x $15/mo = $30 |
| 3 | 0 | Comments and review tasks | Growth | $45/mo | 3 editor seats x $15/mo = $45 |
| 5 | 0 | Comments and review tasks | Growth | $75/mo | 5 editor seats x $15/mo = $75 |
| 10 | 0 | Comments and review tasks | Growth | $150/mo | 10 editor seats x $15/mo = $150 |
| 15 | 0 | Comments and review tasks | Growth | $225/mo | 15 editor seats x $15/mo = $225 |
| 20 | 0 | Comments and review tasks | Growth | $300/mo | 20 editor seats x $15/mo = $300 |
| 30 | 0 | Comments and review tasks | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | Comments and review tasks | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | Comments and review tasks | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | AI Assist for writing and translation | Growth | $15/mo | 1 editor seat x $15/mo = $15 |
| 2 | 0 | AI Assist for writing and translation | Growth | $30/mo | 2 editor seats x $15/mo = $30 |
| 3 | 0 | AI Assist for writing and translation | Growth | $45/mo | 3 editor seats x $15/mo = $45 |
| 5 | 0 | AI Assist for writing and translation | Growth | $75/mo | 5 editor seats x $15/mo = $75 |
| 10 | 0 | AI Assist for writing and translation | Growth | $150/mo | 10 editor seats x $15/mo = $150 |
| 15 | 0 | AI Assist for writing and translation | Growth | $225/mo | 15 editor seats x $15/mo = $225 |
| 20 | 0 | AI Assist for writing and translation | Growth | $300/mo | 20 editor seats x $15/mo = $300 |
| 30 | 0 | AI Assist for writing and translation | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | AI Assist for writing and translation | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | AI Assist for writing and translation | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Access levels + scheduling + AI Assist | Growth | $15/mo | 1 editor seat x $15/mo = $15 |
| 2 | 0 | Access levels + scheduling + AI Assist | Growth | $30/mo | 2 editor seats x $15/mo = $30 |
| 3 | 0 | Access levels + scheduling + AI Assist | Growth | $45/mo | 3 editor seats x $15/mo = $45 |
| 5 | 0 | Access levels + scheduling + AI Assist | Growth | $75/mo | 5 editor seats x $15/mo = $75 |
| 10 | 0 | Access levels + scheduling + AI Assist | Growth | $150/mo | 10 editor seats x $15/mo = $150 |
| 15 | 0 | Access levels + scheduling + AI Assist | Growth | $225/mo | 15 editor seats x $15/mo = $225 |
| 20 | 0 | Access levels + scheduling + AI Assist | Growth | $300/mo | 20 editor seats x $15/mo = $300 |
| 30 | 0 | Access levels + scheduling + AI Assist | Growth | $450/mo | 30 editor seats x $15/mo = $450 |
| 50 | 0 | Access levels + scheduling + AI Assist | Growth | $750/mo | 50 editor seats x $15/mo = $750 |
| 75 | 0 | Access levels + scheduling + AI Assist | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Over 100 GB of assets with multiple access levels | Growth | $40/mo | 1 editor seat x $15/mo = $15; Estimated asset overage (50 GB) = $25 |
| 2 | 0 | Over 100 GB of assets with multiple access levels | Growth | $55/mo | 2 editor seats x $15/mo = $30; Estimated asset overage (50 GB) = $25 |
| 3 | 0 | Over 100 GB of assets with multiple access levels | Growth | $70/mo | 3 editor seats x $15/mo = $45; Estimated asset overage (50 GB) = $25 |
| 5 | 0 | Over 100 GB of assets with multiple access levels | Growth | $100/mo | 5 editor seats x $15/mo = $75; Estimated asset overage (50 GB) = $25 |
| 10 | 0 | Over 100 GB of assets with multiple access levels | Growth | $175/mo | 10 editor seats x $15/mo = $150; Estimated asset overage (50 GB) = $25 |
| 15 | 0 | Over 100 GB of assets with multiple access levels | Growth | $250/mo | 15 editor seats x $15/mo = $225; Estimated asset overage (50 GB) = $25 |
| 20 | 0 | Over 100 GB of assets with multiple access levels | Growth | $325/mo | 20 editor seats x $15/mo = $300; Estimated asset overage (50 GB) = $25 |
| 30 | 0 | Over 100 GB of assets with multiple access levels | Growth | $475/mo | 30 editor seats x $15/mo = $450; Estimated asset overage (50 GB) = $25 |
| 50 | 0 | Over 100 GB of assets with multiple access levels | Growth | $775/mo | 50 editor seats x $15/mo = $750; Estimated asset overage (50 GB) = $25 |
| 75 | 0 | Over 100 GB of assets with multiple access levels | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $15/mo before Enterprise features |
| 2 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $30/mo before Enterprise features |
| 3 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $45/mo before Enterprise features |
| 5 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $75/mo before Enterprise features |
| 10 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $150/mo before Enterprise features |
| 15 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $225/mo before Enterprise features |
| 20 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $300/mo before Enterprise features |
| 30 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $450/mo before Enterprise features |
| 50 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $750/mo before Enterprise features |
| 75 | 0 | Single sign-on (SSO) required | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $15/mo before Enterprise features |
| 2 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $30/mo before Enterprise features |
| 3 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $45/mo before Enterprise features |
| 5 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $75/mo before Enterprise features |
| 10 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $150/mo before Enterprise features |
| 15 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $225/mo before Enterprise features |
| 20 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $300/mo before Enterprise features |
| 30 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $450/mo before Enterprise features |
| 50 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $750/mo before Enterprise features |
| 75 | 0 | Fully custom permissions per person | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $15/mo before Enterprise features |
| 2 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $30/mo before Enterprise features |
| 3 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $45/mo before Enterprise features |
| 5 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $75/mo before Enterprise features |
| 10 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $150/mo before Enterprise features |
| 15 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $225/mo before Enterprise features |
| 20 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $300/mo before Enterprise features |
| 30 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $450/mo before Enterprise features |
| 50 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $750/mo before Enterprise features |
| 75 | 0 | Coordinated multi-page launches (Content Releases) | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |
| 1 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $15/mo before Enterprise features |
| 2 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $30/mo before Enterprise features |
| 3 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $45/mo before Enterprise features |
| 5 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $75/mo before Enterprise features |
| 10 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $150/mo before Enterprise features |
| 15 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $225/mo before Enterprise features |
| 20 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $300/mo before Enterprise features |
| 30 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $450/mo before Enterprise features |
| 50 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $750/mo before Enterprise features |
| 75 | 0 | Shared media library across separate websites | Enterprise | Custom pricing | Reference: equivalent Growth seats would be $1,125/mo before Enterprise features |

## Which Sanity plan should you choose?

**Choose Free** if you're:

- Testing Sanity for a small to medium project
- Building personal websites or small business sites
- Working with a small team that only needs Administrator and Viewer roles
- Comfortable with public datasets only
- Under the 10,000 document limit

**Choose Growth** if you're:

- A business that needs scheduled publishing for individual documents
- Working with a team that needs collaboration features (comments, tasks)
- Need private datasets or more than 2 user roles
- Want AI Assist for translations and content generation
- Under 50 team members and 25,000 documents

**Choose Enterprise** if you're:

- Coordinating content launches across multiple documents (Content Releases)
- Managing assets across multiple studios or datasets (Media Library)
- An organization that requires SAML SSO, custom roles, or audit trails
- Need dedicated support and custom onboarding
- Exceeding Growth limits regularly and want predictable pricing

Not sure which plan fits your team? As [Sanity agency partners](/services/sanity), we've helped businesses at every stage pick the right plan and get the most out of it. If you're still looking for the right partner, we have a [guide on picking one](/blog/choosing-the-right-sanity-cms-agency). If you're just getting started, our [workshops](/services/workshops) are a great way to hit the ground running.

---

## Getting the hang of Sanity's parameterised templates


> Use Sanity's parameterized initial value templates to pre-fill fields and speed up content creation. Code for schema templates and desk structure included.

**Published:** 2023-02-11 | **Updated:** 2026-07-23 | **Categories:** Sanity
---

Sanity is a powerful platform for managing structured content, with various features that make complex data structures simple to create and manage. The ability to use parameterized templates, which allow you to define reusable templates that can be customized for each individual piece of content, is one of these features.

### Sanity initial value template
In Sanity, a parameterized template is a schema that contains variables that can be replaced with actual values when the template is used to generate new content. This enables you to create reusable templates specific to each piece of content, making it easier to manage and maintain your data over time.

This [blog](https://robotostudio.com/blog) aims to provide a thorough overview of the concept of parameterized initial values within the Sanity platform. This concept enables the implementation of customizable templates, which editors can use during the instance creation process. The goal is to improve Sanity's content management's overall efficiency and flexibility.

![intent](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/getting-the-hang-of-sanitys-parameterized-templates-blog-intent.png)

### Use Case: default value
Language-specific parameterized initial values can be considered when an editor needs content to be presented in a single language, such as French but does not need the base version. This method enables template customization to meet specific language requirements, increasing the overall efficiency and specificity of the content management process.

```javascript
// sanity.config.ts
import {defineConfig} from 'sanity'

export default defineConfig({
  // ...rest of config
  schema: {
    templates: (prev) => [
      ...prev,
      {
      id: 'article-en-us',
      title: 'Article English(US)',
      schemaType: 'article',
      value: {
        __i18n_lang: 'en-us'
      },
    },
	],
})
```

As shown in the image above, this code snippet demonstrates adding a new intent to an article.

### Use case: parameterized
Using templates in Sanity can significantly speed up the content creation process, especially when there are multiple child types present, such as "how-to" articles. Editors can benefit from increased efficiency and a more user-friendly experience by incorporating pre-defined parameterized initial values.

To achieve this use case, separate list items on sanity document structures can be used, as this will provide a clear and organized method for managing the relevant information.

```javascript
export const article = {
	name: 'article',
  title: 'Documents',
  type: 'document',
  icon: FiFileText,
  fields: [
		{
	      name: 'kind',
	      title: 'kind',
	      type: 'string',
	      options: {
	        list: [
	          { title: 'Recipe', value: 'recipe' },
	          { title: 'Explainer video', value: 'video' },
	        ],
	      }
		  },
		...,
		]
	}
};
```

```javascript
export const structure = (S: any, context: any) =>
     S.listItem()
        .title("Articles")
        .icon(FiFileText)
        .child(
          S.list()
            .title("Articles")
            .items([
              // Default Article Document
              S.listItem()
                .title(`Recipe`)
                .icon(FiFileText)
                .child(
                  S.documentList()
                    .title(`Recipes`)
                    .schemaType("article")
										// filter based on the kind
                    .filter(`_type  "article" && "recipe" in kind`)

                ),
              // Video Article Document
              S.listItem()
                .title(`Video Articles`)
                .icon(FiHelpCircle)
                .child(
                  S.documentList()
                    .title(`Video Articles`)
                    .schemaType("article")
                    .filter(`_type  "article" && "video" in kind`)
                ),
            ])
        );
```

now you can create templates to handle intents

```javascript
// sanity.config.ts
import {defineConfig} from 'sanity'

export default defineConfig({
  // ...rest of config
  schema: {
    templates: (prev) => [
      ...prev,
      {
        id: 'kind-match',
        title: 'Kind Match',
        schemaType: 'article',
        value: (params: { value: any }) => ({
					// kind will be prefilled
          kind: params.value,
        }),
      },
	],
})
```

modifying the existing desk structure.

```javascript
export const structure = (S: any, context: any) =>
     S.listItem()
        .title("Articles")
        .icon(FiFileText)
        .child(
          S.list()
            .title("Articles")
            .items([
              // Default Article Document
              S.listItem()
                .title(`Recipe`)
                .icon(FiFileText)
                .child(
                  S.documentList()
                    .title(`Articles`)
                    .schemaType("article")
										// filter based on the kind
                    .filter(`_type  "article" && "recipe" in kind`)
	                   .initialValueTemplates(
				              S.initialValueTemplateItem('kind-match', {
				                value: 'recipe',
				              }),
				            ),
                ),
              // Explainer video
              S.listItem()
                .title(`Explainer Video`)
                .icon(FiHelpCircle)
                .child(
                  S.documentList()
                    .title(` Articles`)
                    .schemaType("article")
                    .filter(`_type  "article" && "video" in kind`)
                    .initialValueTemplates(
				              S.initialValueTemplateItem('kind-match', {
				                value: 'video',
				              }),
				            ),
                ),
            ])
        );
```

With this implementation, the ability to create distinct sections within the desk structure has been added. The relevant parameterized initial values will be automatically populated upon creation.

### Conclusion
Parameterized templates cut the repetitive part of content creation. Define the template once with customizable initial values, and every new document starts with the right structure instead of a blank form. Your editors stop copy-pasting boilerplate, and the shape of each content type stays consistent no matter who creates it.

> **Sanity CMS development**: We build Sanity setups with templates, workflows, and schema architecture tailored to your content team. [Learn more](/services/sanity)

---

## 11 top tips for SEO with Sanity & Next.js


> 11 SEO tips for Next.js and Sanity sites: image optimization, structured data, GROQ query efficiency, Vercel analytics, and bundle size reduction.

**Published:** 2023-02-03 | **Updated:** 2026-07-23 | **Categories:** How To, Sanity, Next.js
---

> **There's a fuller, more up-to-date version of this post**: We've rewritten our Sanity AEO/SEO playbook from scratch for 2026. It covers everything below plus JSON-LD, AEO (answer engine optimisation), content negotiation for agents, llms.txt, accessibility, and the feedback loop that catches drift. If you're starting fresh, read that one instead. [Read the 2026 AEO/SEO guide](/blog/aeo-seo-best-practices-for-sanity)

## 1. Static/server-side rendering
Use [Next.js](/services/nextjs)'s SSR or SSG feature to speed up page rendering. If you're pulling from an API make sure you're not pulling too much data down onto the page. Make sure it's specific rather than pulling a whole bunch of junk that you never actually use.

### Bad time
This is bad, you're going to pull basically everything and only actually use like: *title, categories, portable text*

```groq
*[_type  "article"] | order(_updatedAt desc){
  ...
  categories[]->{...}
}
```

### Good job
Much better, now you're actually specifying what you want and not taking a truckload of data onto the page.

```groq
*[_type  "article"] | order(_updatedAt desc){
  title,
  portableText,
  categories[]->{title}
}
```

## 2. Get your schema right
You've spent those late nights searching for junk that you want to fill your house with. Well, that only appears because of [Structured Data](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)

Guess what? It's even easier with [Next SEO](https://github.com/garmeeh/next-seo). You can essentially nest this within your actual components to ensure you're getting the most out of your SEO. So if you add a product to your page, such as "Henry", make sure you're including the [Product](https://github.com/garmeeh/next-seo#product) structured data within there so Google understands.

![Henry hoover & co](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/top-tips-for-seo-with-sanity-and-nextjs-blog-henry-hoover-co.png)

## 3. Use Sanity's image URLs
Do you know what takes up the largest amount of data on nearly every website? **Images**

That's why it's important that you either use [Sanity's image url resolver](https://www.sanity.io/docs/apis-and-sdks/image-urls) or [Next/Image](https://nextjs.org/docs/app/api-reference/components/image). If you're like us, we use both.

What that means is when somebody visits your website, they're not spending ages looking at a screen loading and blurring images in. If you're looking at doing this yourself. Here's our typical go-to Next/Image component.

```typescript
<Image
  src={urlFor(image).url()}
  alt={alt}
  width={getImageDimensions(image).width}
  height={getImageDimensions(image).height}
  placeholder="blur"
  blurDataURL={urlFor(image)
    .width(24)
    .height(24)
    .blur(10)
    .url()}
  sizes="
  (max-width: 768px) 100vw,
  (max-width: 1200px) 50vw,
  40vw"
/>
```

## 4. Use "getImageDimensions" to size the image
You might have noticed the width and height of the image above. Not many people even know this exists as a function within Sanity.

[But it does](https://github.com/sanity-io/asset-utils/blob/main/README.md#getimagedimensions)

If you use the above, it ensures you're sizing the image to the same aspect ratio as the original. So you're not going to get any stretched images or wonky looking pixels.

## 5. Make sure you're only using one `<h1>`
This is an interesting topic that focuses far more on how you design your structured content rather than the page itself. Essentially make sure you're only using one `<h1>` on the page, which can easily be duplicated with **Portable Text**.

Do you know how we resolve it?

Completely remove **"Heading 1"** from portable text and force your `<h1>` to be populated by a title string. It always ensures you only have a single `<h1>` on the page, and a content editor doesn't accidentally duplicate it.

![How we use a title to ensure it's only one `<h1>` to a page](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/top-tips-for-seo-with-sanity-and-nextjs-blog-how-we-use-a-title-to-ensure-its-only-one-h1-to-a-.png)

## 6. Get your keyword targets spot on
So, remember how we suggested to only use one `<h1>`. Well now you've got to ensure that the `<h1>` is populated to keywords that you want to make sure your page ranks for.

So for example if you're going to rank for Sanity Enterprise Agency, you might want to make sure the `<h1>` is set as:

```html
<h1>Sanity Enterprise Agency</h1>
```

*Pretty simple right...*

## 7. Actually pay for Vercel analytics
We reckon Vercel analytics is probably one of the most overlooked essentials when optimising your SEO. *Here's the skinny, *it does a lot of what Google analytics does, it can bypass adblocks and from the get-go it can tell you where you're getting most of your traffic from. It's extremely useful and a snip at $10 a month.

## 8. Vercel analytics part 2
Okay we've talked about actual analytics so far, however, something that has become more and more of a focus with larger sites is actual on-device performance.

Vercel analytics can tell you all about what is causing issues on your site **performance** wise. Take the image below, we've managed to smash **Cumulative Layout Shift**, however, our **First Contentful Paint** and **Largest Contentful Paint** *sucks*, so we know exactly what we need to do to improve our performance.

![Vercel analytics](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/top-tips-for-seo-with-sanity-and-nextjs-blog-vercel-analytics.png)

> **Sanity CMS development**: SEO-optimized Sanity and Next.js builds with structured data, performance tuning, and content architecture. [Learn more](/services/sanity)

## 9. Use the Sanity SEO pane
What's a better way of understanding a pages SEO than getting a specific pane that tells you exactly what can be improved SEO-wise.

If you're looking for some top-level tips, there's nothing better than configuring the [SEO pane](https://www.sanity.io/plugins/seo-pane) to help you out when building out your pages. It's one of the first things we set up on every [Sanity project](/services/sanity).

## 10. Bundlephobia
No, this isn't the fear of being packed away inside of a cardboard box... It's a tool to analyse package sizes with libraries you might be using.

I'll give you an example. If you use FontAwesome and import a library, you're going to end up with about a 3Mb bundle, before you even start on a website.

## 10 (and a half). Next.js + Webpack Bundle Analyzer
Carrying on from the bundlephobia above, you can [use this tool](https://www.npmjs.com/package/@next/bundle-analyzer) to see what makes up each package on your final website. This is **exactly** how we found out that a good chunk of our initial load was spent on a couple thousand icons...

Now we've got a solution using Next/Image with fontawesome, that we'll probably talk about at some point... But there's no blog post yet... Watch this space.

## 11.  Speed up your content flow
We are probably a shining example of churning out content that we hope is actually useful. Yes, it's barely coherent a lot of the time and is littered with cat pictures, but the reason for doing so is *"because it's more fun".*

If you can find pain points of your content team such as "Can I source my imagery directly from Unsplash inside of Sanity" - [solve those problems](https://www.sanity.io/plugins/sanity-plugin-asset-source-unsplash). Or if you're like us, just use [Open Ai to generate your images for you](/blog/revolutionizing-visual-content-creation-with-sanityio-and-openai). A well-configured [Sanity Studio](/services/sanity) should make content creation feel effortless, not like a chore.

Naturally, the more your content editors like using your editor, the more they will write, the faster they will write it, and to quote "Field of Dreams":

> "If you build it, they will come."

---

## Revolutionising visual content creation with Sanity.io and OpenAI


> How to add AI image generation to Sanity Studio using OpenAI's API, from the original DALL-E plugin to the newer options available today.

**Published:** 2023-01-31 | **Updated:** 2026-08-24 | **Categories:** AI, Sanity
---

We originally wrote this in January 2023, when DALL-E 2 was the only game in town and sticking it inside Sanity Studio felt like a neat trick. The landscape has shifted quite a bit since then, so we've updated this with what actually matters now.

The core idea hasn't changed: let editors generate images without leaving the CMS. The tools have.

## The original approach: sanity-plugin-asset-source-openai

We built [sanity-plugin-asset-source-openai](https://www.npmjs.com/package/sanity-plugin-asset-source-openai) as a quick way to wire DALL-E into Sanity Studio. It adds an "OpenAI" option to any image field, lets you type a prompt, and uploads the result as a Sanity asset.

### Installation

```bash
pnpm add sanity-plugin-asset-source-openai
```

### Config

```javascript
import { defineConfig } from 'sanity'
import { openaiImageAsset } from 'sanity-plugin-asset-source-openai'

export default defineConfig({
  // ...
  plugins: [
    openaiImageAsset({
      API_KEY: process.env.SANITY_STUDIO_OPENAI_API_KEY,
    }),
  ],
})
```

> Store your API key in an environment variable prefixed with `SANITY_STUDIO_`. Add it to `.env.local` and keep that file in `.gitignore`.

### Schema

Any standard image field works. Nothing special needed:

```javascript
export default {
  name: 'post',
  type: 'document',
  title: 'Post',
  fields: [
    {
      name: 'title',
      type: 'string',
      title: 'Title',
    },
    {
      name: 'image',
      type: 'image',
      title: 'Image',
    },
  ],
}
```

### Using it

Click the image field, select "Open AI Image" from the asset source dropdown:

![ai-plugin](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/revolutionizing-visual-content-creation-with-sanityio-and-openai-blog-ai-plugin.png)

Type your prompt and hit Generate:

![prompt-dialog](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/revolutionizing-visual-content-creation-with-sanityio-and-openai-blog-prompt-dialog.png)

If you like the result, click Confirm to save it as a Sanity asset. If not, generate again until you get something usable.

![ai-image](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/revolutionizing-visual-content-creation-with-sanityio-and-openai-blog-ai-image.png)

Here's a demo of the full flow:

[https://www.loom.com/share/267fed477cf4458394eb2c2e4c964efc](https://www.loom.com/share/267fed477cf4458394eb2c2e4c964efc)

## What's changed since 2023

Quite a lot, actually.

### DALL-E 2 and 3 are being retired

OpenAI is shutting down both DALL-E 2 and DALL-E 3 on **May 12, 2026**. The replacements are `gpt-image-1` (released April 2025) and `gpt-image-1.5` (December 2025), which are built on the GPT-4o architecture. They're better at following instructions, rendering text in images, and producing photorealistic output. Pricing moved to a per-token model, starting around $0.02 per image at low quality.

If you're using the plugin above, it will need updating before the deprecation deadline.

### Sanity has native AI image generation now

This is the bigger story. Since Sanity 3.26, the official [@sanity/assist](https://www.sanity.io/docs/studio/install-and-configure-sanity-ai-assist) plugin includes built-in image generation. You configure `options.aiAssist.imageInstructionField` on an image field and your editors get prompt-based generation without any third-party plugin.

[Agent Actions](https://www.sanity.io/docs/agent-actions/agent-actions-image-generation) takes it further, generating images as part of whole-document creation. If you're on Sanity's Growth plan or above, this is probably where you should start now rather than wiring up your own OpenAI key.

### Other plugins worth knowing about

- **[sanity-plugin-gemini-ai-images](https://github.com/ncklrs/sanity-ai-image-video)** uses Google's Gemini 2.5 Flash for text-to-image and image-to-image editing, including background swaps and lighting changes.
- **[sanity-plugin-image-gen](https://www.sanity.io/plugins/sanity-plugin-image-gen)** (also ours) routes through Next.js API routes and Replicate, which gives you access to models like Flux and Stable Diffusion.

Here's that Replicate plugin running inside a studio, if you want to see what the editor actually gets.

## Which approach should you use?

If you're starting fresh today, use **Sanity AI Assist**. It's first-party, maintained, and doesn't require managing your own API keys.

If you need a specific model (say you prefer Flux's aesthetic over what Sanity's built-in option produces), one of the third-party plugins gives you that control.

The `sanity-plugin-asset-source-openai` approach from this original post still works, but you'll want to make sure it's updated for `gpt-image-1` before May 2026. We're evaluating whether to update it or deprecate it in favour of our Replicate-based plugin, which is more model-agnostic.

The point remains the same as when we first wrote this: editors shouldn't have to leave their CMS to get an image. How you wire that up is just an implementation detail.

If you're interested in AI inside Sanity more broadly, [Sanity Canvas](/blog/sanity-canvas-a-better-way-of-writing-content) covers AI-assisted writing directly inside the CMS, not just images.

> **Sanity CMS development**: We configure AI image plugins, schema design, and editorial tooling for Sanity teams. [Learn more](/services/sanity)

---

## Sanity top tip: the Grandma test


> The Grandma test for Sanity schemas: write field descriptions that non-technical content editors can understand. Code examples and validation tips included.

**Published:** 2023-01-25 | **Updated:** 2026-07-23 | **Categories:** Sanity, How To
---

Before we even touch upon Sanity Schema, I want to do a brief rundown of Structured content because it's important when assessing what needs to be in/out of your schema.

Structured content is a method of organising and managing information in a standardised, consistent format. It improves content accessibility and discoverability, making it easier for users and developers to find and use the information they require. [Sanity](https://www.sanity.io/) is a powerful platform for structured content.

## Give me an example in real terms
An example is a blog post you've almost definitely come across. They all have different fields but let's address the ones that nearly always appear:

- Title
- Publish date
- Author
- Body of text

Structured content is all about organising the above into an easy-to-understand structure without forcing your content creators to spend 20 mins scanning through forms.

## The grandma test
How do we make structured content in a simple, consistent way? We design it for our grandmas'.

Instead of thinking of our schema as a complex collection of data, we approach it as if it's a note we left on the fridge. Keep it casual, friendly and assume pitfalls when writing it.

*E.g. don't make a title too short.*

### Here's an example of writing the above schema with Grandma in mind:

```typescript
import {FaNewspaper} from 'react-icons/fa'

export const SingleArticle = {
  title: 'Article',
  name: 'article',
  type: 'document',
  icon: FaNewspaper,
  // Nice little icon to help people understand what type of document this is.
  fields: [
    {
      name: 'title',
      title: 'Title',
      description:
        "Every page should have a title that isn't too long or too short. We recommend page titles are between 10 and 60 characters.",
      type: 'string',
      validation: (Rule: any) => Rule.required(),
    },
    {
      name: 'date',
      title: 'Published Date',
      description:
        "Make sure to select a publish date in the future if you plan to release it at a later date, or if you're planning on publishing today, use todays date",
      type: 'datetime',
      validation: (Rule: any) => Rule.required(),
      initialValue: () => new Date().toISOString(),
    },
    {
      name: 'description',
      title: 'Description',
      description:
        "Page descriptions shouldn't be too long or too short. Long page descriptions will only be partially shown in search results and short descriptions are unlikely to be helpful to users. We recommend page descriptions are between 100 and 320 characters.",
      type: 'text',
      rows: 3,
      validation: (Rule: any) => [
        Rule.required(),
        Rule.min(100).warning('We advise writing a description above 100 characters'),
        Rule.max(320).warning('Any more and it will get truncated'),
      ],
    },
    {
      name: 'image',
      title: 'Image',
      type: 'image',
      description:
        'Add an image to make it nice for people to view when sharing it on social media. Remember to make sure the image is bigger than 1200 pixels, you can always crop it with the hotspot',
      validation: (Rule: any) => Rule.required(),
      options: {
        hotspot: true,
      },
      fields: [
        {
          name: 'alt',
          type: 'string',
          title: 'Alt Text',
        },
      ],
    },
    {
      name: 'author',
      title: 'Author',
      type: 'reference',
      description:
        'Remember to attribute this blog to an author, that way it shows that they have written it on the page.',
      to: [{type: 'author'}],
    },
    {
      name: 'portableText',
      title: 'Document text',
      description:
        'This is where you enter the majority of the text, not forgetting to add headings, lists, images, etc.',
      type: 'portableText',
    },
  ],
  preview: {
    select: {
      title: 'title',
      subtitle: 'description',
      media: 'image',
    },
  },
  orderings: [
    {
      title: 'Publishing Date, Newest First',
      // Make sure to add this to see your latest published by the publish date
      name: 'dateDesc',
      by: [{field: 'date', direction: 'desc'}],
    },
  ],
}

```

The more you think of writing up schema as if it's a note to Grandma, the better it will be. It'll be less confusing; it will take a little longer to write but guaranteed to save you time in the future.

*We're probably going to be releasing more tips in the future* so keep your eyes peeled for more advice on getting the most out of Sanity.

For more on structuring schemas in a way that scales, see our post on [tips and tricks for building Sanity schema efficiently](/blog/tips-and-tricks-for-building-sanity-schema-efficiently).

> **Sanity CMS development**: We build editor-friendly schemas with the Grandma test baked in. [Learn more](/services/sanity)

---

## Tips and tricks for building Sanity schema efficiently


> Want to build a page or craft detailed articles? Our Sanity schema tips and tricks offer the perfect starting point. A guide to upping your CMS game. 

**Published:** 2023-01-08 | **Updated:** 2026-07-23 | **Categories:** How To, Sanity
---

We're big believers in standardisation, it's all around you, you've seen:

- Design systems
- Design tokens
- Componentised design
- React patterns

So we thought to ourselves: "Why should Structured Content be any different?". That's why we've written a fully **opinionated** guide for building your *regular* style of website.

Now you might be asking: "*surely the whole point of Structured Content is to give the developer the freedom to build whatever they like". *This is true, but the reason we've written this guide is to make the whole process of learning about Sanity CMS more uniform, and easier to understand.

This guide won't fit everybody, but it should hopefully give you an understanding of how to better structure content. If you're just looking for a [Sanity](/services/sanity) V3 primer, there's a great [layman's breakdown here](/blog/what-sanity-studio-v3-means-for-clients)

## The anatomy of a good document
We've broken down a good document to help with understanding the why's and how of writing a piece of Sanity schema.

```typescript
export default {
  // Get used to camelCase for naming things
  name: "exampleDocument",
  title: "Example document",
  type: "document",
  //   The fields array is where you define the fields
  //   of your document type
  fields: [
    //  The reason we always use Title is because
    //  Sanity defaults to this field when creating previews
    {
      name: "title",
      title: "Title",
      type: "string",
    },
    {
      name: "description",
      title: "Description",
      //  A nice thing to do is to create a rough row limit dependent
      //  on the description. E.g 3 rows for a short description.
      //  You can also add validation but we're not covering that here
      rows: 3,
      type: "text",
    },
    {
      name: "image",
      title: "Image",
      type: "image",
      //  You can also add hotspots to images.
      //  Be aware it's a little trickier if you're using Next Image
      hotspot: true,
      fields: [
        // This is to ensure the alt text is filled out
        {
          name: "alt",
          type: "string",
          title: "Alt Text",
        },
      ],
    },
    // We will explain the basics of portable text in the next section
    {
      name: "portableText",
      title: "Portable text",
      type: "portableText",
    },
  ],
  //   This is how we setup the preview for the document type
  //   When it's a document we almost always use the description
  //   field as the subtitle
  //   However, we advise a little different on a page builder
  preview: {
    select: {
      title: "title",
      subtitle: "description",
      media: "image",
    },
    prepare({ title, subtitle, media }) {
      return {
        title: `${title}`,
        subtitle: `${subtitle}`,
        media,
      };
    },
  },
};

```

> **Sanity CMS development**: Schema architecture, reusable patterns, and Sanity studio customization for content teams. [Learn more](/services/sanity)

## Previews
The most important element of the above content is a preview, that's where your client can *actually see* the content being populated from the Document pane.

See how much better the data looks on a *properly prepared* page builder, in comparison to one without any preparation:

### Unprepared preview
![Unprepared preview](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/tips-and-tricks-for-building-sanity-schema-efficiently-blog-unprepared-preview.png)

### Prepared preview
![A prepared preview](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/tips-and-tricks-for-building-sanity-schema-efficiently-blog-a-prepared-preview.png)

The difference is night and day (not just because of light and dark mode), and your future clients will appreciate the effort.

## Adding an icon
Something you might have noticed on the prepared preview above, is the little icons to the left of the title and description. Can you see how much clearer it makes it - providing a client with not just a descriptive text of what it is, but also an image to represent.

```typescript
import {FaNewspaper} from 'react-icons/fa'

export const SingleArticle = {
  title: 'Article',
  name: 'article',
  type: 'document',
  // This icon makes all the difference
  icon: FaNewspaper,
  fields: [
  ...
  ]
```

## Page builders
The faster you get used to adding these little icons and nice little previews, the quicker it becomes to scale your structured content. As a nice little bonus, all these icons get pulled through in arrays and other structures to make it even easier to build a page builder and actually know what you're adding to a page.

---

## Dynamic open graph images with Sanity & Next.js


> Looking to get dynamic open graph images working with your Sanity & Next.js website? We explain the steps to create truly dynamic images for your future blogs.

**Published:** 2023-01-04 | **Updated:** 2026-08-19 | **Categories:** Sanity, Next.js
---

This post covers the single-size setup: one 1200x630 image per page. Once that works, the [multi-ratio version](/blog/one-og-template-every-aspect-ratio) renders square and portrait variants from the same template.

The aesthetic of a website on social networking can be enhanced by using Open Graph Images. it is possible to manage how a website is portrayed when it’s shared on social networking platforms by defining these images using a collection of meta tags on the head part of the page.

It is easy to notice the advantages of using Open Graph images when comparing a website with defined Open Graph images with one without. When shared on social media, the website with an Open Graph image will display an aesthetically pleasing and representational image, but the website without an Open Graph image will either display no image or a random image from the website's content. The user's opinion of the website and the likelihood to click on the shared link may be considerably impacted by this.

### Setting up open graph image/social card generation on the next app
To create social cards there’s a plugin provided by vercel.

```bash
# @vercel/og
# to install this on a next js project:
npm i @vercel/og
```

*For Next.js implementations, make sure you are using Next.js v12.2.3 or newer*

Create an API endpoint by adding og.tsx under /pages/api. Then paste the following code:

```tsx
import { ImageResponse } from '@vercel/og';

export default function () {
  return new ImageResponse(
    (
      <div
        style={{
          fontSize: 128,
          background: 'white',
          width: '100%',
          height: '100%',
          display: 'flex',
          textAlign: 'center',
          alignItems: 'center',
          justifyContent: 'center',
        }}
      >
        Hello world!
      </div>
    ),
    {
      width: 1200,
      height: 600,
    },
  );
}
```

Then, based on the Open Graph Protocol (https://ogp.me/#metadata), create the web content for your social media post as follows:

- Create a `<meta>` tag inside the `<head>` of the webpage
- Add the property attribute with value og:image to the `<meta>` tag
- Add the content attribute with value as the absolute path of the /api/og endpoint to the `<meta>` tag

```tsx
<head>
  <title>Hello world</title>
  <meta
    property="og:image"
    content="%absolutepath%/api/og" // absolute path of the app after deployment.
  />
</head>
```

### Adding a dynamic touch to it.
To make the Open Graph image generation dynamic, developers can pass data into the API endpoint as query parameters and generate images based on that data. This can be done by creating a 

`<meta>` tag in the `<head>` of the webpage and setting the **property** attribute to `og:image` and the **content** attribute to the absolute path of the `/api/og` endpoint, along with any desired query parameters.

```tsx
export default function Page({title, image}) {
  const searchParams = new URLSearchParams({
    title,
    image, // link to image
  })
  const imageUrl = '...absoluteaddress/api/og?' + searchParams.toString()
  return (
    <html>
    <head>
      <title>The post's title</title>
      <meta property="og:image" content={imageUrl} />
    </head>
    ...
  )
}
```

and on the og.tsx page

```tsx
import {ImageResponse} from '@vercel/og'
import {NextRequest} from 'next/server'

export default function handler(req: NextRequest) {
  try {
    const {searchParams} = new URL(req.url)

    // ?title=<title>
    const title = searchParams.get('title') ?? 'default Title'
    // ?image=<image>
    const image = searchParams.get('image') ?? 'https://linktodefaultimage'

    return new ImageResponse(
      (
        <div
          style={{
            backgroundColor: 'black',
            backgroundSize: '150px 150px',
            height: '100%',
            width: '100%',
            display: 'flex',
            textAlign: 'center',
            alignItems: 'center',
            justifyContent: 'center',
            flexDirection: 'column',
            flexWrap: 'nowrap',
          }}
        >
          <div
            style={{
              display: 'flex',
              alignItems: 'center',
              justifyContent: 'center',
              justifyItems: 'center',
            }}
          >
            <img alt="image:alt" height={200} src={image} style={{margin: '0 30px'}} width={232} />
          </div>
          <div
            style={{
              fontSize: 60,
              fontStyle: 'normal',
              letterSpacing: '-0.025em',
              color: 'white',
              marginTop: 30,
              padding: '0 120px',
              lineHeight: 1.4,
              whiteSpace: 'pre-wrap',
            }}
          >
            {title}
          </div>
        </div>
      ),
      {
        width: 1200,
        height: 630,
      }
    )
  } catch (e: any) {
    console.log(`${e.message}`)
    return new Response(`Failed to generate the image`, {
      status: 500,
    })
  }
}

```

this way you can customize the og image per page.

> **Sanity CMS development**: OG images, metadata, and Sanity + Next.js integration for better social sharing. [Learn more](/services/sanity)

## **Conclusion**
In this article, we have examined how to use Vercel and Next.js to generate and output Open Graph images for social media sharing. We have seen how to set up a Next.js app with Vercel and use the **@vercel/og** plugin to generate Open Graph images. We have also explored advanced techniques for customising the Open Graph image functionality of a Next.js app with Vercel, such as generating dynamic images.

I hope this article has been helpful! If you have any questions or would like to learn more about using Vercel and [Next.js](/services/nextjs) for Open Graph images, be sure to check out the [**Next.js documentation**](https://nextjs.org/docs) and the [Vercel documentation on og images](https://vercel.com/docs/og-image-generation). 

### Thinking about generating an image for Sanity's blog?
Here's a quick tip, it says the image is 1200x700px - it's actually closer to 1200x758px if you want it to look identical to the Roboto Studio open graph.

---

## How Sanity handles your data


> We go through all the security certs and accreditations that make Sanity a league of their own when it comes to data protection. 

**Published:** 2022-12-08 | **Updated:** 2026-07-23 | **Categories:** Sanity
---

Sanity implements comprehensive security measures while meeting the best practice compliance obligations in the industry. These rigorous security and compliance procedures are employed to ensure that users feel trusted and confident about sharing their most critical assets.

An effective IT security program is a stepping stone to success in businesses and Sanity takes this responsibility very seriously. Sanity uses security and compliance protocols to ensure whether you’re aiming for **GIAC Security Essentials**or *ISO 27001,* you’re covered. In the next section, we will explore in depth about how Sanity helps businesses meet digital security standards.

### SOC 2 type 1 Compliance
Sanity is certified with SOC 2 Type 1 and therefore demonstrates that they are appropriately protecting data within their systems. This certification also allows users to request for a "right to audit" at any point. This in turn assures users that their sensitive data is handled with care.

### General Data Protection Regulation (GDPR)
Sanity is thoroughly GDPR compliant and employs best practices for security and privacy to protect users’ data. It also provides users with clear information about how their data is managed as well as information about their right to access, object and restrict data. Users are provided with tools such as - data retrieval via GROQ query language, custom data retention policies, and APIs for permanent data deletion - which helps them to remain GDPR compliant themselves.

### Payment Card Industry Data Security Standard (PCI DSS)
Sanity uses Stripe payment processor to handle all credit card and payment information. Stripe has been audited by an independent PCI Qualified Security Assessor and certified as a Level 1 service provider in the payments industry - meaning they meet some of highest certification requirements available to processors worldwide.

### Infrastructure Security
Sanity is hosted on Google Cloud Platform which undergoes frequent security audits for a variety of security scrutiny such as ISO 27001, ISO 27017, ISO 27018, SOC 2, SOC 3, CSA STAR, HIPAA, and PCI DSS.

### Data Retention and Removal
Sanity removes or anonymises all data as soon as possible after it is no longer needed, with a short grace period and backup retention periods stated in their service agreement to allow for accidental or malicious removal. Users can also contact them if they wish their personal information to be removed from their servers entirely.

### Data Access Control
To ensure the security of customer data, employees have access only to systems required for their role. The central resources are accessed using two-factor authentication, which requires an account with Google or Github. All remote connections are encrypted either through HTTPS transport level security or VPN connections. Employees will never directly interact with any customers' controlled assets unless it's necessary due to support reasons and, in that case, will generally ask for the permission first.

> **Sanity CMS development**: Data security, compliance, and Sanity infrastructure for teams that take data seriously. [Learn more](/services/sanity)

### High Availability, Backups and Disaster Recovery
Sanity is equipped with fully redundant and distributed systems, operating across multiple data centers. This means that if one component failed, the others would continue to work as normal - providing relief for the businesses during disasters like natural ones or cyberattacks.

Sanity has real-time data replication systems across multiple data centers as well as continuous data backups of their databases to remote storage in several locations. According to [Sanity's security documentation](https://www.sanity.io/security), databases can be restored to any point in time within their stated retention period with per-transaction precision.

For disaster recovery purposes, backed-up data is copied to a separate cloud account in another geographic region. This is protected with strict access controls and dedicated authentication mechanisms. For the most current details on backup retention and access policies, refer to [Sanity's Trust Center](https://www.sanity.io/security).

If data security is a priority for your next project, we can walk you through how [Sanity](/services/sanity) stacks up for your specific compliance requirements.

---

## What Sanity Studio v3 means for clients


> Sanity Studio V3 brings faster Vite builds, dark mode, multi-workspace logins, and improved custom component support. Here's what matters for clients.

**Published:** 2022-11-28 | **Updated:** 2026-07-23 | **Categories:** Sanity
---

With Sanity V3 right around the corner, we wanted to break down the changelogs into bite-sized chunks. Help you to understand the why's more so, than the what's.

## Embed it in projects
This is a bit of a niche one, but incredibly useful for you if you fit the description. It essentially allows you to embed an editor **within** the framework of your choice. Where might this be useful? Well, there's already an [awesome example here](https://www.youtube.com/watch?v=00iepYPbQII) from Jonas at Kickstart DS.

You could skip a whole bunch of work embedding an entire

## Vite tooling
You don't need to know too much about what [Vite](https://vite.dev/) is... However, this utility provides much faster updates as developers work on the project in a local environment. It means that changes that may have taken 5s to see a difference now take roughly about 0.5s, bear in mind, a dev probably makes a change every 5 or so seconds, and this snowballs into shaving potentially days of the output of a total project. Faster = Better.

## Better custom component support
Sanity V3 has a far more solid foundation of which to build custom components from. This means when you want to do something such as *a custom opening times component*. It's far easier and far more straightforward.

This means that combined with the Vite tooling, it should be faster to design, develop and ship brand-new form fields inside your Sanity Desk.

## Dark mode
**My eyes! It burns**

That will be a thing of the past, now we've got dark mode baby! This only probably applies to developers, but anybody that has spent late nights responding to emails, only to be blasted by a sudden bright white screen knows this pain all to well.

Well retina burn is a thing of the past with the new dark mode studio. Every element of the studio has now been converted to support dark mode.

## Multi-workspace-logins
As somebody that works with 10+ Sanity workspaces, we're all too aware of the hopscotch to move from one workspace to another. This quality of life improvement will make it easier to navigate between separate workspaces.

For example, if you have a separate workspace for your app and a separate workspace for your website, you can have a simple dropdown that allows you to switch easily from the desk itself.

## Future plugin work
Because of all the above changes, performance, QOL and speed of delivery should increase tenfold. With all this groundwork being added, we are sure there will be an even bigger surge of new plugins, extensibility and easier, better ways to handle structuring your content.

You can read more about our [first plugin here](/blog/revolutionizing-visual-content-creation-with-sanityio-and-openai)

*So what are you waiting for.* We've [migrated a good few projects](/services/cms-migration) so far, and it's a simple process (*mostly*).

Once you're on v3, there's a lot more you can do with the studio day-to-day. Our post on [getting better at using Sanity Studio](/blog/get-better-at-using-sanity-studio) covers the practical tips for non-technical editors and developers alike.

> **Sanity CMS development**: Migrations, custom components, and studio configuration. [Learn more](/services/sanity)

If you're having any issues, drop a message across to [hello@roboto.studio](mailto:hello@roboto.studio) and we can see if we can help.

---

## We are Sanity agency partners


> Guess what? We're Sanity agency partners. Learn how coupling a top-tier CMS with a high-performance frontend delivers an unparalleled web experience.

**Published:** 2022-10-10 | **Updated:** 2026-08-03 | **Categories:** Sanity
---

As an agency, we always test our tech stack the same way *every time*. We swap out our CMS or our Frontend. Why? Because it's a long and arduous procedure and we wouldn't advise anybody to do it unless they're certain that the result will bring far more advantages than the time it would take to just refactor.

**Along came Sanity.**

So when we started speccing out the CMS, knowing all of the long-term issues that might arise, we wanted to make sure that we found our golden goose.

*First, *we tested the scalability, how does referenced content work? Will we be able to non-destructively change field names? How about validation, can we customise it?

*Second*, we tested how performant it was, how on-board the development team was with questions and what the roadmap looked like.

*Finally, *we internally critiqued it, essentially drilling down to every last detail to ensure we hadn't picked a doozy.

## Drop everything, we're going all in
Once we realised, that every last box had been ticked, we knew it was going to be our **be all and end all. **So we started refactoring the Roboto website, piece by piece building back up the components. What was even better was the fact that all of these components came as standard with typescript generation thanks to a nifty tool called [Sanity Codegen](https://www.sanity.io/plugins/sanity-codegen).

After some late nights, blood sweat and tears we finally got the new and upgraded version of Roboto using Sanity as the CMS. Naturally with any new technology there's an element of honeymoon period... However, we're still well and truly feeling the love, far outside of that... In fact so much so, that I'm typing this with the new Sanity V3 environment and loving every second of speedy content generation... **Check it out.**

![Sanity Editing Environment](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-are-sanity-agency-partners-blog-sanity-editing-environment.png)

## Happily ever after
Following our swap over to Sanity, we've been building more and more ambitious projects, and becoming more and more involved with the community. *So much so* we're now on the Community Ambassador team (awaiting a sparkly pin to show everybody) and Sanity Agency Partners.

If you're planning on building a Sanity CMS powered website or app, [get in touch](/contact), we love to talk shop and we'd be more than happy to share our experiences of "the good, the bad, and the ugly" in [headless CMS](/services/headless-cms)'

![Sanity logo with a verified partner badge](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/we-are-sanity-agency-partners-blog-body-image-2.png)

> **Sanity CMS development**: Official Sanity agency partner. Schema design, migrations, and ongoing support. [Learn more](/services/sanity)

Picking the right team matters as much as picking the right stack. Our [Sanity CMS development agency](/services/sanity) handles the schema design, migrations and ongoing studio work, so you get a build that editors actually want to use.

For those looking to accelerate their projects, our [workshops](/services/workshops) provide a focused approach, combining the best of both worlds to deliver high-performance applications quickly.

Additionally, if you're focused on building solid applications, our [Next.js app development](/services/nextjs) service ensures you use the full potential of this powerful framework, providing scalability and efficiency.

---

## How to transfer from WordPress to JAMstack fast!


> A walkthrough of migrating WordPress posts to a JAMstack site with Stackbit, kept up for posterity now Netlify has folded Stackbit into its Visual Editor.

**Published:** 2021-09-30 | **Updated:** 2026-07-23 | **Categories:** How To, CMS
---

> **Update (July 2026):** The stack this post walks through doesn't exist anymore. Stackbit got acquired by Netlify and folded into their Visual Editor, and Forestry was retired in favour of Tina. I'm leaving this post up for posterity, but you can't follow it step by step anymore. If you end up reading this and want a newer version, [DM me on X](https://x.com/jonoalford) and I'll write the whole thing up.

We're going to go through the process today of dipping your toes with a new JAMstack website. We're going to cover getting all your previous **posts** from WordPress and the basics of migrating individual pages and the do's and dont's that we encountered when migrating a website of our own.

For a rough estimation of time, we've listed the elements below and a timeframe you'll need for each

- Signing up for Stackbit, Forestry, GitHub & Netlify within Stackbit - 30mins to an hour
- Migrating WordPress, converting your posts to Markdown and adding to site - 1 hour
- Polishing the little bits of SEO that are left out - 2 hours

## The caveats
A few things to note before making the switch:

1. Page builders such as Gutenberg, Elementor or ACF will not migrate properly and require a much more comprehensive migration process - which is why we're not covering it
1. Pages will migrate over providing they're mostly text, however this post primarily focuses on simple blog posts
1. There is a small refresh time when using JAMstack when you make amends to the site - this is purely to re-render all the content, this provides the fastest possible way for your clients to view it.

## Exporting from WordPress
We went with a WordPress website we worked on a long time ago called Say no to Mowlands. We wanted to simplify the site, and keep the blog posts at the forefront of what is important as it provides weekly/monthly updates on progress.

We started by exporting all the blog posts out of it. You can access the export options from:

**Sidebar → Tools → Export**

Inside of this section you can tailor the exact categories/authors you want to export, however if you want every post dont make any alterations to the dropdowns and just press the **Download Export File** from the bottom of the page

![Exporting a WordPress website](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-exporting-a-wordpress-website.png)

This will download your posts in an XML format, which we will need to convert before importing into the site**.** The reason we love **Forestry** and we're using it within this tutorial, is because it closely represents the same UI of WordPress so it's less of a jump to UX-wise when migrating.

![WordPress website exported to XML](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-wordpress-website-exported-to-xml.png)

## Converting the XML
To get the XML to play nice with Gatsby & Stackbit, we're going to need to convert it to Markdown. Luckily some clever dev out there (shoutout to @LoneKorean [https://github.com/lonekorean](https://github.com/lonekorean)) created a simple way to batch convert them.

You can pickup the tool here: [https://github.com/lonekorean/wordpress-export-to-markdown](https://github.com/lonekorean/wordpress-export-to-markdown)

Once you have downloaded the tool, **extract it**, then you should see a folder like this:

![WordPress XML being converted to Markdown](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-wordpress-xml-being-converted-to-markdown.png)

From here you want to open a terminal up then navigate to the folder where it was downloaded to. In our case we downloaded it to the downloads folder.

![Opening up the terminal](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-opening-up-the-terminal.png)

We're going to install everything with:

```
npm install
```

It should be absolutely rapid and once finished, you should see a node_modules folder and no errors in the terminal. **Keep your fingers crossed.**

Once installed to keep things simple we are going to rename the export from WordPress to "export.xml". We're then going to drag it into the root of the wordpress-export-to-markdown-master folder which we downloaded and extracted earlier.

![Results from the export](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-results-from-the-export.png)

Our next step is return to the terminal (pro-tip: make sure your terminal is set to the correct directory) and type:

```
node index.js --postfolders=false --prefixdate=true --addcontentimages=true
```

This should spit out a list of all your posts and a separate folder inside with images linked in the markdown. You might have a couple of errors within the terminal dependent on any externally linked images. For these you will need to download manually and fix.

Once we have this output, this is the first big step, give yourself a pat on the back.

## Getting the site setup
Now for the much more fun, and fancy part. We're going to start by signing up for Stackbit. This is a tool that brings together our:

- **GitHub -** where we will keep our site along with any amends we make along the way
- **Netlify -** the platform we use to deploy changes and host our site
- **Forestry -** the CMS where we make changes to the website

It also allows us to choose from a selection of themes and site generators to build the site from e.g HUGO, Gatsby, Jekyll.

## Choosing which theme
You can select from a bunch of different themes within Stackbit. The reason we're using Stackbit is for 2 reasons:

1. Their theme selection is very impressive and high quality
1. Their themes work in every language and CMS without any fuss, nice and simple

For our theme we chose Ampersand, because it matches the simple green theme of our original website and keeps the focus of the homepage on a list of most recent blogs.

![Choosing a theme](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-choosing-a-theme.png)

## Selecting a site generator
For the site generator we are using Gatsby, however this method will work for both Hugo and Jekyll. So go ahead and click that Gatsby button and move to the next step

![Choosing a generator](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-choosing-a-generator.png)

## Selecting a CMS
Now this is section is very important, mainly because if you **press the wrong one, it won't work.**

So make sure you choose Forestry CMS. The reason being is that some CMS's revolve around API's so the content is passed to your static site builder in a different way. For this version we use Forestry as it adds new markdown files to your git repo as you make changes within the CMS.

![Choosing a CMS](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-choosing-a-cms.png)

## Selecting deployment
There's no other options here, but we would recommend using Netlify anyway due to the way it handles deployment + forms + edge (seriously, check that last one out).

Once you've connected all the accounts your last step will be creating your project!

![Using GitHub and Netlify](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-using-github-and-netlify.png)

![Choose a name](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-choose-a-name.png)

This is where the magic happens, Stackbit will commit a Gatsby website to your GitHub account, it will spin up an instance of Netlify and tie all of it together (rather miraculously) and setup everything to get you started with a www.**yourwebsite**.netlify.com domain.

![Building the project](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-building-the-project.png)

**Side note** - it takes roughly 60 seconds or so to deploy, so press start and put yourself on a cup of tea really quick, and by the time you're back it'll be finished.

> **Headless CMS services**: CMS migration and modern frontend builds for teams leaving legacy platforms. [Learn more](/services/headless-cms)

## Moving your wordpress posts into Gatsby

![Stackbit dashboard](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-stackbit-dashboard.png)

When your website is live you want to go ahead and click the GitHub link on the right hand-side

The next step is fairly simple, but for the theme we chose, it requires some modifications. A good way of working out what frontmatter you need, is by opening the files that can be accessible from: **/src/pages/posts**

Once you're in here you should be able to see some posts that have already been created with the site. You can click into these, for example:

![Frontmatter in polite tulip](https://qxvqs298ldvynvwd.public.blob.vercel-storage.com/how-to-transfer-from-wordpress-to-jamstack-fast-blog-frontmatter-in-polite-tulip.png)

At the top, there is "Frontmatter" this is essentially the details about the specific post, pay close attention to the furthest right frontmatter item "template - post". This is how we identify the style/layout of the page.

See bottom row below.

```markdown
---
title: Basic Rules For Walking In The Mountains
date: '2019-04-09'
template: post
---
```

What we now need to do as our last step is take the markdown generated from the WordPress to Markdown script and add the missing "template: post" to the frontmatter. We can do this in a multitude of ways, such as Regex searching, but seen as we're into simple solutions to complex problems, we're simply going to use Visual Studios find and replace.

We're going to open the folder of all your new markdown files, and from there, you want to press cmd+shift+f and use the find and replace left hand search to find the snippet highlighted in the window below.

```markdown
template: post
---
```

From there you're going to replace this with:

What this will do is essentially add "template:post" to the end of all your frontmatter within your markdown and allow the website to show these.

## That's all folks!
If you'd like to see a working version of the above you can view a site here: [https://www.saynotomowlands.com/](https://www.saynotomowlands.com/)this website was essentially migrated from a WordPress website and is now roughly 5x faster with minimal hosting costs.

If you get stuck, drop us a message. We've helped teams migrate from WordPress to modern [headless CMS](/services/headless-cms) setups, and these days we typically recommend [Sanity](/services/sanity) paired with [Next.js](/services/nextjs) for the best results.

---

# Videos

## A/B testing in Sanity Studio with PostHog


> A quick walkthrough of A/B testing a hero button with Sanity Studio and PostHog. Set up control and variant pages in Sanity, ship them to users, and read exposures, clicks per user, and winners str…

**Published:** 2026-09-22 | **Updated:** 2026-09-23 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=86lW_o3tadg

---

## Transcript

AB testing with Sanity Studio and PostHog. I'm going to show you a very cool example of a button hero that we built internally and how easily you can set your own test and check the results on PostHog.

As you can see on my screen, I've set up my test on Sanity. This is the AB testing space where I've added my control and my other one, called it blue. Essentially it's a black button. And the other thing is I have pages for black and white as well. You can set as many pages in your particular case as you want.

Now I'll show you exactly how this looks. The user will see this and what they can do is click on this button, and you can see the total clicks changing on the screen. If I refresh it, hopefully I get a different variation to show you.

There we go. So we've got the black one. Click a bunch of times. Anyway, you can do this for any use case with different variations. You can do it for form clicks, different pages, or whatever suits your needs. I'll show you how this looks on the PostHog side.

This is my particular demo. As you can see, total exposure is 125. That's 125 times this was exposed to people. I have my control and I have my blue. I called the other one blue but it's essentially a black button. I know it's a little bit confusing but bear with me.

As you can see here, on average there's eight clicks per person for the control, and on average there's nine clicks per user for blue. But the interesting thing is 30 versus 23 exposures to look at. So 23 times the blue button was exposed to the user as compared to 30 times for the control variation. But on average, nine clicks per user was recorded for the blue one. So the blue one, or the black button, is winning in our case.

You can set your metrics here, look at them, look at all the different charts. In our case, as I mentioned, the blue one is doing much better than the white one. But this is a very simple example. The whole point of this video is to show you how easy it is to record this and use it in your own use case.

The tool is completely open source. Let us know if you'd like to try it for yourself and how you found it. We love making these kinds of videos.

## Frequently asked questions

### What is AB testing in Sanity Studio?

AB testing in Sanity Studio lets you create different variations of content, like buttons with different colors, and serve them to users to see which performs better. You set up a control version and one or more test variations, then track how users interact with each one to determine which wins.

### How do you set up an AB test in Sanity?

In Sanity's AB testing space, you add your control variation and name your other variations, like we called ours blue. You can also create multiple pages for each variation if you need them. The setup is straightforward and you can customize it for whatever you want to test.

### What metrics does PostHog show for AB tests?

PostHog displays total exposures, which is how many times a variation was shown to users, and average clicks per user for each variation. You can see these metrics side by side to compare performance between your control and test versions, along with additional charts and data points.

### How can you tell which variation is winning?

Compare the average clicks per user between your variations. In our example, the blue button had nine clicks per user on average while the control had eight, making the blue variation the winner. PostHog makes it easy to see these numbers and determine which version performs better.

### What kinds of things can you AB test?

You can test button variations, form clicks, different pages, or really any use case where you want to measure user interaction. The system is flexible enough to accommodate whatever variations you want to compare across your product or site.

### Is this tool free to use?

Yes, the tool is completely open source, so you can use it without paying for a license. You can set it up for yourself and start running tests right away with no cost barriers.

### How easy is it to track test results?

Once you set up your variations in Sanity, they automatically feed into PostHog and you can see all your metrics and charts immediately. The whole process from setup to viewing results is designed to be straightforward so you can focus on what the data tells you about user behavior.

---

## Turbo Start BigCommerce: a Sanity + BigCommerce starter


> A first look at our Turbo Start BigCommerce starter. It pairs Sanity with BigCommerce as a one-way sync engine, ships JavaScript-free navigation for SEO and AEO, and leaves room for dynamic B2B pri…

**Published:** 2026-09-22 | **Updated:** 2026-09-23 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=bytVuBvwjTk

---

## Transcript

So, Big Commerce. Why would I build with Big Commerce over Shopify? Generally Shopify is B2C and Big Commerce is B2B. Now, if you're not particularly well-versed on your TLAs, what's a TLA? Well, the three-letter acronym. A B2C is business to consumer. B2B is business to business.

Why is this important and why does the central infrastructure change depending on which one you're going for? Well, with Shopify, as a general rule of thumb, you have a store. The store has a bunch of products, probably hundreds if not thousands. The store maybe has something like a coupon, but it's all kind of nice and slim line. The idea is you can just fire these things out and start selling products.

B2B is slightly different. There's a lot more focus around accounts and different prices depending on who you are, and a lot more of that custom functionality that you'd expect as you build a relationship with another business. B2B is a totally different kettle of fish.

Starting with Turbo Start Big Commerce, I want to show you a few of the different things inside here and why this differs from the pure Big Commerce offering. One of the most important ones that most people don't get on their websites, and I will tell you, go try it on all the different websites: disabling JavaScript.

What happens when we disable JavaScript? There are some caveats because I've just said that you have custom pricing per user and that's probably not going to work here. But I will show you why this is important. If I disable JavaScript and refresh the page, you're going to notice that absolutely nothing has changed. That's actually a really good thing because you realistically want to be able to see the page and see all the different versions of it.

Right now this is set up more as B2C because of the products in here. Nobody's going to go from business to business to buy a denim coach jacket. But the point of this demo is that we've put a bunch of fake dummy content in here. We might swap this out in the future, but for now it was the easiest way of doing it.

However, as you can see, you can actually navigate the store. JavaScript is still off and I can still see all of these pages, which is really important because if you're going for Google, Google takes a hell of a lot more time to index your website if it's all client-side JavaScript. You can see all these different collections and all these different items inside of here. Even things like categories. If I go for the bottoms category here, you'll see there's a couple of different bottoms inside of it.

The main thing here is that something can navigate it without JavaScript, which means it's amazing for Google and amazing for AI crawlers. There's one more step with the AI crawlers that I don't know if anybody's actually done this yet. I think we might be the first folks to build a Sanity and Big Commerce starter that actually works with AEO out of the box.

If we go in here, you can see this page. I notice the add to cart is missing very intentionally because essentially we want this to be able to reflect the dynamic pricing. You still want the pages to be indexed, but you don't necessarily want to show that dynamic pricing. We could do some clever stuff with a fallback, but the idea of a starter is we don't want to make it too opinionated either.

You get everything that you see right here. It's a one-click install and you can run it directly from Sanity. I'm saying Sanity a lot, but I can't really see anything so far that's from Sanity. Well, the cool thing here is that you're basically building a sync engine that sits between Big Commerce and Sanity. You can populate your Sanity database with all this information that comes from Big Commerce.

It's really important when you want to actually have integrated pages where you build a curated experience and then include the products with up-to-date information. Generally you want to do it as a one-way sync, and I think that's how this particular template is built.

I do want to show you a couple more things and show you what's out there so far and why this is kind of important in my opinion. Obviously it's important from my opinion because we built the damn thing. This is the Sanity exchange Big Commerce. I'm going to show you one from Mitchell. If you haven't met Mitchell already, he's a really cool dude. He built Sanity Press, a really nice tool. Definitely check it out if you get two minutes.

One from Todd Padwick, who I think is from Form and Function, which is another big agency. You can also see the Advette Commerce, a progressive web app for the front end. Founder of Form and Function Digital. There's only two people basically that even talk about Big Commerce on Sanity right now. It's not like we're trying to fill an SEO gap or anything like that.

Have a read of Mitchell's really interesting blog if you get two minutes. If you want to build something with Big Commerce, definitely give us a shout. If you're more interested in seeing how this works and seeing the editorial experience, I'm happy to show that as well. I thought I'd just do a quick first version and come back later if you want more information. Drop a comment below and let me know how you get on.

## Frequently asked questions

### What's the main difference between Shopify and Big Commerce?

Shopify is built for B2C, meaning business to consumer, where you have a store with products and coupons. Big Commerce is built for B2B, meaning business to business, where you need multiple accounts with different pricing for different customers and more complex functionality to manage ongoing business relationships.

### Why does infrastructure change between B2C and B2B?

B2C stores are simpler with hundreds or thousands of products and basic discount codes. B2B requires custom pricing per customer, account management, and relationship-specific features that make the infrastructure fundamentally different from a standard product catalog.

### What happens when you disable JavaScript on the Turbo Start template?

The pages still work and you can navigate the entire store without any JavaScript running. This is important because it means Google can index your site faster and AI crawlers can access your content, rather than waiting for client-side rendering to happen.

### Why is JavaScript-free navigation important for SEO?

Google takes significantly longer to index websites that rely heavily on client-side JavaScript. By making your store navigable without JavaScript, you ensure that search engines and AI crawlers can access all your pages, collections, and products much more quickly.

### What's the Sanity and Big Commerce starter template?

It's a one-click install that creates a sync engine between Big Commerce and Sanity, letting you populate your Sanity database with product information from Big Commerce. This lets you build curated editorial experiences with up-to-date product data while maintaining control over your content.

### Why remove the add to cart button on some pages?

When you have dynamic pricing based on customer accounts, you don't want to display specific prices on indexed pages since they'll vary by customer. You can still let pages be indexed for SEO without showing the cart button, though you could use fallback pricing if needed.

### Is the Big Commerce and Sanity integration a two-way sync?

No, it's set up as a one-way sync, pulling information from Big Commerce into Sanity so you have a single source of truth for product data while building your editorial experience.

---

## Sanity Everything NYC 2026 recap: every feature announced


> A walkthrough of everything announced at Sanity's Everything NYC 2026 event. We cover Knowledge Bases, Workflows, Content Variants, Durable Functions, Blueprints, Project Horizon, and Resonance - w…

**Published:** 2026-09-18 | **Updated:** 2026-09-19 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=oj1TP63OmEI

---

## Transcript

I got the jacket on, and I want to show you this. Sanity Pioneer 2026. Very happy about that. Thanks everybody at Sanity, really appreciate it. Great event.

Everything NYC, first of all. Wild landing page. I don't know if you've played around with it, but it actually has a full AI agent for this. The conference is at Pioneer Works, which is wild. I don't know if anybody's ever been there, but it's a really cool place. There's also an amazing light show or live art installation that was really cool. I've noticed that Sanity's design game has been going real high. It's looking really cool.

Let's talk about the landing page. If you haven't seen it, there's an Everything 2026 recap. I'm going to tell you exactly what I think of everything on here.

Knowledge bases is an interesting one. I didn't initially know what this was going to be, but effectively if you've used the Sanity context thing, it's kind of similar, but this is far better at creating a giant pool of information and being able to get that information and find out where the content gaps are. You can also find out what people are looking for depending on the level of security, and most importantly, you can find inconsistencies.

Pretty much everybody has tried creating a company portal in a multitude of different ways. We've tried it. We're actually in the process of building a Turboar brain. This was before knowledge base came out, but knowledge base actually makes it better. As soon as you build one of these, it works the exact same way as development. When somebody says as soon as you build a line of development, it's development debt because it's just a matter of time before systems upgrade, code changes, things get deleted.

Knowledge base is interesting because it has this self-sustaining element of it where you can effectively say on your website that your pricing is a tenner to do this, but on your database it actually says that your pricing is 15 quid. Or on documentation it says your returns are 30 days but on the actual product page it says 15 days. Which one's the right one? That's one thing that knowledge base can do very well.

The other thing it can do very well is basically set up an MCP endpoint and then you can have people hit that MCP endpoint and find out exactly what people are searching for. This is really cool for two reasons. One because people are looking for things on your website and you've given them basically a way to interact with that, whether it be by chatbot or search or something else. You can basically hit that endpoint.

But the more interesting thing is that you can use this knowledge base for finding out what your LLMs are looking for if you use it in a certain way. You can feed the LLMs and say here's an endpoint that we're basically putting out there publicly, and then the LLMs can go hit that endpoint and you can serve that information back. But the cool thing is that you can actually find out where those knowledge gaps are. So if all the LLMs are trying to work out what we do for WordPress, I can have a heart attack and say there's no way I'm going to build that crap and then eventually have to be forced down to building WordPress because so many LLMs are going out to basically find that information.

It's really cool. It works with existing Sanity. What was most interesting is it also exists with websites that aren't on Sanity or systems that aren't on Sanity that are able to be scraped, and it also works with PDFs which is pretty wild. Definitely worth looking into. For forward thinking companies, I absolutely think this is going to be the big kicker thing for 2027.

And talking of 2027, 2026 is the year of workflows. Everybody's releasing workflows. There was AI SDK and the workflow SDK and now Eve from Vercel. This is kind of more of a curated workflow system where you can essentially set the steps up.

Where I can see this working, if you haven't done this already, it's really cool, is that you could have somebody on the team, and realistically we should run a lawyer before we actually say anything on our blogs. So we might have multiple steps. We might have first version, AI slop version. The first version basically puts a whole bunch of AI content. We look for a bunch of competitors and say I want to have a blog that outranks A, B, and C. Cool, here's that slop 30,000 character article. Nobody wants to read this crap.

Step two is a human comes in and goes, I don't want to read that. Let me cut it down a little bit. Maybe cut it down to 1,500 characters. Maybe throw a couple of colloquialisms in there. Eventually you're at the point where you think, oh, step two, that's great. There's a human in the loop. I've proof read it. It looks good. Cool, let me move it on to step three.

Step three is your legal team that goes, oh my god, you can't say that. You can't say that. And we'll probably get sued if you say that. So we can go back to step two again. Human comes in the loop. Okay, let me fix this and then push it back to legal until it's completely milquetoast and it says nothing offensive about anybody and we can push it out to the live website. That's realistically one of the use cases of workflows.

But it doesn't have to be just three steps. It could be 20 steps. It could be two steps. It could be an entire AI workflow that goes for 10 steps and then there's only a human at the 10th step. The limit is your imagination. I could see this being super useful, especially with teams that are going for internationalized content. Workflows is going to be huge.

There's also videos on here. These videos weren't here originally, but they're definitely worth a watch.

Content variants is one I'm not sure how much I'm allowed to say about. It looks like some variation of content that you're writing. From what I can see, read this bit here. I'll say no more.

Durable functions is this one I'm arguably the most excited for because I'm a big fan of AB testing and personalization and a lot of other stuff. Durable functions is great because you're actually getting these things inside of Sanity. Everything is very native to Sanity.

I can see that the way that this is going is that for example, you have development environments. You probably want to have Next.js and Vercel and that whole thing feels seamless. You can also use Eve and that's like the AI side of things from a development perspective. And then there's a content platform which is Sanity where you have Sanity's durable functions, Sanity's AI actions, Sanity's workflows, and Sanity's knowledge bases, all of these things coming together.

I think there's never been a better time to build like your website, your company support pages, your company AI bot, the processes, the way that if you have a whole returns process, you can basically give that knowledge base and you can give every answer and every question possible that comes from your entire surface of your website, support pages, PDFs, everything. It's a really good time to basically silo the two of those things only when they need to be siloed and basically build two totally separate systems. One that's more focused around the development side, one that's more focused around the content side and marry the two of them up in perfect harmony for headless stuff. It is a very cool time.

Sanity blueprints is neat as well. This one's coming soon, not even a beta. A Sanity blueprint is basically a speed running a function. One of the ones that we've used before was a Sanity blueprint to do redirects. So for example, if you change a page URL, the Sanity function immediately fires off and puts a redirect from page A, which it used to be, to page B. So you don't lose any of the SEO from people that would go to the old page that might be indexed in a whole host of different places. It just redirects to the next one without you even having to think. The beauty of blueprints is it just comes in, it knows how your setup is and it builds it.

This is especially interesting to us because we've had this long-term question about Turboar of should we make this kind of a piecemeal offering or should we have very distinctive repos that people can take from and build.

Project Horizon looks wild is all I'm going to say. There's a lot of very cool things on the horizon that are coming from Sanity. It looks like it's very agentic. Agents use tools, delegate tasks, and move projects through to completion with your team in the loop the whole way. This bit is very cool, and I would be very curious as to how this looks in the future.

Resonance I remember was really cool. Basically resonance is a way of testing content. We saw this when we were looking at it on here with the MGH life sciences folks. It's a great way of being able to get that same sort of committee. If you're going to push something out there and you have a whole bunch of personas that are specific for your market. For us, we might have tech-conscious CTOs that are looking into content work or somebody from marketing that wants to make their entire marketing pipeline faster. Write a whole persona about it and then basically test the blog based on that persona. Does it score well? What do they think it's missing? Where are the content gaps?

Resonance is really good. I could see it being a pharmaceutical company's best friend because you have to do so much work to make sure that you aren't essentially alienating specific folks. You also have to talk in such a language that basically you have to have a computer decode it to be able to figure out what the hell's being talked about. Resonance is a really good one if you're in one of those specific niches that has to make sure that their content lands no matter what.

There's so much to unpack from the event. If anybody has any questions or if anybody was at the event and didn't get a chance to meet up, I'm more than happy to jump on a call or chat. Everything was an absolute blast. Thanks for inviting us.

## Frequently asked questions

### What is Sanity's knowledge base feature?

Knowledge base creates a giant pool of information from your content and helps you find gaps and inconsistencies across your website, database, documentation, and PDFs. You can use it to spot when pricing differs between your site and database, or when return policies contradict each other across different pages, helping you maintain accurate information everywhere.

### How can knowledge bases help with content inconsistencies?

It surfaces conflicts like when your website says pricing is ten pounds but your database says fifteen, or when documentation claims thirty-day returns but your product page says fifteen days. You can then identify which information is correct and update your systems accordingly to keep everything aligned.

### What are Sanity workflows and how do they work?

Workflows let you set up multiple steps for content approval and refinement. For example, you might have an AI generate a draft, a human editor cut it down and add personality, then a legal team review it before publishing. You can have two steps, ten steps, or twenty steps depending on your needs and team structure.

### Can knowledge bases work with non-Sanity systems?

Yes, knowledge bases work with existing Sanity setups but also with websites and systems that aren't on Sanity as long as they can be scraped, and they work with PDFs too. This flexibility makes it useful for companies with diverse technical stacks who want to consolidate their information and find gaps.

### What are Sanity blueprints?

Blueprints are coming soon and automate common tasks by understanding your setup and building solutions without manual work. For example, a redirect blueprint watches for URL changes and automatically creates redirects from old pages to new ones so you don't lose search rankings from indexed old links.

### How can knowledge bases help LLMs and AI agents?

You can set up a knowledge base as an MCP endpoint that LLMs and AI agents can query to find information. This lets you see what information they're searching for and identify content gaps. If multiple LLMs repeatedly search for something you haven't documented, you know that's a priority to build.

### What is Resonance and who should use it?

Resonance tests how well your content performs with specific personas like CTOs or marketers. It scores content against your target audience and shows what's missing or what they need clarified. It's especially valuable for regulated industries like pharmaceuticals where content must land perfectly with specific personas and meet strict compliance standards.

---

## Sanity Log Analyzer - Find What's Eating Your Sanity Usage


> A quick walkthrough of Sanity Log Analyzer, our internal tool that turns your Sanity request logs into a usage report. It shows which queries, images and files are eating your usage, when traffic s…

**Published:** 2026-09-18 | **Updated:** 2026-09-19 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=dMpRk1LwyFo

---

## Transcript

We built an internal tool called Sanity Log Analyzer. It gives you a log report of your Sanity usage and suggestions on where you can optimize your Sanity Studio. You'd be surprised what you find out.

We built this tool primarily for developers and larger teams, but that's not to discourage small teams. Go ahead and try it and let us know if you liked it.

So this is where you go to get your logs. You go in the user section and all the way down, then download it and wait for it to finish downloading.

One thing Mac does annoyingly is that sometimes it adds spaces. So after you've unzipped this, make sure you rename it. I'm just going to call it log.

Now we'll run this and get the log analyzer started. I'm very lazy at typing things, so I have my own shortcut. This is what you do. We get the name log.nd JSON.

Here we have our Sanity Log Analyzer. As you can see, it gives you an overall report of where you're spending your Sanity tokens the most. In our example, our settings are costing us a lot. We need to optimize this. As you go down you can see what images are costing a lot, or should I say Sanity tokens. This file needs to be optimized. It's a big chunky one.

When traffic lands, there's high traffic on this day. This is interesting. Localhost doesn't surprise me. Our developers are always on it. Interesting, it's showing the IPs as well.

You get an idea from this. Another interesting thing you can do is filter some of these. As you can see, these are filterable, and once you click on it you will get the data related to that particular category. Remember, not everything is filterable. You can't query everything. These two, for example, can't be filtered. It's just to show you. These two categories are filterable and you can click on them and look into the details below.

## Frequently asked questions

### What is Sanity Log Analyzer?

Sanity Log Analyzer is an internal tool that generates a detailed report of your Sanity usage and provides optimization suggestions for your Sanity Studio. It shows you exactly where you're spending your Sanity tokens and highlights areas where you can improve performance and efficiency.

### Who should use Sanity Log Analyzer?

We built this tool primarily for developers and larger teams, but it's open to anyone. Small teams are welcome to try it out and see if it helps optimize their Sanity setup.

### How do I get started with Sanity Log Analyzer?

Go to the user section in Sanity, scroll all the way down, and download your logs. After unzipping the file, rename it to something simple like 'log' to avoid issues with spaces that macOS sometimes adds. Then run the analyzer with your log file.

### What information does the analyzer show me?

The analyzer gives you an overall report of where you're spending the most Sanity tokens, breaks down costs by category like settings and images, shows you traffic patterns and which days had high traffic, displays IP addresses, and helps you identify which files need optimization because they're using too many tokens.

### Can I filter the data in the report?

Yes, some categories in the report are filterable. You can click on those categories to drill down and see detailed data related to that specific area. Keep in mind that not everything is filterable, as some data types can't be queried that way.

### What should I look for in the log analyzer results?

Start by looking at your overall token spending and identify which areas are costing you the most. Common culprits include settings and large images. Pay attention to traffic patterns and any spikes in usage, then focus on optimizing the biggest token consumers first.

### Why would I want to analyze my Sanity logs?

You'd be surprised what you find out about your Sanity usage. Analyzing your logs helps you identify hidden inefficiencies, reduce token costs, and improve your Studio's performance by understanding exactly where your resources are going.

---

## Turbo Start: Sanity, Shopify, BigCommerce, Contentful & AI starters


> A tour of every Turbo Start template from Roboto Studio: Sanity, Shopify, BigCommerce, Contentful, plus the AI-driven Pointer and Hot Rod builds. Next.js and Astro starters with page builders, head…

**Published:** 2026-09-01 | **Updated:** 2026-09-04 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=6SvJfFkkQDc

---

## Transcript

Turbo Start is our opinion of what a Sanity website should be. A Sanity, a Next.js, probably Vercel website with Tailwind CSS thrown in there for good measure. We're going to progressively get more opinionated as we go through this, but for the very start, this is what I would say makes a perfect website if you are going to do page building and you're going to put a blog post on there. It's a great foundation that we use when we build any client's website. So if you like this, you'll like our work.

This is completely open source. It's on a great license. I think it's the most free license. That doesn't mean go make a brand new rival agency and just basically sell this as your own. Don't do that. But essentially, it is something that you can use wherever you want. You can use it for a business website, whatever.

If you look on the homepage, you can see all the different page builder blocks. These are just the different bits of the page all the way down here. It's basically built with a lovely green color. I actually really like this. But it's basically powered by Sanity and it's hosted on Vercel. It's fantastic. It has a light mode, has a dark mode. It even flips the video at the top, which is really cool.

The next one we have is Turbo Start Shopify. This is an example of what you can do with Shopify now. This is where it slightly diverges from the original because it's still going to be using Sanity. Turbo Start Shopify basically is Shopify and Sanity in a headless configuration with the sync engine that keeps all your products in sync inside of Sanity and Shopify.

Why is that so important? Why would everybody add this extreme complexity on top of just a regular Shopify store? Well, Shopify is great if you are going to build a very standard experience, but a lot of the times a commerce website is not a standard experience and the standard experience is not a very good experience. So we built this particular tool.

The beautiful thing about it is that by the time you download this, it should all work without JavaScript pretty much all the way up to the checkout. The reason why is because JavaScript, you want to be able to go through the different stores and the different web pages without JavaScript because that's exactly what Google search crawlers or AI crawlers do. They can't run JavaScript, and it's very important that you can basically just run the whole store, see all the different products and get the information from those. You'll be surprised how few templates actually work without the JavaScript. So it's very important that we did this here.

Turbo Start Shopify is B2C. There's also Turbo Start Big Commerce, which is basically the Big Commerce variant of this, with the exact same sync engine. These are all AI generated models, and if it is something that you are interested in doing where you are creating product shots, we're more than happy to help with that. If it seems like something that would be valuable as part of this starter, give us a shout on GitHub and we'll get that implemented.

We also have Turbo Start Contentful. It's basically exactly the same as Sanity. It's opinionated in exactly the same way, but it is configured differently to work with Contentful to follow their way of handling schema.

The big core difference between the two tools is one of them is GUI based schema. What GUI based schema means is that when you start building these pages, you say, I'm going to drag a string field which is going to be a title. I'm going to drag a rich text field which is going to be the main chunky bit of the blog and then I'm going to make a reference to an author and you drag all of those bits and pieces in. That's for Contentful, a GUI based CMS.

Comparatively, Sanity is a code-based schema. So you would literally write in code: oh, let me get a string that will be the title. Let me get a portable text that will be the main content that's inside of the blog. Sanity in my opinion and I think in a lot of people's opinion has a slightly higher skill floor. However, I personally think the trade-off is most definitely worth it, especially with AI. But I think Contentful is a great solution if you are looking for something where you want to be able to drag and drop the schema, you're happy with the different tiers that are in there and you basically want to be able to create websites with a whole range of different developers because it's a relatively easy thing to pick up and just start working with.

Now I'm going to get into the controversial zone here because these are not CMS driven websites. These are AI-driven websites. We're going to start with Pointer, which is a faithful replication of the Cursor website. Basically, it's built with the exact same blocks that are on the page. Behind the scenes, this uses something called MDX. MDX is basically markdown, but you can throw components inside of it. And it means that you can actually just create page builder pages like this.

The whole idea of this was an experiment that happened at the time. There was a big thing where essentially Cursor had a whole discussion about removing a CMS or adding a CMS. They tore out a CMS and then they wrote a whole blog about the CMS and then Sanity wrote a whole blog about why you shouldn't build a CMS from first principles and there was this whole spat. But basically that's what happened. And so we were like, "Oh, okay. That kind of sounds interesting. Let's see what it's like." And so we ended up building Pointer.

If you are even thinking about this particular route, make sure you think triple, double, quadruple check that nobody's ever going to use the CMS on your team again. The problem here is that if you are doing this, you have to really really commit to it and you're going to end up using like a terminal or CodeEx or Claude Code or even in some cases some people use things like Replit. V Zero is very good with this by the way. But you have to really commit to the AI side of things. The images are hosted inside of Vercel blob. We expect you to host it on Vercel because it's nice and easy.

You've seen Cursor and the Pointer thing. This is Hot Rod, which is on Astro. This is where we started thinking about this a little bit more because I think it is a nice interesting way of building websites. We kept getting requests for people that wanted to build things essentially without a CMS by basically using one of these tools that exists out there. So this particular version was done with Astro rather than Next.js. But again, still hosted on Vercel. We're using Vercel blob. We're using Mux, which is the best video hosting tool to basically host your videos.

The real beauty of this is because we're using Zod typed blocks, it kind of works like a CMS and it validates the blocks as they get put into the page. So it's very very difficult to actually screw up building these pages out.

If you're interested in Astro, this is what I would potentially use. If you're interested in Next.js, this is what I would particularly use. In both of these cases, you have to be 101% into building everything with AI and never using a CMS unless you want to retrofit and fix all of this back up.

If you have questions, drop them in the comments below. Make sure you like the video. Make sure you subscribe, turn the bell on. Have a great day everybody. Thanks for watching.

## Frequently asked questions

### What is Turbo Start and what stack does it use?

Turbo Start is our opinion on what a modern website should look like, built with Sanity as the CMS, Next.js for the framework, Vercel for hosting, and Tailwind CSS for styling. It's a great foundation we use when building any client website and it's completely open source.

### Why would you add Sanity on top of a regular Shopify store?

Shopify is great for standard experiences, but commerce websites often need customization that the standard Shopify setup doesn't provide. By using Sanity with Shopify in a headless configuration and sync engine, you can keep your products in sync across both platforms while building the unique experience your store needs.

### Does Turbo Start Shopify require JavaScript to work?

By the time you download it, Turbo Start Shopify should work without JavaScript all the way up to checkout. This is important because search crawlers and AI tools can't run JavaScript, so you need the whole store to be functional for them to see your products and information.

### What's the difference between Sanity and Contentful in these templates?

Contentful uses a GUI based schema where you drag and drop fields to build your structure, while Sanity uses a code based schema where you write the structure in code. Sanity has a slightly higher skill floor, but the trade off is worth it in my opinion, especially when working with AI. Contentful is great if you want something easy to pick up across different developers.

### What is MDX and how does it work in Pointer?

MDX is markdown but with the ability to throw components inside of it, which lets you create page builder pages without a traditional CMS. Pointer uses MDX to create a website similar to Cursor's, storing content as code rather than in a database.

### Should I use an AI driven website or a CMS driven website?

If you go the AI driven route with something like Pointer or Hot Rod, you need to commit fully to it and make sure nobody on your team will ever need to use a CMS again. You'll be using a terminal, CodeEx, Claude, or tools like V Zero to build everything. If there's any chance you'll want CMS access later, stick with a CMS driven approach.

### What are the differences between the AI driven templates Pointer and Hot Rod?

Pointer is built with Next.js and replicates the Cursor website using MDX, while Hot Rod is built with Astro. Both are hosted on Vercel and use Vercel blob for images. Hot Rod also uses Zod typed blocks which validate the blocks as they get put into the page, making it harder to break things when building pages out.

---

## How to Get Better Documentation in Your Sanity studio


> A quick look at page-level documentation in Sanity Studio using Turbo Start Sanity and sanity-plugin-md-notes. You can easily point your AI agent at a document, and it fetches the data to render co…

**Published:** 2026-08-19 | **Updated:** 2026-09-03 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=cpsZAuMZEIk

---

## Transcript

So you go to Sanity Studio. I'm in the structure mode. You can do this in presentation as well. For this example I'll be using home page. You click here. The whole thing is written in markdown, so you can just point your agent to your Sanity Studio for home page and it will fetch all the data from home page and simply display it here.

You can see all the page builder blocks you've used or any other document that your team thinks is worth putting there. You can also add Loom or anything to help your team. Super simple stuff. You can just collapse it by pressing the same icon. You can also do this in presentation mode. Go to home. Press the same icon. Then of course you can change the width. If it's distracting to you, just press it back and then it goes back to normal.

It's super easy to install. You can read the readme section, copy paste from here, and just point your AI agent and it will do the rest of the stuff for you.

## Frequently asked questions

### What is Sanity Studio and how do I access it?

Sanity Studio is where you manage your content. You can access it in structure mode or presentation mode, and you'll see all your page builder blocks and documents right there. It's built to let your AI agent fetch data directly from your Sanity Studio and display it wherever you need.

### How do I view my home page content in Sanity Studio?

Go to Sanity Studio, click on your home page in structure mode, and you'll see everything written in markdown. All your page builder blocks and team documents show up right there, making it easy to see what content you're working with.

### Can I collapse the content view in Sanity Studio?

Yes, you can collapse the view by pressing the same icon you used to open it. This works in both structure mode and presentation mode, so you can keep your workspace clean if something feels distracting.

### How do I adjust the width of the content panel?

In presentation mode, you can change the width of the panel to fit your preference. If you want to go back to normal, just press the icon again and it returns to the default width.

### How do I set up an AI agent to fetch data from Sanity Studio?

It's straightforward. Head to the readme section in Sanity Studio, copy the instructions, and point your AI agent to your Sanity Studio. The agent will handle fetching all the data and displaying it without any extra work from you.

### What kind of content can I add to Sanity Studio documents?

You can add anything your team thinks is useful, including page builder blocks, Loom videos, markdown content, and any other documents. It's flexible enough to support whatever format helps your team collaborate effectively.

### Does this work in presentation mode as well?

Absolutely. You can do everything we've covered in presentation mode too, including collapsing the view, adjusting width, and accessing your home page content. It's the same functionality with a different view.

---

## A Very Practical Introduction to AEO, GEO & AI SEO


> A practical walkthrough of technical AEO/GEO/AISEO checks you can run on any website. Covers disabling JavaScript to see what crawlers see, pagination without JS, markdown content negotiation for A…

**Published:** 2026-08-18 | **Updated:** 2026-09-11 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=L75YVJ8pQJg

---

## Transcript

AEO, GEO, AISEO, they're all basically the same thing despite what people argue about the nomenclature. What matters is that they work. We've been monitoring them internally and you can apply them on your own website, or you can talk to a Next.js Sanity agency if you want help building this yourself.

Let's start with the website itself. This is something you can do without being a developer and still get the same result. If you right-click on any website and hit inspect, there are two things I'd advise doing.

First, it might not look like this straight away. It probably looks cluttered. On a Mac, press command, shift, and P. On Windows it's control, shift, and P. Type disable JavaScript. You may notice immediately nothing's really changed. But if you hit command and R to refresh the page, you'll notice immediately that certain elements have gone. The reason is they're JavaScript. This is roughly what Google sees, and it's a great way of navigating your own website to see what's going on.

There are some caveats. If you look at the left-hand side you'll see exactly what's going on. For example, if I press here you're going to see things like divs, you're going to see things like P tags, which basically just means paragraph. This is how you can actually see the content on your page and work out exactly what's happening. JavaScript's turned off, so I can see all of this stuff on the page. From an SEO perspective, you're doing something very good. From GEO and AEO perspective, you're also doing something very good, but not quite the best, which we'll talk about next.

This is especially important. I'll show you where everybody screws it up so you can not screw it up yourself. Let's enable the JavaScript again because my navigation won't work, and let's go over to blog. You can make your navigation work without JavaScript. We purposely chose not to do that. There is a way around it and you can do clever stuff, but for the sake of this conversation, keep it simple.

When you have pages like this, I'll show you what everybody screws up. Hit command shift P again and disable JavaScript. Refresh the page. Lines have gone. We see where we're going with this, but the blog posts are still here. More importantly, we have pagination, which means if a crawler hits the website they need to go through the pagination. They need to see more than just the first set of articles. Let's go to page two. Great, I can see page two. Let's go to page three. This is really important. Same principle applies. Categories don't work right now, so that's something I'm going to fix after this video, but you can see the point. The more you can do without JavaScript, the better the website generally indexes. This is a general rule of thumb, so don't hold it as the be-all and end-all, but it is very important. It also means that a lot of this stuff can get cached if you're rendering it statically. There are nuances with rendering techniques, but for the sake of doing one big overall view, this is the first thing we do when assessing a website for SEO and AEO.

One thing I actually stole from a Profound presentation is a website called RunRepeat, which is quite useful. RunRepeat is very interesting because it gets cited a lot. The reason it gets cited so much is that everything you're seeing on the page here is unique, interesting, numerical information that AI can't find literally anywhere else. If you have unique, numerical, interesting information and most importantly AI can't find it anywhere else, you're going to do pretty well on citations. If you look up something like how much pressure can a Nike Vomero take on my feet, or how long will they last, you'll get this information. This is very important.

The other thing I've left off so far is content negotiation. Content negotiation sounds scary, but it's not actually that scary. What this basically does is give a way for AI crawlers to see your website. This isn't a strict rule before I say this, but most AI crawlers do not run JavaScript on the website, which is why I was showing you that for the first part. But the interesting thing here is when AI hits a website, it looks like this. This is what an AI will basically see. This looks like the Matrix. Nobody can read this. It's really hard to see what is here. However, let's try this again but with this nice little bit at the end, which is accept text markdown. You have to actually do this on your website. This isn't just something you can say "go throw this at the end, it's done for you." It actually takes a lot of work, and it's very important that you have parity between the HTML version and the markdown version.

What we're going to do is copy this exact thing over again and paste it back in. This is Vercel's, not our own, but I can also put our own on here and it will show you exactly the same thing. Is it going to look like the Matrix part two? No. It's actually going to look like markdown, which is really important. If you think about it, AI crawlers and how we use AI in general is we try not to blow the context window. If you want to know how that works, it basically means the more information you put into AI, generally the worse it gets. There's a sweet spot around 20% of the actual context window depending on every model. Instead of having all this crap where it bloats that context window when things are crawling, you get this where it tells you exactly what you need to know. More importantly, Vercel did a little teardown of how this actually works. The most interesting thing was that it was 3 KB, so a 99.37% reduction in payload size instead of 500 KB. This is super important.

What I will say is the pitfall most people fall into if they're doing this for their own website is the fact that there isn't parity. If you get a 1 KB payload but it only has half the information of the page, that's far worse than just using the original HTML. What you've got to make sure you do is that the markdown version is in parity with the HTML version. In some cases you need to expand things. For example, an FAQ section, if it's inside a component, then you need to make sure that FAQ actually gets brought into markdown in a way that's nice. There are loads of intricacies depending on what you're doing here. The best way to do this is just give us a shout and we can talk you through it.

Let me show you a couple more things. This is Tetris from Wikipedia. I'm sure you've seen this before. However, something you probably never thought about is why did Wikipedia end up doing so well in the first place, and why does it appear so high on Google? One of the many reasons is if you look at the left-hand side, this is a table of contents. If you look, we have an unordered list and then list items. You can see table of content, list item, list item, list item. It's all semantically correct, which basically just means it's the way HTML should be written. It's the way computers can easily interpret what's actually going on on the screen. There's not a tremendous amount of JavaScript being fired here. Whenever we're building something like a blog, you're going to make sure you have a table of contents similar to Wikipedia. You don't necessarily want to have all the JavaScript, or it should still run and be semantically correct without JavaScript. All of these different little bits and pieces add up.

Last one I want to show you as well, we're going to right-click and hit inspect. You don't need a developer involved to do this. Just click into this thing on the left. Doesn't matter where you click. Try not to click a link. Just try to click anywhere in here and press command F or control F if you're on Windows and type JSON. Now what you're looking for is JSON-LD on the page. Let me have a look. This is what I'm looking for. You see breadcrumb JSON-LD. Pop this open and you can see the information about the breadcrumb inside here. Let me look for another one. Okay, collection page JSON-LD for blog. Great. This is showing me what's actually on the page from a JSON-LD perspective. I understand what's going on here and by proxy, a computer understands it too. This is really important to essentially show that you know what's going on on the page and you're presenting that to Google and all these different AI crawlers. It's really helpful to give some rich structured data.

Final thing worth doing here is there is a JSON validator from Google. I won't show it in this session in particular, but you should always just check at one level that the JSON is valid. I know there's a couple in here where we need to do a couple of bits of tweaking to make sure the JSON is valid, but it's always important to do that.

This gives you a rough idea of everything you can get started with. This is just scratching the surface of what AEO, SEO, and all of these different functionalities are about. What I want to do is have more deep dives and talk more about it in the future if you're particularly interested.

## Frequently asked questions

### What's the difference between AEO, GEO, and SEO?

They're all basically the same thing despite the different names people use. What matters is that they work. These techniques help your website get discovered and ranked by search engines and AI crawlers, and you can apply them yourself or work with an agency if you want help building them out.

### How can I see what Google actually sees on my website?

Right-click on any page and hit inspect. Then press command, shift, and P on Mac or control, shift, and P on Windows, then type disable JavaScript. Refresh the page and you'll see what crawlers see without JavaScript running. This shows you roughly what Google indexes from your site.

### Why does it matter if my website works without JavaScript?

Most crawlers, especially AI crawlers, don't run JavaScript on websites. If your content and navigation only work with JavaScript enabled, crawlers miss important pages and information. The more functionality you can deliver without JavaScript, the better your website indexes overall. Static content also gets cached better, which helps performance and discoverability.

### What is content negotiation and why should I care?

Content negotiation lets AI crawlers see your website in a format they can actually read, like markdown instead of raw HTML. When you add accept text markdown to your content, you give AI a clean, stripped-down version that's around 99% smaller in file size. This prevents wasting the AI's context window with unnecessary code and helps it understand your content better.

### How do I make sure my markdown version is good enough?

You need parity between your HTML version and markdown version. If your markdown only has half the information, it's worse than using the original HTML. Make sure everything on the page, including components like FAQs, gets included in markdown so AI crawlers see the full picture.

### What's RunRepeat doing right that other sites miss?

RunRepeat gets cited a lot because everything on the page is unique, interesting, numerical information that AI can't find anywhere else. If you create original data and insights that AI can't pull from other sources, you'll rank and get cited much better than sites with generic, copycat content.

### Why should I add JSON-LD structured data to my pages?

JSON-LD tells Google and AI crawlers exactly what's on your page in a language they understand. Adding breadcrumbs, collection pages, and other structured data helps you show that you know what you're doing and makes it easier for machines to interpret your content correctly. You can validate your JSON using Google's validator to make sure it's correct.

---

## Contentful Pricing: Free vs Lite vs Enterprise - What You Actually Need


> A walkthrough of Contentful's pricing tiers and the hidden content type limits that quietly push teams onto sales calls. Covers the free vs lite trade-offs, how content types get eaten by SEO and p…

**Published:** 2026-08-17 | **Updated:** 2026-08-19 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=aHtdjUwgMEg

---

## Transcript

Hey folks, how's it going? How are you doing today? So, I'm glad you've jumped in here. I want to talk about Contentful pricing and I'm going to save you a lot of money. I guarantee it. So, let's start with the pricing here. It's nice and simple. It's only got three tiers. That's what you might think coming in here. That's not the case. And there's a lot more that's lurking below the surface like a shark.

Let's start with free. So free is good. Everybody loves a free tier. Especially developers. We love being cheap, right? Um, free gets 10 users, two roles, two locales, 100K API calls a month, and 50 GB a month CDN bandwidth. Um, I'm going to say something controversial here. You can run most websites with these stats. Almost every website that we have and that we've built that's been well optimized sits below these stats. It's only the type of website that has, you know, like 50,000 users coming through a month, um, and starts moving into, you know, like higher tier, lower enterprise that really start not hitting these stats. However, there's only a couple of options here when you want something like internationalization because you'll notice the two locale on the three locale on light. So, if you are going for an internationalized website, you want to take a moment, pause, think about this, and see what you're going to do with it. It may be worth having an initial call with the sales team over at Contentful.

But I want to go back for a second and show you one more thing. So, remember how I said the pricing is relatively simple? Well, this is the bit where it stops becoming simple. There is one starter space included. So, if you press this, you get a whole new pricing table. So, we're talking tables inside of tables at this point. However, I'm going to tell you the most important thing. So, ignore everything I've said so far. What you want to care about is content types. Now, you can see on the top line, it says 25 content types for the starter space and 50 content types for the light space. Okay, now, we're going to go flip back to the original pricing and we're going to see what you get. You get okay, you get one starter space, you get one light space, you get one starter space, you can have multiple custom spaces. For the sake of this, I'm going to call a space a database, okay, just for the sake of it. I know it's not exactly a fair comparison to make, but let's stick with that nomenclature because it's important.

Now, if you look at this, you see the content type. So 25, right? Now, when we think about content content types. The easiest way to think of it is each unique repeatable document. Okay, repeat that after me. Each unique repeatable document. Um, so if you're thinking about a blog, that is a content type. So, one content type. Cool. Okay. Now, you might be wondering what happens with nested things where you can repeat them again and again. Well, that's two content types.

Now, let me tell you an anti-pattern that we've seen firsthand and people screw this up all the time. You've got SEO inside of a page. You've got meta titles, you've got meta descriptions, you've got the open graph title, open graph descriptions. You might be tempted to go, "Hold up. We're going to use that across multiple pages. Why don't we make that a repeatable content type?" Okay, nice and simple. Don't do it. This is wrong. Very, very wrong. Okay, what you want to make sure that you're doing is you are building these long form, big chunky schemas for each of these content types. If you do what I've just said with SEO, Contentful uses these as repeatable pieces of data. Okay? Everything is repeatable. Everything is referenceable. So, what that means is if you put that SEO there, you're never going to repeat meta titles again and again and again, or it's very unlikely that you do that, because it's bad SEO practice. You don't want to have 10 of the same SEO titles across all of the website. You realistically have to have a one and done. However, now you've taken up two content types. And so, as you can see, this gets very tight very quickly.

So, let me give you another example, which is page builder blocks. Now, with every single new kind of website that you want to build, you want to have pages where you can, you know, shuffle the blocks that exist inside of the page. Now, can you see where we're going with this? That's page, which is a content type. So, now we're up to two content types, and we want to have 10 page builder blocks. Cool. 10 page builder blocks. Well, hold up for a second. That means we're up to 12 content types. So, we've basically exhausted half of the available content types on the starter space or let me do the maths, a quarter on the light space. Okay? So, as soon as you go past that light space, that's come talk to sales. Come talk to us. You know what that means? Cash money, baby.

So what you want to do is make sure that you are being very, very specific and you know, positioning the content types correctly when you build these kind of websites. So, building a blog again, there is another usage of a content type. What about authors? Okay, there you go. There's another content type. We're up to 13 content types. What about categories? 14 content types. I hope this makes a lot of sense. Uh, the records, you probably won't hit unless you're like, I don't know, news of the world or something. You're going to have 10,000 records is a lot of records. Uh, we very, very rarely see this unless you're doing something where it syncs data from another system and you're syncing it into Contentful. Then you might hit this record. Um, but effectively the 50,000 records you won't hit. Uh, workflows, nice thing. Uh, additional API usage, calls usage, this is great. Realistically, you won't hit anything else inside of here apart from these two and apart from the internationalization. Um, now that's essentially the two things that I would care about.

There is also add-ons. So, I think if we go further down here, you move straight into the enterprise plan, which I'm happy to kind of talk about. I don't want to spend too much time on it today because realistically, you're not watching this video for enterprise plans. If you are, get in touch with me. You know, it's good. It's good. We want a little bit of cash money. So, uh, but yeah, essentially there is personalization, there is AI actions, and there is studio. I personally do not like studio. This is a personal preference. I am a big fan of things where you can do them programmatically or with AI. And I especially think this is going to be important coming into the next few years. But the personalization is very valuable because every single headless content management system is very difficult to build personalization for, and especially when it's not integrated. However, Contentful, I think, acquired, I forgot what company it was, but they acquired somebody at some point for the personalization. I've seen this firsthand. It is very nicely integrated. It's very, very good.

So, if you are a big company going to Contentful and you are looking at the Enterprise Edition, the personalization and the AI actions are both very, very good features. I would honestly personally say skip the studio, um, because I'm not such a big fan of you know, like drag and drop, because you know, you're pretty much at the stage of Framer or Webflow at that point, and we both know their ass. Um, so yeah, essentially this is the pricing. If you have questions, drop them down in the comments below. I hope this has helped somebody. Give us a shout. Have a great day everybody. Bye-bye.

## Frequently asked questions

### What does Contentful's free tier include?

The free tier gives you 10 users, two roles, two locales, 100K API calls per month, and 50 GB of CDN bandwidth monthly. Most well-optimized websites actually run within these limits, so it's a solid option for many projects unless you need internationalization across multiple locales.

### How should I think about content types in Contentful?

Think of each content type as a unique repeatable document. A blog is one content type, an author is another, and categories are yet another. You'll quickly consume your available content types, so it's important to build long-form, chunky schemas rather than breaking things into small reusable pieces like SEO components.

### Why shouldn't I make SEO fields a separate repeatable content type?

Making SEO a repeatable content type is an anti-pattern because you won't actually repeat the same SEO meta titles across your site, that's bad SEO practice. By creating a separate content type for SEO, you're wasting precious content type slots that could be used elsewhere on your project.

### How many content types do page builder blocks consume?

Building a site with a page content type plus 10 page builder blocks uses up 12 content types total. That's half your starter space allocation right there, so you need to be strategic about your schema design from the beginning.

### When should I consider moving beyond the free or light tier?

Once you start adding more content types like blog posts, authors, categories, and page builder blocks, you'll quickly exceed the 25 or 50 content type limits on free and light tiers. At that point, it's worth having an initial call with the Contentful sales team to explore paid options.

### What add-ons does Contentful offer for enterprise users?

Contentful offers personalization, AI actions, and studio as add-ons for enterprise plans. The personalization is particularly valuable because it's nicely integrated and solves a problem that's difficult in most headless CMS platforms. The AI actions are also strong, though studio is more of a drag-and-drop interface if that's your preference.

### Will I hit the record limits on Contentful?

You probably won't hit the 50,000 records limit unless you're syncing data from another system into Contentful or running something like a major news operation. Most websites operate well below this threshold, so it's not typically a constraint you need to worry about.

---

## Real-world AI agents with Vercel's eve (our actual setup)


> A real-world walkthrough of using Vercel's eve to run agents on our own site - updating CMS comparison pages, posting reports to Slack, and orchestrating multiple agents on cron jobs.

**Published:** 2026-07-20 | **Updated:** 2026-08-11 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=e2bWdLqlswk

---

## Transcript

Hey folks, how's it going? Hope you're having a great day. So I want to talk about Eve. And if you don't know what Eve is, it's basically a way of building AI agents. Whether it's kind of like on your website, whether it's doing changes, or it might just be a chatbot within Slack or something. Um, I want to give you kind of like the top level overview. I don't often see people show real world examples of these things. They're very nice in a demo environment, but those demo environments are great until you actually use them in the real world. So this is a real world example. This is where we're using Eve on our own website. And something that you might want to think about if you're doing like comparison pages on your own website. This is a great way of doing it. So we have all these different URLs. Um, I'm hoping we don't get in trouble with Google at some point because these do have like a programmatic nature to them, but we try to keep them up to date and fresh with very organic information.

Um, so if we're looking at these pages, we have this last verified date, which is the 17th of July, which luckily is today. Um, so this for example is going to take information called challenges with WordPress and tell you all the challenges that WordPress has and then tell you how good Sanity is because of the URL structure. It's got the problem platform that we're moving away from and the solution platform that we're moving to. Now we generally do a hell of a lot of this kind of work. We do a lot of headless CMS migrations. Um, but we have to try and keep these up to date. Now we use YAML behind the scenes to be able to keep all that information in one particular file. And the beauty of having a file-based system is that you can keep these updated and you can create pull requests to change things inside of these. And so this is a perfect example of something that you want to do with Eve because it's versionable, it's simple, and it's kind of very deterministic. And the reason why I use the word deterministic is because if something is deterministic, it's way easier to do it with AI and it costs way less money on tokens. And we'll come back to that at some point because token spend is going to be a hot topic. It probably already is, but in the next six months it's going to go through the roof. Um, but you can see here this is getting updated.

Now the second part of Eve, and this is kind of like an announcement that came along with Eve, which I would argue is probably the most important announcement, is this connect, this vercel.com/connect. Uh, this is a way to be able to make these agents just integrate directly with whatever tools you're using. Uh, in my particular case, it's Slack and Linear we use for the vast majority of time, but you could use this with GitHub. You could use it with any of these. You can see here just below, you can click any of these and they'll work, which is really neat. Uh, and all that changes here is just throwing this in and it's all connected inside of Vercel.

Now let me show you in Zed um some of the findings in here. So this is basically like an example finding. So we have uh this updater bot that basically goes out, uses sub-agents to find all this information and create a pull request um to update that information. So in this case, it's like, oh, here's the Framer FAQs. Here's some uh official URLs where we can have a quick look at all the different Framer things. Um, and you can basically set these things up. This is inside of the actual agent skills. So we have these agents. We're a little bit, we're sloppy on the naming convention right now. It's going to get better and we'll release some guides as to how to do this. Um, but essentially right now we have like negative features. So no self-hosting. So Framer sites are locked to Framer hosting. Uh, here's the sources where this is coming from because what you don't want to do uh is put all this information in there that's incorrect without the sources, without it being generated. Uh if you have all these sources in there and you're generating this stuff, I actually personally think it's better than a human researched uh system because it knows exactly what it's looking for. It knows the fors and againsts. Imagine what you can do with this with comparison pages, you know, from one software company to another. Everybody does it. Don't get me wrong, it's not the most ethically like outstanding, really really nice way of doing business, but it is something that pretty much everybody does comparison pages.

Um, but yeah, you can see this is an example finding and then you can create skills based on these. Here's like the guard rails. Um, so skeptical voices, all kinds of different things you might want to put, you know, like this is uh the way that we talk, this is our messaging. There's going to be something if you go dig through this. I bet I've showed something here where I shouldn't have showed it, but you get the idea, right? Um, and so what's interesting about this is once you've got all this together, you can create a loop that basically keeps going and keeps going and you can set it on cron jobs. Uh, we set a whole bunch on cron jobs inside of here. Let me just move this aside and find it. Uh, where are we? There is a cron in here somewhere. Schedules. So you can see CMS freshness, for example, is on the cron job. Um, and I can never read these things, but this is on I think once a week and I think it's on a Thursday from memory. Um, but essentially every time it goes and runs through that cron job, you're basically updating across all the different CMSs that information. So you've actually basically created a self-updating bot. And guess what the bot does after it? It tells you this information. And so once you've built one of these things end to end, it then becomes very simple to create the next one, and the next one, and the next one. And you can either do it in two different ways. You can either make them in isolation. So you can have all these different agents that don't really talk to each other or you can do like we've done here where we have, you know, like competitor intelligence. We have daily SEO, we have a Reddit scout, uh we have like route strategies, uh CMS sweeps, all kind of stuff. Like there's a lot of information that's in here. Um and again, a lot of different skills. So I'll show you just a very quick example inside of our Slack. I'm trying my hardest to not accidentally like dox anything or put anything out there, but if you look inside of Slack here, this is a great example of it. So um, inside of here, we actually have a website report bot. And this website report bot takes information from um, Vercel observability and a whole bunch of other different touch points and basically tells us what's going off. And because we've got all this information ahead of us, we can actually make educated uh decisions as to how we progress the website. So this is a really cool feedback loop and it's been pretty much vital for our growth as a business. Um, where you can continuously spin these things up, continuously rely on these. And the best bit of it all is I put like a hundred dollars on our AI uh whatever it is, the AI gateway. Um, and I haven't spent it yet. And we've got like five different um agents that are constantly running. And we've been doing this since pretty much day one of Eve dropping. Um, not Eve dropping, but like Eve the tool dropping. Um, and so it's yeah, it's pretty pretty wild. It's pretty cool.

Um, and I would definitely recommend that this is going to be the way that people use agents more with being able to take all these different disparate systems, pile them into a single Slack channel and not making it overwhelming. Um there is a different way of doing this completely separately as well which is kind of interesting which is you can use things like Claude Schedule but the problem with this is that Claude Schedule and I can talk about this in another uh video if anybody's interested but Claude Schedule is a non-deterministic way of doing this and it's pretty difficult to get it to be deterministic. So it means that you get kind of like instead of rigid things where it tells you and being able to kind of piecemeal get better and better. It's kind of like a scattershot where it might answer this way one week and it might answer this way another week. And the problem is it's very difficult then to you know take that information week by week and compare it to one another if it doesn't match the same data structure.

So I'm pretty heavily, I'm I hate this expression, but I'm pretty bullish on Eve being like a long-term uh tool that we use internally to take all these different systems, mesh them together, and just tell me what the hell's going off on the website rather than being completely clued out and not understanding how, you know, like Google Analytics works, Google Search Console works, uh Post Hog, Ahrefs or whatever, different disparate systems. You get the idea. Anyway, if you want more info about this, drop us a comment down below and we'll uh we'll get back to you. Thanks for watching. Have a great day. Take care. Bye-bye.

## Frequently asked questions

### What is Eve and what can it be used for?

Eve is a platform for building AI agents that can operate across different systems. You can use it to create chatbots in Slack, automate website changes, build comparison pages, or integrate with tools like Linear and GitHub. The key advantage is that Eve lets you connect these agents directly to whatever tools you're already using through Vercel Connect.

### How does Eve help with keeping comparison pages up to date?

We use Eve with a YAML file-based system that stores all our comparison page information in one place. This makes it versionable and allows us to create pull requests to update content. Eve can automatically run these updates on a schedule using cron jobs, so our comparison pages stay fresh without manual intervention.

### Why is using deterministic systems better for AI agents?

Deterministic systems are much easier and cheaper for AI to work with because they follow predictable patterns and rules. When you set up your agent skills with clear guardrails and structured data like we do, the AI can reliably execute the same tasks repeatedly, which significantly reduces your token costs.

### How much does it cost to run multiple agents with Eve?

We've set up five different agents that are constantly running across our systems, and we put a hundred dollars on our AI Gateway at the start. We haven't spent it yet, so the cost is remarkably low for what you get in terms of continuous automation and intelligence gathering.

### How can Eve integrate with Slack?

Eve connects directly to Slack through Vercel Connect, allowing you to set up agents that send information and reports into your Slack channels. For example, we have a website report bot that pulls data from Vercel observability and other sources, then delivers insights right to Slack so your team can make decisions based on real-time information.

### What makes Eve better than non-deterministic approaches like Claude Schedule?

Non-deterministic systems like Claude Schedule can give different answers each week depending on how the AI interprets things, which makes it hard to track changes over time or compare data. Eve's deterministic approach means your agents return consistent data structures, so you can reliably compare week-to-week results and actually see what's improving or degrading on your website.

### Can I run multiple agents together or do they need to be separate?

You can do both. You can create isolated agents that work independently, or you can build connected systems where multiple agents feed into each other. We've built something more integrated with agents like competitor intelligence, SEO tracking, Reddit scouting, and CMS updates all working together and reporting into a single Slack channel.

---

## Agentic eCommerce with Shopify and Sanity


> A quick look at our Turbo Start Aisle agentic eCommerce starter. It uses Sanity Agent Context to generate shopping UI on the fly, narrow down by brand, size, and color, and…

**Published:** 2026-06-01 | **Updated:** 2026-08-11 | **Categories:** Shorts

Watch: https://www.youtube.com/watch?v=Axvtvf1t-fY

---

## Transcript

Hey, how's it going? Today I'm going to talk about Agentic e-commerce, what it means, and how it's going to completely shape the way users interact with your e-commerce website. In this demo, I will show you how the agents will work to generate UI on the fly and it would be completely the opposite of the traditional way of using filters and categories in your e-commerce website. So let's have a look.

Okay, so I'm going to try to find a tea for myself. And I'm at Turbo at Isle, which is Robboto's e-commerce website built with Shopify and Sanity. So let's go to the chat. And I'm going to first of all find out what brands they have. Oh, great. So they have Robboto. Perfect. That's the top end of my budget. 50 quid tea is still quite expensive. Oh, thank God they have three options. Great. Do you have any in small? Oh, amazing. Do you have in small and pink? Pink, not whatever I typed. Oh, great. So let's have a look. Okay, so they have Tazmin in pink and in my size. So this is a great example of just showing how you would interact with agents in an e-commerce website.

You can also probably find out what the policy is like, return policy. So, um, explain written policy to me like I am a two-year-old. Okay, so that's pretty straightforward. So this is one example of how you would interact with agents in your e-commerce website. Obviously you can do it in many different ways and Turbo at Isle is a very, you know, small website with some products and categories. But if it's a large e-commerce, the world is your oyster. Go crazy with it. Hope you enjoyed today's video. Thank you so much for watching.

## Frequently asked questions

### What is agentic e-commerce?

Agentic e-commerce is a new way for users to interact with your e-commerce website using AI agents instead of traditional filters and categories. Rather than browsing through menus, customers can chat with an agent to find exactly what they want, asking natural questions about products, sizes, colors, and policies in real time.

### How do agents generate UI in e-commerce?

Agents generate UI on the fly by responding to customer queries with dynamically created product interfaces. Instead of showing pre-built category pages, the agent understands what you're looking for and displays only the relevant products and options that match your specific request.

### Can I ask agents about product specifics like size and color?

Absolutely, that's the whole point. You can ask an agent if they have a product in a specific size, color, or brand, and they'll check their inventory and show you exactly what's available. It's a conversational way to narrow down options rather than clicking through multiple filters.

### What else can agentic e-commerce agents help with besides finding products?

Agents can help with much more than just product search. You can ask them about policies like returns, shipping, and warranties in a conversational way. They can explain company policies in simple terms or answer any other questions about how the business works.

### How does this compare to traditional e-commerce filtering?

Traditional e-commerce relies on you navigating categories and using filters to find what you want. Agentic e-commerce flips this on its head by letting you just tell the agent what you need, and it handles the searching and filtering for you through conversation.

### Is agentic e-commerce only for small websites?

We showed it working on a small website, but the potential is huge for larger e-commerce sites. With more products and categories, agentic interactions become even more powerful because customers don't have to hunt through endless menus to find what they're looking for.

### How do I try agentic e-commerce?

We built an example on Turbo at Isle, an e-commerce website powered by Shopify and Sanity where you can chat with an agent to find products. You just go to the chat, describe what you want, and the agent helps you narrow down options through conversation.

---

## Should I build my website in markdown?


> Should you build your website in Markdown/MDX or stick with a headless CMS like Sanity? We've shipped both - here's an honest look at the trade-offs, the hidden costs, and which approach actually f…

**Published:** 2026-05-22 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=zNzjTGC6xlA

---

## Transcript

Hey folks, how's it going? So this is a bit of an interesting one today. Markdown. Should you build your website in markdown? It's kind of interesting because I've heard murmurings in the whole kind of tech industry about people starting to go this way. And we've actually had personal close experiences with it ourselves, which I thought was very interesting because, believe it or not, we've actually had experience on both sides of the fence.

So you might be thinking, you know, Sanity, Next.js, that's what you do all day, day in day out. And you're probably just going to say that Sanity is the best way to do all of this. And truthfully, not really, and kind of really, just to give you kind of an early spoiler for the video. But people might not know that we've actually done something to basically build a knockoff Cursor just to see how markdown works, or more specifically MDX works, for building websites. Because, you know, it's a time where everybody's going for agentic websites and agentic this that and the other, and I thought it would be kind of interesting to talk about the realities of these things, as well as kind of reference something that went off between Cursor and Sanity. And I think they both have relevance and I think they both have content that you should take into account before you even start building something, thinking of the long-term aspect of a website rather than just thinking, okay, we're going to build a traditional website, it's going to get launched and then we're probably going to put a blog up once every couple of weeks and then that's it.

The entire kind of ecosystem is in a strange position right now and it's kind of wild westy. But we have had experience of everything that's involved in this, so I thought we'd just tell you from a pretty off-the-cuff way.

So first of all, let's start with a traditional headless content management system. Who do you think we're going to talk about today? Now we actually haven't just had experience with Sanity. We've had experience with Contentful. We've had experience with Storyblok. Unfortunately, we've even had experience with Strappy and Prismic, which has been a blast, let me tell you. But all of these different systems all kind of have very similar ways of working, and kind of like very similar software stacks or not software, but like stacks of what they do, which is usually something like a media browser combined with some way of being able to build models for a website, so kind of a traditional page builder if you think of that. And all of these things combined basically create a headless content management system.

Now, it's kind of cool that we're able to just talk about that side of things, but the other side of this is markdown, or more specifically MDX. And if you don't know what MDX is, it's basically markdown with the ability to put components inside of it. And you might be asking, why do we put components inside of markdown? Why do we even care? It's because if you have components inside of it, it means that you're able to build a traditional page builder blog like you see here. So, you know, there's a hero here, there's a logo pond, some people call these things or social proof or whatever, there's a left text, right image, left image, right text, and a whole bunch of buttons and all this kind of functionality that exists inside of there. Each one of those would be built inside of kind of React in a component. I'm saying React, but more than likely we'll talk Next.js in this video. But this can create these whole brand new page builder blocks.

Now, this is where the paradigm shifts. Now, if you're using something like Sanity, you get a very, very easy to use drag and drop builder. If we're using something called Presentation, or you get kind of like the old school way of creating pages using something called Structure. Structure kind of works a bit like an Excel spreadsheet where you just kind of drop things on the page and you write inside of inputs, kind of like a HubSpot form if that makes sense. And that gets translated to a real world website. Kind of cool.

However, and this is where the difference starts. When you are building a website with markdown, chances are the vast majority of your time you're interacting with building pages on the website is inside of kind of like a ChatGPT prompt window, you know, like the little thing where it says, "Go talk to me today" or whatever it is. You've seen it. It's on every single website now. Basically, it's talking to your website in that way to create things. And this fundamentally changes the way it works because if I make changes on here, the changes go to Sanity's content lake. And that content lake is what provides the whole website with the data. And then you're obviously offsetting that to a third party vendor, which has a lot of benefits, also a lot of negatives depending on which way you look at it.

And then in comparison with markdown, you are basically putting everything inside of GitHub. Or, and this is the point that I want to kind of focus on quite heavily, you have a little bit of a problem now, which is that you have media inside of this. And if you ever use GitHub, you'll know it's a bad thing to basically save these images inside of GitHub, which takes you on to the second point, which is then, okay, what happens when you need to move away from a traditional headless content management system and now you need to start saving images?

So I believe it's Vercel Blob, from last time I checked, that the Cursor team is using. I'm not sure whether it's said about on here. They're mostly talking about removing complexity, which is like user management. So they're handling all of this again through the actual GitHub side now. And so that's quite cool and that seems like a logical next step. And I think it is very cool, but you're basically kind of shifting from one third party to another third party because effectively, if you say need to save images, the most simple way of doing it is through something like Vercel Blob. But the problem here now, if you are going to go down this route, is that you need to be able to upload those images. Now, how do you do it?

Now, I can't remember if this is fiction or whether I've actually seen this. This is it. Yeah. So this section here, they talk a little bit about asset management. Now, they've built their own asset manager, which I think is built on top of Vercel Blobs, last time I looked at it, into their website. Now, depending on how you look at this (and this is my bias coming through here), I absolutely hate rolling your own for most things. The reason why is that as soon as you start rolling your own, you have to manage those things, and if they break it becomes a nightmare. Especially if it's something as kind of fundamental to a website as a media browser. That being said, you know, the Cursor team is very talented tech team, so I suspect they may be able to build a media browser that never breaks and is totally fine. However, there's a lot of complications with that and it's very, very easy to break them.

And then there's the other problem here. Obviously, there is one great thing here, which is they're going to talk very quickly about the cost of this because it is a lot cheaper to potentially do it this way. But the big thing here is you have to take into account that Cursor's team is obviously going to be using Cursor a lot. I think they even said themselves pretty much every member of the team uses Cursor, which I actually think will become increasingly normalized: an AI agent working for every member of the team. I don't believe that's going to be something like Microsoft Copilot. I don't think it's ever going to expand that functionality out into every single crevice and cranny on like your website and being able to use all these different interconnected tooling. But I do think something like Claude or like ChatGPT is going to sit as a middleman between all of these different systems.

But right now, that's a very, very different kind of thing. So, for example, in most companies you probably can just create a page, and again, this is where if we go back to the Sanity version, you can already use Sanity with an MCP. So you are effectively doing the same thing just with one less service in place. But you can build page builders this way. So you would say, okay, can you build me a homepage for the sanity.rostudio.com website? Um, you also now have to kind of onboard marketing folks into the concept of, oh, by the way, you need to understand how context works, which is not the easiest thing to understand if you, you know, you haven't been adjacent to development all these years.

But essentially now, the whole model changes in the way that it works because we're saying, okay, everybody's a developer. So this is where you can see this gets kind of complicated, because we're only up to the point of where we're saying, okay, let's just put a couple of images on the website. But I think it's a very interesting point, and you can see here one of the biggest things as well was performance. That you can see on this, and I think this is kind of interesting because people are going to push harder and harder for performance with their websites because naturally, you know, there's far more focus on providing content (I don't want to talk about SEO, we're not going to talk about that today) to kind of like LLMs to be able to get information about your website. So if you go, what's the best Sanity CMS agency, hopefully we show up, right? But that is something that people focus on. And again, this is really important that you kind of understand all of these things, the benefits and drawbacks in it. I'm going to let you in on the spoiler that I talked about at the start: neither option is without its faults or without its problems. And the very system that you use inherently is going to make a massive impact on your business.

Now, me personally, I actually really do like the markdown way of doing things, the MDX system. However, 99% of teams, I would probably say this. Well, I say, okay, here's the caveat, right? 99% of teams at this moment do not understand the trade-off to build it this way. And I don't think the team is going to be able to edit and continue to build it. However, I think if that team is willing to skill up and spend the next three to six months pretty much teaching every single member of the team, no matter, you know, like age, ability, previous experience adjacent to developers, if they're willing to take that time to spend that time to try and focus people around these things, maybe it might be worth the payoff.

If you're a team like Cursor, it's absolutely worth the payoff, right? If you're a team that's very, very close to the metal when it comes to development, when it comes to AI, yeah, it seems great. However, on the other hand, if you have a lot of marketers on your team and the marketers are willing to start actually taking baby steps towards using AI in separate flows, so like are able to use AI and start moving into AI with MCPs. Sanity's got an MCP. Why not just use that for now and see how they get on with that?

And if anybody has done this, and we have done this ourselves, if you start looking at how these output content, you really have to do a lot of personalization of creating a full AI harness for yourself to be able to generate the content that you actually want with the voice that you want. And if I said harness and your eyes just glazed over, a harness is effectively just the way that you use AI to do what you want to do: your personalization, your opinionation of that particular AI and all the systems that you use around it. And that is extremely important in building these things.

If you are particularly interested in that, we actually use it quite a lot internally and I'd be more than happy to do a video of that in its own right. But I would say, you know, consider all these different trade-offs: the media browsers, the focus on forcing people to actually use almost religiously an AI tool, the way that you actually make changes on a page. So gone are the days where you can go into, for example, Sanity and you can click and you can highlight it and change it manually like you would do a Word document. That's going to change quite crazy in comparison.

All of these things are the trade-off, but the thing that you get out of this is a more agentic ready website if you are willing to take the compromise. And by agentic, I'm talking like a bare bones setup. The easiest way to describe it is that you have Sanity, which is kind of like a Swiss Army knife or like a modern car, like a brand new electric car. So like a Tesla, let's say a Tesla for the sake of this. Tesla has all these different functionalities, right? You can reverse it. It's pretty hard to slam the Tesla into a wall because it's got all different bells and whistles being able to do that. And compare that kind of fully integrated, fully end-to-end solution versus, you know, like one of these kit cars that somebody builds in their garage.

It probably, well, probably in a straight line will out-accelerate a Tesla. Okay, let's not think too much into the analogy. But it probably, let's say for the sake of this, would out-accelerate it. However, as soon as you start reversing that thing, it might not even have a reverse gear. It might not have, of course, it's not going to have any electric sensors and it's not going to do all this fancy stuff. But it does this one thing very, very well, which is kind of like a more refined, restricted, or a stripped-away driving experience, in the same way it is with a markdown website with AI with Next.js.

I hope this is a kind of a nice primer, like an intro to all of this, and we're more than happy to kind of talk more in depth about each of these individual aspects. And if you liked it, feel free to, you know, hit the like, hit the subscribe, whatever at the bottom, because I would absolutely love to talk more in depth about this sort of stuff. But yeah, good primer. Have a great day. Take care. Bye-bye.

## Frequently asked questions

### What is MDX and how does it differ from traditional CMS?

MDX is markdown with the ability to embed React components inside of it, allowing you to build dynamic page builder blocks directly in your content files. Unlike traditional headless CMS platforms like Sanity that use drag-and-drop builders or form-based editors, MDX lets you create rich, interactive pages while storing everything in GitHub, giving you a more developer-centric approach to content management.

### Should every team build their website with markdown and MDX?

Honestly, no. About 99% of teams don't understand the trade-offs involved, and most won't have the capacity to edit and maintain it long-term. However, if your team is willing to invest three to six months training everyone on AI tools, MCPs, and AI-driven workflows, it could be worth it. It really depends on whether you have skilled developers and whether your team embraces AI-augmented development as a core workflow.

### What are the main challenges with building in markdown?

The biggest challenges are managing media assets (images shouldn't be stored directly in GitHub), needing to build or integrate a custom asset management solution, requiring team members to work through AI prompts rather than visual editors, and losing the ability to make quick manual edits like you would in a traditional CMS. You're essentially trading ease-of-use for performance and AI-readiness.

### How does content creation differ between markdown and Sanity?

With Sanity, you use a visual interface to click, drag, and manually edit content like you would in Word. With markdown, you're primarily working through AI chat prompts to generate and modify pages. This is a fundamental paradigm shift that requires your entire team to think differently about content creation and to become comfortable working conversationally with AI systems.

### Why would Cursor choose markdown over a traditional CMS?

Cursor's team chose markdown because they're highly skilled developers who use AI agents constantly and understand the trade-offs. They get a stripped-down, optimized system that performs exceptionally well and is ready for agentic interactions, similar to how a kit car might out-accelerate a Tesla in a straight line. For a team like theirs, the benefits outweigh the complexity costs.

### What is an AI harness and why does it matter?

An AI harness is your personalized setup for how you use AI to generate content: your opinions, preferences, and workflows built into the way you prompt and interact with AI systems. It's extremely important because raw AI outputs need significant customization to match your brand voice and content style, and without a thoughtful harness, you'll spend a lot of time refining what AI generates.

### Can you use AI agents with traditional CMS like Sanity?

Absolutely. Sanity offers MCPs (Model Context Protocols) that let you work with AI agents while keeping your content in a solid, user-friendly CMS. This gives you the benefits of AI-augmented workflows without forcing non-technical team members to work entirely through prompts, making it a practical middle ground for most teams exploring agentic workflows.

### What's the main advantage of markdown websites for AI and performance?

Markdown-based sites are what we call agentic-ready: they're optimized for being crawled, indexed, and understood by AI systems and LLMs. They also tend to perform better technically. The trade-off is that you lose the safety rails and integrated tools of a full-featured CMS like Sanity, which functions more like a modern Tesla with all its built-in protections and conveniences.

---

## Sanity SEO done right: Open Graph, JSON-LD, fallbacks


> A quick walkthrough of how we handle SEO inside every Sanity project we build - the exact schema patterns, fallback logic, and Open Graph setup we use as a default baseline on Turbo Start Sanity.

**Published:** 2026-05-18 | **Updated:** 2026-09-04 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=nG7IgrhaJBY

---

## Transcript

Hey bird, how you doing? So, first of all, I wanted to put this on YouTube so everybody else can actually see the answer to this question because I get asked this so many times on a daily basis, but I thought it might be helpful for you. Uh, so in short, and this is a very, very common thing that we get: has anybody done SEO work on Sanity before? Doesn't really go too much into what's actually built into the model, but I hear this time and time again. Um, and the reason why you have this happen so much is because Sanity is very, very unopinionated. And the reason why it's very, very unopinionated is because it can create models that can do anything, genuinely anything, when it comes to just writing a blog, or it can be more complex, as in running an entire e-commerce system, or it can be as simple as creating like a terminal that tells you the latest train times at a train station. It's really, really scalable.

Anyway, so what I'll talk about is a little bit of this. So this is an old Learn article that we wrote with Sanity, which is really helpful. It tells you about how you should opinionate your actual SEO, and it's all good and fine if you want to take the time out to go look through this. That's great. You've got a lot more time than I have, so that's fantastic. Now, I'm going to show you something totally different. This is actually the Turbo Start, and this is the way that we do it. It's the same thing that's in the Sanity Learn documentation. Um, but I know how low people's attention spans are today, so very, very quickly, I'll show you how this works. This is how we opinionate SEO and we do the exact same on every single one of our projects.

So when we build a page for a page builder or for a blog or any other document type, it has a title, okay? And you can do validation. You can do things like, oh, it has to be x number of characters. You can do that. That's really cool if you think it would help the client. But for the simplicity of this, we don't have like that little number underneath, um, because we're trying to be unopinionated. Um, and description, which is going to be effectively used as your meta description on the page. This can also double up. So if, for example, it's a blog, um, the title of the blog could also be the title that sits inside of here, and the description could be the little blurb that you get just before you click into the blog on a card. That's one thing to know. So this becomes our baseline.

The same with images. So you may see an image in here as well. Um, which I believe is an SEO. So ours is a SEO image override. Um, however, sometimes we actually include the image in here as well. It could be that it should be in here. Nope, okay. Um, that might get tweaked on the Turbo Start Sanity, but essentially I like to have an image inside of here as well as part of the pages as a fallback image. However, we have this secondary tab which is SEO. This is your SEO, your meta title. So your title tags at the top, um, and the meta description, which would be in the meta description section. Um, and these will override the title and the description. And you might ask, hold up, if we've got the title and description, then what's going to happen if we override them? Then there surely there's no reason to have these in the first place. Well, the reason we have these is because they're always a fallback. So it means that you have a consistent way of editing your pages, whether that's a page with page builder blocks or a blog which has like the blog title, blog description. So it may not appear on all pages.

Now we've got our SEO. So our metas are sorted. What about our open graph? Well, makes perfect sense. Let's do open graph title, open graph description. And you can go a step further and also do, I think there's a separate open graph image. Uh, you can separate it out down to as granular a level as here's what we want to have on Twitter, here's what we want to have on Facebook, and I think LinkedIn does it as well, just off the top of my head. Um, this is kind of like our de facto baseline. So I would highly, highly recommend doing it this way. Um, however, you can go a lot more granular. You can put JSON-LD in there. You can do all sorts of things. However, a note on JSON-LD, and I've said this to a lot of different people: I much, much prefer set and forget JSON-LD. So if you're already putting all this data like titles and descriptions and things like that in there, and authors. If you're on a blog page, let me show you a quick example of this.

Um, I'm wondering if we have authors on here. I hope we do. If we don't, I'm going to tell you how to do it. Uh, we do. Great. So if we've got all of these authors that are inside of here, why don't we just pull those authors into JSON-LD by default, which is set and forget? So you don't have to think about it. You just enter the data inside of Sanity and a like-for-like pair comes up with JSON-LD. And it's not so complicated these days with AI, so you can even do this relatively quickly. Um, but yeah, this is what I'm talking about when I talk about a de facto default SEO experience. What you should use as a baseline for every single Sanity website that is going to be a website. This obviously differs if it's going to be a different function. But if you're looking to start this straight away, or in your case, I would just literally go to the Sanity Exchange, go find Turbo Start Sanity. You can also find this on GitHub. Um, go view the repo and tell the developer to just go look inside of here.

Um, and pay special attention to two files. One of them is Query. So Query shows you how we handle our Groq queries. And Groq is the query language from Sanity. And then the second thing you want to pay attention to inside of here (um, let me see if I can find it for you. Let me just press up top, any second now) is the SEO. I think it's SEO fields which you can see you can reuse this. This is what we use on ours where it's the SEO title, SEO description. Makes perfect sense. SEO image, SEO no index, and SEO hide from lists. And the reason we have these two left is because obviously you want to have a no index. Sometimes maybe it's a pay-per-click content page that you very specifically want to tunnel down a specific person that's coming to your website. And the second one is SEO hide from lists because, for example, you have a blog post. It may be that you don't want that blog post to show up on certain lists. It may be that you have a no index and you also don't want it to show up on certain lists, or vice versa. That's the reason why we do this because if you have SEO hide from lists inside of your Groq, you can say give me all the blogs except for the ones that are getting hidden from lists, and it's really nice and easy to work with.

Uh, there's some very basic validation here. If the SEO problem continues, just give us a shout. We're more than happy to try and help and give you pointers in the right direction. Thanks a lot. Have a great day. Take care. Bye-bye.

## Frequently asked questions

### Does Sanity have built-in SEO support?

Sanity is very unopinionated by design, which means it doesn't come with a fixed SEO setup out of the box. That's actually a feature, not a bug: it lets you build SEO to suit any project, whether that's a simple blog or a full e-commerce system. We have a Learn article that walks through how to opinionate your SEO, and our Turbo Start Sanity starter is a great practical reference for how we do it on every project.

### What is the baseline SEO setup you recommend for every Sanity project?

Our de facto baseline includes a title and description field on every document type, which act as fallbacks, and then a dedicated SEO tab with a meta title and meta description that override those fallbacks when set. We also add open graph title, open graph description, and an open graph image. This gives you a consistent editing experience across page builder pages, blogs, and any other document type.

### Why have a separate SEO title and description if there's already a title and description?

The top-level title and description are always a fallback, so every page has something sensible in place even if no one fills in the SEO tab. The SEO-specific fields let editors fine-tune exactly what appears in search results and social previews without changing the page's actual content fields. It's a clean separation that keeps things flexible without leaving anything blank.

### How do you handle open graph and social sharing metadata?

We add open graph title and open graph description as a baseline, plus a separate open graph image field. You can go even more granular and split this out per platform (Twitter, Facebook, LinkedIn each support their own tags), but the open graph baseline is what we'd recommend as a starting point for most projects.

### What is your approach to JSON-LD structured data in Sanity?

We strongly prefer set-and-forget JSON-LD, meaning we automatically generate it from data that's already in Sanity rather than asking editors to fill in extra fields. For example, if a blog post already has authors assigned to it, we just pull those authors into the JSON-LD automatically. With AI it's pretty quick to wire this up, and it means the structured data stays accurate without anyone having to think about it.

### What are the 'no index' and 'hide from lists' SEO fields for?

The no index field is useful for things like pay-per-click landing pages where you want to drive specific traffic but keep the page out of search results. Hide from lists is a separate toggle because sometimes you want a post excluded from sitewide blog listings even if it is indexed, or vice versa. Having both as explicit fields means you can filter them cleanly in your Groq queries: for example, fetch all blogs except those hidden from lists.

### Where can I find your SEO setup to use it as a reference?

You can find the Turbo Start Sanity starter on the Sanity Exchange or on GitHub. The two files worth paying close attention to are the Query file, which shows how we handle our Groq queries, and the SEO fields file, which covers the SEO title, description, image, no index, and hide from lists fields. You can point your developer straight at the repo and they should be able to get up and running quickly.

---

## Build Sanity CMS Pages Faster with MCP


> Build full Sanity pages in minutes using the Sanity MCP in Claude. I walk through the setup, prompt Claude to generate a services page with zero copy, and review how well it picks page builder blocks.

**Published:** 2026-05-13 | **Updated:** 2026-09-04 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=hF2Xecy--Xs

---

## Transcript

Hey, how's it going? So in this video, I'm going to show you how to build pages faster with Sanity MCP in Claude. So you can do it two ways. You can either do it from the chat view that I'm on currently or you can also do it from projects. So I'll show you what to do first. You go here and you make sure you add your project. Do not forget this step, otherwise Claude will be completely clueless and would not have the context. It's pretty obvious, but a lot of people forget this.

Anyway, the second step is to go to connectors. Since we're using Sanity MCP, make sure Sanity is selected. After this, you go to projects. This is a very important part as well. You select your project. I'm using Turbo Sanity. I've already created my project. But this is the important bit. You need to make sure you have added your project ID and your organization ID. Again, if you don't do this, then you're not providing enough context to Claude. You can simply find this information from Sanity's admin panel and copy paste it from here.

Anyway, going back to Claude, we go to the chat. And for this video, we're going to create a services page for a bottle. And I'm going to provide a prompt that I will paste in the description below. And I'm also quite lazy, so I'm not going to type it. So here we go.

So I don't know if you noticed it. I have added a special instruction for Claude. I would like my cards to be displayed in threes and sixes, not in fours and fives, because that's how it looks balanced in my particular case. Also, I need to double check that I've added my... okay, so did you see that? I thought I added my project, but I didn't. So make sure you've added your project here. Otherwise Claude would just go ahead and create without any context.

Anyway, let's do this. This is going to take some time. While it's doing it, it's very important to know that with current Sanity MCP, we cannot add images. So this is one of the limitations and I'm sure the Sanity team is working towards it. But for images, you have to do it manually. But this is great for adding content and it's so fast. You will see in a second. And especially when you have hundreds and thousands of pages just to add the content out there, it's huge.

Okay, so moment of truth. I can see Sanity MCP is using the pre-existing page builder blogs to make decisions. Bear in mind I've not provided any copy for the page. I have not given any strict information and also Turbo Start Sanity website is a very small website with, I would guess, five page builders in existence. So obviously it will be different for your use case. You can use it for a large website and if you have twenty page builders available, MCP can take a lot more context and a lot more page builders to play around with.

So we can check out the page now and see how it looks. Okay, so we are in presentation view. What I like to do is I like to go to structure view and I like to just make sure that everything is in the right place. Services, I can see here. There we go. URL looks great. Oh, interesting. Three page builder blocks are here. This is decided by Sanity MCP. I have not given any instruction here. So let's see how the page looks like. Wow, this is really cool. The fact that it picked the correct logo side icon is very impressive as well.

To recap, I have not provided any copy for this page. I have given a very vague piece of prompt saying I would like to create a services page for a robot studio, and this is the result. So Sanity MCP, as you can see, is pretty good at predicting and implementing page builder blocks for a page, and this will be a completely different use case for your own company. This is a very small website, but for a small website this looks really impressive and I can only imagine what would be the case for a large website.

So anyway, thank you so much for watching. Have a good one.

## Frequently asked questions

### What is Sanity MCP and how does it help build pages faster?

Sanity MCP is a connector tool that integrates with Claude to automate page creation in Sanity CMS. It can generate page structures and content based on your existing page builders, allowing you to create pages significantly faster without manually typing out all the details, especially useful when managing hundreds or thousands of pages.

### What setup steps are required before using Sanity MCP in Claude?

You need to add your Sanity project to Claude, select Sanity as your connector, and then provide your project ID and organization ID from Sanity's admin panel. These steps are critical because without them, Claude won't have the context needed to understand your project structure and make informed decisions about page layout.

### Can I use Sanity MCP to add images to pages automatically?

No, adding images is currently a limitation of Sanity MCP. You'll need to add images manually after the page content has been generated, though the team is working towards this capability for future versions.

### How does Sanity MCP decide which page builder blocks to use?

Sanity MCP analyzes your existing page builders and uses them as reference points to make intelligent decisions about which blocks should be included in new pages. The more page builders available in your project, the more context MCP has to work with and the better it can tailor pages to your specific needs.

### Do I need to provide detailed copy and instructions for Sanity MCP to create a page?

No, you can provide a simple, vague prompt like requesting a services page and Sanity MCP will generate appropriate content and structure based on your existing page builders. This makes it excellent for quickly scaffolding pages without needing to specify every detail upfront.

---

## Agentically creating Sanity Studio thumbnails


> Want AI-generated thumbnails for your Sanity page builder, in one prompt? We walk through the skill we use on top of Turbo Start Sanity, our open-source Next.js + Sanity starter. Try it yourself or…

**Published:** 2026-05-07 | **Updated:** 2026-08-11 | **Categories:** Walkthroughs

Watch: https://www.youtube.com/watch?v=4fCQPG8jAJU

---

## Transcript

Okay. So I'll show you a quick demo of how you can add thumbnails for your page builders on Turbo Sanity. So I have already copied the prompt, but I can drop the prompt in the description and I am going to paste my prompt. So since I already have thumbnails from before, I can show you just now. I have it in my prompt to delete the existing ones. So for this demo, I'll show you, for example, for this page. You can see the add items. The thumbnails already exist. Not to worry, they will disappear in a second. So this is my prompt. And here we go. So this does take some time. I would say five to six minutes depending, you know, on your internet, depending on Floyd's mood, etc. Anyway, you know, hopefully it shouldn't take too long and I would be able to show you side by side. On this side, when this is done, you would have completely brand new thumbnails. Okay, so it's nearly done. If you don't know what Turbo Sanity is, it's our open-source framework for building a solid Next.js and Sanity website. So check it out. As I said, I will link this skill in the description. And also by the looks of it, we have successfully added the thumbnails. So let's refresh. Moment of truth. There you go. All fresh thumbnails. How nice. Anyway, hope you enjoyed this video, guys. Give us a thumbs up and like or subscribe. And thanks a lot. Have a good one. Bye.

## Frequently asked questions

### What is the Sanity Studio thumbnails skill?

It's an agent skill we run on top of Turbo Start Sanity that generates and assigns custom preview images for every page-builder block in Sanity Studio. You drop a single prompt, the agent works through your schema, and you end up with a complete thumbnail set instead of editors picking blocks from a wall of identical icons.

### What is Turbo Start Sanity?

Turbo Start Sanity is Roboto Studio's open-source starter for building production websites on Next.js and Sanity. It ships with the page-builder patterns, schema definitions, and visual editing setup we use on every client project, so you don't start from a blank Studio.

### How long does it take to generate Sanity page builder thumbnails?

In the demo it took about five to six minutes end to end, depending on connection speed and how busy the model provider is at the time. The skill runs unattended once kicked off, so you drop the prompt, walk away, and come back to a finished set of preview images.

### Why bother with thumbnails for a Sanity page builder?

Editors pick blocks faster when they can see what each one renders as, instead of reading a label. Custom previews are part of why Sanity's page builder feels editor-friendly in the first place, and skipping them is one of the quickest ways to make a Studio feel generic.

### Can the agent regenerate thumbnails I already have?

Yes. The prompt has an option to delete existing thumbnails before it runs, so you can rerun the skill any time the design language changes without ending up with a mix of old and new previews.

### Do I need Turbo Start Sanity, or will this work with my own setup?

The skill is built around the conventions Turbo Start Sanity uses, so it works out of the box there. On a custom Studio you can still use it, but you'll likely need to adapt the prompt to match how your blocks are named and where preview images get stored.

### What is a Sanity AI agent?

In this context, an AI agent is a long-running process driven by a prompt and a set of tools: read the schema, generate an image, upload it, write the reference back to the document. It's how we automate jobs in Sanity that would otherwise need a developer for an afternoon, like generating thumbnails for every page-builder block.

---

## "Can I fix this, or does a developer need to be involved?"


> A short from the official Sanity channel on how we use Content Agent alongside the Sanity MCP and Claude at Roboto Studio: the whole team has Claude Pro, and editors can fix content problems themselves instead of waiting on a developer.

**Published:** 2026-04-21 | **Updated:** 2026-08-11 | **Categories:** Shorts

Watch: https://www.youtube.com/watch?v=wb-r4IXVT_E

---

## Transcript

You can try asking the content agent if you can fix it from a content level, which is great. So you can literally go, issue one, can I fix this from a content level? Yes, here's the bulk edit to fix it. And if it says no, then okay, a developer needs to be involved. But that's, that's a great way of kind of starting.

Such a good way. It's good to, like, empower editors to be able to do more, right? Like, anyone wants to do more, right? And anyone wants to maybe not want to bother the developers all the time if they can fix it. So I think this is really cool.

## Frequently asked questions

### How do you tell whether a content problem needs a developer?

Ask Sanity's Content Agent directly. You can literally go, here's issue one, can I fix this from a content level? If it says yes, it hands you the fix, and if it says no, then a developer needs to be involved. It's a great way of starting the triage.

### Can the Content Agent actually fix the problem for you?

When the fix is possible at the content level, yes. In the example from the video, the agent responds with a bulk edit that resolves the issue, so the editor can apply it without touching code or raising a ticket.

### Why let editors do this instead of just asking a developer?

It empowers editors to do more, and most people want that. Editors would rather sort a problem themselves than bother the developers every time something looks off, so developer involvement is saved for the cases the agent says genuinely need code changes.

---

## Running git work-trees with Portless & Conductor


> Here's how we set up Portless with Conductor so each of your git worktrees gets its own isolated environment. The setup is pretty straightforward: you configure Portless once, point it at your code…

**Published:** 2026-02-26 | **Updated:** 2026-08-11 | **Categories:** Shorts

Watch: https://www.youtube.com/watch?v=65rZkLeMPrk

---

---

## Your first AI agent


> Looking to build your first AI agent workflow? We share the stack that powers our current lead enrichment, and the open source Lead Agent repo from Vercel. Go build it, or ask us to build it for you.

**Published:** 2026-02-19 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=rhoYynL-4pY

---

## Transcript

Hey, how's it going? Hope you're having a great day. I want to talk about workflows and agentic workflows and how you can actually integrate them inside of your website and very specifically the ones that are very high value with very low effort. Because this should be basically like a gateway drug for you getting into, you know, the agentic stuff and everything else. You've probably rolled your eyes by now, but it's very, very important. And I think you should be using it today because I think there's going to be a huge amount of companies that are going to dwarf the efforts of other companies with being able to basically leverage AI.

So let's start. What do we currently use and what is valuable with our particular business? Well, we use a form enrichment system. So whenever somebody submits a form on our website, it takes the name, it takes the domain name that comes out of the email and it takes the message to understand intent and it creates a whole research chatbot that goes off and basically uses a bunch of tools to read the information from that particular client and come back and give me a complete synopsis of why they're getting in touch, whether they're a good fit, all these different informations, you know, financials, whether it's a series A round, series B round, all that kind of stuff. So that's really really valuable.

Now, how do you do that? And how would you get that running as fast as possible? Well, you're probably going to be using something like HubSpot or Salesforce. HubSpot is an interesting one. Depending on which plan you have, but there are a whole bunch of different trade-offs that are involved in there, whereas Salesforce is very very easy to do this with. But basically, you would stick it in between those two endpoints and you would make sure that it basically runs.

Now, how do you know this is going to run consistently? Because that is a problem of its own. Well, I'll tell you about the most underutilized thing that I know of that Vercel has, which is this tool called workflows or the use workflow development kit. It's right here. Now, what does make any TypeScript function durable mean? I don't know when I first looked at this, nor did anybody on my team know. Let me tell you what this actually means, because it's so much simpler when you know that it basically means that no matter what happens, this generally doesn't break. It will take another go at whatever it is doing.

So in the particular context that we're talking about here, if for example the AI responded with an incorrect system, so like it basically gave you an error when it came back, it would try again maybe three times before it basically failed. Or for example, it tried going to an API and the API wasn't available at that particular time. It can just basically go again and wait and go again. Even more impressive is that it can wait for a tremendous amount of time. So you could very easily say, "Go ping this after 5 minutes. Go ping this after 10 minutes. Okay, that didn't work. Go ping this after 3 weeks." It's really that functional. So like it will go that length of time.

Now, if you're a developer, you've probably just heard what I've said and thought, "Oh, wow. How do they keep it running for three weeks or a month or six months?" I don't know. Frankly, I don't know how they do it. It's magic. It works though and it's really, really incredible. And you can do some incredible onboarding flows with this particular technique. It's just that people aren't using it right now. And I think these companies that are going to use it are going to absolutely blow other companies out of the water.

So this is just basically some of the code. We can give some advice as to how to build these things for the first time. But the best way to just start working with it is to use something that somebody else has built, which is the lead agent. So this thing right here is something that Vercel has open-sourced and it is a perfect example very similar to what we were talking about where it is an inbound lead qualification tool that uses your own data set. So you can actually put your own data warehouse in here or whatever tools you're using to enrich that particular lead that comes through.

Now, this is a pretty big form. And I'm not the biggest fan of having to fill out quite substantial forms, but this shows you how the architecture works. And you can see, you know, user submits form. This starts the workflow. So, again, the workflow development kit here. And then the research agent goes off using AI's SDK. Again, the AI's SDK qualify lead. You can have your own thing. And this is the reason why it's so powerful. Once you've built this functionality, you can tweak it exactly to your business rather than having to use predefined tools that already exist that are kind of like a one-size-fits-all. Think of it like tailoring a shirt that you know is going to look really really nice versus buying one off of the rail and it kind of looks all right, but it's a bit boxy and it looks a bit weird. That's what we're currently used to with all these different SaaS solutions. This is the custom-tailored looking really really nice when you actually wear it.

So yeah, that's the difference here. And again, this is just using the Vercel architecture. I would really heavily advise using Vercel. Not because I'm getting paid for this, but because we just use it. And every time we use Vercel, there is no headaches with anything that we build. It's just really, really efficient.

And one thing that's really particularly nice about this demo in particular is the Slack bot that comes involved in it. So the Slack uses Bolt, which is a brand new library for Slack. I think it was released like three months ago from memory. But it's a way of Vercel basically putting this adapter that sits between those two toolings. I'm going to check this. I'm going to fact-check that this is a new tool from Slack, but I'm fairly certain it is.

And you might be wondering with all of this, this is all sounding great so far. But surely putting our conversions and things like that inside of here is a very easy way for data to leak and we should start worrying about that kind of like that information going out. Well, that is where Sandbox SDK comes in. So this in particular is usually used for if people are going to try executing code and doing things and trying to stop people from wiping stuff. But there is a whole host of different ways to ensure that your data doesn't leak from this AI agent. There are a lot of them built in. Vercel basically builds into this whole tooling. But this is one that if you want to do more complicated stuff is very very valuable.

And now I'm hoping your brain's spinning with a whole bunch of different things that you might want to do with your own form. But if not, I'll give you a couple more suggestions that are very very useful that I would consider doing right now and we are doing internally for different clients and for ourselves.

So internationalization is a massive one. Internationalization used to be so so expensive to do, and now it's gone down to pennies. So you can use tools like Languin, which is fantastic to be able to pass it back in markdown or pass it back in a whole different range of different file types, or you can integrate with AI itself to just rewrite pages and give you a great first draft.

And talking of first drafts, there's another option that you can do with this, which is if you're trying to do content velocity, you know, you need to put out blogs and you find yourself kind of bottlenecked by the number of marketers that you have on your team. Well, the great thing you can do is you can actually generate on a cron job. So when it goes off like once every week, it fires five different drafts off based on something like, say for example in our particular field, you might do it based on X posts like X kind of trending things or something like Hacker News. You can base those and create a bunch of different blog posts. So you can generate the first draft of say five blog posts every week at 9:00 a.m. UK or 9:00 a.m. US, whatever. That's something you can do with this particular tool. You can feed that into Sanity or Contentful or any other headless content management system that allows you to make API calls.

And then finally, probably another one that's really really useful that we see, some people are offering this as a SaaS, but you might want it internally, which is you might want to create an internal chatbot from the company information wherever that is kept. If that's in a data warehouse or if that's kept in, for example, markdown or it's kept inside of Sanity or an API. Getting all that information together and being able to query that information fast is like the fastest way to onboard new people to the team. That's all possible with everything that we've just talked about.

So if any of these things sound particularly interesting, get in touch. We're going to do a few more demos in the future where we talk about how to actually build these and show a lot more development environments. So if you like this, do us a favor. Give us the thumbs up or subscribe or whatever it is that people usually say at the end of these videos. Anyway, thank you ever so much for listening. Take care. Have a great day. Bye-bye.

## Frequently asked questions

### What is a good first AI agent to build?

Lead enrichment is a great starting point. When someone submits a contact form, an agent can take the name, email domain, and message, run research across the web, and return a summary covering company size, funding stage, and likely intent. The value is high, the scope is contained, and it slots into a workflow you already have.

### What is the Vercel Workflow SDK?

It's a toolkit that makes any TypeScript function durable. If an API call fails or an AI model returns an error, the workflow retries automatically rather than dying silently. It can also wait for long periods between steps, so you can build flows that check in after 5 minutes, 3 hours, or even weeks without keeping a server alive the whole time.

### What is the Vercel Lead Agent?

An open-source inbound lead qualification tool from Vercel. A user submits a form, the workflow kicks off, and a research agent enriches the lead using your own data and tools. It includes a Slack integration via Bolt so results land in a channel rather than just an email. It's a working reference implementation you can fork and adapt to your own business logic.

### What other agentic workflows are worth building?

Three worth doing now are automated content drafting (a cron job that generates blog post drafts from trending topics each week and pushes them into your CMS), internationalization (passing pages to a translation service or LLM to produce first drafts at a fraction of the old cost), and an internal knowledge chatbot that queries your company data warehouse or CMS so new team members can get answers fast.

### How do you stop data leaking from an AI agent?

Vercel's Sandbox SDK is designed for this. It isolates execution so the agent can't reach data it shouldn't, which matters when agents are running code or accessing internal systems. Vercel also builds additional data guardrails into the workflow tooling itself.

---

## What features should a headless CMS have in 2026


> Our video on what a headless CMS needs in 2026. We cover the editorial features we look for and the capabilities we check before recommending a platform.

**Published:** 2025-12-30 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=m6Muniv7WD8

---

## Transcript

Hey, how's it going? Hope you're having a great day. Let's talk a little bit about headless content management systems. If you didn't know, we're just about to move into 2026, and it's obligatory that we make these kind of lists to see how far off the mark we are when 2027 comes around. So, um, let's talk a little bit about the features that I would be paying attention to if you're looking for a headless content management system. Um, most important are usually kind of towards the top of the list and the less important are towards the bottom of the list because they should be table stakes anyway.

So starting with AI and your CMS. Now we don't want to just talk to this as like a chatbot that talks to your content management system. You are going to find that you need more than that. And I think teams that have marketers that are willing to use things like Cursor or, you know, like Claude or something along those lines, like these AI assistants that are able to use MCP, are going to absolutely crush things.

I'll give you a very quick example of something that we did in house and I could see how a marketer should be, and absolutely should spend time doing this. Um, but we had the launch of Next.js workflows. You may have seen it. It was about three months ago. They called them durable workflows. I don't think anybody knows what durable workflow is outside of developers. And then when you actually started using them, they probably created the most impressive tech, um, where you could literally say "go wait six months" and it would still work, um, which is just unheard of in the whole development environment, not without you know creating tons upon tons of infrastructure.

Anyway, when this came out, they put out a press release. And the coolest thing was the fact that we were able to use Cursor with an MCP to take that press release, take it as a brief, you know, set of notes and refactor one of our pages that existed inside of Sanity to create a page that now exists on our own website called SL Services. I think it's workflow slservices/workflows. Um, the whole of that page actually isn't written by us. Um, it was a first draft that actually worked through an AI. So, um, I'm obviously going to say this and probably end up getting deranked by Google, but it was something that you could do from the get-go. And obviously, we've done some tweaks to it. Don't dank me, Google. Um, and it now is like our own words, but the fact that we were able to smash a first draft in roughly two, three minutes using Sanity's MCP is incredible.

Now, Sanity's MCP, if you didn't know about this, has just been released, a brand new update to it. Um, there's a ton of different interesting stuff in there, but you should be getting all of this functionality inside of your headless content management system. Um, because you're going to find these small teams of these three marketers absolutely surpass what teams of, you know, ten, twenty, thirty marketers can do.

Um, and our next one is a good ass preview. So, this is something that everybody gets wrong when they build their websites. Um, if you don't have a preview and you don't have a working preview that's almost instantaneous, uh, you're doing something very, very wrong because I guarantee you a marketer is going to want to see what's been changed on the website. So, more relevant than ever is that there is this, this idea, this concept of a preview that just works with one without locking other people out.

So something that happens on some content management systems is, you know, person A and person B want to make a change to a website. You have to wait for person A to hit publish or hit save draft before person B can start making changes to the same document. You do not want that. You want a multiplayer environment, you know, like Google Docs, where multiple people can be working on the same doc at once. Um, it's been out on Google Docs for god knows how long. What, like ten years, I think or something stupid. Um, we should absolutely have that in our headless content management systems. Um, and again, this comes back to the good ass preview one. We want to see our changes live as fast as possible.

Now, as far as I'm aware, I think Sanity has a proprietary system. I forgot the name of it. Is it, it's got a weird name, but they have some proprietary system that makes your changes almost instantaneous. Um, I think it's called the Insanity Live Content API, but I forgot the name they specifically use for it. It works with blank spaces, but it's really, really powerful, really fast. Um, what's so impressive about it is you hit publish and even on a statically generated website, you're going to see those changes instantaneously and everybody that's on that page will also see those changes. Um, and it's instantaneous.

So, having all these things kind of work together, these top three are probably the most important I would say. Um, but having them all work together is a massive boon for the actual marketing team because there's less, you know, less tiny little paper cuts. You know, the whole idea of death by a thousand cuts, that especially applies to content management systems. Um, and the more we can make all of these things easy and actually be able to write this content faster, the better it gets.

And now with all these top ones, we're going to move into kind of like the enterprise area, which is the idea of a DAM. Uh, and a DAM is a digital asset management tool. I think they call it digital asset management platform. Um, the more we talk about kind of a media browser, and this is something that I will say Contentful is very, very good at, um, is having this kind of like multifaceted media browser where you can bring everything together into one singular, uh, storage space. Um, Sanity is also pretty good at this, but the videos leave a little bit to be desired. Um, because you need to have something like MUX, and depending on which company you're working with, uh, it's another onboarding of another vendor and it can be a real pain in the ass to do that. Um, but yes, the whole idea of a digital asset management tool is super important and something that I think is going to have more and more demand as these uh headless content management systems are becoming mature.

Um, and then scheduling that doesn't suck is another one that I personally really don't like. So I have had no end of problems with scheduling in my time. Um, especially with WordPress, especially with issues with PHP, all kinds of stuff back in the day. Um, but having a scheduling tool where you know and you feel confident you can hit schedule, um, and it just works in a day's time or two days time is huge.

Now the other part of this is not just the scheduling but the concept of scheduling multiple things into a release. Now Sanity has something called releases. It's fantastic. Um, it's a way of being able to set up a whole bunch. So, for example, if you know you're going to release five different services uh next Wednesday, um, then you can actually use this releases to create next Wednesday's release of new services and put all of these changes into a single release and immediately publish it all at the same time. It's really cool, really good functionality, and it gives you that ability to see the changes before they happen again. So, that that kind of pulls back into the good ass preview. You need a great preview to kind of action the rest of these items on the list.

Uh, publishing, unpublishing, and roll back. So, if we're talking about scheduling, we have to talk about these things. And not every system has a great roll back. Um, trust us, we've experienced it firsthand. Um, and the main thing that you want here is the ability to go step back through the history of changes. Um, it doesn't seem like an important thing until somebody accidentally um changed a good chunk or accidentally overrode, you know, two hundred um lines of of text. Uh, and that's the point at where you need that roll back. And Sanity has a great one. Uh, a lot of these different headless content management systems have a pretty good one, but it's something that you want to test before you get to that critical point.

And then finally, the last one, instant search. So this one is about more than the raw speed of the search. It's about finding that data. Um, so this kind of plays again, I know I sound like I'm just pitching for Sanity at this point. Um, but again, Sanity is a very, very good tool for having structured content. And all of this kind of AI indexing and all these, you know, answer engine optimization that people are looking for all comes from indexing things in a great way, having great data available to these tools. The same principle applies with search. Um, if you want to test this out, and again with Sanity, um, there is Sanity's embeddings index, which is like the AI search tool. Um, and we actually did a long time ago, we did a blog on, uh, I think building the first, as far as I'm aware, embeddings index search, uh, engine with Sanity. So, feel free to have a look at that.

Um, but all of these different things you want to make sure that you're looking for in your headless content management system in 2026. Um, and more importantly, when you are looking for these, make sure you're not getting absolutely rinsed for a price because all of these things are kind of like industry standard in every other aspect except headless content management systems. Uh, in our opinion, there are very, very few headless content management systems that feel like a truly mature product. Um, and it's because of that kind of that spanning of so many different facets of a website and trying to spin in all different tooling. Uh, you know, like personalization and digital experience platforms in general, which I am going to talk about more later. Um, but you know, they're trying to bite off more than they can chew. And it's very important that you have something that is very specifically purpose-built for you.

And again, this wouldn't be a video without a tacky little sales pitch at the end. If you are looking at getting a headless content management system uh implemented, make sure to get in touch with us. We aren't just going to bat for Sanity. We have a whole bunch of different tools, but we do like Sanity a hell of a lot. So, feel free to get in touch and we'll catch you later. Take care. Bye-bye.

## Frequently asked questions

### What features should a headless CMS have in 2026?

In rough priority order: AI and MCP integration, a fast live preview with multiplayer editing, digital asset management, reliable scheduling with batch releases, publish/unpublish/rollback controls, and instant structured search. The first three are the ones that most CMSes still get wrong.

### Why does AI integration matter in a headless CMS?

Because marketers using AI tools (Cursor, Claude, etc.) with MCP access to the CMS can produce content faster than large teams doing it manually. At Roboto Studio, a first draft of a full services page was written in two to three minutes by pointing Cursor at a press release and letting it push content directly into Sanity via MCP. Small teams with good tooling outpace large teams without it.

### What should live preview look like in a headless CMS?

It should be near-instant and support multiple editors on the same document at the same time, no locking. Sanity's Live Content API pushes changes to a statically generated page in real time, so a marketer sees edits reflected immediately without a rebuild. Most CMSes still don't get this right, and it causes constant friction for content teams.

### What is digital asset management in a headless CMS?

A single place to store and browse all media (images, documents, video). Contentful is notably strong here. Sanity covers images well but requires a separate video provider (like Mux) for video, which adds onboarding complexity. As headless CMS platforms mature, this is becoming a more common requirement.

### What are Sanity releases?

A feature that lets you batch multiple content changes into a single scheduled publication. If you're launching five new service pages next Wednesday, you group them all into a release, set the time, and they go live together. It works alongside Sanity's preview so you can review the full set of changes before the release fires.

### What is Sanity's embeddings index?

An AI-powered search feature that indexes your Sanity content semantically, not just by keyword. It underpins answer-engine-style queries on your content. Roboto Studio wrote one of the early blog posts on building a search engine with it, worth reading if structured AI search is on your roadmap.

---

## The difference between a code-based and GUI-based CMS


> Code based (Sanity CMS) and GUI based (Dato CMS) and how they work and the differences and nuances of using them. Get in touch below, bring your hardball questions.

**Published:** 2025-12-05 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=m_4zeFYN-E4

---

## Transcript

Hey, how's it going everybody? So I want to show you something real quick. The difference between GUI based CMSs and code-based CMSs. Now everybody has different opinions on this, but I'm going to give you my opinion. I think this is the right opinion and we'll go through it very quickly.

So essentially the two differences between them, and I'm going to show you two different examples. This is Dato CMS. This is their default marketing template and this is our Turbo template. They're very, very similar, but they're like the best-in-class, or at least we like to think they're the best-in-class between Dato and Sanity.

Now Dato is a GUI based CMS. And what do we mean by GUI based? Well, let me show you. It means when you start building schema and when you start building your content models, which is what you enter your data into, you have to drag and drop them. So for example, I can throw a piece of text in here. I can say it's a single line string, a multiple paragraph text, or some structured text, right? They all have their own proprietary way of doing it.

So this applies to almost every headless content management system. This applies to Dato. This applies to Contentful. This applies to Prismic. Prismic has a weird one. They're kind of halfway between the two, but we'll ignore Prismic. All of these have some form of kind of like data structure where you can pull drag and drop items inside of them, apart from Sanity. The other exception on this is Payload as well. Payload is also code-based, because they basically just copied Sanity's homework.

Anyway, going through the fields here. So you have your text, your modular content, your media. All of these are unique for every single system. And when you click them, you can drag them in. You can press single line string and I'm going to say, "Oh, this is the title of the page." Okay.

Now some of them will have localization on, some of them won't. There will be different validation. So you can see the validation here, and this is a very important one because we're going to come back to this in a second. But validation is essentially the way that you actually validate the field. And it might sound simple, you know, "Okay, it might be nice and easy," but what happens if you, for example, need to match a specific pattern? And some of these do support it. Some of them say, you know, URL or email, custom format, and this is where it starts usually going to regex.

If you don't know what regex is, it's a really, really complicated way of saying, "Oh, by the way, the third letter has to be a capital or something like that," or we can only do regular text and dashes. So this is kind of useful, but the problem here is, and this is what we always recommend, the same thing is GUI based stops at a certain point with validation. It also stops at a certain point when you need to do something custom.

So as you can imagine, their GUI is presented on their website, but as soon as you want to start doing things like, "Oh, by the way, can I integrate our custom component that we use on the website?" Or, "Can I create a brand new SEO validator that sits inside of here?" Or, "Can I make sure that if this website has Wikipedia, we don't reference it because we shouldn't be using Wikipedia pages to reference to?" Um, that's not possible with these validations usually inside of a GUI based CMS.

Compare this to, um, this is the Sanity version. You should always remember this. Um, this version has obviously a visual way that you can edit the page. You know, you can click on things, you can drag and drop, you can do all this kind of stuff. Nice and simple. So same fields, everything the exact same. However, there's a lot of custom stuff that you may want to do inside of here that Sanity allows you to do because it's code-based.

Now that's not the only benefit. There is some negatives as well, but the benefits are that you can also build custom things inside of it. So if you look here, this is the blog page on our Turbo Studio website. You can see we have things like create OG image field, image preview field. The reason why we use that is because I don't want to have to create a brand new image every time I push things to Sanity. I just use the OG image field that we've built to generate a very purposefully built image with all the text and all the data and a generated cat on there.

So it means that every single time we publish something to Sanity, we're doing it in a fraction of the time. And the idea, you'll hear this again and again, but the reason why we love code-based CMSs is because you get this progressively better and better and better kind of gains in publishing and what's the word that they use? They use content velocity. That's the word that we're looking for. So they use this expression of content velocity. The more you can do that, the less time you have to burn through marketers and things like that.

And again, the same principle here. So there's a lot of reusability and a lot of things that you would do in JavaScript. So this all sounds very positive. Why doesn't everybody just use code-based CMSs, right?

Well, there is kind of this is the negative bit. It's harder to build them. And anything that has a skill floor that's a lot higher, people go, "Oh I don't want to learn that." So it is more difficult. Now Sanity does have an entire learn section, but it's still quite a difficult tool to learn if you're not used to kind of like the paradigms of how a headless content management system works.

So what I would say is our personal preference is always a code-based CMS, but it is very important to know the differences here, which is that if you have a GUI based, there are going to be more agencies that can work with a GUI based CMS or a GUI based content modeling system. But it ultimately will be worse when you get to the point of "I can't do this anymore" or "I can't do this particular functionality because it's limited by the CMS itself," whereas something like Sanity, and by proxy I think Payload is similar, you will get to the point where it doesn't matter how complicated it is, it can be built. It's just a case of time and money that needs to be used to be able to build the thing.

And so you can see this here, nice and simple, but if you can read this and it reads kind of like traditional JSON, then you can basically build anything. And there is some really clever stuff that's in here. So there is things like AI automation in here because we don't actually want to write our FAQ questions every single time when we build a blog. We would much rather just take the entire content of the blog and generate the FAQs.

But the best thing to do if you were trying to weigh up the difference between what is a GUI based CMS versus a code-based CMS is just run the default templates from both, so from Sanity and from Dato and from any other tool that you're looking to potentially use, and see how they feel, and whichever one feels the best, go for that one. It's as simple as that.

But the other side of this is think also about how you're going to scale your website because if you want to be able to scale something that's like 10,000 pages with a lot of nuances, you probably won't be able to do it as well with a GUI based CMS.

I don't know anybody or I haven't seen too much talk about people coining the terms GUI based CMS and code-based CMS, and I don't see it thrown around a lot, but it's actually the core thing that changes how you build your website. So pay attention to it, and if you have any questions just send us a message over. Cheers. Take care. Bye.

## Frequently asked questions

### What's the difference between a code-based and GUI-based CMS?

A GUI-based CMS (Dato, Contentful, Storyblok) builds content models with drag-and-drop fields in an admin UI. A code-based CMS (Sanity, Payload) defines those models in JavaScript or TypeScript files in your repo. The trade-off is straightforward. GUI is easier to learn; code lets you do anything you want with custom fields, validation, and components.

### What is a code-based CMS?

A code-based CMS defines its schema, validation, and custom fields in source code rather than through a web UI. Sanity and Payload are the two main examples. Because the schema lives in code, you can drop in custom React components, write arbitrary validation, and reuse fields the way you'd reuse functions in a normal application.

### What is a GUI-based CMS?

A GUI-based CMS (Dato, Contentful, Storyblok, and most of the market) has you build content models by dragging fields into a form-builder inside the admin UI. It's faster to onboard non-developers, but the level of customization is capped at whatever the vendor exposes through that UI, especially around validation and custom field types.

### Sanity vs Dato, which is better?

Both are solid headless CMSs, and Dato's marketing template and Sanity's Turbo Start template can produce visually similar sites. The choice comes down to how custom you need to go. Dato is faster for straightforward content models; Sanity wins as soon as you need custom fields (like an OG image generator), regex-style validation, or AI-driven automations baked into the studio.

### Sanity vs Contentful, which should I choose?

Contentful is GUI-based, Sanity is code-based. Contentful is the safer pick if your team has more content editors than developers and you want a settled, well-documented CMS. Sanity is the right call if developer flexibility matters; custom inputs, AI workflows, or anything beyond the standard set of fields will be easier to build there.

### What is content velocity?

Content velocity is how fast a team can ship new content; write, publish, iterate. The argument for code-based CMSs is that the studio compounds. Each custom field (an automatic OG image, an AI-generated FAQ block, a structured author profile) shaves time off every future post, and those wins keep adding up across the year.

### Is Payload similar to Sanity?

Yes. Payload is also code-based, with schema defined in TypeScript files. The video calls out that Payload "copied Sanity's homework" in a good way. If you've decided you want a code-based CMS but Sanity's hosting model isn't a fit, Payload is the closest equivalent.

### How do I choose between a code-based and GUI-based CMS?

Spin up the default starter template from each candidate (Sanity's Turbo Start, Dato's marketing template, etc.), spend half a day in each, and pick whichever editing experience feels best. Also factor in scale; at 10,000+ pages with nuanced content models, a code-based CMS holds up better than a GUI-based one.

---

## Vercel Ship AI overview


> They announced a lot at Vercel Ship AI. Our video rundown covers which releases matter, what AI SDK 6 changes, and what we would start building with first.

**Published:** 2025-11-10 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=ks5A5ji1N_s

---

## Transcript

Hey, how's it going? Hope you're having a great day. Um, I want to talk very quickly about this list. This is the AI ship releases and I very specifically want to go through everything as a whistle stop tour and just tell you a little bit about it because I think it's important.

Um, AI SDK number one. Uh, the AI SDK is basically an easy way to be able to talk with AI models through using TypeScript. That's that's basically it. Okay. Um, now there is a beta that's just come out and this does a whole bunch more to be able to stop things from like toolings from running on forever. But the main thing here is that you should have a go with just playing with it. It's really, really cool. It's really powerful.

Number two is the Vercel marketplace. And the Vercel marketplace, you might be thinking, hold up, this is this has been around for a while. Um, that is correct. So, there used to be the ability, well, I say used to be, there still is the ability to be able to just install a database, something like Neon or Upstash or any of these tools, um, by pressing a button. Well, one of the things that's kind of interesting, it's a bit of a paradigm shift, is we're seeing more and more kind of very specific niche AI models. Um, and as you can see, one of the big things here is that Vercel is thinking about the same process of where you just press one button and you immediately get that AI model or that AI tooling or potentially any number of things that might work with the AI SDK by just pressing a button. It means you spend less time on infra and more time actually building the thing you want to build.

Um, number three, and this is the sleeper hit, this is our favorite inhouse is the whole idea of workflow. You're going to hear the word durability thrown about a whole bunch. Um, what durability basically is is it's a way to be able to do something over a long period of time and it reliably work. Um, it doesn't have to necessarily be a long period of time, but even with things like flaky models or failovers, sorry. Um, that's the kind of thing that workflow does. So, it sits on one side and it basically goes step one, has it been completed? Cool. Step one completed. Step two, has it been completed? No, it failed. Okay, let me retry it. Step three, well, we don't do step three until a week's time. So, wait a week, then do step three. That's what workflows does.

Now, if you're a developer, this is a nightmare. It takes a long, long time, and you have to do things like cron jobs, and you have to hope to god that things don't break. Um, but this is now so much simpler and amazing for teams like to be able to do some incredible stuff. Um, maybe even just being kickstarted from a form.

Number four, Vercel agent. So this one's interesting and this one's actually solved a couple of bugs inhouse already from us. So Vercel agent basically sits on top of the observability layer and rather than you having to manually go through and go oh you know what happened at this 500 error how many people did it happen to what was the cause where did that come from is it a vendor yada yada yada Vercel agent basically tells you and it's pretty accurate we've we've seen it kick off about six or seven times and every single time it got the answer the cause of what caused the issue. Um, so really really cool tool. Just enable it. It's it's really cheap for what it does. If you compare this to certain people, data dog, um, it's it's really good.

So number five is Vercel for Python. So for the three developers out there that still use Python, really really good tool. So feel free to use that.

Number six, um, an agent on every desk. Okay, this is this one. This one this is a thinly veiled marketing ploy. So definitely click that one. Definitely click on the uh the contact us form. No, I think it's a really good thing. So, basically, Vercel is trying to encourage people to build agents inhouse and I can see this being a very very defining thing between kind of mediocre agencies or mediocre uh companies where they don't really touch AI. They don't use it in any internal workflows and they fall behind. Um and so, you know, they're telling you this and then they're giving you these on seven and eight.

So, seven and eight. Seven is a lead agent. So, it's a way of being able to take things like forms and then enrich them with AI doing R&D in the background. Um, and there was a great example saying it takes about 15 minutes to do this each time. Can you imagine how much time you're going to save where if an AI goes off and does all of this and it's already there, you can just literally run it with one button. Um, this does it where it can integrate into your forms and research that information.

And then finally is the uh data analyst agent. And this one is also very cool because you can throw this in Slack and you can actually start using it like oh uh out of interest how many people came to the website last month? How many of those people converted? What did they convert from? Which pages did they go to? You know all these kind of questions. Um and it will create the SQL to read your data warehouses and things like that to get that information.

Um I hope this all helped. I'd love to hear what you're building at the moment. Get in touch. Thanks a lot. Take care. Bye-bye.

## Frequently asked questions

### What was released in Vercel Ship AI?

Eight things worth knowing about. The AI SDK (TypeScript-first way to talk to AI models), an expanded Vercel marketplace for one-click AI tooling, the Workflow SDK for durable multi-step processes, the Vercel Agent for observability and incident debugging, Vercel for Python, a "build agents inhouse" initiative, a Lead Agent for form enrichment, and a Data Analyst Agent that writes SQL against your data warehouse from plain-English questions in Slack.

### What is the Vercel AI SDK?

A TypeScript library that gives you a clean, unified interface for talking to AI models. The beta at the time of recording added controls to stop tool calls running indefinitely. The main pitch is simplicity, swap models without rewriting your integration.

### What is the Vercel Workflow SDK?

A tool for building durable, multi-step processes in TypeScript. Each step is retried automatically on failure, and a workflow can pause and resume after days or weeks without keeping a server running. Useful for anything where reliability matters more than speed: lead enrichment, onboarding sequences, long-running research tasks.

### What is the Vercel Agent?

An AI layer on top of Vercel's observability tools. Instead of manually sifting through logs after a 500 error, the Vercel Agent diagnoses the cause for you. Based on internal usage at the time of the video, it correctly identified the root cause every time it fired, covering about six or seven incidents.

### What is the Vercel Lead Agent?

An open-source reference implementation that enriches inbound leads. A contact form submission triggers a workflow that researches the company, then surfaces a summary (company size, intent, and other details) so you're not doing that manually for every inquiry. Vercel estimates it saves around 15 minutes per lead.

### What is the Vercel Data Analyst Agent?

An agent you can drop into Slack that answers plain-English questions about your data. Ask it how many people visited last month or what pages drove conversions, and it writes and runs the SQL against your data warehouse. Useful for teams that need quick data access without waiting on a data analyst or writing queries themselves.

---

## Sanity presentation in action


> Trying to get an idea of how it actually feels to edit something in Sanity's Presentation mode? Here's how we edit pages on our own site in real time.

**Published:** 2025-09-22 | **Updated:** 2026-08-11 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=SuEY5VHpI0g

---

## Transcript

Hello. Hello. So this is an example of a working preview and how we use it at Roboto Studio. So this is my Sanity Studio opened. I'll show you very quickly how we change the title. So example title, take that, we love building with on the left. What you're seeing is called live preview. This is the presentation mode. And this is literally how long it takes for me to edit live content on my website. I'll show you another example. Example description. Pay attention on the left. How cool is that?

## Frequently asked questions

### What is Sanity Presentation mode?

Presentation is Sanity's split-screen editing surface. You see your live website on one side and the document fields on the other. Editing a field updates the rendered page in real time, so you can write and lay out content with the page in front of you instead of toggling between tabs.

### How does Sanity live preview work?

Live preview streams document changes from Sanity to the rendered page as you type, so the title, description, and other fields update immediately on the right-hand side of the studio without needing to publish or refresh. It works because Sanity ships drafts in real time over the same channel that powers Studio.

### What is visual editing in Sanity?

Visual editing means editors interact with the rendered page itself. Clicking on a heading, paragraph, or image jumps you to the matching field in the studio. Combined with live preview, it makes the editing experience feel closer to a page builder while keeping the underlying content structured.

### Does Sanity have a visual editor?

Yes. Presentation mode is Sanity's visual editor. It pairs the structured document fields with a live preview of the front end, and lets editors click elements on the page to jump to their fields. It's available in Sanity Studio v3 and later when Presentation is configured in the studio.

### Which CMS offers a visual editing experience?

Several do. Sanity (Presentation mode), Storyblok, and Builder.io are the most-cited examples. Sanity's version is notable because the underlying content model stays fully structured: you get visual editing without giving up clean, queryable JSON for your front end.

### How fast is Sanity's live preview?

Edits show up on the rendered page essentially as fast as you can type. There's no publish step or rebuild between the field and the preview. That's the experience the demo in the video shows; it feels closer to editing a Google Doc than a traditional CMS preview.

---

## Sanity pricing plans compared - Free, Growth, or Enterprise?


> Trying to choose between Sanity’s Free, Growth, and Enterprise plans? Here's which one you need and when to jump to enterprise. We give you a whistle-stop tour of what the plans give you, and what…

**Published:** 2025-09-17 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=2-vlAoEhzX0

---

## Transcript

Hey, how's it going? So let's do a quick video on which pricing tier is right for you with Sanity. I'm going to talk about free, growth, and enterprise. Probably roughly about the same equal time. So let's start with free.

First of all, free is probably the most generous free tier we've ever seen on anything, probably paired with Vercel. I think both of those are hand in hand for great free tiers. Um, the one thing that you're probably going to miss out on with the free tier is the scheduling, which is called content releases. Um, the comments and tasks and the AI assist. Now, I personally really, really like the AI assist. Um, also there is something that we'll talk a little bit about for those more technical people out there that are thinking of chatbots and AI. You also miss out on the embeddings index, which actually is very, very worthwhile. Just people don't know how to use it properly. Um, but yeah, again, so free tier, very, very good. If you're a business that's coming into this, just do yourself a favor. Pay the $15 a month per seat per month. Um, but yeah, I'm going to show you that.

So let's move on to the growth tier because the free tier is just essentially great, but with caveats. The growth tier is where you are really starting to get something good from it. So you get a lot more permission roles. So where a permission role actually comes into its own is the ability to say this user can read this, this user can't read this, this user can publish. That's the idea of a permission role. Um, up to 50 user seats, that's a lot of users. But again, every single user is $15 a month. So if you're getting towards the top of those user seats, I would say that's probably a good time to go speak with Sanity about the enterprise group.

Um, and again the two data sets, private or public. So now you're actually getting a private data set, which is useful because if you don't want to show people, for example, all the data from your actual database, that's really helpful. Um, it's especially helpful when you have like an authenticated part of the website. That's where that really comes into its own. Um, you do have pay as you go. So one thing that's really nice about this is you'll notice it's kind of like a whole ensemble of different bits and pieces that you can just keep chipping in and adding on to.

Um, and especially this is where we would kind of talk about the enterprise and when you should do it. Um, my rule of thumb advice is if you choose a couple of these on the more expensive end. So for example, SSO and dedicated support. So dedicated support is a bit of an interesting one. If you haven't used it before as part of an enterprise, or an enterprise plan, not all dedicated support is the same. Now, I swear by the dedicated support on Sanity's side and I swear by the dedicated support on Vercel's side. Um, both of those teams are absolutely phenomenal.

Um, so again, this is actually in my opinion a pretty good deal if you're looking to grow and you essentially don't want to get another developer, but you want somebody that is going to give you a very, very good, um, kind of like here's an example of this, here's an example of that. You want to take this example and utilize it. It probably cuts down on a good few days worth of development time. So depending on how much you're paying developers, it's probably valuable to get dedicated support. But again, um, this can all be added onto the growth plan rather than getting enterprise. But there is a certain point where you have like two, maybe three big ticket items, and then that's the time that I would definitely get in touch at that point.

Um, increase quote is very, very nice. If you want my honest opinion, you shouldn't really be hitting it unless you're like really, really killing it, like you know, uh, what's it called? Morning Brew or like BBC News or something like that. That's only the point of where you would probably get this add-on realistically. Um, one thing to be aware of, people do set up Sanity projects wrong and do blow through quotas. So it is a thing that we've seen a lot of times with different clients. So definitely if you're suddenly blowing through the 500k, I think it is quota, um, there's something pretty wrong. You probably want to get in touch with us or somebody else pretty quick.

Um, and again, seats availability, we can keep going up. There's a really nice effect, by the way, when you're looking through the pricing here. You can see this kind of cool cursor effect. It's nice, nice touch, whoever built that. And especially when it transitions from like blue to orange. Very nice.

Um, but yeah, and again, the thing to pay attention to here, this is the bit that's kind of like a sleeper hit inside of this is the API CDN request. So again, 250k if you're using the API requests or a million of them if you're on the API CDN requests. A lot of the times, depending on what you actually need and depending on how fast you need it, a lot of the times the API CDN request will be more than enough for what you need. So if you are finding you're getting close to the overages on 250k, it's pretty smart move to swap to the API CDN requests. That's something we've done a couple of times as well.

Um, one thing to pay attention to as well that not everybody knows what this is. This is the live content connections or the live content API connections. Um, what it means is if there is a thousand people on the same page at once and you update the data, um, the thousand people within this will see that without it actually refreshing. So instead of having to refresh the page and see the update, um, if you have a lot of people, say for example, you know, like Louis Vuitton's releasing a new bag or whatever, right? They all, everybody's piling into the website, um, there's 10,000 people on the website and somebody changes the stock from in stock to out of stock. 1,000 of those people will get that update and see the page just go from normal stock to out of stock. Um, but the other remaining 9,000 will not see it unless they refresh the page. The first thousand will obviously see the page just update like that. It's pretty cool if you haven't seen it.

So again, we will talk more about this live content API because I think it's the most important thing Sanity offers, but it's the most boring sounding offering there is if you don't know what it actually does. It's really, really powerful.

Um, and again all the free hosting. So one thing that I would always recommend and we'll talk more about this at a later date, always go for a mono repo. So when we say free hosting, we always recommend running Sanity through, you know, robotto.sanity.studio rather than robotto.com/cms or something along those lines because the performance isn't perfect in my opinion. It's quite slowish in comparison to actually just hosting it straight through Sanity and just hands off, don't need to think about it. Works beautifully. Um, same principle here. So live preview, visual editing, you just get this on every single one which is helpful.

Um, but the real, the real interesting stuff comes from the AI assist. So I'll tell you where AI assist comes in handy. One of the perfect examples of it is if you have an internationalized website and you have an English page and you have a German page. Now, I can't speak German very well, but I would very much like it if an AI could come across and do the best first draft imaginable from the English version. And that's exactly what Sanity's AI assist can actually do. So it can do generations of like translations. Um, we also use it internally at the moment to do our FAQs. So when we write a blog, uh, you always get to the FAQ section at the bottom which is very, very important for like SEO and things like that. And I've already got a giant blog full of content. Why don't I just generate the FAQs? And so you can use the AI assist to do that. Um, there's lots of like tiny little time savers which kind of add up to a much better editorial experience and that's what we focus on.

Um, but yeah, that's one of them. And again, these review changes. So you can see it's got a 90-day retention on the review changes of drafts. Um, and yeah, essentially when you start getting down to this area, this is very, very enterprise. So all the stuff that you expect from enterprise.

Um, and this one's kind of cool at the moment. So if you haven't seen this one before, functions invocations is the new Sanity functions functionality. Um, and so essentially what that does is in our case we actually use this for um creating redirects. So for example you make a change to a page, you change the URL from page A to page B. Um, what would happen in the traditional sense is people would go to page A and obviously the page is moved. So you want to have a redirect from page A to page B. Now if you change the name from page B to page C, you're going to want a redirect from page A, page B to page C. Um, that's all possible with functions. And again, these function invocations are very, very generous. Um, we don't hit anywhere near the 500k mark. Um, unless obviously you set something up incorrectly by accident, and it does happen to the best of us.

Um, and one of the things that's worth noting is this difference between media browser plugins and media library plugins. Um, so this media library is very focused on like a multi-website or a multi-app setup. So for example, if you have a set of images, um, again going back to one of the examples like Morning Brew. Um, you have images that you want to share between your website, your web app, your application, uh, maybe an email campaign, all of those things combined from the same Sanity media library. That's what this is. This is a great way of handling content between all of those different disparate systems. But again, it is an enterprise add-on.

And again, the open source editor built with React, all this stuff is awesome. You get it on every single package. Um, and the image pipelines are fantastic. So we use them a lot to be able to deliver things. Uh, the main reason why you would actually want the image pipeline is um because you don't want to have to spend a bunch of time going, "Oh, I've just uploaded a three megabyte PNG. I need to go to that optimization tool, optimize the three megabyte PNG, put it back in here, re-upload it as a, you know, like a WebP or an AVIF file, and then hopefully it all works." No, you don't want to do any of that. You just want to upload the image at its source value, and then just get all the automation and get all of those optimized images just by default. Um, that's what you can do with this, and it's very, very impressive.

And again, these are all the security and compliance stuff at the bottom. So, um, this is a complete snoozefest, but infosec people will be frothing at the mouth over this stuff. Um, so make sure you've got everything correct in here. This is mostly for your enterprise again. Um, and all these different things at the bottom. Again, uh, all enterprise.

Uh, but there is a hell of a lot that's already in the growth plan and the free plan. So I hope that helps. And if you have any particular questions about anything that's on this pricing list, we have a ton of experience in using all of it. So feel free to ping me, drop a comment below, and I'll try and get back as fast as possible. Thanks for listening, and take care. Bye.

## Frequently asked questions

### How much does Sanity CMS cost?

Sanity has three tiers, Free, Growth, and Enterprise. The Free plan covers a lot of small projects and prototypes. Growth starts at $15 per seat per month and adds permission roles, scheduling, AI Assist, and a private dataset. Enterprise is custom-priced and aimed at larger teams that need SSO, dedicated support, and add-ons like the media library.

### Is Sanity's free plan good enough?

For most prototypes and small sites, yes. It's one of the most generous free tiers in the CMS market alongside Vercel. The main things you give up are content releases (scheduling), comments and tasks, AI Assist, and the embeddings index. If you're running a real business on it, the $15-per-seat Growth plan is a small upgrade for what you get.

### What's the difference between Sanity Free, Growth, and Enterprise?

Free is the entry tier with the core editor and APIs but no scheduling, AI Assist, or fine-grained roles. Growth adds permission roles, up to 50 seats, a private dataset, AI Assist, and pay-as-you-go add-ons at $15 per seat per month. Enterprise unlocks SSO, dedicated support, the media library across multiple apps, higher quotas, and the security and compliance suite.

### When should I upgrade to Sanity Enterprise?

When two or three of the bigger Growth add-ons start stacking up, typically SSO, dedicated support, and a meaningfully higher quota. Hitting more than around 50 seats is another sign. Sanity's dedicated support is genuinely useful and can save you days of developer time, so it often pays for itself once you're at that scale.

### What is Sanity AI Assist?

AI Assist is Sanity's editor-side AI. It can draft translations between locales, generate FAQ blocks for long-form content, and otherwise speed up small editorial tasks inside the studio. It's only available from the Growth plan up, and it sits inside the editing UI rather than running as a separate tool.

### What is the Sanity Live Content API?

The Live Content API streams content updates to live visitors without a refresh. If 10,000 people are on a page and an editor flips a stock badge from in-stock to out-of-stock, the connected visitors see the change instantly. The number of concurrent live connections is gated by your plan, which is why it shows up on the pricing page.

### What's the difference between Sanity API requests and API CDN requests?

API requests hit Sanity's origin and have a tighter monthly quota (250k on Growth at the time of recording). API CDN requests are cached and far more generous (around a million on Growth). If you're running close to the API request limit, switching reads to the CDN is usually the cheapest fix and is fast enough for most front-end use cases.

---

## The best Next.js cookie bar


> It's Inth and c15t, it's fast, it's open source, it's everything we could have dreamed of and more. Here's the best cookie bar for Next.js.

**Published:** 2025-07-18 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=Pot1e5CRtR4

---

## Transcript

Hey folks, how's it going? I want to do this video today because I really want to talk about this thing, uh, just over here. This is, uh, C-15T, and more specifically it's C-15T hosted on consent.io. Um, it's an incredible cookie bar. Um, I don't think most people know it even exists. I didn't know it existed, and I am so stoked to actually talk about it.

Um, so one of the first things that you'll notice is this is styled perfectly like the rest of the Robboto Studio website. It's fully, fully customizable. We're using Tailwind CSS to style this, but you can do whatever you want. If you want to use styled components, if you want to use Tailwind, whatever it is, it works great.

Soon as you see, uh, this load up, I'll show you how fast this thing is, by the way. So just with a refresh, obviously you probably want to do a full refresh. So feel free to go visit the website and see for yourself. Um, but you can see it's ludicrously fast. It loads up in like 100 milliseconds.

Um, talking about that, there is a website called cookiebench.com which tells you the best performing cookies and the worst performing cookies, which is the ones that we always have to implement and it drives us crazy because you hate going from like a 100 out of 100 on a performance score to dropping down to, like, literally in some cases, you know, 80, 70, just from the cookie banner. So really, really cool tool.

Um, so again, the hosting side of this is consent. Feel free to have a look over there. Look at that beautiful logo on the bottom as well. Um, but they're using, you can see how well they've actually customized this themselves. Totally different from what we're using.

Um, and again, C-15T, this is the coolest bit if you want my honest opinion. Um, the entire setup for our website was literally step one. We didn't need to do database migrations. We literally ran this tool and it did everything. The only thing that caught us out when we were building was we forgot to put the environmental variable in, which is, you know, everybody does it. Schoolboy error.

But we're using PMP. So feel free to use this with Turbo Start Sanity, Turbo Start Contempt, whatever tool you want to use. Obviously, they're the best tools, but feel free. Um, I just want to tell people about it. It's awesome. I haven't been sponsored to say this. I love it. Take care. Have a great day.

## Frequently asked questions

### What is c15t?

c15t is an open-source cookie consent and banner library for modern web apps. It ships with sensible styling defaults but is fully customizable, so you can use Tailwind, styled-components, or your own setup. Inth (https://inth.com/) is the hosted version of c15t, which is the easiest way to use it in production.

### What is the best cookie banner for Next.js?

c15t hosted on Inth is the recommendation here. It's open source, loads in roughly 100ms, integrates as a single setup step (no database migrations), and matches whatever styling system your Next.js app already uses. Performance is what sets it apart: most cookie banners noticeably tank Lighthouse scores, and this one barely moves the needle.

### What is Inth?

Inth (https://inth.com/) is the hosted product behind the c15t open-source library, previously known as consent.io. You get the same banner and consent flow without running the back end yourself. Connect it to your Next.js (or other) app, drop in an environment variable, and the banner is live. The styling is fully customizable so it doesn't look like an off-the-shelf widget.

### Is c15t open source?

Yes. c15t is open source, and Inth is the hosted commercial offering built on top of it. You can self-host the open-source library or pay for the managed version, depending on whether you want to run the consent storage and dashboard yourself.

### How fast is the c15t cookie banner?

Around 100 milliseconds to render, based on the demo in the video. That matters because most cookie banners are responsible for noticeable performance drops; going from a Lighthouse score of 100 to 70-80 just because of the banner is common. c15t is designed to avoid that, which is why cookiebench.com is a useful place to compare options.

### How do you add a cookie banner to a Next.js app?

With c15t and Inth it's a single install step plus an environment variable. There are no database migrations to run, and the library works out of the box with Tailwind, styled-components, or whatever else your project uses. The hardest part is remembering to set the environment variable, which is the one thing that tripped Roboto Studio up during their setup.

### Does c15t handle GDPR?

Yes. c15t is designed around modern consent requirements (GDPR, CCPA), and Inth stores the consent records on your behalf if you want a managed setup. You still need a cookie policy on your site, but the banner, opt-in/opt-out flow, and consent storage are what c15t handles for you.

---

## Vercel ship 2025: the good bits


> Another year, another set of features we are rapidly trying to keep up-to-date with. Vercel Ship 2025 is here, and there's a whole bunch of goodies that dropped that we specifically care about.

**Published:** 2025-06-26 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=GXHdNiYBgC0

---

## Transcript

Hey, how's it going? So we're looking very on brand today. We're going to talk about Vercel Ship. So first of all, I'm going to tell you a little bit about it and we're going to do a whistle stop tour through all the different features and all the things that more specifically we find interesting because a lot of our stuff is focused around websites, clients, all that good stuff.

Um, so first of all, Bot ID. This is kind of interesting to us in particular because Bot ID is an alternative to Google reCAPTCHA. And if you've ever used Google reCAPTCHA, you know it sucks. Um, Google reCAPTCHA is like one of the worst things and you've always experienced it where it's like click three buses or click some crosswalks or do this or do that just to be able to fill in a form, and then as soon as you have that, people just drop off completely. So this completely removes all of that. Um, this particular tool can sit on any kind of route or any kind of like function, and essentially check if there is a bot. And you can see there's a very simple version of the code here where it's saying: is it a bot? Check Bot ID. If it is a bot, access denied. If it isn't, then totally fine. Um, that's a really, really cool functionality. It's probably the most important thing, as far as we're concerned, that came out with Vercel Ship. And it gives you more granular control over using these things.

And let me bring you on to the next one. So we got a couple to get through today. Uh, the next one is concurrent builds. So if you haven't experienced this, great stuff. If you have, this is very, very powerful. So it is where you basically make a whole bunch of changes to a website. And say the website takes two minutes, three minutes to build. Um, the first website, you made the change, but then uh oh, I left in a typo. So now we have two changes that we need to put in. So I do another build, and while the first three minutes is still building, you have to then wait the three minutes for the first one to finish, and then a new build comes in and does another three minutes, and it's six minutes later and you've actually seen the typo change.

Um, this allows for on-demand concurrent builds, which basically means um you can essentially run two of them at the same time or three of them or four of them or five of them all the way up to 32 at once. Um, and it's on demand. So it's not that you have to pay for 32 different um environments or whatever build systems. You just basically have um, whenever you need it, an on-demand concurrent build. So it's pretty cool, and it's, you know, it's another step if you'll see this in all of these different ones. Um, it's another way that Vercel is doing something where it's not price gouging. It's actually very, very nice. Um, so yeah, let's move on to the next one.

Uh, AI gateway. So again, if you're building AI right now, this is going to be helpful for you. This particular one is more about making the entire development experience easier when you know model 1.32 is going to change to model 1.33, or you know you're using OpenAI and then all of a sudden the next one that's better is on Gemini, or you know whatever system you're going to be using with AI. It's the idea that it can flick between any of them, any different model, any different vendor, and you just have one particular hub.

Um, now I think the uh what is it, the AI SDK already is basically being used by the vast majority of AI companies out there, which is really, really cool. So if there is something where it's kind of um an AI (I don't want to say wrapper, I'm going to say wrapper) um on top of you know some functionality, let's say uh video captioning, anything like that. Um, this is really, really useful because all the time these models are changing, like literally on a weekly basis. And this just stops you from having to go out, find the API key, make all the changes, find all the nuances of the new changes. This is just, you know, you throw in a different URL, literally one line. Um, and it's fixed, and that's the new model running.

Um, rolling releases. Now, if you are looking at this, first of all, why are you watching this video? Because this is far too large for this video. But essentially, rolling releases is when you have a massive, massive company, and you basically want to roll out a certain amount of um the new deployment to see if things are broken. Um, it's really, really powerful because it means that you can, you know, uh say you make an absolute dud of a change and you push it to prod. Um, and all of a sudden the performance goes down to 20%. This is going to be able to warn you before you distribute it to 100% of your customers, and maybe you'll find out at like 5%, and you'll go uh oh, I need to roll that back instantly. Hit the button, all good. But it's really nice, really nice uh development experience again.

Um, and I want to talk a little bit about the firewall because the firewall keeps getting improved, and literally only today um I got challenged uh with it. Well, somebody got challenged on the website with a DDoS, um and basically 12 people got denied, which is great. So it's always running. It's always fantastic. And frankly, if you're setting it up just nice and native, the way that it's done through Vercel, it just works. I haven't had to think about any of this stuff. It just does everything it needs to do. And that's exactly what I want: more hands-off stuff.

And then the Vercel agent. So this ties in very, very nicely with the firewalls because Vercel agents are very, very neat in the way that you can basically debug a good chunk of what's wrong. So for example, if I pick this here, I can drag this bit, and I can say, you know, uh what's what's happened here? What can I do to improve it? Um, how do I stop this from happening in the future? This is a great way of using like uh LLMs to be able to do a lot of the, you know, kind of grunt work that you don't want to have to do, and the debugging work that you don't really want to have to do, and just make your websites more secure and better and nicer.

And then finally, we have micro frontends, that absolutely nobody knows what they do. Um, at some point somebody's going to find out why we've built microfrontends, but there's now microfrontend support, which is great.

So yeah, have a great day everybody. Bye-bye.

## Frequently asked questions

### What was announced at Vercel Ship 2025?

The standout launches were BotID (a reCAPTCHA alternative), Vercel AI Gateway (one endpoint for many AI models), on-demand concurrent builds (up to 32 in parallel), rolling releases, an upgraded Firewall, the Vercel Agent for incident debugging, and microfrontend support. The shape is consistent: most of these features remove a workflow tax rather than adding a new product.

### What is Vercel AI Gateway?

Vercel AI Gateway is a single endpoint that proxies requests to any AI model or provider. Switching from OpenAI to Anthropic to Gemini becomes a one-line change instead of swapping API keys, retrofitting auth, and rewriting client code. It pairs with the AI SDK, which already powers a lot of production AI apps, and is mostly aimed at teams that wrap LLMs in their own products.

### What is Vercel BotID?

BotID is Vercel's bot detection product. You call `checkBotId()` from a route or function, and if the request is a bot you deny it. There's no captcha, no "click all the crosswalks" puzzle, just a yes/no decision the platform makes for you. It can sit on any route, not just forms, which is what makes it more flexible than something like reCAPTCHA.

### Is BotID a reCAPTCHA alternative?

Yes. BotID is positioned as a reCAPTCHA replacement. The selling point is the user experience: reCAPTCHA's puzzles cause real form drop-off, and BotID handles bot detection silently in the background instead. Because it's part of Vercel's platform, it can run on any route or function rather than only on forms.

### What are Vercel concurrent builds?

Concurrent builds let multiple deployments build at the same time instead of queueing. Push a fix on top of a still-building deploy and it runs in parallel rather than waiting another three minutes. They're on-demand and scale up to 32 simultaneous builds, so you only pay for the parallelism you actually use.

### What are Vercel rolling releases?

Rolling releases gradually expose a new deployment to a percentage of traffic instead of flipping it to 100% in one go. If you ship a regression and performance tanks, you catch it at maybe 5% of traffic and roll back before it hits everyone. It's mainly aimed at large-scale production apps where a bad deploy is genuinely expensive.

### What is Vercel Agent?

Vercel Agent is an LLM-powered debugger built into the Vercel dashboard. You select a chunk of logs or traffic, ask what's going wrong and how to prevent it, and the agent walks you through diagnosis and fixes. It pairs especially well with the Firewall, since most of the "what is this attack pattern" grunt work moves off your plate.

### How does the Vercel Firewall work?

The Firewall ships native DDoS protection and challenge-based filtering on top of every Vercel project. It runs continuously in the background, blocks bad traffic without manual rules in the common case, and surfaces challenges in the dashboard. The Vercel Ship 2025 update tightened the integration with BotID and Vercel Agent so investigation and response are mostly hands-off.

---

## Optimizing usage on Vercel


> A Vercel community session where Jono answers live questions about optimizing usage: where the costs actually come from on Vercel, and the practical changes that keep image optimization, function invocations, and bandwidth spend under control.

**Published:** 2025-04-24 | **Updated:** 2026-08-11 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=V6Yd9wgY-uU

---

## Transcript

Hello. Welcome to this week's Vercel community live session. I'm Amy, I'm one of the community team here at Vercel and I'm going to be one of your moderators for today. If you don't see the chat, make sure you're signed in and click going on the event listing, and then you'll be able to see the chat. Before we begin, I just want to remind everyone of our community code of conduct. You can find that linked up above in the site nav and below in the site footer, and let's just continue to keep it a positive space for everyone so we can keep doing these events. If you feel comfortable sharing where you're listening from, you can let us know in the chat. We love to see where everyone is tuning in from. And of course, feel free to share any of your comments and questions. We'll save those and ask them at the end. And I'd like to hand it over to Archa.

Thanks, Amy. Hi, everyone. I'm Archa and I am part of the customer success team here at Vercel. I'm really excited to be here. It's an absolute pleasure to be part of this vibrant and growing community of developers, builders, and innovators. In my role, I'm here to ensure that you're getting the most value from Vercel, whether you are just starting out or already deploying at scale. I also want to give a quick shout out to our amazing community team. They are dedicated to supporting you with expert solutions and workarounds for any Vercel platform issues you might run into. Whether it is through personalised assistance or easy to access self-served content, they're always working to make your experience smoother and seamless. So, if you haven't already, I encourage you: get involved, ask questions, share your feedback, and connect with others. We are all here to grow together. Thank you so much for joining today's session.

All right, so super excited for this one. Joining us today is Jonathan Alford from Roboto Studio. He started the studio to cut through the noise of bloated agencies, focusing on speed, simplicity and modern web tech. His team builds top tier editorial experiences and was among the early adopters of AI tools like v0. Today he is diving into how they optimise their Vercel usage and workflows. So Jonathan, over to you.

Hey everybody, how's it going? So this is optimising usage on Vercel, and I want to talk to you about a couple of the different things that we do in house. And we'll start with the agenda. So first of all, let's kind of break this down into how we actually diagnose what's causing the overage, how we handle fetching, how we handle caching. When we talk about media, what do we actually do when we come to optimising it? And finally, we're going to use AI to essentially roll up everything we've learned today and put it into a set of actionable rules.

So, let's start from the first one, diagnosing. The first thing I'm going to talk about is observability. If you haven't used observability, it's an incredible tool, and you probably want to enable observability plus if you're on the enterprise package. Essentially you want to use it to tackle the low-hanging fruits. And let's talk about that. So if you're looking at this here, the first thing you want to notice is what can we actually tell from these graphs and what should we be looking at? And the first thing that stands out to me is the Vercel functions. So with the Vercel functions you see these gigantic spikes, and I see something that goes up to the very top, which is at 60%. So I know something is going wrong, and I know a lot of it is going wrong. I can also notice on the right hand side that there is a tremendous amount of consumed hours with very, very little saved hours. You will notice though, if you look very, very carefully at the bottom right one, progressively the saved has started kicking up, which is great news.

Anyway, so let's look at the first of those big spikes from the previous page. Now this is a particular slug that we can see has a tremendous number of invocations. So you can see all the ones below it. The highest one that's closest to it is 182K, whereas the actual top one itself is on 2.3 million. This should be ringing alarm bells. And as you can see, the further on we go down this, you can see that there is an error rate of 43.8%. The reason we have that error rate is because we've actually hit both the API usage of the external tool that's being used here, and by proxy, Vercel is getting basically error pages because of the way that this was initially built. So this is something that you need to fix fast, but also you need to work out where it's coming from and why it's happening.

And so with that I kind of want to talk about speed insights. And this comes back to the whole idea of how we actually optimise usage inside of Vercel. So the idea is that if you have an extremely performant website, chances are you use less data, and by proxy you're actually using far less of your, you know, your quota. So when we check speed insights, this is something that we always run on every single one of the websites or web applications when we first set up a Next environment. The reason being is because there's a generous amount of use inside of it. It takes one line to set up and it's very, very useful for breaking things down to see exactly what the problems are. So again, the thing that we're focusing on is the left hand side. We don't want to see the good scores. You know, it's nice to see the 98 out of 100, you know, give us a pat on the back. But the thing that we really want to pay attention to is the low scores. So, anything below 50 and anything between the 50 and 90 point is worth looking at. So, you usually pick the poorest, but we're going to go for the slightly better than that. So we're going for the middle one. We're going to go for blog.

Now, the way that we can read this, the way we can understand this, is by looking down the left hand side and essentially understanding which ones are the most problematic out of this. So first contentful paint's an interesting one. It can be a pain point because of the amount of data that's being fetched in the first instance of this, but it's not the worst. Let's just go from a very simple, you know, green, yellow, red perspective. Largest contentful paint is huge at 8 seconds. So there's definitely a big problem there. Interaction to next paint is pretty high still, but it's not, you know, enough to worry about. Cumulative layout shift shouldn't basically exist if we're using Next images and things like that correctly. And then again, first input delay is pretty poor and time to first byte is pretty poor. The one that concerns me the most on this is largest contentful paint, especially with it being a /blog route. The other thing to be aware of is the number of users that have actually looked at this. So if you look at the very bottom, that 368 with a little three dots next to it is the number of users that have essentially gone onto this page. And the one to the right of that is the performance of this page: 46. So with largest contentful paint, that probably means in this case, if we know it's on the /blog, there is a tremendous amount of data being loaded, and if there's a tremendous amount of data being loaded, the performance is terrible. So we want to optimise basically both of those things, the data and the performance. And so if you have something like a blog, the reason that this was happening is because there isn't pagination in place. So instead of, you know, loading a hundred or 200 or 300 blog posts, which is not a great experience and it's very slow, we can instead break it down and paginate those or do some sort of loading technique within that.

And now I want to talk about more of the bad actors. So far we've only really discussed good actors and the idea of looking at a website and understanding what is happening from the perspective of somebody wanting to use your website normally. But oftentimes it's actually not the normal usages that cause the problems, and I want to talk a little bit about DDoSing, you know, if there's a single IP or any of these sort of things that are in here. And I want to show you this. So this is the firewall inside of Vercel. I'm sure most people have actually seen this at some point, but I just want to very quickly talk about the idea, the whole DDoS mitigation and allowed requests. So you can see there's 1.4 million requests on this, and of those 1.4 million, 590 are DDoS mitigation. Now, with the number of users that are hitting this website, that's actually a pretty good score. However, there are times when you might catch one of these. You might catch where that red spike went up, because that red spike went on for probably, I think it was a half a day period. If that happens, that button at the top, the enable attack challenge mode, is a fantastic tool. Now we have enabled this before in the past and it immediately dropped basically all the DDoS attack straight away. The one thing to know about this though is the user experience isn't as good while it's on. So, you don't want to use it as a consistent fix. You want to use it as a temporary fix, and then you want to basically solve the issues that caused the usage to get blown out.

And so we'll talk a little bit about Vercel analytics when you want to actually track down what is happening. Now, this is a bit of an interesting tip, because not many people necessarily use it for this reason, but it is a very, very useful reason. And I want to show you two totally separate parts of the same list. So, this one on the left hand side is if you press the view all on the routes, and this is kind of like normal usage. I can see that the homepage has got quite a lot of people on it. This has some particular slug that has quite a lot of people on it. It has blogs, contacts, you know, all the usual things. And then on the right hand side we can see that events has two, and I've obviously scrolled down quite a way to see that all these routes are getting hit because they've only got like one or two visitors, but then I see, hold up, what is this "cy state", you know, what is "wait for delay"? These aren't pages, these are code, essentially, and I can see that somebody is trying to do some form of injection. So it's very helpful to know this, because I can see which routes they're hitting, what they're trying to ping, what they're trying to do, and essentially I can understand how people are trying to use our website in a, you know, in a bad actor way essentially.

And so with that being said, we've kind of talked about how we actually diagnose it. Let's talk about how we actually fetch the data and caching of that data, so we can kind of avoid these first problems from happening. So first of all I want to talk about parallel fetching, because parallel fetching happens quite a lot when you're building applications. There's a lot of times where you have data that you need for one part of the page and another part of the page, and you essentially do not want to go in a waterfall. So this is basically how you do it. This is the actual fetching itself. And what we can see here is that we have a posts promise, a users promise, a stats promise. These are three different data. They may be from the same data source, they may be from different data sources, but the most important thing here is that they all run parallel. So in other words, we don't have to wait for posts to finish for the users to start. We don't have to wait for the users to finish for the stats to start. It's very, very helpful, and it kind of ties in very nicely with how we actually handle this on the front end.

So on the front end, we're going to use multiple skeletal loaders for each component, and we're going to try and avoid this cumulative layout shift, because we're at the point now where cumulative layout shift shouldn't even be a thing. And very specifically I want to tell you a nice way of doing it with artificial intelligence. So you can see here we're using a little bit of Tailwind. If you haven't seen Tailwind before, this is essentially a set of columns. We have, sorry, two-thirds of columns on the left, one third of columns on the right, and you have all this information inside of it. And you can see how it's basically set up. Now we're using a suspense. So instead of having like a gigantic circle loader that sits in the centre of the screen, we want to have these skeletons that you've probably seen on, you know, Facebook and things like that, where they show some sort of gradient that's morphing to show that there is data being loaded in. Now at the time that all of these parallel data sets are, well, the data is coming in, we will load each individual section. So in other words, if posts come through first, we will load post section, or for example users, you will use users, and so you will actually get this essentially construct in real time on your page, and it's a very nice experience if done correctly.

I want to talk about the AI side. So the way that you would do this with AI that's really, really clever is you would basically feed in the real world posts that you get, maybe a screenshot, maybe the actual code of the posts, and you would basically just ask it to create a skeletal loadout with fixed widths and fixed heights. What this means is that when they're actually loading you get this nice gradient effect, and when the actual data actually is loaded and is put on the page there isn't any shifting. There's no cumulative layout shift. You just see the posts. And it's really, really nice when it's done properly.

And now I want to talk about try catch. So this is something that's really helpful if you are pulling data, and you should do this. This is a great experience for both developers and, essentially, debugging. So this is a generic type that is a way of being able to fetch data from somewhere and, essentially, if it fails, get an error back in an array. So essentially this is how it works. And you can see how it actually is implemented here. So you can see the post at the top with the post and the error, and you can see how it's awaiting the try catch. So it gets the post and it pulls the posts. Now this is a particular example inside of Sanity. We use a lot of Sanity to build websites and such, but this works for basically any type of data that you're pulling. And we have some examples at the end of specific ones for like page routes and things like that. And you can see how this actually returns a graceful error state. So you see here "could not load post", instead of getting just that giant full screen error, you know, 500, that scares clients basically. So if it works, you actually get this post display.

And now I want to talk a little bit about caching. Now we've talked about fetching, go to caching. This is an example of caching with something that has a lot of global calls to this particular data. So something like navigation, but like a significant mega nav. This is using the unstable cache with Next.js. You can see how essentially we have this data that's being pulled from a global navigation query, and inside of this we're essentially having the revalidation be for every hour. So at that hour point you're basically passing something on where it makes it faster. So rather than essentially waiting for this to be loaded on each page, which is very, very bad from a performance perspective and very bad from kind of like a usage perspective, this now will just be cached and it will keep rehitting it and rehitting it and rehitting it. Which is very useful, because ultimately it's the same thing that we've said all the way through: anytime you have good performance, chances are you have good optimised data usage.

And then finally, this one's a great one, and you can probably, you know, show your boss that you've built this, because you haven't. You've basically just turned on fluid compute, and the whole build process has probably got 100 milliseconds, 200 milliseconds faster. Fluid compute is fantastic for firing off all kinds of different bits and pieces. There's no negatives with the actual functionality as far as I'm concerned. It's literally just turn it on, it works, it's fantastic, and welcome to the future, you know? It's really, really cool.

Now we've talked about the data fetching and the caching. Let's talk about something that usually is the majority of data that comes from a website, which is media. So first of all, let's talk about images, because whenever we inherit one of these, any kind of project, usually this is the thing that people don't get correct. Next image is a fantastic tool and it does a lot of leg work for you, wherever you are pulling your images from. And very specifically I want to talk about this section. If you remember just one thing from this presentation, remember this one line of code. So line eight is the most important one. So where it says sizes, this is a perfect example of kind of a predefined image that you may want to use again and again. I've left out the props, but ultimately it's passing down data, and the sizes section is basically telling you how you want the image to be optimised. Now this is a little bit different from what you would usually read, but it's very, very similar to kind of Tailwind. If you've seen Tailwind before, it's basically saying that up until a 768 pixel screen, which just happens to be the Tailwind default for tablet, make the image 100% of the view width. It basically sits 100% the view width. And then after that point, after 768 pixels, what happens then? It goes to a maximum size of 512 pixels. Why is this important? Because essentially, if you are using a normal website or a web app, you typically only use half, roughly, of the container of what that image is in. So in other words, if you have a website, you have text on the left hand side, some rich text beneath it, some, you know, bullet points and things. And then usually it's a 50-50 split. On the right hand side, there's a nice image. And usually the container is somewhere between 1,024. You could bump this number up if it's a bit bigger than 1,024. If it's 1,200, you would change this to 600 pixels instead of 512. But ultimately you're getting a nice level of optimisation without scaling the image far bigger than it needs to be. You don't need a 4K image for 512 pixels by 512 pixels.

And then the other thing that's worth mentioning on here is lines six and seven. The reason why the width and height is so important in here, and the reason why we kind of got these fallbacks in place, is because that is the thing that dictates the size of the image. And that's important because of cumulative layout shift. Cumulative layout shift is, and I guarantee you've experienced this, when you go onto a website, you go to press something, and then ultimately the page loads a little bit more, and then you end up pressing an ad or something like that, and then you end up going to it, and it's just a horrible experience. It shifts the page about. We don't want that. So, if you don't know how to build these things, definitely just use this image. Tailor it to how you would use it and reuse it again and again, and you're going to leverage the best out of Next images.

And this is an actual global based one. So this is a Next config, rather than doing it on an image by image basis. So there are some circumstances where you might have, for example, an older client base that doesn't need, you know, super high DPI images. We can go with much lower. So the device sizes might actually be far smaller. Same principle: if you know that it's only going to be a mobile only application, you might want to just drop the device sizes to lower. The other thing that's inside of here is the formats, image/avif. If you find you are using a lot of your quota on images, then you can actually swap this and put AVIF, which will be essentially a better image format for optimisation. The only cost that comes into this is it will increase your build times, but that might be worth it, because it's always a balancing act. If one is better than the other, then switch around. And then finally, something for protection: make sure that you use path names. And you can see how there's this process.env.NEXT_PUBLIC_SANITY_PROJECT. Make sure you're putting UIDs within these path names within the remote patterns. The reason being is that if somebody wants to use this maliciously, they could optimise their entire image base if you don't put a UID in it and it happens to follow the same structure. So that's very important.

And let's talk about videos. So videos is kind of interesting too, because essentially there's one provider that I'm going to recommend, and I always say the same thing, although I have three on the next page. So I'm going to say just use Mux. Mux is a fantastic tool, because essentially, in the same way that we've just talked about images, where they deliver the most optimised image on every single screen size, Mux is basically the exact same thing but for videos. The thing is, you don't want to start messing around with video codecs, because it becomes an absolute nightmare and there's all kinds of different bits and pieces that go off. But I would always advise just use Mux if you want a first-party feeling experience with video. The option two: so, sometimes people already have buy-in in something like Wistia or Vimeo or any of these other different tools. You're probably going to need a third party player. Well, guess what? This is back to option three. We're going to have to use something like React Player, which is maintained by Mux. So, you can see where I'm going with this.

And I really want to talk about this very quickly. So, Mux is very, very good from an experience perspective. So rather than thinking of performance, the user experience is quite important with video, because if you use a video player, even if it loaded in a split second, it's probably not going to be a great experience if you can't, you know, unmute it, or you can't skip ahead by pressing tap twice, and you can't really scrub along the video playlist. So it's very important that you essentially think about the performance from an actual analytics perspective, or like a Lighthouse or web core vitals, but also from how your clients are going to interact with those videos. We actually built a version of Mux which was one that would essentially get 100 out of 100 on Google Lighthouse. But I will say, do not aim for Google Lighthouse 100 out of 100, as somebody that basically built their entire agency's website for 100 out of 100. So our team basically did everything we could to get that, and it ultimately was great, but the experience is not as good as what would have happened if we would have just focused on making sure that the videos felt nice, the images were crisp. There's a balancing act with everything.

And this kind of plays a little bit on it. I'm not going to spend too much time, but this is Dylan from Mux basically talking about this particular component that we built. And the main thing that you want to talk about here is that he was recommending we use lazy loading. But I want to focus very quickly on the Mux website. And if you get two seconds, go look at the Mux website. It feels lightning fast. You can click through all the different places. It feels really, really good. But if you run that on a Google Lighthouse score, the last time I checked, and sorry Mux if you're watching this, essentially it hit 60 out of 100, which shouldn't be a reason to be deterred from using Mux. It's actually just a case of emulated Lighthouse scores versus real-world performance scores. And that's very important to make that distinction. But yeah, again, very much focus on potentially using the lazy load player. Chances are you don't want to use our video player, for that exact reason. You're probably not trying to go for 100 out of 100 Lighthouse, just a great performing website.

So again, everything you've heard so far is great, but how can we actually do this without thinking too much about it? Because there is a lot of overhead to think about the performance, to think about the sizes of images, to think about all the things we've discussed. So I'm going to talk about using rules inside of AI. Now we have a heavy, heavy bias on using Cursor and v0. So I think those two tools are the best. However, Windsurf also has rules. VS Code has rules coming in, I think it's in beta right now. But the whole idea is that you want to be able to create consistent fetching patterns, you want to have consistent suspense patterns, and you want to be able to do as much as possible with, essentially, one-shotting it with AI. Something to know is, if you are going to build something and you are building a lot of pages or a lot of routes with AI, I would highly recommend making one very, very good page first. If you go and focus on making a good page first and then basically use that again to create more pages, it works far better than creating four pages with AI as a first go. The idea, you'll hear this come up again and again, it's the flywheel effect with AI. The more things that you feed into it for context, and the more kind of patterns you can pass to it, the better it performs.

And then finally, I want to talk about one thing that's very specific to Cursor, and you should definitely try out Cursor. We aren't getting paid for this. But if you start writing chats inside of Cursor, or you start essentially making changes inside of your codebase with Cursor and you're really happy with the results, there's something you can do by pressing /generate cursor rules. It's so important. It basically takes everything that you've spoken about contextually and it creates a rule that can be taken back into AI and create the same thing again, in theory. Obviously, there's still, you know, little bits and pieces that might not work and replicate, but it's pretty good.

And then finally, I want to talk about the pro tip that I don't think most people actually know. So, v0 is a fantastic learning tool. I would argue it's one of the best parts of v0. So anything that you've heard about today, so for example if we spoke about parallel routes, or if we spoke about, you know, different fetching patterns, v0 is incredible at creating like a minimum viable code base, essentially, to be able to create that thing. So it's really, really good. The other thing to do with it is to actually take your code from your website or your web application and paste it directly into v0, and then just ask it, how can I optimise this and what are the trade-offs? Because it's trained on Next.js and it's very, very focused, very close to the actual core subject. It's always going to have the best results for Next specific questions. So definitely use it. It's a great learning tool, and it's also very, very good for using your existing code and making it better.

And then finally, a couple of honourable mentions that I didn't get chance to really talk about. These are the three. So Turborepo: we swear by Turborepo. Everything we build is using Turborepo. It's a monorepo system. We actually use it for one of the things that we open sourced recently, which is called Turbo Start. There's no association, but it is great. But essentially it's a fantastic way of being able to make build systems where they can rely on certain repos within the same repo. So in other words, if you have a UI project that needs to be compiled before you can actually use it in the website, this is an ideal situation for it, because it's going to cache that build. So if you've built the UI and nothing has changed, instead of having to wait, I don't know, 30 seconds, a minute, it's just going to take the cache and it's going to immediately use that, instead of waiting that 30 seconds, 60 seconds for a rebuild. This compounds so fast, the larger the team you have.

The other one is Next third parties. So, I'm fairly certain a lot of people don't know this exists, and it's an amazing tool. It's the best way to get Google Tag Manager, Google Analytics, YouTube, Google Maps, all working with basically no configuration. All you've got to do is put the ID in and it'll just work perfectly. It's what we're using at the moment with GA4, and it's been flawless.

And then finally, Turbopack. So Turbopack's an interesting one. This is going to heavily influence the future of usage on your specific environment. What I would do right now is just test the Turbopack flag. If you're up to the latest Next.js, or relatively recent Next.js, test if Turbopack works for it. We actually have some projects that were from five, six years ago, and they worked first time with Turbopack, which was absolutely staggering. The main thing it does is make your builds faster. And very, very soon, I'm very excited to see when it comes out, it will be able to be run on Vercel as well, for basically 100% success rate for all projects. Currently it's something like 99. But when that happens, the build times are going to go down significantly, and by proxy your, you know, well, not the quotas are going to be reduced, but the actual usage of those quotas is going to be reduced significantly. So it's very good. And yeah, that's me done. So, if you have any questions, anything hardball, definitely throw it at us. We've seen a lot of different environments. We're more than happy to kind of talk about our experiences, but yeah, thanks for listening.

Hey. All right, we did have a few questions come up in the chat, so I'll get started with the first one. Should I use firewall rules to block crawler scraper traffic from wp-admin.php requests? That is a good question. So, I guess a WP admin PHP request, so they're essentially trying to find out if you have a WP admin. So, depending on what kind of environment you're running, if you have a WordPress headless environment, it shouldn't be essentially looking for that in the first place, because the whole purpose of it is essentially to try and brute force your admin panel for WordPress, most of the time, I would guess. So I would pretty much, yeah, just block it as far as I'm concerned. Just keep an eye out as to what the firewall is also looking for. Not firewall, sorry, the crawlers are also looking for. But as a general rule of thumb, that sounds like a bad actor.

Awesome. We have another question. Would you still recommend using Mux for background videos in a hero section, or is it more intended for a use case where you need player controls? That is a good question. So, I'll make sure that it's included on the presentation, I think it's included on the presentation. Essentially, if you're only using it for videos in the background and you don't want people to interact with it, and you're not too worried about compatibility, that is the point at which I would definitely use our version. So our version literally is a case of, it stripped everything out. There is player controls, but it's the native HTML player controls. But it also takes in, you know, like, you will have to make sure that you apply a plays inline, you'll have to make sure that it's autoplay, all that kind of stuff. That is a time when I would use it. The only time I would use a Mux player generally is when you are wanting somebody to interact with something. It might not be the best scenario for you in that particular way. So yeah, I would still use Mux. I would probably use our component in that circumstance, providing you're focusing on trying to get the best performance out of it, and there's no need to use it anywhere else on the website with an actual, you know, UI to change the player and things.

Another question in the chat related to optimising graphics. Does sizes in Next image affect the fetch dimensions of the image? The fetched dimensions. The way that it works is it basically provides a source set. So, for example, the source set is optimised for the screen sizes. So it provides, for example, 300 view width, 600 view width, I'm just going to go up in 300s, 900 view width, and so on and so forth. Essentially it provides, depending on your sizes, the best possible image optimisation to the maximum amount that you set. So, in other words, if you have a 4K screen, but you said the max size it ever gets is 512 pixels, when you get to a 4K screen, it'll still be a max of 512 pixels. If you're talking more so about aspect ratio, and changing the way that the aspect ratio works, it will take whatever is set as the width and height, unless you've not used width and height and you've used the fill instead, or you use an overriding class with CSS. Either way, I personally think with Next image you should just set it up with sizes, and spend so much time on the first version, like, think long and hard about how you should set it up. Unless the image wildly changes depending on screen resolutions and things, in which case then you do it on a case by case. Especially if you're building it in something like a page builder, then it's worth doing on a case by case.

Thanks Jono, thanks for breaking that down. We have another one. What's the difference between Next's unstable cache and React's use cache? So, Next unstable cache, as a general rule of thumb, it works a lot better for Next.js. It's Next.js's version and it has a lot more benefits than React cache. We actually have, if you check, I can't remember if it's in the presentation, if it's not I'm going to make sure I add it, we actually have a blog that we're going to put out that's exactly about that, and it shows you how to use the two of them side by side. So, in other words, here's the unstable cache, here's the React one. If you're using React, use the React cache. If you're using Next.js, definitely use the Next.js one, because it's going to perform better. And again, it's the whole something we always say about Next.js and Vercel in general: if you just want the best performance and you want the best experience and everything else, it's just using Next.js and Vercel. Like, don't overthink it too much. So, anytime something comes out like this, chances are the first party support is always going to be the best experience for the tool, if that makes sense.

That makes sense. We had one more question in the chat. Would you still use Turborepo even if you don't intend to add extra packages or apps to the repo? Yes. That's a hard question, by the way, because I don't understand the context of it, but I think I would use it anyway, because, for example, I'll tell you how ours works with Turbo Start, and this should give you some good context for it. So a lot of people do use it without having multiple packages, and they use it just on the root of a Next environment. However, with ours, we basically built it with Sanity, which isn't even like a Next.js tool, and Next.js inside of the same repo. And essentially it means that you are tightly pairing your data with your web, or the web front end. And so essentially I would advise using it that way anyway, because I personally think that if you ever do do it in the future, it's a lot less hassle than otherwise not using it. Worst case scenario, you can just strip it all out and just, you know, expand upwards the folders, and it's all done. But I would recommend using it. It's a great tool. And honestly, again, I haven't experienced them firsthand, I've never seen any downsides of running a monorepo ever, with Turborepo. Let me make sure that I emphasise that bit.

Yep, that was super helpful. A question that we keep getting from our customers, right, for folks trying to make sure their caching setup is actually working the way they want: what should they be looking out for? Is time to first byte a reliable signal? Do you know what, actually, I left this out of the presentation. I really wanted to include it, but I didn't want to take up too much time. But knowing how the Vercel cache hits work. So this is just from a page basis, right? Before we kind of talk more specifically, I'm going to assume that this is about pages and page performance rather than individual components and things like that. Essentially, if you're using a website, something that most people might not know is that you can go into the network tab, the one that is the name of the website. So in our case it would be robotostudio.com. You press in there, you press the one that's just the document, and you go and look for Vercel cache hit or miss, depending. That's one way of debugging it. I don't know whether everybody knows that, but I hope everybody can now know that thing.

But as far as time to first byte, one of the things that I think is great, and again, didn't have chance to put it in the presentation, is partial pre-rendering is wonderful. If you are using a Canary version of Next.js, I think it's only on Canary, you'll have to double check for that, make sure you enable it. So immediately your time to first byte will go down significantly. But the other question you should be asking yourself, if you are having issues with time to first byte, is how much data are you pulling in. So something that we know time and time again is that, say for example, a nice simple one, if you have a blog, you might pull a hundred blog posts in. That's going to be a horrible experience from a time to first byte, because you're having to pull that gigantic payload of all those different blogs, and it depends on what data you even have of those blogs. So it might not be just the slug, it might be the title, it might be the rich text that sits beneath it, and it might be a whole range of different content. So definitely look at what data you're using. So definitely look at like how the fetches are going, and read the actual payload of the fetch, and pay a lot of attention to that, but also simultaneously enable partial pre-rendering. If you do those two things, your time to first byte will go down to like in the double digits milliseconds. It's ridiculous. Oh, and of course, make sure that you're putting the service centres closest to your users. So, use a US data centre if it's a US company, that kind of thing. I hope that helps.

Definitely. And another question that we see a lot about caching is, what would be the difference between caching headers and ISR? Caching headers and ISR. So, it depends on how, am I still, I'm still here? Cool. So, sorry about that. Caching headers and ISR. So incremental static regeneration, as a general rule of thumb, is useful for when you have heavily nested websites. So I'll kind of explain that side more, because essentially, when you have something like a website where you have multiple authors, and those multiple authors have their own page, you have to think about how much changes on those websites. So for example, in that particular example, you may not need to actually refresh the entire website. You might not need a hundred pages rebuilding. You may only need three, for example. It might be that the actual page the article was on, you've added a new author, and that new author also needs its own index page. So page, author index page, and maybe an extra category that you've got. So realistically, instead of doing the whole caching through the headers and such, doing the incremental static regeneration is probably going to give you a significant amount more gains, because you're only actually rebuilding the things that you need. The trick in that one, that's the most difficult bit of all of this, is finding a clever way of invalidating the routes that need updating. So, for example, we're very kind of focused around Sanity. So in our case it's like, if an author changes name, that's something that would potentially cause a rebuild of those particular pages that that author sits on. But one thing to be aware of as well is, if you do this incorrectly, and you want to make sure that you don't do this, it's very easy to essentially have the, what's it called, the cache uncache thing. I forgot the name of it, but it's the one that's the caching in the quota. If you make a lot of changes and then make a lot of rebuilds and recaching, it's very easy to rack up a whole bunch of caching that way. So if you have a very constantly updating website, you may be better off doing certain things client side, if that makes sense.

Thank you for the details. I love that. Shifting the gears slightly, for teams keeping an eye on budget, what's the best way to monitor and stay in control of serverless costs on Vercel? Are there any dashboard tools or alerts that you would recommend setting up early on? That's a good question. We're actually investigating this as we speak, as to what the best solution is. So I don't want this to be the definitive solution by saying this. I would recommend Better Stack so far. You want to check the pricing page on Better Stack, so I don't get in trouble for saying this, but on the pricing page of Better Stack is the reason why we recommend Better Stack. But essentially that's a very, very good tool for monitoring things. They're all expensive, very, very expensive, but Better Stack seems to be the cheapest of the bunch, and also provides one of the best experiences of the bunch. However, we are going to probably put up a blog post at some point to tell you what our opinion is on this particular subject, but definitely check out Better Stack. It's been fantastic for us so far. And one of the big things that we've been using it for is if our forms essentially flop and don't send a form off to us, that's where it's really, really useful. The only thing I need to look into is, when I was looking at it last, you had to pay for first responders and you had to pay for a pricing tier, and I couldn't figure out a way to essentially not include first responders. So, it might get very pricey for larger teams where you have to have a lot of first responders, but it's pretty good from what we can tell so far.

All right, I want to ask just one last question, I want to be conscious of everyone's time, but if there was like one piece of advice that you want to give people about optimising their usage on Vercel, what do you think is the most important thing for them to focus on? That's a really hard question. I know. Okay, I'll tell you the one that comes up the most, that's the most expensive when people do it incorrectly, and you'll see it a lot: use clients. So, I haven't really talked about use clients the whole way through this, but use clients are the one to worry about. So, we don't recommend tools like Material UI, and the reason why we don't recommend them very often is because there's a lot of use clients. I'm not sure of the state of it nowadays, so it might be an unfair characterisation, but there's a lot of use clients. And when you have to use use clients, you have to wrap a lot of stuff in use clients, usually, in most circumstances. Now the problem is, if you accidentally wrap a fetch request or something like that, or a use effect that pulls data from somewhere, you shouldn't, again, you shouldn't really use effects to pull that data, but ultimately that is where you probably blow the most of the quota. That, combined with, oh, and as well, don't put things in the public folder that are huge. So like, don't put a 4 megabyte, 5 megabyte image in the public folder, because it's a world of pain. Put it in blob storage. It's nice and easy. But basically the public folder is there to just be very, very fast storage that doesn't keep very heavy things. So like favicons are a perfect example. So yeah, those two combined. So make sure you're always using client correctly. We always recommend Tailwind CSS with Next.js, just because it's so simple and it works perfectly and it scales beautifully. And we also recommend, well, avoid Material UI, and make sure your images are not inside of the public folder, or worse still, a video in the public folder. Make sure you're using something like, I think it's next/video, which is the Mux integration one. That one's awesome and very, very easy. It means you get the same experience, but you can just use videos. It's nice.

That is great advice. Thank you so much. You've got such good insights for everybody. I think this is going to be a valuable resource even as people watch it back. Thank you for being here. Thank you to everyone who watched and asked questions. I just want to remind everyone, we will be here again next week actually, talking with Mux about how to integrate video into your Vercel projects in more detail, and you can always check out upcoming events at community.vercel.com/events, and we look forward to seeing you again soon.

## Frequently asked questions

### How do I work out what's actually causing high usage on Vercel?

Start with observability (and observability plus if you're on enterprise) and go after the low-hanging fruit. Look for the big spikes in function invocations: in the session, one slug had 2.3 million invocations while the next highest was 182K, with a 43.8% error rate because an external API's limits had been hit. Pair that with speed insights, where you focus on the poor scores rather than the good ones, because a badly performing page usually means too much data being fetched.

### What's the single most important Next.js image setting for cutting image optimization costs?

The sizes prop on Next image. Jono's example is 100vw up to the 768px breakpoint, then a maximum of 512px, because most images sit in roughly half of a 1,024px container, and you don't need a 4K image for a 512px slot. Also set width and height (or fill) to kill cumulative layout shift, and put UIDs in your remotePatterns pathnames so nobody can maliciously optimize their entire image library through your quota.

### What should I use for video on a Vercel site?

Just use Mux. It does for video what Next image does for images, delivering the most optimized version per screen size, and messing around with video codecs yourself is an absolute nightmare. If you're locked into Wistia or Vimeo you'll need a third-party player like React Player, which is maintained by Mux anyway. For background hero videos with no interaction, a stripped-back native player (like the one Roboto built) makes more sense than the full Mux player.

### Should I chase a 100 out of 100 Lighthouse score?

No, and Jono says this as someone who built his agency's entire website for 100 out of 100. The team did everything to hit it and the experience would have been better if they'd just focused on videos feeling nice and images being crisp. The Mux website itself scores around 60 on Lighthouse but feels lightning fast in the real world, which shows the gap between emulated scores and real performance.

### When should I use ISR instead of caching headers?

ISR wins on heavily nested websites, where an author name change might only need three pages rebuilding rather than a hundred. You only rebuild what you need, and the hard part is finding a clever way of invalidating just the routes that changed. Be careful though: if the site updates constantly, all that revalidation can rack up its own caching costs, and you may be better off doing certain things client side.

### How can I check whether my Vercel caching is actually working?

Open the network tab, click the document request (the one named after your site), and look for the Vercel cache hit or miss header. For time to first byte, enable partial pre-rendering (on canary Next.js at the time of the session), which can drop TTFB into double-digit milliseconds, and read the actual payload of your fetches, because pulling a hundred full blog posts on one route will always be slow. Also make sure your servers are in the region closest to your users.

### What's the most expensive mistake people make with Vercel usage?

Misusing "use client". Wrapping fetch requests or data-pulling effects in client components is where most of the quota gets blown, which is part of why Roboto avoids recommending libraries like Material UI that push you towards lots of use clients (Tailwind with Next.js instead). The other one is dumping huge images or videos in the public folder; keep that for light things like favicons and put heavy media in blob storage or something like the Mux integration.

---

## Getting the most out of Turbo Start


> Rough cut process of building page builder blocks within Turbo Start Sanity. Watch the schema, queries, and components come together in real time.

**Published:** 2025-03-20 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=CNPjWyVQeC0

---

## Transcript

Hey, how's it going? So I want to do this very quick video because a lot of people have been asking me how to get the most out of Turbo, and I want to basically get right into it, talk about how we actually build websites and our development flow, and show you all the different ways that you can actually use this. But from the very start, I want to talk about how this is actually structured, why it's structured that way, and just go through a few things.

So first of all, you'll notice that we have this apps. This apps is because it's a monorepo, and you can see that we have a pnpm file. And if you press command P and you go look for some packages, you'll notice there's a hell of a lot of different packages in here. There is this main one that basically sits at the very top level. Very easy pitfall to do, but don't do this: installing things on the root. You don't want to do this because you don't need to have many packages in the root's package.json. You can see that they have very, very few inside of here. And the same applies here. So when it comes to actually building the user interface of this and using things from things like Shad CN UI, which I definitely recommend using, they're going to go into the packages UI package.json. That's where it goes in. So you can see already we have Radix, React accordions, and all this kind of good stuff.

And now with that being said, the majority of stuff you're probably going to install that's not related to Shad CN is going to be in package.json in the web folder. However, something that's kind of interesting about this: if you try installing Shad CN in the web folder, it'll automatically get extracted out into the UI part of the website, which is kind of cool. You have environmental examples inside of here, an environment file that gets generated when you first spin this up. But right now we're going to make sure we get started. So let's run prd. This is just the post install. So I'm using pnpm run. Make sure you're using pnpm. Let me get rid of that. Let's do that again.

So you should 100% use pnpm rather than npm because it's going to save you a whole bunch of data when you're actually using these tools, because we install a hell of a lot, you know, Next and Sanity in hundreds of projects. So yeah, here we go. Here's the first thing you'll probably see. And you can have this in dark mode, you can have this in light mode, all of this good stuff, or system. This is all just data that's taken from Faker and populated inside of here. So you can tweak all of this and change it however you want.

But realistically, what you want to be doing is building your first page builder block. Now today I'm only going to really focus on the page builder block side of things because that's kind of the most important. But ultimately we have this thing called page builder. You'll notice there's two files. One of them is the definitions inside of schema types. Always pay attention to this thing. You see where it says studio? So studio here, web here. The web and the general rule of thumb (although this is not always the perfect way of looking at it): most of the time .ts is going to be inside of the studio, so the Sanity Studio, and then the other times .tsx is going to be in the actual web side of the website, so the Next.js environment.

I'll give you an example here. So let's go to page builder. Let's see how this is actually built. Okay, cool. So this is essentially an array. It's going through the array and it's mapping each block to each member inside of that. So let's hit page builder blocks and see how that works. Cool, this is how we handle our page builder blocks and how we essentially assert them. So let's go click one of these. Let's go see hero, and here is a hero block.

Now one thing that we are going to do to improve Turbo start in the future is putting in some rules. I actually would recommend putting in these rules inside of Cursor. Sorry, not Sanity, inside of Cursor. So you can see if you go into, I believe it's rules inside of here, you can start creating project rules. We are going to include some project rules at a later date. But if you are trying to use as much as you can from today outside of Cursor, that's the way you do it.

With that being said, let's then move on to creating our first schema. And you can do a lot of the schema generation with AI, but I would highly recommend going through the Sanity learn. But for the time being, we're going to go for a brand new schema called example block. And all this is going to be is an image, a title, and a rich text, and I'll show you how that works.

So there is an extension that's quite useful called Sanity Snippets, I think. It just essentially allows you to put a Sanity schema in. So if I go (I've forgot the exact way that you do this now), essentially I'm going to go take it from another one because it's been too long since I've done this manually. These days I'm actually using AI a lot to be able to generate this stuff, which is pretty poor, but bear with me.

Example block. Let's put this in. So let's go create a schema that uses a title (because we always use titles as a title; if you keep standardizing the fields, always keep that in the back of your mind), rich text and an image, and we're going to hit enter. And this is going to generate the example block. I am using Claude 3.5 thinking. It's good, basically as good as the regular one. I just thought I'd see if it gets it right first time on this. And I'm using the agent. You can do this with command K as well, but this is just a nice, quick, easy way to do it.

And for most people that are watching this, I'm guessing a lot of developers these days are just actually blasting these things out with AI. I cannot tell you how important it is to not make a fool of yourself like myself where you try actually writing one of these things out manually and forgetting how you do it. So we'll see this. So create a new schema that uses this. So first mistake, and this is actually very helpful to use: instead of calling it example block, it's created a brand new block called content with image. So something to be aware of that AI does very often is it generates a hell of a lot of code, but it's very poor at removing that code. You can also see here: I'll get rid of this example block and we'll stick with what it's created, which is this content with image. You'll notice that we have this defined field. This is just Sanity and this is TypeScript, which is really helpful.

Something to know about the project as well: the whole project generates types for you. So as soon as we have included this within the index (and we will, we will also), let's see where this is getting pulled into. Yep, this is correct. So this is inside of the index. Let me double check that it's inside of the page builder. It will be, because that's where the blocks are coming from. So this is wonderful.

Now the next thing we want to do is we want to run pnpm run type. So pnpm run type. And what this will do: you will forget that it's not actually included. You can actually set this up so you can do it from the root directory, but I haven't inside of Turbo, so we will make sure that we get that soon. Again, I'm making sure that we hit all of these errors intentionally to try and provide some education with all of this, because it actually is worth knowing. And you can see that we had 45 schemas created, 45 schema types, and 13 GraphQL queries.

So if I flip back very quickly, you will now notice that if I go ahead and I build an equivalent block (so content with image), I'm going to go ahead and find another block that exists on this. So hero.tsx. You'll notice that they are always named the same thing: hero.tsx, hero.ts. So let's go here, and you'll notice it's in the sections. And what we're going to do, we're going to do a brand new file and we're going to call it the same as what we have: content with image.tsx.

Okay, now what we can do is we can go back to here, we can pop this in, and we can say: let's get content with image, let's pull both versions. So that version, this version, get rid of example block because we don't need it anymore. And say: I would like to create a basic block with content with image schema. And again, we can use other ones. So like one of the things that I would always recommend is very helpful is using another component to opinionated what this one's going to do. So can you use at hero.tsx to see how we handle images and rich text, etc.? So going to hit enter again, and you'll see this should hopefully populate this content with image. The one thing that might be interesting is whether it gets the type correct or not, because it's generated that type. But also the type generation file is absolutely massive. It looks like it did it correctly. Yep. You'll see that we now have this.

Now the thing is, we don't have this left right. So can you see we have this image position? But did it include that? Do we have a left right in here? Oh, we do have a left right. Okay, cool, so that's fine. Let's see what it's complaining about here. Ah, this image asset. That's interesting. Let's see what it does. I'm really curious as to whether it will fix it or not. So we can have a quick look on here as to how the Sanity hero image asset worked. So, image. Let's have a quick look. Hero page builder type hero. Let's see. Let's move back and see what's going on. Asset image. Where's the problem here? Property asset, which is declared on... okay, so let's go check this out. Let's go check what this might be getting caused by. I have a feeling this is to do with the query. So let's go check the queries out. And you'll notice there is an image fragment on here. Let's see if there's one for... let's stop this. Okay, we'll accept what it's got so far. That's fine. And we will look at the hero block.

So if we go to hero block inside of here, I notice that there is an image fragment and a rich text fragment. Now this is the way that we handle GraphQL. So if we go one below, we were going to say content with image block. Let's take that for now. And we want that. That's actually exactly what we want. So let's just finish that one off. Perfect. And then let's take this content with image block and pop that into the page builder, wherever that is. Is it down here? Yep, perfect.

Now if we pop back and we run this again (so let's run the pnpm run type), see if it breaks, and we'll go through if it breaks as well, because that'll be really helpful. This just means that everything that you're writing up is actually fully TypeScript. And you'll see: bada bing, bada boom, it just went green, which is great news. So that's worked, and it was all down to a couple different files: the query file with Sanity and making sure we're using these fragments.

The reason why these fragments are so useful is that at first it seems like a lot of fuss and a lot of hassle, but as the website scales and you have like 600, 700 pages, this is not a lot of hassle. What is a lot of hassle is trying to figure out why your queries are timing out because you're pulling so much data in one go. So I definitely recommend doing this. And as you can see, this is now all wired up.

Let's go on to Arc and let's go into localhost 3333, which is the Sanity environment. And inside of here we should give it a couple seconds. Oh, here we go. Let's log in. I'm really hoping it doesn't come up with an error. Okay, cool. So let's go to structure. Let's go to pages. We can do this through the actual presentation, but for example, let's take this page and let's hit the plus. What is this? Get rid of that. And let's do content with image. So this was it. So we know that if this works, this is actually working. So write "content with image". Content with image title, rich text. Let's choose an image from whatever's in the environment. Oh, that one's not so good. Let's pick one from Unsplash. Let's go for this nice coffee-looking thing. Let's wait for that to download, and then we're going to hit publish. And this should be lovely. A little bit of rich text to complement the block. Okay, hit publish. Ignore the low battery. Okay, and what we're going to do: we can open this. So we can actually go back, pages, go into here, and open it this way. Opening presentation should open straight away, and we'll see if it's in there.

Ooh, component not found with block type content with image. Now let's find out how we fix that. So remember how we had this page builder here? The problem is that we have another page builder here that we forgot to put it in. So if we pop down a level, you'll see that we have content image with block, or content with image block. And now we've added those two. So again, it's just literally the actual string and then this version that is the actual component itself. So in theory that should have just worked, and we'll see if it has. And there you go. That is a full Sanity block being built for a page builder from start to finish. It took us less than 15 minutes, which is great. But this is a very, very simple version. As your website scales, this will scale with it, and this will be very, very good for building these kind of websites. But this is the baseline for building these blocks and what you can essentially do with the project.

Yeah, have a great day. Take care. Bye-bye.

## Frequently asked questions

### What is Turbo Start?

Turbo Start is Roboto Studio's open-source Next.js + Sanity boilerplate, structured as a pnpm monorepo with separate apps for the Next.js website and the Sanity Studio. It's designed to give teams a working page builder, type generation, and a sensible starting structure on day one rather than wiring everything from scratch.

### How is Turbo Start structured?

Turbo Start is a pnpm monorepo with two main apps, `studio` for Sanity and `web` for Next.js, plus a shared UI package. Schema files live as `.ts` inside the studio, and matching React components live as `.tsx` inside the web app. The root `package.json` stays deliberately small so dependencies belong to the workspace that uses them.

### How do you add a new page builder block to Sanity in Turbo Start?

Create a schema definition in the studio app, register it inside the page builder array, run `pnpm run type` to regenerate the TypeScript types, then add a matching `.tsx` section component in the web app and wire it into the page builder block resolver. After that the editor can place the block from inside Sanity Studio.

### How do you create a Sanity schema?

A Sanity schema is a `defineType` object that lists fields like title, rich text, and image. In Turbo Start the schema lives next to its sibling components, you generate types from it with `pnpm run type`, and you reference it from the page builder index so it shows up as a block option in the studio.

### How does Sanity work with Next.js?

Sanity stores content and exposes it through GROQ queries; Next.js fetches that data and renders it server-side. In Turbo Start the two are split into a monorepo so you keep schema, type generation, and rendering in one repo while still deploying the studio and the website separately.

### Should I use pnpm with Turbo Start?

Yes. Turbo Start expects pnpm, and that's the reason the workspaces and dependency hoisting line up correctly. Using npm or yarn will produce duplicated installs and inconsistent lockfiles, which gets painful fast across many Sanity and Next.js projects.

### Why does Turbo Start use GROQ fragments for queries?

Fragments like `_image` and `_richText` keep blocks composable, so a hero block and a content-with-image block can share the same image query without duplicating fields. It feels overkill on a small site, but at 600 or 700 pages it's what stops your queries from timing out by over-fetching.

---

## Generating AI images inside of Sanity CMS


> Looking to use replicate directly inside of Sanity CMS? Well we've got just the plugin for you. You can download it here: https://www.npmjs.com/package/sanity-plugin-image-gen

**Published:** 2025-03-04 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=2v2Yge5-eLY

---

## Transcript

Hey folks, how's it going? We're back again. So, um, I just want to show you something very cool that we've built in-house and I'm fairly certain that a lot of people are going to get a lot of use out of this.

So if you notice, we have this new little thing inside of Sanity called Generate Image. Now, the reason why we built this is we kept going to Replicate, we kept taking the data from there, and we kept throwing it back into our blogs. And depending on how good you are at doing that, um, it can take anywhere between like 15 seconds to a minute, which is very, very, you know, frustrating over time, especially when you're trying to create something on the fly and you just don't want to lose that editorial flow.

So, um, this is a plugin that you can now add into Sanity and it runs using the Next.js API routes. Um, I'm going to show you that in a second. It's going to show you how to set it up. Um, and if you are interested in seeing a whole video about how to set this thing up, we're more than happy to do that as well. But first of all, let's get some cute kittens in here, right? Let's generate that. So I'm just typing in "cute kittens." I'm going to hit generate and there you go. Boom! That is from Replicate. They look a little bit unsettling. That's exactly what we want.

But um, we have this whole Advanced Options section and we can do a lot of clever stuff in here. Everything from changing, like, the aspect ratio to the image size, um, and to the number of kittens that you're going to get generated. So, um, and of course we can do things like negative prompts. So we could put "ugly kittens" in here as a negative prompt. But you'll see, nice, very, very cute, very nice.

Um, and you can essentially just click any of these. So if I like this one best, I can hit it. It's going to upload that data. It's going to tell me we've got low battery, which is always great. And there we go. We've got it. That's it working.

Um, so if you're interested in using this, it's actually available here, which is Sanity plugin image gen. Um, it's been published 13 days ago, but we've been kind of just tweaking around with it for the last second. Um, so feel free to run this. Tell me if you get against uh any snags or anything that's kind of difficult to work with.

Um, and again, this is all the configuration that's inside of here. How to actually get it running. It has things like type safety built in, so it should in theory just work and should make it a lot easier for you to get it working. Um, and again, this still needs the Replicate uh ID inside of here. So it needs an API key. Um, but ultimately, all of this should in theory just work and you can tweak it to exactly the way you want. If you want to use a specific image model, you can tweak that. If you want to use specific prompts that start at the beginning (I've seen people use things like with iPhone camera setting so it looks more realistic), all of that is possible with this tool.

So yeah, hope you like it. Tell me how you get on. Take care. Bye-bye.

## Frequently asked questions

### What is Replicate AI?

Replicate is a platform that lets you run open-source AI models, including image generation models, through a single API. In this plugin we point at Replicate to generate images on demand from a text prompt, instead of opening another tab and pasting the result back into the CMS.

### How do you generate AI images inside Sanity CMS?

Install the sanity-plugin-image-gen plugin, add your Replicate API key, and an editor can type a prompt directly inside Sanity and get an image back without leaving the studio. The plugin runs through Next.js API routes and uploads the chosen image straight into the document.

### What does sanity-plugin-image-gen do?

It adds a "Generate image" action inside Sanity Studio so editors can turn a prompt into an image without leaving the CMS. It supports advanced options like aspect ratio, image size, the number of variants generated, and negative prompts.

### Does Sanity have AI image generation built in?

Not natively. Sanity itself does not ship an image generator. The sanity-plugin-image-gen plugin from Roboto Studio bridges Sanity Studio to Replicate so you can generate images from prompts inside the editor. You bring your own Replicate API key.

### Can I use Replicate with Sanity CMS?

Yes. The plugin calls the Replicate API from a Next.js API route in your app, which means any image model Replicate hosts is available from inside Sanity Studio. You can swap the underlying model and tweak the default prompt prefix to suit your house style.

### Is Sanity CMS good for AI image workflows?

Sanity is well suited because its plugin model and custom input components make it easy to embed generators directly in the editing experience. With this plugin, the AI step is part of the editor's normal flow rather than a separate tool, which is what makes it useful for blogs and landing pages.

---

## The best Sanity CMS agency


> If you're looking to build a Sanity website, we give you a list of table stakes to make sure you get with every project. Don't settle for less.

**Published:** 2025-02-26 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=VFnkQQZFs6w

---

## Transcript

Hey, how's it going? So I want to do this video because instead of just telling you, "Oh, we're the best Sanity and Next.js website builders in the world," I'd rather just show you all the features. You tell me whether you get this in the first version, and just keep an eye out for this because we're ultimately just trying to make sure that you get everything that you need first time round. We don't want to inherit anything.

So, um, let's start by looking at Turbo Start Sanity. This is our own template. It's open source. You can take it today and press one click deploy and you'll get everything that you see on the page right now. Um, this is called presentation, what you're looking at. Um, and it's essentially Sanity's answer to being able to navigate through a website and then be able to click something and edit it right there and then. It's the best of both worlds. If you've used something like Webflow or what is it, Visual Bakery Composer in WordPress, it's very very similar, but it's a bit more on Rails, which is a good thing.

Um, so what I can show you is you can turn this thing off called the edit overlay. The edit overlay looks like this. Um, but it's pretty difficult to navigate with it on, so what we do is we'll go to the homepage and all we'll do is we'll change the title here. So let's turn it on. Let's click the title and let's say "Hello everybody." Okay, now the cool thing is the one on the left is the version that you get. This updates in real time. You can see this, but the customers can't see this. Let's take the same URL and we'll do this on an incognito browser.

Now this is really interesting. So this also encompasses something called Live Content API. We'll come back to this, but can you see how this version doesn't have the new text? This version has the new text. Now in a traditional way, what would happen when somebody hits publish is it would build the website. It would take roughly two minutes to see those changes in real time if it's kind of like a server side website, or it is an incremental static regenerated website. If it's client side, which you shouldn't do, it will show up immediately. That's not a good thing though. So if you want the best SEO, you want to probably be doing something that's ISR, so incremental static regeneration, or SSR, server side rendered.

Um, so let's hit publish and let's see what happens. So pay attention real quick. So publish, I'm going to flip here. Hands off any second. Boom. Cool. So instantaneously I didn't have to refresh the page. This is an incognito website. We're not looking at anything with any kind of cookies or anything. It's just instant that it loads.

Um, this is Live Content API. As far as I'm aware, I don't think at the time of recording this anybody else is doing this. Um, the first thing you may be questioning is how much API usage is this going to take and is it going to burn through the quota really really fast? Now we have a couple of clients that have tens of thousands of customers always hitting the website. Very very large websites. And they haven't even hit the quota for Sanity yet. And even if they did hit the quota, which is 250k API invocations, um, as soon as you hit another 25,000, guess how much it is? $1. Right? So even if you hit 500,000, you're talking $10 cost a month. It's worth every penny.

Um, so let's flip back real quick. So inside of here, this is kind of like the last thing I want to show you, um, is the idea of different routes. So now we're able to say, "Oh, okay, let's go into here. Let's click into blogs. Give it two seconds. Let's click into uh, one of these pages, and then we hit edit, and then we hit the title, and then we can change it in real time." So that's the actual presentation side of things that's in there. Um, I just want to kind of focus on that too because this is going to come into use, especially with what we're about to show next.

So if we look at structure and we look at Pages, this is another view inside of Sanity. This is kind of like, think of this as more, uh, almost like how you handle a traditional database. This is a great way of showing the contents in isolation. Um, but you can see here that we actually have two different routes that are on the same sort of URL route. So /Services Consulting and /Services. This is difficult to build inside of Sanity, and you should have this by default. Uh, the reason for having this is because it's incredibly easy to then build nested pages and nested features on the website, and this always comes up every single time.

Um, so when you're inside of one of these, let's say that we have this page here. Uh, we've made some changes to it. I'm happy with those changes. Uh, some more changes. Cool. Hit publish. Let's check what this looks like. I can hit this button up here that says "Open in presentation" and I can very easily start working on this. Give it two seconds. There we go. Cool, cool. So you could change everything inside of here, and this is the presentation view again. Really nice to work with. Really easy to use. But you also want the ability to be able to go onto pages like Consulting and do the same thing.

Now these are going to look exactly the same um because I've just duplicated it, but ultimately if I go into here and you'll notice I'm on Services Consulting, let's change the color of the page or some stuff on here just so you can see the difference. Um, so this is Consulting page and the other one will go back again. So let me hit publish on this. Um, and then the other version is the services page just so you can tell the difference. But to be able to build this, you want to make sure that you've got it because I see no end of websites that don't have this built in. Um, and it just means that at a later date you're going to have to do some work to be able to create new routes, to be able to create nested parent-child routes.

Um, but you can see now so this is services. This is /Consulting. This is all working in real time. Um, all of this functionality comes. All of it's kind of polished. Feel free to download this yourself. So again, Turbo Start Sanity, go to the Exchange. It's on the Sanity Exchange. Featured at the minute. Play around with it. Tell us your thoughts and make sure that you have all of these features if you're going to build a website.

So yeah, hope that helps. Take care. Bye-bye.

## Frequently asked questions

### What should you expect from a Sanity CMS agency?

Working visual editing through Presentation, Live Content API set up so changes show instantly without a rebuild, dynamic and nested routes (e.g. /services and /services/consulting on the same project), ISR or SSR rendering for SEO, and a sensible base template like Turbo Start. If those aren't in the first version they ship to you, you'll be paying to retrofit them later.

### What is Sanity's Live Content API?

Live Content API streams document changes from Sanity to anyone currently viewing the page, with no rebuild and no refresh. In a traditional SSR or ISR setup a publish would normally trigger a build before visitors saw the new content; with Live Content API the update appears instantly even in an incognito window with no cookies set.

### Should a Sanity website use ISR or SSR for SEO?

Either is fine for SEO. The thing to avoid is full client-side rendering, where your content shows up immediately for editors but search engines see an empty shell. ISR (incremental static regeneration) and SSR (server-side rendering) both deliver the rendered HTML to crawlers, so they're the right choices for a content-heavy Sanity site.

### How much does Sanity API usage cost at scale?

Sanity's Growth plan includes 250k API requests; once you exceed that, every additional 25k costs $1. So even a site burning through 500k requests a month is paying roughly $10 in overage. Live Content API on top of that is rarely the thing that pushes a project into expensive territory. Roboto Studio's largest clients haven't hit the included quota yet.

### Can Sanity handle nested page routes?

Yes. `/services` and `/services/consulting` can both exist as separate Sanity documents and render through the same dynamic route in Next.js. It needs to be designed in from day one because it touches the URL slug field, the page query, and the route resolver. Retrofitting it later is painful, which is why it should be table stakes from any Sanity agency.

### What is Turbo Start Sanity?

Turbo Start Sanity is Roboto Studio's open-source Next.js + Sanity template, available on the Sanity Exchange. One-click deploy gives you Presentation mode, the Live Content API wired up, dynamic and nested routes, and a working page builder out of the box. That's the same baseline an agency should be starting every project from.

### Is Sanity Presentation similar to Webflow?

Conceptually yes. You click on a piece of content on the rendered page and edit it in place, the same way a Webflow Designer or WordPress Visual Composer works. The difference is Sanity stays "on rails": the underlying content model is structured, so editors can't accidentally break the layout, and developers keep clean queryable JSON for the front end.

## Related services

- https://robotostudio.com/services/sanity

---

## How Roboto Studio ships faster with v0


> Vercel's first ever community session, featuring us. Jono walks through how we build applications from the ground up with v0, skipping traditional design tools entirely, with real examples like an investment firm site and a financial calculator.

**Published:** 2024-12-19 | **Updated:** 2026-08-11 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=PRgPyfl0KeU

---

## Transcript

I can see that we've got a couple of people already tuned in to this stream, so yeah, welcome everyone to our very first Vercel community live session. My name is Pauline and I work in the community team here at Vercel. I'm joined by Amy from the team as well, and you may have actually seen our faces in the community forum. Together we're here to just support you with everything, any questions that you have in the Vercel ecosystem. We're really excited to finally have this session up and running. This is what we hope to be the start of a series of consistent live gatherings happening right here in our community platform.

Just to understand what you can expect, this is the space to be if you want to become a Vercel expert and learn everything you can about building, deploying, and optimising with Vercel. We're really looking forward to bringing guests from our customers, our broader community, and even our own team here at Vercel to share these insights and tips and tricks and just experiences. It's also a really great opportunity to see kind of like the faces behind Vercel, which is super exciting. I can see there's already a few of you in the chat, it's so great to have you here. Let us know where you're actually tuning in from and feel free to say hello. If you are watching this and you're like, I don't see a chat, it should actually show up on the right hand side. Just make sure that you're logged into our community platform and click the button. You can see it down below, it's like a little event box. Make sure that you click going on the event page and the chat functionality should appear for you. Amazing. Well, I will pass on to Amy who will talk a little bit more about our code of conduct.

Hi, I'm Amy, also part of the community team, as Pauline said. I just want to remind everyone there's a link down below to our community code of conduct, and I just want to make sure that we all honour that and keep this a respectful and positive environment. We want to keep doing these events and that relies on all of us being respectful toward one another. So, very excited. With that, I want to introduce our guest, Jonathan Alford. He's the CEO of Roboto Studio. He's a Vercel customer, fan of v0, you've seen him in the community, I'm sure. So I'll pass that on to you, Jonathan.

Hey, how's it going, folks? Thanks for the intro, Amy and Pauline. Yeah, I'm Jono, I'm the founder at Roboto Studio. We build websites that are extremely fast, very editorial experience focused, and they're really, really scalable, and they use the bleeding edge technologies. Today I want to talk mostly about how we basically ship faster with v0, and I've got something really cool to show, so two seconds.

Hopefully everybody can see this. This is something that I want to show. This is one of the tools that we actually built completely from scratch using v0, which is Logal. Now Logal is kind of a very creative name because it uses the naming of Toggl, the, what is it called, a time tracking app, and it uses Linear, so we combined the two of those, and we wanted to build this as an internal tool. Now the really cool thing here is that we haven't actually had the opportunity to build an internal tool for quite a long period of time because it's very, very time consuming. But because v0 came along, we've actually been able to build the full app with v0, which is nuts. There's so much inside of here that basically is functionally built with that. But most importantly, something that I thought was a little bit of a tall tale when I first heard it was this concept of being able to build completely without a UI. Now everything here actually has been built inside of v0, and you can see we have things like empty states in here, we have things like loading states, we have a giant chart section here. All of this stuff is actually built with v0, which is nuts. So it's something that's cut down the development time of something like this from what used to be, you know, 10, 11, 12 weeks easily, right down to probably a couple of weeks realistically.

And I want to show you something else that's really cool in here. The reason why we built this tool is because essentially Linear is an incredible tool for project management, but it lacks a little bit when it comes to individual client visibility. So we have this second view called the Linear project view, where we can actually show the tasks that are currently in progress, and again, everything on here was actually built using v0 without any kind of wireframe. This is a very, very early work in progress version, but again, a lot of the functionality that you see here is just completely built through prompts, which is crazy.

Now the next one is kind of an interesting one, which is Sonati. This is a project that we took on about roughly three or four months ago, and it's a website build for some of the folks that are founders. They're an incredible team. But I really want to show you something neat. When you first look at the website, you get hit straight away with this cool falling block effect, which is kind of neat. Now this is using a tool called Matter.js, which is a 2D physics engine, and it actually has some really fun things, so you can actually pull these blocks about and shift them over the page like that. Now, as you might imagine, if you're trying to build something with Matter.js, it's going to take you a long time to build, because you have to learn how a 2D physics engine works and how that actually is implemented correctly, and then you have to try and figure out, one of the trickiest parts in here was actually getting it to be like a semicircle with a little notch out of it. So that's very, very difficult, and believe it or not, the entirety of this falling block was actually originally built inside of v0. The only things that have actually been done outside of v0 is this text effect on the top, and essentially just scaling it up at different screen sizes.

The other part of this is that every block you actually see on this page, including the little animations and things like this, these are actually all built in v0 again. So the foundational functionality, the foundational framework, the layout, everything, even the typography inside of here, how it changes between them, it's all built using v0 from the very start. It's really cool because, what you can do, and something that's a really nice tip if you're looking at building something like this and you're looking at putting this into a headless content management system, is that when you're actually writing prompts, you can ask to put the data, the JSON or whatever, in a separate file. What that means is that when you actually get the component, you get the props bounded to that component, and it makes it very, very easy to use something like, for example, this one's built on Sanity, to integrate the two of those and make them work together. If you're really clever, you can even actually generate the schema itself using v0, which we have done a couple of times.

Something else that's kind of neat if you're using images inside of v0, like here, you can see how part of the effect is the actual hover state, and this hover state and these images are actually stored originally in Vercel's Blob storage, which is really cool, because it means that you don't really have to think straight away where you're going to actually store all the media. You can actually get a mockup that looks closer to the real thing. It's a really, really nice way of doing things. And I want you to pay attention to this particular one as well, because I'm going to talk about something in a second related to this, but this again is all part of that same fundamental, the foundational components, the blocks that make up the page, all built in v0.

So let me show you this. Remember this one? We have this thing called the early animation in v0, so I actually wanted to do a throwback to the chat inside of v0, so you can kind of see. And believe it or not, to get the correct, I forgot what they call it, it's not a ticker, they used to call it a different name, marquee I think it was, this like marquee style where they both go in alternating directions, believe it or not, and you can see it on the left hand side, this took three prompts to get to, which is cool. And again, we basically pivoted and changed, and the original, so this one was slightly based on a high fidelity design, which you can see here. We ended up pivoting on this actual design and using more of a cohesive message with the actual branding of Sonati. So if we go back to the website, you'll notice that we now use this, where you're going to see a star coming at some point. There we go, "what opportunities excite us", and you can see we show a star amongst all the rest of them. But the core foundation, the animation in this case, and the actual layout, all built in v0.

And then finally, I want to talk about something that I'm going to complain about heavily until we bring it back, which is the customisation, the theming. So if anybody used early v0, and this really was the early v0, you would have seen that they had a theme customiser like this. It was really, really cool, because you could put an AI prompt and it would create all of the shadcn/ui themes. And so for example, on this one I'll show you a couple of them. This does a client side retheming of the page in real time, so you can see there's teal and plum, there's sky blue, there's green innovate, and my favourite on this is sunshine, which is this one. So you can see how the colours look, and if you think, for example, oh, this sunshine colour is not so good, you swap the background. I like it, I like it a little bit darker. There we go, perfect. So this used to be a v0 thing. I think we're going to end up rebuilding it and actually using it for ourselves and open sourcing it. But this was really, really cool, because I thought the idea of being able to build tokens, where you can actually put those design tokens back inside of v0 and use them to create projects, that was really, really neat. But yeah, this whole website again, completely, the foundation built in v0. And again, we talk about a couple of different things: the colour picker stolen from old v0 theming, and obviously data as an object is very, very important. If you basically put the object separately, it makes it way easier to work with props and make it kind of usable by a headless CMS.

And now I want to talk about something that's really neat, that's a client that we've got. Essentially, the client isn't a developer, and they have built every single one of these demos that I'm about to show you. The only thing that we've actually done in this is wire them up inside of Sanity. So I'll start with the first, and they're going to get progressively cooler and more interesting, in my opinion. Most of the website outside of this, again, very similar system using v0, but this in particular, you can see that we have all of these different fields, and again, there's a lot of accessibility in here, so if we tab through, you see nice tab targeting, nice accessibility. Say a home price at 250k, which is a little bit ambitious these days, and we say that the loan start is from 2025. We've got a down payment, you've just seen the validation come in there as well, by the way, which is kind of cool. We've put a down payment of 20,000, and the interest rate is definitely not going to be 3.5%, let's say five, and loan terms, 30 years. Now this is the cool bit. As soon as you hit calculate, you're going to get a full graph that generates all the information about everything that's in here. We've even got a little extension bit where it says optional, so you know, taxes, insurances, HOA fees. But this was completely built, like I said, by somebody that isn't a developer, and you can build these things yourself.

And why it's so important is because, from an SEO perspective, in the old days these things used to take, I don't know, probably a couple of days, at least three, four days for a developer to build a calculator, and they were very, very good if they got picked up. But if they didn't get picked up, you've just wasted four days' worth of developer costs. However, nowadays you can build these things in like 30 minutes and pass them on to a developer who will integrate them within your headless content management system or whatever tools you're using, and the costs drop dramatically. And the organic SEO for people finding these sorts of things, like, you know, "mortgage loan calculator", this is a perfect example, and you can integrate this not just within a singular page, you could integrate this within a blog. You could reuse this content again and again and again. It's really cool.

So let's go on to our second, which is neat. This one is a Chase rewards calculator. This is really cool, and again, he's built the same thing with this. We've built a couple of different things in here that match in with the colour scheme of the page, but you can see how these help you to enter the number of points, so you can go 25, 50k, 100k, and you can see how it changes. So for example, with the Chase Sapphire Reserve, there's a cash back of $1,000 if you just do it as cash back. However, if you go through transfer partners, there's the potential of up to 300% more cash back that way, which is really neat. And again, you can swap between cards, you can see these different cards, and you can see it adjust on the graph independently. But the fact that you can build these so fast is just wild.

And finally, my favourite one, which is the calculator example three. This one is really special. So it is a retirement saving projection. Let's be realistic and put zero current retirement savings, an annual contribution, maybe $500 at best, and desired retirement age, sorry. So, got to be a bit realistic here, so I'm probably going to be working till I'm 80, and life expectancy, and again, if you see all these bits and pieces, you can see how we have like tab targeting and accessibility and all of that. Investment growth rate, and let's be very, very pessimistic, so inflation rate of 5%. You can see how this chart is built. Now here's a really cool thing. Let's compare this to a more sensible scenario. Current age 30, well, I'm 31, but we'll go with 30. Current retirement savings, let's just pretend we have that much in retirement funds. Annual contributions, $10,000, all this stuff, and again, you can put additional factors in. But with all that in, watch this. You hit this add scenario, and you see how it makes this one look very depressing, actually, but you can see how powerful compound interests are, and this is really exciting and interesting if you actually are the sort of person that gets interested in retirement funds.

But the really cool thing, and this is the bit that I would never ever have predicted that people could do, essentially without a developer, is building the PDF. Now if you've used PDFs, or you've actually created PDFs before inside of React, you'll know this is no small beans, to be able to build something like this. This shows you the exact kind of metrics that you need to hit to be able to get to your retirement funds and everything else. But I want to reiterate, this wasn't built by a dev, this was built by somebody that was basically trying to work on the marketing side, so this is huge. And again, one more reason to start looking into v0 and start looking into being able to build these applications yourself, because you absolutely can build them.

And again, I want to take the most important app that's on here today, which is the Victorian cat generator. So if you've read our blogs, you've probably seen that we have a whole bunch of AI generated cats, and this is no different. We realised we were spending far too much time generating these cats, and to be frank, I didn't want to have to pay for a $20 a month ChatGPT subscription just to generate cats. So instead, we actually built a tool to be able to generate these things. So let me show you this. We have this, these are all the toggles, and on the right hand side, I think you might like that, that's the original version of the cat that I drew with Microsoft Paint. But let's say British Shorthair, and you can adjust the weight of the cat, so you can be all the way from skinny mini to boy he thick, and we can put a monocle on the cat with monocle. And you won't believe this, so we hit generate portrait, and bear in mind, at the time of building this, I hadn't spent that much time on image generation with OpenAI, with any of these tools, actually building tools and taking those API keys and making it work. And hopefully, beautiful.

You can see how powerful this tool would be, because all of the idea that I'm trying to tell with this particular tool is, something that is the future of companies is not just essentially building these huge behemoth monolithic tools. It's going to be a lot of tiny little tools that you use to speed up very specific processes. And this is obviously a bit of a ridiculous one with the Victorian cats, but this could be applicable to a whole load of different things. So just off the top of my head, you can think of something like, for us, we could very easily build something like a Sanity schema generator to be able to encourage people to start building with that tool. Or, for example, something that we are thinking about doing is open sourcing the old v0 theme generator, because it's great to be able to get your first shadcn/ui set of design tokens. All of these things are really, really powerful. You want to keep thinking about how you can build value and reduce, I guess, time to shipping inside of your companies with v0 and all of these other tools, because there's never been a lower barrier to be able to build things like this, which is an amazing situation to be in.

And finally, one of the last things I want to talk about is the fact that we actually built this entire thing, so all of this, you know, the open graph image, all of the content on here, literally three hours before this talk, with the whole team. We were all throwing our weight at it, so thanks everybody, by the way, on the team, it was a great effort. And I've included the good, the bad and the ugly of the prompts in here at the bottom, which I will link at the end of this call, but essentially this shows you exactly the process we went through, and you can see how we prompted to it. I think it was about 50 prompts in total, but it was worth it, so it was good fun. So yeah, I hope that makes sense, and thanks everybody for seeing the different tools that we've built.

So yeah, I think, I was muted. Hello, can you hear? Okay, great. I have like a mute button on my actual microphone, which is why I sometimes get confused there. Amazing, that was so incredible, Jono, thank you so much for going through all of that. I feel like it's just helpful to see how people create their v0 prompts and what can actually be built from v0, so this is really great that you can really see the value of using the tool. So we have a few questions, we'll try and get through them because I know we've got 10 minutes. The first question is, someone in the chat, I believe they are, I want to say, sdb23, they asked: looks cool, when I tried designing my app I had issues editing and creating new files in the v0 code editor. How was your experience, i.e. creating a file outside the app folder?

I think, so, I have encountered this issue once or twice, and I'm not sure whether this may be the same thing that you have had. So there is another tool that we're actually building behind the scenes at the moment, and basically, when I uploaded significantly large images and it went into Blob storage, sometimes there is issues relating to that. Now the way that we kind of got around that was by forking the actual project and then starting again, because I think, at least from what I can understand, it's something related to the size of the, what do you call it, like the clipboard or whatever you want to call it, the locally stored images. That was our problem, our specific issue. As far as I'm concerned, I know there is the functionality where you can now right click and just delete files, which obviously I would say use sparingly, because if you know that it's reliant on something, you may end up getting an error, which, again, the beauty of v0 is you can feed that error back in to try and fix it. Check as well, so something else that's worth looking at is the app directory. Sometimes, occasionally, a file gets generated outside of there, but that's very, very rare. We've only encountered it twice in the entire time of using it, over, you know, tens of, even potentially hundreds of different chats, if that makes sense. So I would definitely look into whether it's generating dual, so for example dual pages on dual roots, or whether it's generating something like a Tailwind config or something outside of the main directories. But if you want to shout us, we can give you a hand with it. Just get in touch and we'll see if we can help.

Great answer. I don't have anything else I want to say for that. Amy, do you want to take the next question? Yeah, another question, actually from the same person: during iterations, how are you handling secret API keys?

So this is a good question. When we first started, it was a little bit cowboy-esque, so obviously, they're internal tools, before we say any more. So for example, the Victorian cat generator, I'm guessing somebody's going to see if they could absolutely rinse my API key. That one is hidden behind one of the Vercel, basically a Vercel account, so the authentication comes up. But if you're talking about more generally now, if you're using, I believe it's the pro tier and above, in fact, it may even be on the free tier, actually, I think there's five on the free tier that you can get for the projects, you can actually put the environmental variables per project and keep them as like hidden storage. So depending on what you're using, that should be more than enough. It's obviously come a long way, so some of the ones that we showcased today, so for example Sonati that we showed today, comes from really, really early v0, so back when it wasn't even multiple files or anything like that, it was just like the real early stuff, but it's still, you know, totally feasible, providing you use the environmental storage. But just be super careful with environmental keys.

Really good reminder, I think, especially when speaking to v0. Oh, we have another question that's just popped up in the chat by Riz. She says: hey Jono, repping Nottingham, you okay? Which is great, fantastic, another Nottingham. Yeah, did you have any issues with file management for v0 iterations? I tend to fork many, many times while iterating and end up having to do a lot of memorisation of my chat names.

That's a really good one, yeah. I will say, so the way that we have gotten around it is we've been ultra specific with projects, with those specific, you know, the chats that are inside of those projects. So my advice would be to go more granular than you would expect, to essentially say, you know, for example, we have not just a Roboto Studio project, we have a Roboto Studio apps, we have, you know, like a Roboto Studio website, marketing, etc. So making sure that you kind of break it down to more projects is really useful. The only other thing that I can think of is, obviously, something that's really neat, and I know this is going to be kind of a tool inside of a tool, but you can very easily, similar to what we built today, you can very easily actually build a list of items inside of there. And one thing that I would love to give as a piece of advice on this is, markdown and MDX is extremely powerful with AI. I didn't mention it actually in the talk today, but we use markdown and MDX files, and this is a little bit of a private tool, but I'm more than happy to share it if you're interested. But essentially, you can use markdown files and something called a Nextra docs site, which is actually, one of the Vercel folks did actually build this originally, but you can use things like that to document things that are going off, like for example v0 chats. And more specifically, if you're doing a lot of marketing and things like that, you can use these to generate a lot of content for those things. So if, for example, you have, you know, 10 files, and inside of those 10 different files you have 10 different marketing things that you want to talk about, it's very easy to use a tool like that to generate content back into v0, if that makes sense. Give me a shout if you want more tips on this. I'm more than happy to kind of share our process, because we already use this quite a bit with v0.

Amazing, awesome. We have a bit more time. Hey, Amy, do you want to ask a question? Just pass on to you. You're muted, by the way. Great, okay, unmuted. Yeah, I just want to ask, just what types of projects does Roboto Studio typically work on, in addition to, you know, the kinds of examples that we saw? But, you know, what does your team usually work on?

Absolutely, yes. So we work with a whole bunch of different projects, everything from web apps to ecom to websites. One of the things that I was given as a tip as well that's worth mentioning, when I was at one of the conferences for v0, one of the biggest things that I didn't think about using, and this is something that we actually use and we have recently used, is v0 is an awesome, awesome migration tool, because you're basically getting all of the knowledge from that tool, that is pretty much all of the folks from Vercel, all of the best developers, basically all of that information is inside of v0. So if you're looking to migrate from platform X to platform Y, that is a great solution, and that is something we've been doing a lot recently. So as well as doing sort of websites, web apps and ecom, we've done a hell of a lot of migrations where they're really complicated, from certain tools and certain versions, and honestly, and this is no word of a lie, v0 has been so, so helpful in a 600k page migration we've done recently, because there was so many things that were so niche to specific Next versions and specific tools that were used in the original website, to basically make it worthwhile, and it's got that knowledge inside of it, especially for the latest versions. So yeah, it's really good for that.

Yeah, that's a really, really good shout. I know we're like nearly at time, but before we conclude, I have one more question, because I feel like the v0 team would like this question to be asked, and that is: if you could give like maybe a wish list of maybe two features that you would love to see the v0 team ship next, what would that be?

I think everybody knows what it is going to be. So one of them is definitely the theme generator. You took away my baby. I love the theme generator, so I hope they bring that back. It was really, really cool. If anybody got the opportunity to see it originally, what you used to be able to do is you used to be able to put in like AI themes, so in other words, you would type the prompt, you would say, oh, I want to have a theme that shows it's very modern and cool and uses the primary colour of orange, for example, and you'd get like the whole theme would show up beside it. This is more when there was kind of like a focus on just individual blocks. So that's definitely one, I would love a new version of the theme builder back. And then the second part of this, and this kind of ties in actually pretty nicely, so there is the ability to add files to an environment, but I think one of the biggest missing links in all of this, so for example, when people talk about Figma and v0 and the handoff between designers and developers, is this concept, I think if somebody would just build like an open sourced design tokens, where everything can basically digest those design tokens, that would be insane. So in other words, like, you just have a way of saying, oh, this is the Roboto purple, so I know I can use it in my Figma designs, and it will sync up with my v0 designs, and it will sync up with, you know, like my local GitHub environment or whatever. Something like that, some sort of design token storage, would be amazing, because I think that is the missing link between all of these tools. But yeah, just keep shipping incredible stuff, and I was really happy because you got the Figma plugin recently, which I was really happy about. But kind of ironically, at the same time, we actually have become a little bit less dependent on Figma, which is quite funny, because it's, you know, something I never thought would happen, is the idea of not necessarily starting with a design, which we've done on a couple of different projects, and especially for internal tools, it's very, very good.

That's really great. Well, Jono, we're going to take that snippet and we'll make sure we send that to the v0 team so they can take that into account, so thank you so much for going into detail there. So I'm going to wrap us up now. Thank you everyone in the chat who has been engaging throughout the session, thank you for joining us. Actually, if you're looking for more v0 content because you're super inspired after this session today, we have, I think about an hour from now, we have the v0 team, they're hosting a webinar called what's new with v0, and they are talking about the new Figma plugin and everything like that. So you can sign up and find the details, actually, I will just share in the chat here, feel free just to sign up via the link there. And yeah, we'd also love to see you at our next community live session, so if you want to get involved, share some ideas, take the stage and share what you're building in the Vercel ecosystem, then let us know. Get in touch with the community team, like Amy or I, like, we are happy to try and get you in the calendar. But yeah, thank you again. We would love to hear also your feedback, so please let us know in the community platform, and with that, I will leave us, I will stop this stream, and yeah, thanks again, Jono, for joining us. Thanks for having me. Have a great day, everybody. Take care.

## Frequently asked questions

### Can you really build a full internal tool in v0 without any design work?

Yes, that is exactly how we built Logal, our internal time tracking and client visibility tool that combines Toggl-style tracking with Linear. Everything in it, including empty states, loading states and a large chart section, was built inside v0 through prompts with no wireframe at all. It took development time down from an easy 10 to 12 weeks to a couple of weeks realistically.

### How do you make v0 components work with a headless CMS like Sanity?

The trick is to ask v0 in your prompts to put the data (the JSON) in a separate file. That way the component comes back with props bound to it, which makes it very easy to wire up to something like Sanity afterwards. If you are really clever you can even generate the schema itself with v0, which we have done a couple of times.

### Can non-developers actually build useful things with v0?

Absolutely. One of our clients, who is on the marketing side rather than a developer, built a mortgage calculator, a Chase rewards calculator and a retirement projection tool complete with PDF generation, and all we did was wire them up in Sanity. Building a calculator used to cost three or four days of developer time; now you can build one in about 30 minutes and hand it to a developer to integrate, which changes the economics of SEO tools completely.

### How do you handle API keys and secrets in v0 projects?

Be careful here, because we were a little bit cowboy-esque when we first started, though those were internal tools. Our Victorian cat generator sits behind Vercel account authentication, and for everything else you can set environment variables per project in v0 and keep them as hidden storage. Just be super careful with environment keys generally.

### How do you keep v0 chats and forks organized when iterating a lot?

Go more granular with projects than you would expect. We do not have just a Roboto Studio project, we have separate ones for apps, website, marketing and so on, with specific chats inside each. Markdown and MDX are also extremely powerful with AI, so we use markdown files and a Nextra docs site to document what is going on across v0 chats.

### Is v0 useful for anything beyond building new UI?

It is an awesome migration tool, which is something I did not think about until someone mentioned it at a v0 conference. It has the knowledge of Vercel's best developers baked in, so it handles things that are niche to specific Next.js versions and tools. It was genuinely helpful on a 600k page migration we did recently.

### What features would you like to see added to v0?

Two things. First, bring back the theme customizer: early v0 let you prompt for a full shadcn/ui theme and see it applied, and I would love a new version of that. Second, some form of open sourced design token storage, so the same tokens sync between Figma, v0 and your local GitHub environment, because that is the missing link between all of these tools. Funnily enough, we have actually become less dependent on Figma and often skip starting with a design, especially for internal tools.

---

## How to use Cursor for Content Generation


> How we use Cursor to write docs and blog content. Pull URLs in as context with Cmd+K, build a tone-of-voice guide from any site, and rewrite copy in that voice.

**Published:** 2024-10-29 | **Updated:** 2026-08-11 | **Categories:** Tutorials

Watch: https://www.youtube.com/watch?v=myEh-xU17Yw

---

## Transcript

Hey, how's it going? So we are going to do a video about how we can generate documentation and blog content and all that good stuff using Cursor and a tool called Nextra. Do sites. So let's start with one of those. Let's go with Nextra. Do sites. Um, so you can go to this by just going to www.nextra.com. It's a documentation tool, kind of similar to Mint Leafy or I forgot what the other one's called. Git Docs, I think it was or something like that. Um, but the real beauty of it is it's completely open source and you can run it through Vercel very easily. You can basically go to Documentation, Get Started and hit this Deploy. Um, you will need a Vercel account, you will need a GitHub account. Um, it takes one step and it only takes about a minute, about 60 seconds, and you can get it up and running. I'm going to assume that you're able to do this part. If you have trouble doing this part or you have issues with Git or Vercel, get in touch, we can help. Um, but we're going to jump onto the next step, which is the really interesting step.

So we're going to jump into Cursor, and this is our own documentation system that you're looking at right now. Now, every single file is an MDX file, so that's just the way that you write things. If you haven't used MDX before, you're essentially using these little hashtags as headings. So heading one, heading two. This is a paragraph. This is a paragraph. You get the idea, right? It's not super complicated. You'll get it real fast if you haven't used it before.

Um, now here's the really interesting bit. So say I'm going to build a brand new blog or I'm going to go for this blog that I'm writing at the moment, which is called Jumping Ship from WordPress. Um, what I might want to do is I might want to start writing on this. So I'm in the process of writing this thing at the minute, um, but I'm getting lazy, so I like some of this stuff and I want to talk about more things related to Sanity. So uh, give me three more features from Sanity. Check them out here. And now what we can do is this. You can do this by pressing Command K here. Uh, you can go to sanity.io, you can go look at Sanity features. Okay, so uh, in fact, you know, I'm just going to use the homepage because I'm going to be lazy. Um, press at, uh, type the URL in. Boom. Okay, so give me three more features from Sanity. Hopefully it brings brand new features and doesn't give me the same ones. More powerful features. AI assist. That's amazing. Localization support. Yeah, we haven't talked about that yet. Advanced Asset Management. Awesome, right? I've just done that with one AI prompt. So let's take that. That's great.

Um, now that is one part of this. Now the other part of this is doing something called a tone of voice guide or whatever you want to call it. Um, so this website we can actually use as our tone of voice guide. So if I copy this URL again, and I can go create a brand new one, I can say uh, Sanity Tone of Voice MDX. And what I'm going to do, I'm going to go uh, create a tone of voice guide from at and then paste Sanity's link in and we'll see what it does. This will actually write a tone of voice guide, and again we're just using the Command K at the minute. We're not going crazy, just nice simple Cursor functionality. You can see um, we have things like technical confidence with accessibility, forward thinking and innovative, direct and empowering, data-driven credibility, and you can see things like dos and don'ts. This is really nice, and this is just from one singular prompt inside of Cursor, okay?

Let's take that. Now what we can do is we can take the same document again, and what we're going to do is we're going to say oh, Jumping Ship from WordPress Sanity Edition MDX. Um, and I'm basically going to throw the same thing in and I'm going to say rewrite this using at tone of voice. Um, and this is the one I want, the blog, the Sanity tone of voice. So we have our own tone of voice, but we're going to use the one that we've just pulled from Sanity. Um, and you can see, "Transform your content strategy moving from WordPress to Sanity CMS." It sounds a lot more kind of professional uh, rather than what we write. So uh, that's kind of nice. You can see it actually working there.

Um, so this is a really cool piece of functionality because in one jump we've basically rewritten this in a certain way. It works kind of similar to how you would do something like AI translation. You're essentially just taking content and repurposing it, and that's what's really powerful inside of Cursor. Um, and the beauty of this is this completely scales. And now I know what you might be thinking, this is really cool, um, but aren't we just going to use this to rip everybody else's websites off? And you'd be right. So um, what we're going to do, we're going to see their blog and we're going to see what we can do with this. And this is again, I'm sorry, before I do this, Sanity, I hope nobody does this as soon as I've showed this. Um, but you can see uh, let's find something interesting. Um, digital transformation with structured content. So this is one, this is a really cool um, case study. Um, but you can see very quickly how I could write um, generic case study for enterprise. Okay, um, so repurpose. And I'm not saying you should do this. Before I show this uh, at um, to be another company called Acme and rewrite it using our at tone of voice. Now I'm going to use our Sanity tone of voice again, but you can see very quickly how we can pull in. It doesn't have to be other people's content. I'm only showing you other people's content because it's quite, there you go. You see um, you? I might be unleashing Pandora's Box on the marketing folks, but this is, this is really powerful for being able to basically generate content very, very quickly.

Um, obviously you want high quality content so you don't want to do what I'm just doing here. But I want to show you this as a tool to be able to generate content. But I thought I may as well address the elephant in the room that I know people are going to end up using this for. But if you are going to use this, make sure you put your own tone of voice, your own interest, your own stats, your own images, all that good stuff. Put some effort in. Um, but yeah, this is how you would essentially use Cursor as a documentation tool rather than a coding tool. Um, and again it does amazing things with prediction. So you can see very quickly if I throw another one on here, you know, content management, yeah. Oh, what's another one? API-first development. Cool. What's another one? Microservices architecture. Um, really helpful tool. Hope you get the most out of this. Don't just copy other people's work. Have a great day. Bye-bye.

## Frequently asked questions

### What is Cursor AI?

Cursor is an AI-first code editor, a fork of VS Code with a chat panel, inline edits, and the `@` command for pulling in external context like a URL or another file. People mostly know it as a coding tool, but the same workflow is great for writing MDX, blogs, and documentation.

### How do you use Cursor for content writing?

Open an MDX or Markdown file, hit `Cmd-K` to bring up inline AI, and use the `@` command to attach a URL or file as context, for example a vendor's product page or your own tone-of-voice guide. Cursor will then write or rewrite the content using that source as reference, keeping the structure of the document intact.

### Can Cursor write blog posts?

Yes. With `@` you can feed Cursor a source URL and ask it to expand a draft, suggest new sections, or rewrite an existing post in a different tone. Use it as a scaffolding tool. Your own stats, examples, and angle still need to go on top, otherwise the post will read like every other AI-generated piece.

### How do you make Cursor follow your tone of voice?

Create a Markdown file describing the tone (voice, dos and don'ts, technical level), then reference it with `@tone-of-voice.md` in any prompt. Cursor will rewrite the target document using that file as a style guide. You can build that tone-of-voice document by pointing Cursor at an example site you like and asking it to extract the patterns.

### What is Nextra?

Nextra is an open-source documentation framework built on Next.js. You write each page as MDX, and it gives you a Vercel-deployable docs site in roughly a minute. It's similar in spirit to Mintlify or GitBook, but free and self-hosted.

### Can Cursor edit MDX files?

Yes. MDX is just Markdown plus JSX, and Cursor treats it as a normal text file. The `@` references and `Cmd-K` inline edits work the same way as on `.ts` or `.tsx` files, which is why it's useful for documentation and blog work.

---

## Creating preview Images for page builders in Sanity Studio


> Here's a quickfire video showing you how to go from website to page-builder preview images in the shortest time possible with our Figma community file. Shoutout to @amranmohamed377 for the inspiration.

**Published:** 2024-08-13 | **Updated:** 2026-08-11 | **Categories:** Shorts

Watch: https://www.youtube.com/watch?v=SEig1qfOMsg

---

## Transcript

Hey, how's it going? So this is a quick video to basically create icon arrays, so creating the little thumbnails that sit inside of Sanity for page builders and things like that. Now everybody has their own way of doing this, but we have a fast way to do it if you already have the components built. And more importantly, this actually will match the aspect ratio of the little thumbnails that are in there and look really, really clean if you do it this way.

So let me show you how we work with it. So this is the existing Ralo Studio website, and we don't currently actually have the thumbnails. So what we're going to do, we're going to hit command and minus a couple times until we hit around 75, something like 50% could even work. I'm on a MacBook 14 inch, so essentially the screen size isn't big enough to be able to take a massive screenshot around it. So this is how we get around it. Just remember the size that you're doing it for because you have to do all of them by the same zooming out ratio.

So here we go. What we're going to do is we're going to take a screenshot of this. I'm going to take a big old screenshot, try and leave as much space around it as possible, and we're going to go into Figma. And we're going to use this new community plugin that we, or community document that we've just used inside of Figma, and we're going to open it up and it looks something like this.

Now what you're going to get is this array field of thumbnails. Now you can just straight away command click one of these trees that are in here and paste it in. So you can hit that, and there's how it will look inside of the Sanity development environment, inside of the Sanity Studio. However, we have these 3x2 examples here which you can also do. So again, command click (I believe it's control click on Windows), you want to click this and you basically want to paste it in, and that's how it will look.

Now you can do this for every single one of these. So for example, I'll do the next one down, and all we're doing is we're trying to get it roughly 3x2. Sometimes it's a little bit bigger, sometimes it's going to be wider like this. But the lucky thing about Figma is because of the way that it actually scales the image up and down, even if I hit this now where it's a much wider version, it should kind of zoom it into the center.

Now this doesn't look perfect and it's going to drive me crazy, so what I'm going to have to do is I'm going to have to do it again and try and leave more space in there. Now that's probably pretty close. Remember, you're trying to hit 3x2, so if you make sure that you're following that same ratio, it will hit roughly the same ratio perfectly there.

Now I'm not going to be able to live with that either because it's got those next icons below it. So what you can do in these situations is hit the little fill section at the side, hit crop, and just shift it about however you want and shift up the size to get it to work. So if you see there, that to me looks great. And you can do that for every single one of your components.

And all you will do at the end of this is you will export them with the same name as the page builder components and put them inside of the Sanity Studio folder. And from that point onwards, it all works perfectly. But this is a great way to basically template these screenshots and make it easier for you and much, much faster than the traditional way of doing it.

So have a great day. Hope that's helpful. Bye.

## Frequently asked questions

### How do you make thumbnails for a Sanity Studio page builder?

Build the components on your site first, then take a wide screenshot at around 50-75% browser zoom. Paste the screenshot into a Figma template that already has 3x2 thumbnail frames, crop each one with the fill and crop tools, and export. Naming each export to match its page builder component is what wires it up inside Sanity Studio.

### What aspect ratio should Sanity page builder preview images be?

Aim for a 3x2 ratio. That's what the thumbnail slots inside Sanity Studio render at, so matching it means your previews look clean and don't get awkwardly stretched or letterboxed when editors pick a block.

### How do you add preview images to a Sanity page builder?

Export the thumbnails as image files using the same names as your page builder block components, then drop them into the Sanity Studio folder for the studio to pick up. Once the filenames line up with the schema, the previews appear automatically in the block picker.

### Can I use Figma to design Sanity Studio thumbnails?

Yes. Figma works well because it auto-scales pasted images to fit a frame. Roboto Studio uses a Figma community document with pre-sized 3x2 frames, so you paste a screenshot in, crop it, and export. Figma's centered scaling means even slightly off-ratio screenshots end up roughly correct.

### What is a Sanity page builder?

A Sanity page builder is an array field of section blocks (hero, feature grid, CTA, and so on) that editors compose into a page. Each block has its own schema, and most teams add a small thumbnail per block so the picker shows a visual preview alongside the name.

---

## Creating an AI Chatbot in Obsidian


> We talk about creating an AI chatbot in Obsidian using Smart Connections. It's basically a really easy way to "talk to your notes" with whatever AI model you like.

**Published:** 2024-07-08 | **Updated:** 2026-08-11 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=wWC7AEjyZD0

---

## Transcript

Hey, how's it going? So today I want to talk about this idea that we've been pursuing for quite a while, and this is the idea that all of this knowledge we can put into some sort of database or tool or, you know, documentation system and we can then pull from that database as a collective as our agency to basically keep hold of all the information, knowledge, and grow as we grow as a team.

Um, now there isn't particularly anything out there at the moment that does this in a simplistic way until we basically found this tool which is called Smart Connections. Now there are a couple of extra bits that I wanted from this, which is offline functionality, the ability to use your own API keys with whatever AI tool you get, because as all of these AI tools kind of accelerate, they're getting better every single day. So you want to always be on the front runner. So if ChatGPT or OpenAI gets a brand new tool, you want to make sure that that's the best one and you're using the best price for your money. And then if it ends up being Anthropic, you know, swap over.

So Smart Connections is really cool because first of all, you can see all the different types of AI functionality you can use. You can use any of these. You can even spin up a local AI for the actual tool, but for the sake of today I'm going to be using Claude 3.5 Sonnet.

And now on the left hand side, you can see all this information that we've actually set up to try and help people get on board to Obsidian because it's not the easiest tool to get onboarded with. In fact, I would recommend this YouTube video that's on the left here. I'll make sure that's in the description.

But from this, we want to ask it something. If you can look on the left hand side, you can see this "How do we create a paragraph in Obsidian?" And so what this will then do when you file this off, it will find the context of whatever markdown file it finds appropriate and it will respond with a little tiny snippet that tells me about whatever it is that I'm asking.

Um, so it says, "Based on your notes, to create a paragraph in Obsidian, you need to press Enter twice. Specifically, your notes mention..." and then it gives you the actual context.

Now this is kind of cool, but it's very basic at this point. But what I want to show you is something very, very interesting because we're not even in the same file. And I want to ask, how are we able to handle blurs, Sanity image? So, how do we handle blur Sanity image? And now why is this interesting specifically is because there's not all that much information out there about Sanity image and blurs, but more specifically there's no information about how we do it in house.

Now you can see here, this is actually how we do it in house. We use the Sanity image URL four, we set a width of 100, a height of 100, and we blur it to 300. So there's no real performance cost by taking this image. And then from there we actually use an overflow and we get this blur large and scale 110.

Now because this note exists, and you'll see the difference here, so if I hit "Handling blurs on the web," you'll see that this looks totally different to the version that Smart Connections passed this back. And this is because it's essentially taking all that information from my document and then running it through, in this case, Claude 3.5, and giving us a very interesting, you know, kind of more context-accurate response, which is incredible.

Um, you might be asking essentially how much does all of this cost, and the answer is pretty much nothing because the person that's building this obviously works from donations and upgrading the account. But ultimately, you're bringing your own API key and he's essentially just built the tool to be able to work with Obsidian community plugins.

So what I would advise doing is if you are going to use this tool, go ahead and say hi to Brian, who is one of the creators of the tool, and upgrade and pay for the extra bit to be able to get the latest version. But yeah, it's an incredible tool. I'd highly recommend it. It's been something that we've been trying to do for months and months and months on end, and this, as far as I'm concerned, is the best thing out there to be able to handle offline, online AI functionality and be able to get context from your documentation.

So yeah, hope that helps. Have a great day. Take care. Bye.

## Frequently asked questions

### Does Obsidian have AI?

Yes. Obsidian itself does not ship with AI features, but it has a rich plugin ecosystem with several AI options. Smart Connections is one of the most popular, letting you chat with your notes using whichever model you choose.

### What does the Smart Connections plugin do?

Smart Connections embeds your Obsidian notes and lets you have a conversation with them. It uses retrieval to pull the most relevant notes into context, then sends that context to your chosen AI model so you can ask questions and get answers grounded in your own writing.

### Can I chat with my Obsidian notes?

Yes. With Smart Connections installed, you can open a chat panel inside Obsidian and ask questions about your vault. Answers cite the notes they were drawn from, so you can jump back to the source whenever you want.

### Which AI models work with Smart Connections?

Smart Connections supports OpenAI, Anthropic, Google, and local models through Ollama. You pick the one you want to use and provide the API key in the plugin settings.

### How do I set up an AI chatbot in Obsidian?

Install the Smart Connections plugin from the Obsidian community plugin browser, enable it, then add an API key for whichever AI model you want to use. Once embeddings finish generating, the chat panel becomes available from the sidebar.

### Is Smart Connections free?

The plugin itself is free and open source. The cost depends on the AI model you connect to it. Usage of OpenAI or Anthropic incurs API charges, while running a local model through Ollama has no per-query cost.

## Related services

- https://robotostudio.com/services/agentic-workflows
- https://robotostudio.com/services/agentic-websites

---

## How to build with Sanity for scale: 5 takeaways


> Jono's talk from the Sanity community meetup in London, recorded on the official Sanity channel: five takeaways from shipping numerous Sanity and Next.js projects at scale, from content modeling to editorial experience. The full meetup recording also includes talks from loveholidays, evensix, and Sanity's own Simeon Griggs.

**Published:** 2024-06-19 | **Updated:** 2026-08-11 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=970iZKpppoY

---

## Transcript

Let's see. Okay, we're streaming. Welcome everyone. I'm a bit overwhelmed by all the people. It has been five years, I think, since the last time we were in London, in a much smaller room with much fewer people, and it's awesome to get back here and see all of you. We have a pretty packed programme today, but it's also packed with a lot of learning, and we're not doing any Q&A, you have to actually speak to the speakers afterwards, in fact. But yeah, restrooms: through the open door on the left, not the elevator or the emergency stairs, but the door on the left. Yeah, right, yeah. There are fire escapes, there's green signage. This is only for people here, not people watching on YouTube. But yeah, thanks Codehouse for hosting us, fantastic. Hope you have grabbed food and drinks; you'll be able to grab more. There's a little, like, chair game, so in between the talks, if you feel like standing, that's where the people are, now you know. But yeah, there are also benches you can also see, in their own style. But yeah, I shouldn't be talking, because we have, as I mentioned, a packed programme. I'll give the mic over to my colleague Simeon, who you might know from the internet. And I will get back to being a producer. Yeah, thank you again for coming.

Yeah, good, thank you. Yes, on the internet, and there's a bunch of great speakers, more than one person, a bunch of great talks. I'm going to run through the names. So Youssef is going to be speaking tonight, Jono from Roboto Studio, Evelina as well, we've got a talk from Toby at Even Six, and then I'll be closing out with a talk as well. So I don't want to hog the stage too much tonight. Let's get straight to the first one, come forward and get set up.

Actually, while this is getting set up, it's interesting: you've got a migration to WordPress, a migration to WordPress to headless, a migration from WordPress. Where my mind is at the moment, actually, as well: it's the next course. I run the learning programme at Sanity, and it's the next course that I'm currently actively writing. My head's there because I'm literally writing a big migration script from WordPress, so if there's learning to come out of that, I would love to hear it, what's happening there. If you have struggled to migrate into a headless framework, I'd love to hear what the challenges are there. There are so many different data sources to come from with legacy systems, and it is a challenge. So yeah, just trying to gather as much information on that as we can. That's my pitch for what I'm working on next, and I'm going to hand over.

I'm a software engineer. I have my own company, Spaces and Tabs. I do web and mobile development, and I'm here today mainly to tell you a story about how we shipped the website for Women Techmakers. There is a lot to unpack in the story, so I am going to focus on the basics here. It's mainly going to be a story about how to get the basics right, and how getting these basics right gets you a lot of the way there. So Women Techmakers had an old website. I also built it for them; the founder of the community is my wife, so I'm her guy. The old website, as you see at the top here, and the new website is down here. When you look at it, you might not see much: it's just a UI uplift, there isn't really much happening. But actually, under the hood a lot of it has changed to support this new thing we built.

Just a bit of context. The old website was basically a week's project. We sat down together, and in a couple of days got a template using Gatsby. The template was mainly a blog, so it had an about page, maybe a small blog, and we used it mainly to showcase some of the local meetup events that were happening at the time, and that was when the community was small scale. Right now the community is much more than that. So we have different pages, such as directory pages, which are a speakers and founders hub, so it had some interactivity such as search and filtering and things like that. We added a whole lot more than a blog, so you have different types of blogs, different types of content, different types of conferences. So when we had a look and decided to uplift the UI of the website, we also had a look at what we're using in terms of content management, how our content modelling was doing, and the tech we're using to build the website.

So a good question is: why start over? It looks like a fairly simple UI uplift, so why go through the process of doing all that and building it from scratch? Well, on the content side, the first thing is our content model wasn't really flexible. We had all these pages, and every page had its own, what you can think of if you use Sanity as, like, a schema. So you had a conference schema, a blog post schema, a knowledge hub schema. All of them are almost the same, and we are just changing a bunch of fields here and there. So it's not ideal, it created a lot of duplication, and obviously, something that's built in a weekend and then evolved really rapidly, it caused a lot of headaches. And soon enough, Gatsby, we stopped developing as well. It was great when we started, but we're using static site generation, so the more pages we had, the slower it got, and obviously once Netlify acquired it, things got a bit stale, so it wasn't moving or something. And the final nail in the coffin was Contentful got really expensive. We were on the free plan, and it was working for us until they limited the content models, how many content models you can have, and suddenly we were exceeding that limit and looking at a $300 bill per month, which is really quite expensive. So, it's not Contentful's fault, but we really needed to rethink how we model our content.

So I'll talk a little bit about how we planned the migration. The first thing is we looked at the templates we had. A lot of it was actually duplicated pieces and duplicated structures everywhere. Let's say, for example, you had a podcast and you had a blog. Both of them had a piece of rich text, and then in the podcast you had an embed for the podcast player. So why do we have two different data models for them? It wasted a lot of resources and added a bit of a headache in managing it on the content side. So what if we actually took a step deeper into it and figured out what these templates are built from? When you looked at the templates (this is not a real screenshot, like a real image, but just an approximation), when you look at the template, it's actually a bunch of smaller models, UI components you could say, that actually make up the template. So what if our content model is not necessarily mapping to a template, but instead our schema is just the UI components, and then we just render them to form a template, similar to this? Simply, even if you have a big template, or you are building any kind of interactivity or a feature on your website, ultimately it boils down to a body with a bunch of sections in the middle, right? Your hero, your piece of content, and then maybe your related articles. That's just one example. So if we shifted those templates and moved them to a content editing concern, not a development concern, not a content structure concern, we don't care about it when we are rendering a page. And with that in mind, that means when you have different variations of the same component, it's not necessarily a new template anymore, it's just tweaking a few fields in the content schema or the models that we have.

This is a very simple example. It might not give you the full idea, but let's assume these are two separate templates, right? Both of them have an image, have a title, and have a piece of text in the middle. In the old website, what we'd have done is have two distinct content structures for them, named them differently because they're used in different places, but in reality all we needed to add is really a boolean flag to mirror it, right? So these are part of why we just finally decided we needed this rebuild, to update all our content schemas and migrate them away from being duplicated based on what variations we have, into something that's more flexible that we can use to build templates on top of.

The next step in our migration really is moving away from complexity. So as I mentioned before, we're using Gatsby. Gatsby forces us to use React, but do we actually need React in this? We probably don't. We were perfectly happy, like, the new website is perfectly happy with HTML, CSS, some JavaScript in some places, but mostly HTML and CSS, to be honest. And even the CSS, I used Tailwind. I'm a mobile developer, so don't blame me. And yeah, do we actually need static generation? I mean, I'm torn on that, because, well, spoiler, we used Astro. So even with Astro we can do static site generation, but it actually proved more headache than it's worth, because with every update you'll need to rebuild the website, so you need to build some kind of hook mechanism or something to update your website every time you publish something, which I'm sure Sanity has great plugins for, hooking into Vercel or Netlify or whatever. But also the other headache is previews, because now you need to build your website but have some kind of server-rendered version of it to support previews. So if it's already up on live, you might as well just serve it to the people.

So yeah, with this in mind, we actually started on the implementation. Instead of just a fresh UI update and calling it a day, we actually built it all from the ground up. As I said, we used Astro, and I love Astro, I've been using it for a while now. From someone who doesn't really develop websites a lot, Astro is just really a breath of fresh air. Just HTML, CSS, no fuss, very well documented. You can build, like, everything is in their documentation, it has really good plugins, and the best part about it, like I mentioned, is no locking your UI framework in. So you're not locked into React, you're not locked into Vue. If you want them, you can add them; if you don't, you still have your own HTML. They have a hybrid mode as well, so if you want to statically generate you can. Spaces and Tabs, my own company website, is actually Sanity with static site generation, but for Women Techmakers we ended up using server-side rendering. So that really fit well with us because of its simplicity.

And obviously, that's why I'm here: we used Sanity for content management. The big wins for us in using Sanity were actually the Sanity Studio. There's a whole load of customisation on it that we added, and for me at least, I felt it's really nice and really productive to have my schemas and everything defined in the same place where I actually do the rendering and write the code to render all these components. It really fit well with my mental models and how we're working. And the query engine that Sanity has actually really helped us build this kind of page builder, because you don't know the parameters you are targeting and what you want to fetch, because every page can have its own UI components. So it worked really well with how we query things, and I will give you a sneak peek of how we actually do the querying and how we avoid unnecessary calls later in the talk.

So we are building a page builder on Sanity. How do we structure this schema? I think I gave a bit of a brief overview early on. Mainly, we are focusing on UI components. We're not building templates, we are building UI components, and from that, templates become a separate concern for content editing, and we'll see how Sanity makes life easier in that as well, so we can bridge that gap. But I'll just walk you through some of it. I'm sure it's basic knowledge, but these basics are actually what set the project up for success and made life easier for me as a developer and for the Techmakers team to edit their content and migrate it one by one.

First thing is easy: just enforce your rules. If you have any fields that are optional, or should be optional or not, make sure to add your rules in the schema, and that way content editors can get these nice warnings when something goes wrong, and you, as a developer, trust your own data that you are fetching, because you know that you put your rules in there. You know that when something is required, it's required, and it's not going to go missing. That saves a lot of the headache, and it's something that we really lacked in the old website as well. We had some random values, everything was almost optional, so you had quirky behaviour in how things rendered.

The other thing is: really be descriptive. You have name, you have title, you have description. Use them to tell the content editors what exactly this is meant to do, especially in every field, so they have an idea of what to write. Obviously you have your previews, but sometimes they're just filling in their content early on, and you don't want any misalignment.

Next is: choose sensible values for your preview. What I mean by this bit here: Sanity, the Studio, will pick up some default values for you if you don't define it, which is a good start, but this data is contextual in where it is and what you are trying to build. So for example, if we are building a page here, I'd like to know what component I'm using or what component I'm editing, so you customise it to make sure that the preview gives you that title, for example, here in the header. Using sensible values for previews helped us make content editing an easier, smoother experience.

And shared new UI elements should have a schema for them. Even if you don't have a design system, you still would like to share some elements of UI here and there, and if you are already defining a schema for your UI components, you don't want to go about duplicating how a button looks, for example. This button can have a background, or can have a border, or can have an icon, and all these are shared, and you want to standardise that across all the UI components, so it's easier for you to build and support that on a schema level, so content editors can reuse that and can update it once and it goes into all your UI components, rather than just copying the same fields over and over across the components.

And limit the free-form inputs, especially for things that have specific values. So again, Sanity Studio and your schema definition will really help you in getting dropdowns or checkboxes or radio boxes for whatever you need. Again, it's all about removing any unknowns in the content editing journey, and as a developer, trusting the input you're getting. Ultimately you are getting a string, but if I know from the editing side that I'm only getting this subset of strings, I can easily reason with that in my code and avoid any unnecessary edge case handling.

And finally, do yourself a favour, do everyone a favour: your content editing team, give them previews. It's really easy to get the iframe up and running. For us, there is a bit of logic to manage the perspectives and the tokens you are passing in to get this up and running, but once it is up and running, it's really helpful to avoid having a staging environment and a production environment, for example. You can leave everything on draft, it renders the draft, and people can share feedback, and Studio is really amazing to have comments around, and it keeps the collaboration going.

So with all these in mind, and updates, we ended up having a structure similar to the one on the left. We have one level, which is shared UI components, such as your buttons, how your links look, any requirements. So images: we have a requirement that every image should have an alt text, for example, and to filter that through, we use UI components directly in the other page blocks, I call them, or visual blocks. So for example, there is a form block or an author block or a header block. These reference the UI components and have their own fields. Usually, once you clear out the images, clear out the UI components, what you're left with is what type of text you are using: is it normal text, long text, or portable text? It doesn't really leave you much variety, which is good for standardising. Even for a page builder, you don't know what you are rendering, so you need to standardise as much as possible the contract between the content and what you are building.

And this is what a page looks like now. So instead of having a template with a bunch of fields to make a template, a page just starts as an empty array, and you just fill it with the components you need, which is similar to any page builder you have right now. Like if you go to Squarespace or whatever, similar drag and drop, and then you fill each component individually. The good thing about this is it just uses the designs and styles and the components that the content editors are familiar with, and they don't need to recreate them, and it's an environment where we can do more updates, because of how extensible the Sanity Studio is.

So with that in mind, that's the Sanity part of it. How do we consume this data from Sanity? I'm not going to go into a lot of detail about how Astro integrates with Sanity; this is just a brief overview of the journey of a request today. We get a request. We only have one layout now, because we eliminated all the different templates, all the different layouts. Everything that's configurable now is coming from Sanity as a configuration by the content editors and whoever is maintaining the website, and there's build-time configuration coming from environment variables and things like that. So it simplifies a lot of the code. We stripped out all the layouts that we had, all the different templates. It's only a single template, and this is where the head, with all its metadata, gets rendered. It makes it so much easier to reason with, especially around SEO, around Open Graph meta tags and all these things like that, and obviously makes it easy to put scripts in as well, like if you're tracking with Google Analytics or whatever. The page layout just references a block renderer, which basically takes whatever you fetch from Sanity and renders it on the screen as visual components, and you end up with a nice list of visual blocks, and there you have the screen.

A little bit on how we call Sanity. The initial version of what we had basically fetched the page from Sanity, got your references, and then each reference resolved itself. So you're making subsequent calls: if you have 10 components on the screen, you are making 10 plus one API requests, which will consume your Sanity credits really fast. So actually, the trick that we did here is to resolve the first level of references when we are fetching the page. That's why I was talking about having a flexible query, because it just makes life easier. Resolving that first level of references gets you almost all the visual components that we need. There are a few visual components that have references to other visual components, and these can be resolved after, but there are not that many. So best case scenario, on almost the majority of the pages, you have just one call to the Sanity API. Worst case scenario, you do the n plus one, but these are pretty rare for us, so we're happy with that kind of performance.

Another thing is separation between these visual blocks, so they don't know about each other, and they don't know about the UI components they are referencing. Everything calls the renderer recursively to render any children that they need. Again, that way, it's one easy way to standardise everything and make sure that you only have one source of truth on how things are rendered, instead of copying that visual implementation in different places.

So that's really everything of how we shipped it. There is a lot more detail. I'm happy to answer any questions about that. You can find me and ask me any question about Astro later on, but for now I'll just leave you with what's next for the website, with most of the updates that are coming next, hopefully we manage to do it, or I will manage to, later, for them. It's going to revolve around content editing. So remember the screenshots I showed you earlier where the page is just a block of items, right? Content editors still need to manage and work around templates. So one thing to add, I think, is initial value templates: basically a fancy button that creates a blog page that will basically create a page, add all the relevant blocks for them, so they can just fill in the content and don't have to worry about what visual component type they need to use here or there. An extension to that is improving the duplication behaviour, because we're using references, every page, when you duplicate it, carries over the references, which is not ideal if you are content editing and just want to duplicate a blog post and just update the content; you end up overwriting. So again, another duplicate button that will actually work on duplicating all the references as you go will be helpful for content editors. So that will be coming soon to their website. And finally, visual editing. I just saw it got recently merged into the Astro integration, so hopefully we'll get into that, because again, with the previews that we have, that will make content editing a lot easier. And that's it from me. Thank you so much.

I have a written version of that talk, so we can link that up. Thank you.

So hi everybody, how's it going? I'm Jono from Roboto Studio, and today we're going to be talking about five key takeaways from websites that we absolutely loved building. So let's start by talking about what is Roboto Studio. We are a development agency that is hellbent on providing the best editorial experience that you can get right now. What is the best editorial experience? For us, it's Next.js, Vercel, and of course Sanity, and we've basically been building the exact same website for about three years now.

So let's start with number one. Number one: migrating old websites. If anybody's actually migrated a website here, you know how much of a nightmare it is, and so I wanted to talk about things that you actually can do when you are migrating them. Something that's really, really difficult is internal links. Migrating an internal link from content to content is very difficult. Taking images is incredibly difficult as well. Working with old tags for images, that's another thing. And then finally, pulling existing categories from different web pages is really, really tricky. However, something that we don't talk about enough is web scraping, and the power of actually using that.

So let's talk about one of our clients, Jam. They had 4,500 products, they had 200 blog posts, and out of those 200 blog posts they had interlinking, internal links into those products, and now all of those products have changed categories as part of this migration, and it's incredibly tricky to be able to get that content and move it over to a new website. With that being said, we managed to get 100% migration coverage, and you know what's crazy about this? We actually managed to do it because of web scraping, rather than actually having access to the back end. Something that people forget about very, very often is the way that you can actually use web scraping and integrate it directly into Sanity to be able to populate content. And with that being said, we're on to number two.

So we're going to talk about integrations now. When we talk about integrations, a lot of people are going to think just web applications and how they integrate into Sanity, but there's a lot more stuff that you can actually do with it. I'll give you a quick example now that we've done recently. With YouTube, you may have an incredible channel that you're putting a lot of content out on, and you actually want to integrate this directly with your website. Now, if you did this in the old days, what you would do is you would sit there and you would copy, paste, put it over. It's a real pain in the ass, but it's very, very open to human error. There's no end of times that I've put something over and it's actually not spelled correctly, or it's missed out a punctuation mark. But the beauty of integrations is that we can actually interconnect YouTube with Sanity and create a brand new document type, so you have your YouTube videos directly in the Studio. It's pretty neat. The other benefit that you have when you actually pull this data into the Studio is that you can actually enrich that data with Sanity. So for example, if you know that a YouTube video actually has a lot of interesting stuff about, well, let's talk about integrations, you can actually have related blogs that talk about integrations. It's really nice how you can start building on top with these content layers and all these fancy bits and pieces.

And with that being said, I want to talk about cron jobs and API integration with our next clients. We had, pardon me, the Techaro project, which was essentially integrating HubSpot with Sanity. Now, a lot of people actually use HubSpot for marketing, for analytics, all that fancy stuff, but the usual experience of HubSpot is somebody goes into HubSpot, and the most likely thing they want is the forms, because they're really good for funnelling people down to convert. But the experience to actually get that form into a website involves going to HubSpot's embed form, taking the little iframe, putting that on your website, hoping that it doesn't have any, like, iframe hijacking or anything else like that, and it's not the best experience. So you can actually directly integrate the API from HubSpot into Sanity, and so we did that for Techaro. We integrated their HubSpot accounts, so whenever they build a PPC campaign or something that we want to try and convert, we essentially have the ability to just reference the form from HubSpot. We run a cron job to basically pull this data, so it's always fresh, and it's always the latest and greatest forms that they create.

The other interesting one about this is Wistia. If anybody's used Wistia before, they do have an API available, so you can pull, for example, podcasts, you can pull videos, all of this fancy stuff. But the one thing they don't have is transcripts available. So if you were to, for example, pull a podcast, you probably want to also get that transcript. The interesting thing that you can do, and what I would always advise doing, is actually run a scraper with it. You can take that API request and you can basically stack that with a scraper and get all of that rich information and put it inside of Sanity. It's worth mentioning, though: split these two things. Split it into editable content, and split it into content that's basically being pulled in from an API, because you don't want to do destructive stuff on editable content.

And I want to talk about number three today. Number three for us (don't worry, there's only two more): set and forget SEO. Set and forget SEO is where essentially you're using the structured data that already exists in Sanity to essentially populate JSON-LD for Google. This is incredible stuff, because realistically you've already got all the structured content from your content management system, and Google essentially just wants this content that you've written in a format that it can basically take and run with. The beauty with the brand new thing, the Sanity TypeScript generation, is it works directly hand in hand with the schema-dts TypeScript tool, if you've seen this about. If you use those two in combination, you can essentially get all of that data from your Sanity Studio and combine that with all of the data that Google actually wants to see.

For example, we work with a company called Futurepedia that did exactly this. They wanted to generate pillar content, and the pillar content was very, really focused, like pin focused, on organic SEO. So when we were building that organic SEO content, we essentially populated all that JSON so that they could try and rank for things like AI productivity tools, AI image generation, this kind of fun stuff. The other bit that was interesting about this particular project was the fact that we were using, again, scrapers to be able to pull newsletters and their AI events. With their newsletters, it was their previous email campaigns, but it completely populated inside of Sanity, so you've got both of those in one location, and the beauty of it is there's not a singular curly bracket inside. So when they were actually building this JSON, they didn't even realise they were building JSON in the Studio. It was literally set and forget.

This one, so number four, is a really, really complex one, but it might be useful for certain people out there. This is the idea of, if you look at something like BBC News, you have a document where it may exist on both latest news, and it exists there, and it may also exist on, you know, local news, Nottingham news latest. So those two, it has to exist on at the same time. Now, these are notoriously hard to build, because you have to either build them rigidly, or you have to think of some way to be able to extend these out. And we actually built a custom URL builder to be able to do this. So every single step of that URL, so for example the latest would show the latest blogs of the news, the latest local news would pull all of the latest local news, and so on and so forth, all the way down the URL structure. It's just a really clever way of being able to scale your content completely without a developer, because this is all done on URL route generation, and get all of that rich data put into a hierarchical structure.

We actually built this for Global Cycling Network, and this underpins the entire way that the project works. If you can see at the top there, we have things like the breadcrumbs, where it says GCN, racing, news. Each one of those URLs essentially tells you information about that particular blog post. Every single one, it's stacked up and hierarchical. It's pretty tricky to build, and it's only really achievable because you can do so many incredible things with GROQ and the queries within GROQ, if that makes sense.

And so finally, this one's my personal interest: automating as much marketing as possible. When we're building things for the website, the biggest sticking point that I've always had is generating meta descriptions, generating Open Graph descriptions, thinking about how I'm going to source the imagery for all of these, and being able to populate all of these with, you know, like a keyword-focused, you know, long tail, short tail, all that kind of stuff. I find it incredibly boring, and I think that the easiest way to do it is by generating a lot of this with AI, or basically repurposing content with AI. So with that in mind, I want to show a very quick video, if it works. Yeah, great.

So this is essentially a very quick demo showing how you can generate each part of the title, you know, the description, the SEO, Open Graph. In our case we have something called cards. Cards for us is basically where you would reference that blog post from one part of the website to the next. Essentially, all of this functionality is done using Sanity's AI Assist, and the beauty of Sanity's AI Assist, and this is the real cool thing that I don't think enough people necessarily talk about, is the internationalisation. Right this second, there has never been an easier way to get into internationalisation. Usually, when you are actually publishing something to an internationalised audience, you have to get translators involved. You have a huge, huge, huge cost before you can even start putting stuff out there. Today, you can set up with Sanity, with Next.js for example, and have a fully internationalised website working within a day or two. So there's never been a better time to do it.

And the whole idea of AI, and this is the last thing I want to really talk about, is instead of just generating content with it, because, let's be completely real, if it's just AI-generated content, it's not very good, the main thing you want to do is focus on using it to enrich the content that you would write yourself. So using AI Assist, Sanity's AI Assist, you can basically do a hell of a lot of stuff with the content that you write and repurpose, and save all of that time that would usually get burnt doing these manually. So thanks everybody for listening today. Appreciate you taking the time out, and yeah, cheers.

Thanks Jono, that was terrific. And yeah, I think the AI Assist, it's very tough when you're looking at a blank field and you don't know what to write, but then AI writes something and it immediately evokes the feeling of "I can do something better than that". So Evelina, you're next, if you want to come up and get set up. There are a lot of Sanity people in the room. Raise your hand if you are a Sanity colleague of mine. Look at them all. If you want to bring your questions, bring your complaints, afterwards go and find them, and they will absolutely have all of the answers to all your questions. Evelina is from loveholidays, a longtime Sanity customer, and always very interested to see what they're doing.

Sorry, it's a bit scary. Okay. Hi everyone, welcome. I'll be covering a bit around how we at loveholidays ensured crisis readiness by utilising Sanity to our benefit and having non-developers power the content that builds our app and our website. Just briefly about myself: I'm a software engineer, I've been that for four and a half years now or so, and I did an 11-week boot camp. So I'm kind of an ex molecular biologist turned software engineer. I did a boot camp in Amsterdam, an 11-week boot camp. I'm not going to say I was a great developer after that, but I came to loveholidays and have learned a lot since being there.

And for those of you who don't know loveholidays, it's an online travel agency that's been around for, I guess, more than 10 years now, actually, and the vision is to become Europe's number one holiday provider. We intend to do so by giving our customers a lot of choice and the ability to mix and match their own holidays. Currently we sell holidays in the British, the German, and the Irish markets. In the next slide I'll share a little bit around how we utilise Sanity and our tech stack, just briefly, to set the context, and then I'll go into my own experience in leading this initiative called crisis readiness, and I'll also talk about what crisis means in this case.

So yeah, these are actually just some screenshots that I took of our website. That is the homepage to the left, and then to the right is one of our landing pages, and both of these are driven from Sanity completely. Well, "completely" I say; actually, in the screenshots there's, like, search and stuff like that, but I cut that out. In both content and, like, the static structure of it. We basically empower our non-engineers and non-developers to make improvements to our site as part of a rapid development cycle. You know, maybe you have more certain content driven from Sanity, but we have a lot of content driven from Sanity, and we do this basically in a server-driven UI manner, and I will talk about how that works.

This is not a deep dive at all, but it's just basically to set the context around how all this works. Our website is server-side rendered with client-side interactions and navigations. It basically means that, you know, the HTML you get when you land on a page or land on a URL is complete for that page and shouldn't change until you actually navigate. And then for our kind of JavaScript-served interaction, we use the GraphQL backend for frontend. And then in the past year or so, probably a bit longer, we've been migrating and basically, we've been inspired by Airbnb and how they actually do a server-driven UI. That means that our client, in React and TypeScript, is quite dumb. It doesn't really have a lot of logic in it, and it doesn't really know the concept of bespoke pages. So instead, per a given URL, it will basically request generic page data from the GraphQL backend for frontend. Some of that will come from the Sanity CMS, and then basically our GraphQL server will respond with typed components that the frontend will then render. And yeah, like I said, I won't talk more about this, but I have some colleagues in the audience that have built this and that are experts on this, and also on how we use Sanity in general at our company, so if you're interested in more of that, please come and talk to us later. I also reference the Airbnb blog post at the end of this talk. And yeah, I'm no expert on Sanity, but I just wanted to share a bit about my experience in running this initiative, with the help of, obviously, our dedicated web infrastructure team. I'm looking at Chris, he's the only one that's present here, but we have other people that are great at it. But yeah, with the help of them, and also, I think, just the Sanity documentation is very clear, and I sometimes find tech documentation to be a bit boring, but I found Sanity's to be very, like, entertaining. Maybe that's wrong, but you know what I mean. I found it easy to use, and I think the last time I actually used Sanity was, like, three years ago, because we have more of a dedicated team, but this was quite easy.

So yeah, how do we empower our non-developers to get ready for a potential crisis? Well, basically, I want to start with: what is a crisis in the world of travel? When I say crisis, that can be anything from, you know, wildfires to earthquakes, so anything that can actually impact customers travelling. I will share a real-life example of how this looks, and also in an unexpected way, when one of our accommodation suppliers actually went under, which is not great, but this is basically what we set out to prepare for.

In 2023 alone, there were actually four major incidents, as I'm sure you're aware. You know, there was an Icelandic volcano that erupted, there were wildfires in Rhodes, so there was a lot happening last year, and this was kind of before we had all our server-driven UI in place. And, you know, our customer experience team, they worked really hard to communicate as fast as possible and were able to manage calls and all of that, but we realised there was kind of a clear gap in how we contacted our customers and made sure that that came out quickly. If I look at it from more of a customer point of view: something happens, I'll open the chat, I'll be like, is my holiday impacted, can I still go on my holiday, and, you know, you might feel quite stressed, and there's nothing in kind of, I forgot to say it, but I work in the manage my booking team, so it's kind of, like, the post-booking experience. You'll go to your manage my booking, you go to your app, you'll see something happening, and you don't see anything. Basically, you know, earlier, how this worked is it could take up to three days for this message to get out to our customers, because we had to wait for, you know, app releases and all that. And then you see here in this graph, you can see you've basically missed the influx of customers, and also some people might have already gone on holiday, and we don't want to cause people stress, obviously, when they're going to go on their holidays.

So basically, what we did is that, pre our summer holiday peak, so this was at the beginning of May, we wanted to make sure that we are ready for a potential crisis. Obviously we hope that there are no crises, but as we can see later, this has been used already. And we worked together with a cross-functional team across, you know, customer experience, content, comms, to define what an MVP would look like. And also, it's very important that non-developers and people that are not engineers are part of this, because they're supposed to use it. So from day one we've worked with them and talked about how do you want to use this, and what should it include, and then defined the MVP.

So yeah, like I said, non-developers should manage messaging in this manage my booking homepage, which is this one, I'll talk a bit more in a second. We want to reduce the strain on our customer experience team, and then we don't want to have any app releases for this, because we don't want to rely on anyone else but ourselves to get this out. And we also want to make sure that there are some guardrails in place, obviously, because, you know, we shouldn't just be alerting our customers in case there isn't anything to be alerted about. So that is key. And also, yeah, this is just kind of a snapshot of a holiday. This is in our app. You're going to Portugal, you have your itinerary items, this is the way you can amend your holiday, you can see where you're going, all of that stuff. So the idea is that the alert would pop up here and be part of that. You'll see it in a second. But we don't want to overload that page with too much content, so this was key in defining what we're going to do with this.

So yeah, how did we get there? Obviously with Sanity. And this is kind of the main structure, so you get a little bit of insight into how this looks. We don't have all of it here, because I don't have access to all of it. But you will see here on the left side that I actually created a new MMB directory. It's for several reasons, but one of them is it's easy to manage permissions that way, because obviously not everyone should have access to this, because it's important that we are careful with this message. And also, as we scale, I talked about us wanting to become Europe's number one holiday provider, we need to think of how we scale and have that growth mindset. Previously, we would have maybe put this under, like, site content, but that would have meant that we'd have to copy it from, like, the German site to the UK site, and we're moving away from that, so this was one other opportunity to not use that.

And you'll see a little snapshot of what that looks like. Hopefully everyone can see. Like my colleague said, maybe I should have done light mode and not dark mode, and I realised that before, but I'm a developer, so I do dark mode mostly. But yeah, this is an untitled alert, which is also not ideal, but basically, how it works is that you would add a booking ID. Outside of Sanity, you would run a query, for example, you query the affected bookings, and then you would add that into this simple text field. We did talk about whether we were going to use, like, a file type or something like that, but we didn't really know how to handle that fully, and it wasn't something we had used, so we kind of decided that that simple text field is fine, because we can just add these bookings and filter through them later. We also obviously didn't know, because every crisis is different, how many booking IDs there were going to be. I think we tested around, like, 20,000, and, like, Sanity was fine with that. We were like, cool, this is going to be fine. But I'll talk later about what happened. You live and you learn.

And then, basically, next on this alert we have a headline, and we also have a message. I'll share a bit of how this looks in a second, but both the headline and the message are using field-level localisation, so you can add per language. I've not added anything here now, but you can add that per language. We're also utilising a customised field for the block content here, or the block type, where we're using just a simple paragraph and a link. Like I said earlier, we don't want to have too much content on the page. There's some custom validation around what type of link you can add, there's also some custom validation around how many characters you can add. Again, we don't want to overload. So there's been a lot of customisation going on here, a lot of descriptions to make sure that everyone understands how to use this. And then finally, we also have an optional button, which is also using field-level localisation, and this is if we need to gather more information from a customer, we want to link them out to, for example, a form that they can fill in, so we can contact them with more information.

So yeah, how does this all work in practice? Basically, this is something I kind of quickly put together, but if a crisis happens, the idea is that a non-developer can go to Sanity, add an alert quickly, and publish, and then our GraphQL backend for frontend will add this to something we call a mandatory resource. Basically, what that is, is that we fetch these resources, this data, on startup, and update that data on an interval that we set, and we've set this to 10 minutes. We can switch that, and we can have it be longer or shorter. And basically, it's very beneficial in a crisis like this, because you might need to update your booking IDs quite often, because someone goes on holiday, someone comes back, so you need to be able to get this out immediately. And then the function itself is super simple. It's basically just looping through that data, and then basically going through, doing a GROQ query, and checking, you know, is there an alert? Cool, if there's an alert, we'll do a simple lookup per booking ID and locale, and then decide whether or not to return this alert component. And then, in the server-driven UI way, we can basically server-side render this quickly to our customers, both in app and web. I didn't really speak about this earlier, but we basically write the same code for our app and for our web. We do that with the help of a framework called Capacitor JS, which is basically a framework that wraps a web app into a native app. So we've gone from three days to, like, 10 minutes, basically, if you add this alerting quickly, and it should be simple. I think that's pretty cool.

And then I just wanted to share a bit of how it looked. This is just, actually, this did not happen, this is just so I could share. I added that in, I did this, and then you would see this 10 minutes later, basically, and if I update that booking ID, I would see that in another one. So it works quite seamlessly, I would say. And yeah, we were, I guess, hoping to not have to use this, but we've already used it, like, two weeks later, and we already learned a bunch of things that we probably could have done better. But, you know, that's the typical developer life, right? You always iterate, so I think it's fine.

Yeah, I want to talk about just how we've used it and what I've learned and what we want to do next a bit more. I don't know if people are aware of, you know, loveholidays and have followed, but a bit more than two weeks ago, one of our accommodation suppliers actually filed for insolvency. That caused a lot of distress for our customers, which is not great, and this basically caused us to utilise this alert sooner, and maybe in a way we didn't really think we were going to use it. But that's the beauty of tech, I think: you can always reuse it and change things and use it as needed. So yeah, when the news broke, there was a huge cross-team functional effort to communicate and rebook the people that were actually affected. That was kind of, like, sending out SMSes, being very proactive, so we weren't waiting for people to go to the app and check, we were doing that. But then, as the news broke to a bigger audience, people started kind of confusing that our supplier was us. People thought, you know, we had gone under, so that was not great. And then our communication teams were like, okay, we should probably talk to people and communicate that this is not the case. That happened on social. And then we got an even bigger influx of customers being like, is my booking affected? So there was a lot of, you know, I feel bad for the agents that were working tirelessly to help a lot of customers, and then they get a lot of noise from people that weren't affected, and it's kind of, like, handling that. So we kind of had to think quick on our feet, and what we did is that we changed, so you could see it was kind of a red, critical, urgent alert earlier. I did just, like, a quick one-line change in our backend for frontend, because I didn't really have time to go in and change this in Sanity, and I changed that from, yeah, I didn't say that earlier, but this alert component is something we have that's powered through our design system. We have different variants for it, so it's kind of a component that works for a lot of use cases. So I just changed that from a critical look to an information look, so blue. And we did this, which, you know, it's great that we could use it. The only other thing is that, you know, we weren't really thinking we were going to send this to everyone that's not affected, so that was, like, hundreds of thousands of people, and adding that into Sanity kind of broke the UI a bit, which is fair, because, I mean, we weren't really going to use it like this. That's why you see both of the two alerts here, which are basically the same, but we just split the alerts, or the booking IDs, into two alerts.

But yeah, I think, obviously, it's not great that we had to use this, but it's great that it was in place, and I think we've learned a lot from it. I don't think we could have foreseen that this was going to happen, that we were going to use it in this way. But basically, as of last week, we've already implemented a dropdown, I can share that. No, first, I forgot this, actually. So this is how it would look. People would come in, they were like, you're not affected, you're unaffected, you don't have to do anything, like, don't worry. Also, it's very cost-effective to do this: instead of sending SMSes out to hundreds of thousands of people, we could just get this out in 10 minutes, and we could already see that people were sharing on socials to be like, we're not affected, kind of, I guess, spreading the word for us, and having people go to the app and the website and see that, you know, they're fine, because it was a subset of people, and some of them had already been booked into another hotel. So yeah, again, it wasn't great that we had to use it, but I think it's cool that it was in place, and how we planned to accomplish this in, like, 10 minutes, like, thanks to the whole infrastructure, is pretty cool.

And yeah, what's next? I've already talked about it: I've implemented this dropdown, which is kind of informative, critical. I think there needs to be some guidelines on how and when to use the alert. It shouldn't just be overly used, because, I guess, as I said, they're also kind of pushing the content down, and you don't want to, like, it's supposed to be more of, like, if there's anything the customer needs to do, or if there's something they should worry about. It shouldn't just be used to send out extra information. And then I think it's also, obviously, in a crisis there's a lot of cross-team effort, and it's kind of been some of us engineers that helped out with this. In an ideal world, this should be fully driven by non-developers. They should be able to do all of this, which they can, it's just that they have been working tirelessly on a lot of other things. Obviously, we know this, we built this, so it's not like we can't go in and update this. It's fine, happy to help, obviously. Oh sorry, I went too fast.

And then we have preview and schedule, which we're thinking about. I know our web infrastructure team have worked on this. It's basically, like, a custom field where the preview content would, in an ideal world, basically take a booking from the booking ID list, and log into a staging booking, and then you would get to see it, obviously, before you actually publish it. And then scheduling, I think, is also cool: if you know that something has happened, or you want to send out a new message on Monday morning, you just schedule it. So I think that would be pretty cool to have. And then finally, I think the North Star is that anyone can configure and control messages based on certain booking elements. So instead of having to query that in BigQuery in a different place, you would do all of that, you know, it will be clear from there. You would say these dates, this destination, this airport, and stuff like that. But yeah, this is a bigger conversation, I think, around content models in general, but I think that is something that we thought of. So yeah, thank you.

That was terrific. That was really interesting to see behind the curtain there, and another real-world application that perhaps might be a bit uncommon. I'll get Toby to come forward and start getting set up. I was just thinking through that talk: I create a lot of guides, a lot of tutorials, and I have to create different content models and have to try and think of new ones regularly, and they're usually fun examples, like record collections or holidays or learning or shopping, they're aspirational things. But I don't think I've ever once content modelled a crisis, and that's the reality, that's what's really happening out there. So a new example for the next tutorial, perhaps. But we've got Toby next from Even Six. There are a number of Even Six people in the room here today. I got a sneak peek at this earlier. This really is something. Some fancy visuals on display, and I believe a live demo too. I don't want to spook it, this will be the first one of the evening. No, no jinxing it, it's going to work flawlessly.

So this one might be a little bit controversial. How boring is structured content? Now, you know, this is obviously a bit of a biased room. Talk to a number of people, and they might say very. We're here to challenge that. Okay, we're here to challenge that. Hello, I'm Toby, technical creative director at Even Six. Now, Even Six is a digital brand and product agency, so what that means is, really, I am the creative director at Even Six. It's a single reference, you can see right there. Now, I'm also, as technically a creative director at Even Six, that's an array reference, you can see right there. That's multiple creative directors. Semantics are important at Even Six. Semantics are important for structured content. Semantics are important for Sanity.

The truth is, nobody grows up dreaming of structured content. It's a shame, I know. Equally, nobody grows up dreaming of the W3C, schema.org, page speeds, technical SEO. We grew up dreaming of what's possible. So for me, at least, the web was where that was happening. There were no limits, no restrictions, and infinite possibilities. Whatever you can dream up can be made possible. That was the promise. Have we forgotten that about the web? Sometimes I do wonder that. Like, that was a really exciting moment for all of us, when we used to look at things like Awwwards and stuff like that, and look and think, wow, that's incredible. How did that even happen? How did we do that? Let's get back to that a little bit as well. You know, sometimes I think it's exciting to show what's possible on the web. This is our corner of the web. We can do whatever we want in that place, so let's push it a little bit, is what we say.

So let's show what's possible with structured content. Rather than boring people with the benefits, I'm going to jump into what is actually possible. We believe we can leverage the power of structured content to make digital experiences more current, more relevant, and more personalised, without creating extra work for people. That is the challenge. Can we at least attempt to make structured content vaguely exciting? This could be a stretch. Let's put structured content to work, and then we can all be the judge of that, using a 3D model, because structured content, Sanity, and 3D, you have to listen to and trust Even Six on this one, are best friends.

So let's take a company like Cetti. Now, there are a few Sanity people in this room. I know that Cetti isn't a real company, but just bear with me on this one: an innovative tech-based cycling company. Now, Cetti have products, and those products, they could be a bike, or they could be bike parts. What's familiar between the two of them is the fact that they both use components. Now, we can attach a lot of structured content to those components, which is where a lot of magic can start to happen. So we could say that a component is mentioned in a review, we could say that it's mentioned in an article, we could say that that component resulted in a stat, we could say that it was manufactured by a particular manufacturer, and we could say that component has features. I'll get to the last bit in a second, but what are these components? We could have forks, we could have the levers, we could have the mechanical parts of the bike. Every single part of that bike is a component. And like I was just saying, you could have a review, and that review could be in Sanity. You might be mentioning a certain part of that component that we can see here. We might be just mentioning a particular part of a bike in an article, so somebody might be saying something about the wheels, about the saddle, whatever it might be. That can be quite light. And those result in stats, like I just said, so power increase, things like that. The specs for the bike could be, you know, how much it weighs, it could be the dimensions of it. And there are lots of stories that we can tell here, right? So if we said that this designer created this wheel for this reason, and we wrote a story about that, that can become quite engaging, particularly when you're trying to sell a bike like this, which we'll get to in a second. I think we made up the figure; it was about 10,000, so you've got to tell a few stories to try and convince somebody to spend 10,000. Okay. And yeah, it could be manufactured by a completely different brand to Cetti. It might have these different features.

But what we're here today to talk about is structured content and 3D models. So what does that mean? Well, what we have here, and this is a bit of a, the geeks at Even Six know this is not technically how it works, but we have a component which has a camera position that's attached to the component. We might well have a bike, and that bike will also require a camera position, because the bike has multiple components. Let's zoom out a little bit and show what all those component parts look like together. Now, this is all so far quite hypothetical at the moment, so what we're going to attempt to do, as Simeon mentioned, is a bit of a live demo, to show what this actually looks like in Sanity and in Presentation.

So this is all a 3D model with structured content. You can see that if I start to scroll, it can start to do some quite cool stuff. We can change the colours completely for the page, and if I just go back onto this one, you can then start to see that that component story is actually quite powerful, because now what we're looking at is the cockpit of this bike, and that is pulling some content. Now, if I go into this page just really quickly, you will see that this cockpit, this component, has literally no information in it. So why is it that there's no information here, but I'm seeing "a seamless single unit construction", all the description about that component? I can see what material it's made from, the weight of it, I can see the designer, the brand, and even a story that's related to it. Well, that is the power of structured content at work. One of the things that we can see from over here is: this is the article that references that piece of content. If I was to go into here, I can show you that somebody's done a product callout. So somebody might have merchandised this article to reference a particular product. Now, as I showed you a second ago, a product could be a bike part, which is still a component, so we can resolve all of those references, and that is how that piece of content made its way into that page, literally just by somebody merchandising an article. That's the power of structured content at work.

Okay, so now we're going to attempt some of the more dangerous parts of our live demo. Just to prove to you that this is a 3D model with all of these component parts within there, I'm going to now attempt to reorder this 3D model, and this is something that can be created so content editors could tell a more compelling story on this landing page. So what we're going to do, everybody bear with me on this one, is we're going to put the fork to the top of the page. We'll give that a second. This is the power of using Sanity and Presentation. You can start to see all of this structured content coming together and even be able to navigate it. That's what Presentation is there for. In my opinion, you can do some very complicated things. Now, hopefully that has updated. No? Yeah, it has, yeah. Cool. So yeah, so now you can see that the fork's at the top of the list. I can just reorder it, and that is because the camera position was put against the component. We're not trying to, you know, create 3D models all the time. We're trying to work smart here. So camera position, everything, is all bound to the component rather than to the bike itself.

Let's go a step further and try and do something even more complicated here, and really push it. Okay, so here we have the S600 cockpit, seamless single unit construction. Let's go a little bit of a step further, and let's see what happens. Let's pretend that Cetti just brought out an upgraded version of that cockpit, and that is an array list. This is set up so it can actually play quite nicely as a product configurator. Here we have the S600 cockpit V2, and I'm going to publish that. It's really, really tested now. Okay, so just look at that. There's nothing on the top of that cockpit. I feel like a magician right here. Here we go. So does everybody have their fingers crossed? So here we go. Now you'll notice that product can just be updated. It's a component part, so you can update that from a single place. That bike has multiple components. I can update a component part of that bike, and everywhere that I show imagery or 3D for that bike can be updated from a single source of truth. That is my attempt to try to make structured content exciting for everybody. It was a short talk, but hopefully you all enjoyed it. Yeah, that is the end of my talk. Thanks.

I think that absolutely succeeded. The flash is back. Oh, now I have to get set up. So what you saw there is also our demo that Even Six helped us out with, that's great. Maybe at some point you can buy those bikes. If the content management stuff doesn't work out, we can pivot to bikes. Let's see. Yeah, there you are. All right.

So we have been doing stuff the last six months or so, and what we very often notice when we go on about it is that people didn't read our email about the new thing. They weren't aware that we did the thing. And to catch you all up, and amend for that, we have, I think we have 96 slides, so I hope you didn't have to catch any flights. Yeah, we'll let you know what we have been working on, and some future stuff, some stuff even available in the future, and a thing we shipped today while we were here. So yeah, give me 10 seconds. All right, excellent. Yes, I talk quickly, so we can get through 96 slides very quickly.

All right, so today's talk is called Sanity is cooking. Who's used Sanity for at least a year? Keep your hand up. Three years? I've been at Sanity for three. Got some for five? I started five years ago, 2019. Looks like everyone tapped out. All right. So I've had the pleasure of being at Sanity for the last stretch. Now we have this locales repo, which is really clever. Some of our engineers hooked that up with AI, so there are AI-powered translations of new strings as they're added to the Studio, and you can also localise your plugins as well, so anything that you ship. Let me present, share screen. I don't need to narrate this, but I will: share, click, wallpaper, alt tab. Excellent, we're back.

The validate documents CLI. You can now validate a dataset. Previously this was a very difficult thing to do across all documents; you had to validate documents one by one, and that can be quite slow and annoying, but now you can just run this command across the entire dataset. Is that a video that's going to run? No, but you can run that from the command line, and it will show you the status of all of your documents there. And this was an important step to get us towards TypeScript support, I believe, the ability to just check all documents in the dataset. Because even though you write those validation rules in the studio, the data stored in the Content Lake is not guaranteed to be one-to-one with what your studio says. So the studio can be a lie, and the Content Lake will send you anything, because you can write anything you want to the Content Lake. So it is important to be able to validate documents against your studio markup, and it will tell you, oh, the video is playing, it will tell you what's valid and what's not, what you need to go back and fix. This is also excellent for migration, because the content that you pull out of some other service is likely broken in some way, and so to be able to migrate thousands of documents into the Sanity Studio, into the Content Lake, and then validate the status of them, is very important as well. Thanks, YouTube.

Comments are now on by default, in the January 19 release. So comments, one of those things that, I'm really excited about comments in the Sanity Studio because of how boring they are, in such a way, like, they just work. There's not really much to them, but they have been a huge unlock of productivity in the studio. Just one of those features that, once we shipped it, you just assume they've always been there, because it was so useful to use.

The desk was renamed structure. You might see that deprecation in some of your imports as well. Small thing, but we did also ship a codemod to go and rename that in your code, so if you don't want to change two lines in your studio, we can do it for you. And we also added a union cache to GraphQL deploy. Who knew that? I didn't know that, and now I do, and it apparently improves schema generation up to 95%. Again, these are the things you just miss out on if you don't trawl the changelog every week.

We got deprecated fields. Now, I'm not sure if anybody's used this, but this has been really useful when you've got a really long-lived project. If you have been using Sanity for five years or so, you've probably got all sorts of hairy data that you need to get rid of and get editors to stop using. You can mark it as deprecated. It has no functional effect on the data, but it at least gives a nice big scary warning to somebody, and you can tell them not to use this field anymore and to use something else. You can deprecate document types, you can deprecate singular fields.

We also shipped comment reactions, because those are extremely important for boosting morale, and sort of giving that thumbs up. To me, the thumbs up emoji has a double meaning now. It's like, please stop talking, this conversation has ended. That's what the thumbs up emoji means to me.

The all-new Sanity Studio design. This one could be a bit spicy, actually. If we wanted to put an emoji reaction on this one, maybe a hot pepper would be good, because it completely changed the design of it. I won't ask for a raise of hands, who loves it, who doesn't, but I think, now that it's settled for quite a while, it's great. Redesigns of applications are very difficult. The team put an awful lot of work in to clean up the studio, and it does look cleaner, and I know certainly it's grown on me. It's reduced the visual noise that was there before. Everything kind of looks very big in some of the old studio screenshots you'll see here as well.

There's some migration tooling that we've launched as well. This has been really awesome. They are migration tooling helpers, so that you can create migration scripts. Previously, if you needed to migrate content inside of a Sanity Studio, and this is more thoughts around long-lived projects, where you need to change data structures, if you've ever had to change a single reference to an array of references, if you've needed to change a string to a portable text field, those can be quite tricky things to do. So now we have these migration helpers to create these scripts for you. They will do the more difficult things, like batching transactions together. They also have a sort of secondary usage, and again, it's where my mind's at at the moment, which is actually using them for migration tooling as well, because they do handle bulking together transactions. They can be very useful for creating new documents at scale as well.

I'm not sure why that slide's there. No, schema validation, that's different, isn't it? We were looking at document validation before, so now we're going to do schema validation at the same time, to check if there are any issues in the schema. I think this was also a stepping stone towards our TypeScript support. Usually when I do these meetups, I'm one of, like, two people from Sanity in the room, and now that there are more of you here, I've got this pressure on me that maybe some of the things I'm saying aren't true, and when there are no engineers in the room I can just say that stuff and you believe me, and now there are engineers in the room, I'm a little bit worried. It's useful for migrations as well, schema validation, so that's excellent. All right, great.

AI Assist version two launched, which actually was mentioned in one of the talks tonight as well: the ability to translate documents. There was a lot of work put in to make sure that the AI Assist was configured to work with all of the different ways that you can localise content. We do realise that there are a number of ways: you can do document level, you can do field level with objects, field level with arrays. The translation with AI works with all of those, it is designed to work with all of those, which is excellent. And it's very much designed to just be the fastest path to be able to translate documents and translate content and have it write straight to the studio. If you need more options, other providers are still useful for that, and that's why there's still support for those, but if you just need the fastest possible translations in the studio, you click that button and it will do that straight away.

We launched comments in the portable text editor as well, in March here. So now you can actually select short snippets of text and be able to write comments directly on individual pieces of text inside portable text. That wasn't shipped with the first version of comments, but it is there now.

There's the ability to weight searches against particular fields, and there was an update to document actions too. So when you are writing Sanity schema types now, you can infer that some fields have a higher weight than others when you are searching in the studio for those things. So perhaps when a person's searching for documents of a particular type, you want to make sure the name field carries more weight than the description, for example. That's one. And now this next section, this is the one that I am certain nobody knew existed, outside of the engineer that made it, for the person that they made it for: your document actions can actually appear out here now. Why? I don't know, but when you write a custom document action, if you want it to be in the top pane there, it can. So that's really great. You couldn't do that before, and now you can, and we're really just ticking off all of the most hotly requested features, so I'm very, very excited to show that one off tonight.

Persisted user settings, a change that you might not have even noticed, but just an absolute quality of life upgrade for editors. That is, when you have desk lists, desk lists like these, and you're able to sort them and set these settings, these settings are actually saved server-side now, so that if you refresh the browser, you log in from a different computer, those settings will actually be retained. Where it used to be, I think, that was written to local storage, so perhaps only that browser would save those settings; now those are saved to our servers, and that opens up the gateway for us to save a lot more per author, and make sure the studio is much more configured to that person.

TypeGen. This is probably one of the biggest headline features launched in the last few months, and definitely among the most popular feature requests, this one. This GitHub issue going back to 2020. There have been a lot of community efforts around this, and efforts even by our own engineers, and so there's been some amount of tooling out there for quite a while, but we needed to have something. So we sort of looked at those as early work, and certainly our work builds on the shoulders of those, but the solution had to be twofold for us to be really happy with it, and that was: one, to be able to generate types from schema, and types from queries. Because, again, the content that comes from the Content Lake can be different to the content in your Sanity Studio, because maybe your GROQ query reshapes the content. So to be able to generate types from schema was to be able to extract the schema down to a JSON representation, and then be able to generate TypeScript types off of that schema. So now, when you are creating schema like you always have, you extract that out to a JSON file, which then you can generate these types off of. This really solves one side of the equation, which was really, really useful, to have types based on your schema.

But the part that I know personally I was really excited about was the types from GROQ queries, because this is really the power of the platform, and that was brought up in one of the talks tonight as well. It's one thing to be able to structure content in one way in the studio when you're authoring it; to be able to reshape that into whatever application is going to consume that content, that's the real power of GROQ. And so that we can generate types from GROQ queries that just do anything with your content is really excellent as well. You do need to make sure that you're prefixing your GROQ queries with the groq template literal, like is being shown at the top there, and it will generate these types with the typegen generate. It does mean that you do need to keep running that generation script every time you change your schema or change your queries, but at least you do get up-to-date types. And with that configuration down the bottom there, it does mean that if you've got your studio and your front end in different repositories, different folders, sorry, it means that you can sort of read from one source and export to another. So really excited to land that one, and I know that was hotly requested, and a huge quality of life upgrade for developers.

Tasks shipped in April. This was in beta, I believe, but sort of a fast follow-up to comments was the ability to assign tasks to people. This has both the benefit of having authors work together in the studio, not having to work outside in some other application and then bring their work into the studio, but also it can block publishing, so a task needs to be complete in order for something to be published. So it's just really great to bring that stuff into the studio, instead of having to do your project management over here and your content editing over there. You can do it all in the one place.

We launched enhanced search on April 16, which actually was disabled shortly after, but it probably will come back. It's going to be a server-side search of your Sanity content that ought to be much more powerful than just the client-side search, so something perhaps to look forward to in the future.

We have presence cursors in portable text, which also came out. So you've got multiple authors. Sanity's always been multiplayer. I know multiplayer is the new hotness, but Sanity's kind of just always been like that. But now we have this in the portable text editor as well, so you can see cursors inside of portable text and see which author is where in the document. Comments and tasks came out of beta as well in that release, so they're considered stable.

Scheduled publishing is now part of the core Studio package. This used to be a plugin, but we consider it valuable enough that it sort of needs to be inside of every studio, so you'll always see this.

You can now save query results from Vision out to CSV files and JSON. This was brought up by one of our engineers in a recent online meetup that we had. You've got these little save buttons down here on the right-hand side, so you can export those queries out really quickly, which is excellent.

Another one of those things you might not have missed and may never need, but if you have a custom component inside the Structure Builder, it can now handle intent links, which, if you've ever needed that, that's so thrilling, and if you haven't, then terrific, keep living your best life. But yeah, you can drop any custom component, so that's a Structure Builder thing: you don't have to show our document editor there, you can just drop in any React component you'd like, but this now allows you to make sure a link from somewhere else in the studio will respect and find that component. So that is actually really, really cool.

We now sync back to Shopify metaobjects. The Sanity Shopify Connect application has been around for a while, but we continue to work on that as well. It's probably the simplest integration we have from Sanity to something, to be able to get product data from Shopify into Sanity, but now we're writing content back as well, into metaobjects. Some people want all that content in Sanity, some people want all that Sanity content in Shopify. We are doing much better to support both use cases now, and that Connect app keeps getting better and better.

The Actions API launched only recently as well. It's a high-level alternative, it sits on the Mutations API. A lot of what the studio does in document actions, so create, duplicate, creating a new draft when you start typing in a published document, a lot of that was just studio client-side logic. The Content Lake didn't actually know what it meant to create a draft for a published document; that was something that just happened in the studio. Now all of that happens server-side. Probably the biggest pain point, I know personally, for me: if you've ever used Sanity Client to patch documents, and you've wanted that logic of "I want to patch the draft if it exists, otherwise create a new draft from the published version", that's usually required a lot of logic that you've had to do yourself. You have to query the document first, find out if there's a draft; if there's not, you have to create one from the published document, set your revision, and do all of that. But now we have actions to be able to do that and much more. So everything you saw in document actions, a lot of the logic that you saw in the studio, that's all now done server-side. This opens the gateway to build even more complex applications outside of the studio that do studio-like things with your content.

So that's a really quick recap of most of the big feature releases in the last six months. Some of the things that you've seen there, though, require the Growth plan, so the comments and tasks. But if you ever need to try that, you can spin up a brand new project immediately, and you do get this upgrade to be able to try out all those features. So if you are trying to put this in front of somebody, this has been a difficult thing in the past; you're sort of just describing to them some of our marketing points, but now you can actually show these things, because a brand new account will get a 30-day trial of all of those features. So you will actually get to try tasks and comments and all of the best features when you start a new project, and spinning up a new project is free and instant from the command line, so spin up as many projects as you like to try those things out.

Sanity Learn is also something new that got launched as well, and this is where I've been spending my time recently. I know I've spoken to some of you already about the learning platform. This is a Remix application that we've got running now in production. It is where you can go and have your hand held through the journey, start to finish, of, say, setting up a new front end, trying out the schema migration tools, trying out TypeScript, learning more about structured content, putting a team together. There are sort of some conceptual, project manager style things in there, there are some very developer-oriented things there. And it's also the path towards developer certification, which will be launched for all developers later this year, but we're working with agency partners first to get certifications done. The certification exam is complete, and we will be in touch soon with a few people to reach out to first, but we're going to want to start seeing some Sanity certified developer badges on your LinkedIn profiles very soon.

Sanity Create also launched quite recently. This is a whole new app; this is our first other app that we've launched, and it's a distraction-free writing environment that is made better with AI. This is an example of some of the things that you can do, and as you can see, it's a much cleaner experience. It is built on Studio technology, but it is not the Sanity Studio. Anybody can just start a new Create project inside of the application, so you get those sorts of usual text editing features that you'd expect, sort of much cleaner than writing in the studio, but we also get this ghost writer thing off to the side here. We've got more of the text formatting features being shown here, but you can see the little icon off to the side. It happens in this, or maybe the next one. Is there not a video of the AI actually working in this? Who cares about AI? Okay. It is really quite amazing, let's just go back here. The big difference is you can set up these notes that allow you to set context for the writing that you're authoring. So beyond using all of Anthropic's models and understanding, you can give it your own context, your own understanding, what's important to you, and then it will help you finish sentences, it will help you write things out. I mean, the Sanity developer certification process was assisted with AI there, to help sort of write out what was that going to look like, what was a programme going to look like, and it does really ease the editing process, and you still write something that's very unique to what you are trying to do.

The next set of slides are really important things that are now true, particularly for people who've used Sanity for quite some time. It sometimes surprises me, having conversations with people who have used Sanity for a while: perhaps you tried something once, and that's how it worked, and that's how it's always going to be. And I know I'm like that: you try a new software tool, and if it didn't work right the first time, you sort of walk away, and years later still believe that that's how it is. But I just wanted to debunk some myths about the things that are no longer true, and things that are now true.

Visual editing is available on all plans. When it launched, it was Enterprise only, and when it launched, it was only on Vercel, Enterprise only. And so Vercel still have some documentation here, but you can do visual editing on anything that you like. The "only on Vercel" bit is that they will add overlays to your preview builds and you get sort of their editing widget thing, but really, this editing experience here, you can do that on any front end, and you can deploy that anywhere. And if you've got, like, a dynamic server-rendered app, you can put it into an editing mode just like this, and have that click-to-edit, which is really excellent.

Visual editing is simpler to set up. This has been an ongoing effort by our developer team, certainly with our educational efforts, to try and make clear how much simpler this is. It did used to require many different things all to be set up in a row. You do only have to set up the server-side loader, and you can put something in your front end to sort of do the refreshing for you. If you want it faster and better, you can also add this client-side loader, and it will give sort of sub-second updates inside of the Presentation tool. But yes, there are fewer dependencies, fewer requirements to get that started, but we still have really fast, really excellent live preview if you want it.

Presentation is now the best place for live preview, and my heart sank a bit earlier when I saw that Youssef had the iframe pane. This is how previews have always been shown, and I'm not saying you can't do that anymore, and the iframe pane is still fine, so I really should have deleted this next slide. Sorry, it's having a nap, like Remix. Again, yes, so I mean, it's not entirely dead, but it is better to put it into Presentation, and we still have built a bridge between documents being edited and the Presentation tool. So when you use that locations API, you get links at the top of your document there that will take you to the Presentation tool, and then you have this icon at the top right here that will take you back to the document. So even though you are hopping out of that document editing flow, you still can navigate between those two documents. So yes, while the iframe pane still does work, and sadly, I should have retired on the iframe pane. I think it's my most popular npm package of all time, it is literally shipping an iframe out of a React component that took a URL as a prop, but I think it's my greatest contribution to open source, as it still is, and now we've killed it, so thanks.

You don't need to filter drafts out of queries. Again, if you've been using Sanity for a while, you probably wrote queries like this. If you had an authentication token in your client, then it would return draft documents, and you had to add that to your query. You don't have to do that anymore since we've launched perspectives. Perspectives will filter drafts in or out of your queries as well. So you can protect your draft documents with a published perspective, but you can also make sure that drafts overlay your published documents when you want to, with this perspective, and that's set on the client. So just a few things that are no longer true.

The Live Content API. This is something we've shipped recently, and this is among the more exciting things I've seen us ship recently. And I feel like, if you think you've got feature requests at Sanity, you should see our internal Slack. I think I've got you all covered. And this is yet something that I don't think I ever really thought that I wanted. We've had live preview for draft content, and we've had listeners to be able to sort of listen with the API to changes as they come in, but what the Live Content API does is it gives you a way to add a small amount of client-side JavaScript and listen on the query. And what this allows you to do is actually pull live, up-to-date content, not from the API but from the CDN. So your client-side application can be made aware there has been a change made to this published document, because it's tracking the query and the params that you're using, and when those changes occur, it sends you some tags. You just send a request back to the server and say, run that query again from the CDN, but use this tag, and it will give you live, up-to-date content. And so this is far better than the previewing content, the draft content preview, because that requires authentication. It's far better than the listeners, because that hits the API. This is live, almost real-time updates from the CDN, and it's entirely secure; it doesn't require authentication. And so it's actually used on the Sanity Learn app: if you complete a task in one browser, it will update another browser, even though the query for your progress is a private query being run server-side, because the client can be made aware this query and parameters has been updated. There's a demo here. This is in a Next.js application, but again, this can work in anything, but this is the experience that you weren't able to do easily before. You sort of had to hit the API to get this fresh data, or you would have to sort of wait a few seconds for the CDN to update. Now you can do things like a live blog, or sport scores, or anything like that. Hit publish, and now the website is updated with that content, and, again, for the fifth time, it's coming from the CDN, not the API, and I think that's really cool. It unlocks a whole new bunch of possibilities where perhaps you'd use Firebase or something like that to do that instead, and you'd have to have your data somewhere else. Now you can do that from right inside of Sanity.

Don't tell anyone, especially those listening on the internet. We're streaming this online and telling anybody not to share it, but hey, this is what we're also working on. A lot of people have made their own custom blocks for the selector of the array items. I think this might have shipped today. This shipped today, so this is not under construction, this is out there. So the add item dropdown is now searchable, it has tabs, it has custom preview components. We know you love building page builders, so let's just lean into it.

Another hugely requested feature: the ability to copy and paste blocks between documents as well. This is one of those things that I think every Sanity engineer has a proof of concept laying around on a branch somewhere, and it's just never gotten together to ship it into the product. Well, we're going to ship that into the product, most likely sometime soon.

Another pet project that I think we've all got a version of, and certainly, I did a demo of this three years ago, which partly got me my job at Sanity, was a bulk editing view. I think bulk editing views are known as the widowmaker internally, because everybody's had a go, and then you just reach that spot where it's just too difficult. But this is actually under active development, which is really, really exciting as well: to be able to make bulk edits, and be able to see things in a table view.

And we have one more, on the array selector. What even is this one? Oh yeah, this is that nested item view. So instead of having to drill down through modals, which, you modal, modal, modal, modal, modal, and have to click all the way down, what if you could just navigate your entire array of objects in a tree view like this? This is going to make getting through those complex arrays of objects and page builders much simpler to do as well. So that is also under active development with our design and engineering teams.

And one more thing that isn't visually very interesting, but is just a command here: sanity build auto-updates. So what about shipping a studio that pulls in its own updates and keeps itself up to date? Because we are shipping, we are cooking at the moment, so a studio that doesn't require you to redeploy and run npm upgrade, that would be a great benefit as well. So auto-updating studios: under active development.

The next one might need some discerning. We've got some GROQ here, but it is the top line of the GROQ that we need to pay attention to. You've always been able to run functions in your queries, but you've not been able to define functions before. So this sort of brings a whole new level of complexity to your GROQ queries, and options that you've not had before. You don't have to wait for us to ship new functions if you just want to write your own. So user-defined functions in GROQ queries is also being actively worked on as well. Just don't tell anyone you heard it from us. Is it useful? Why is it useful? Are you asking me? You have already made an answer for this. I have an answer. Can you tell me why it's useful? I could make up something, but then I'd fall on my face. Yeah, that's true. So the initial draft of this just looked like fragments, like you might be used to with GraphQL, but at some point we realised that actually being able to write your own functions to do what you like inside of that, instead of just writing small individual queries and then sprinkling those queries through, that you could do something much more dynamic. And so this allows you to resolve a block any way that you want, and sort of run much more logic in there as well. It's a very simplified example, but you might be able to already imagine the more complex handling you could do of things, say, accepting if the type is this, then resolve it like that. I know those things are very useful for things like resolving links, resolving internal links, to be able to give a different slug structure based on the type of the reference. So yeah, all sorts of use cases for that once that ships, and very exciting to see as well. And that is slide 94, that's slide 95, we're done.

And that's it for proceedings. So I'm not sure if Knut, if you had any more closing comments, but thanks again to our lovely hosts for tonight, this has been excellent, and thanks everybody for turning up as well. A massive turnout, and yeah, really cool to see everybody. Come and ask us questions afterwards. I'll hand over to Knut to finish.

I am amazed that, like, it's two minutes left, so, like, we ran fine. Yeah, again, thanks to everyone who came, thanks to everyone who watched the stream, thanks to Alexander and I that came from Norway to be here to represent, thanks, and thank you very much to the speakers. We have some swag for you somewhere. There's some Sanity swag around, some coasters, some GROQ, yes, maybe some GROQ rocks socks or something left, stickers. Make sure to grab some; we don't want to take swag home, basically. There's still sushi and drinks. I don't know, like, when will they kick us out, you can, like, do a Berlin style party until the early hours, whatever. Okay, awesome. But yeah, feel free to stick around, talk to the speakers, interrogate them about how they did things, talk to us, and have a good time.

## Frequently asked questions

### How do you migrate content into Sanity when you don't have back end access?

Web scraping. Jono argues it's underused: you can scrape an existing site and pipe the content directly into Sanity to populate documents. For the client Jam, with 4,500 products and 200 interlinked blog posts whose categories all changed mid-migration, Roboto hit 100% migration coverage through scraping alone, without ever touching the old back end.

### What's the hardest part of migrating an old website?

The connective tissue. Internal links between pieces of content are very difficult to carry over, and images, old image tags, and existing categories are all tricky too, especially when categories change as part of the migration. That's exactly the kind of relational data Jono recommends recovering with scraping rather than manual copy and paste.

### How do you integrate services like YouTube or HubSpot with Sanity?

Pull their APIs into Sanity as their own document types. YouTube videos can land directly in the Studio, where you can enrich them with related content like blogs, instead of copy-pasting details by hand and introducing typos. For Techaro, Roboto integrated HubSpot so editors just reference a form, with a cron job keeping the data fresh so it's always the latest forms.

### Should API-synced content and hand-edited content live in the same documents?

No, split them. Jono's advice is to separate editable content from content that's pulled in from an API, because syncs can be destructive and you don't want them overwriting things people have written by hand. He also suggests pairing APIs with a scraper when they're missing data, like Wistia, which offers podcasts and videos over its API but no transcripts.

### What does "set and forget SEO" mean with Sanity?

Using the structured content already in Sanity to automatically populate JSON-LD for Google, since Google just wants your content in a format it can run with. Sanity's TypeScript generation works hand in hand with the schema-dts tool, so you can combine your Studio data with the structure Google expects. Futurepedia's pillar content worked this way: editors never saw a single curly bracket, yet every page shipped with the JSON-LD behind it.

### How do you handle BBC-style hierarchical URLs where content lives in multiple places?

Roboto built a custom URL builder where every step of the URL resolves its own content, so /latest shows the latest posts, /latest/local-news pulls the latest local news, and so on down the structure. They built this for Global Cycling Network and it underpins the whole project, feeding things like breadcrumbs. It lets editors scale content completely without a developer, though Jono admits it's tricky to build and only really achievable because of what GROQ queries can do.

### Is AI-generated content worth using on your website?

Not on its own. Jono is blunt that purely AI-generated content isn't very good, and the real value is using AI to enrich and repurpose content you've written yourself, like meta descriptions, Open Graph text, and reference cards, via Sanity's AI Assist. He also highlights internationalisation as the standout win: with AI Assist and Next.js you can have a fully internationalised website working within a day or two, instead of paying translators up front.

---

## Cutting through the jargon: demystifying Sanity


> Developers throw around technical terms that mean nothing to the people paying for the project. In this Sanity.io virtual meetup talk, Jono walks through the strategies we use at Roboto Studio to explain Sanity clearly to clients who don't code for a living.

**Published:** 2022-09-28 | **Updated:** 2026-08-11 | **Categories:** Talks

Watch: https://www.youtube.com/watch?v=ahBzwCVcqMM

---

## Transcript

Cool, so this is the cutting through the jargon and demystifying Sanity talk. So, a little introduction: my name is Jono, I'm the founder of Roboto Studio. I've been a founder here for five years, and I am a massive enthusiast in structured content, and I'm a vocal cat parent, so the cat on the left is Kiki, the cat on the right is Kevin.

How I got inspired to actually write this talk and sort of communicate all the different bits and pieces that's inside of here: we had a lot of clients come to us with kind of a mystification around Sanity, trying to understand exactly how Sanity works, how the bits and pieces fit together, and we wanted to essentially write this up to give kind of like an all-encompassing, very high level overview of how we've personally worked with Sanity. And it's been, you know, a great learning curve to understand what bits are missed out from the general knowledge about headless.

So I thought I'd start with one of the things that keeps getting essentially popped around on the Slack channels, which is structured content. If you've had the opportunity to check out the event recently, it was very, very cool. But I kind of have a lot of people actually ask me about structured content, and I'm probably going to upset a lot of people here by saying this, but it's just data. It's essentially data that is constructed in such a way that you're able to mix and match. And essentially, in the old days, the way that websites used to work, they used to have a very rigid, monolithic (and I'll come back to monolithic a little bit later) way of having a title and the description and then the main body of text, and that would typically be your content management system experience. However, now we're having much more of a focus on kind of narrative and the way that we actually structure our websites to be really tailored for customers, and structured content is kind of like a great aid to that. It's the ability to kind of shuffle around all the pieces of content and make sure that everything looks the way you would expect it to look as a client, and kind of pass over visuals in certain ways. So there was a great talk by one of the founders at Sanity where he talks about e-commerce sites, and one being a luxury one versus one being just a very simple "look at this, the size of this mole and the dimensions of it". So if you can think about that, that's the same thing with structured content.

And this brings me on to a content lake. Now the content lake is the one that we found that clients find the most confusing, and to be honest with you, I don't blame them to a certain extent. A content lake is very, very powerful if you sell kind of more the strategy behind why you would use one, more so than the actual core functionality of what one does, because the core functionality is very ethereal in my opinion, and to most clients I believe it feels the same way. So a content lake being more of a means to an end is kind of the way that we talk about this quite a lot, and I hope you'll see why in a second.

So let's go for a real world example. So I've just a few seconds ago had a little Google, because I didn't know the exact numbers about these, but you want to put out a social media post that's of your website. You've put out a new blog post, you want to share it on LinkedIn, you want to share it on Twitter, you want to share it on Facebook. So we've all been on LinkedIn and we've all seen those terribly cropped little thumbnails that you see inside of the feed, and I kind of want to give some sympathy to why that happens, and kind of a bit more of an explanation for most people that aren't developers. So this is generally how it usually goes for an end client, and I think it's very important to sympathize with this and understand why it works like this, to be able to kind of improve it in the future.

So you decide you want to make a blog post. You work out what your image wants to be, and you start to work on, say, Photoshop, and you work out which platforms you're using. So if you're using, let's go for the big three, let's go LinkedIn, Facebook, Twitter. So you go onto Photoshop, you read a little bit on the internet and you say, oh it's, what is it, 1200 by 630 I think it is for Facebook. So you set up a canvas, 1200 by 630, you build the image out, you export it for the web. When you're exporting for the web you probably export something like PNG, JPEG, and you upload the image inside of your content management system. And then as soon as you do that, you share the blog post and you realize it's the wrong size. Now you're back to square one. So that is typically how it goes, and that's typically how you get something in LinkedIn where you realize it looks beautiful on Facebook, terrible on LinkedIn.

So the content lake, in my opinion, is really well suited for this, and this is kind of the key point that people, because they have these pain points, they have these experiences. So let's take it again in a very similar manner. When we say we're going to build an image in Photoshop, we're going to leave a little bit of space on each side for cropping, we're going to export the image for the web, so everything's pretty much the exact same as the first time. We upload the image, and then this is where the real magic of the content lake works, which is that you've essentially got multiple (providing you obviously put the code in there from a development side), but you have multiple different queries that you can use to have multiple different croppings of the same image. So having that version where, if you look on LinkedIn, it looks fantastic, pixel perfect. You have it on Facebook, pixel perfect, and the same with Twitter. Every single version of this blog post looks fantastic now. Because there is that essential pain point with this previously, and there is a lot of people that have had this pain point, it's a great example to kind of explain how the content lake works. I know there is a lot more information that can come from the content lake. There's a lot more to do with CDNs, and there's more to do with file distribution and everything else, but the real core thing here is what will probably happen for most clients on a day-to-day basis, and this is a good example for us.

Which kind of moves me on to the next part of why I explain with clients how Sanity works and why it's a little bit different. And again, this is in my opinion, so this isn't the official terms, but Sanity is a code-based content management system, and that is something that I really want to hammer across whenever we talk to clients. The reason being is, I'll show you the opposite first: a GUI based content management system. So I'm guessing you've probably, most people have probably used these as a developer, and they're fantastic for certain things. They're fantastic for things like a very simple blog, a very simple page builder, but again, the more they kind of scale, the more it becomes problematic. But the real benefit of these things is that they're easy to get started with, and the problem that comes at a later date is the ability to kind of validate your schema. And again, by saying validate schema, the way your actual page gets built, the validation of that is kind of very important to emphasize.

Comparatively, the code-based, so we're coming back to Sanity here, you have this ability for it to be far more customizable. And again, explain it to clients about the fact that you can take a relatively simple thing like a conditional. So say you want to have a link that works externally and a link that works internally. You might say that, oh, you know, not many things support the idea of a conditional where, if you want to go and put an internal link, which again we can use something like Next.js where it improves performance, they will definitely be on board with the performance side from the SEO basis. But again, it's going back to this idea of defining the actual benefits you get rather than the core functionality, rather than the declarative things, you know, code based, scalability, they're all very ethereal.

So talking about this, we'll go on to GROQ. And now when I first heard it, I did think it was genuinely like some goblin name or something like that. Sounds pretty fun. But essentially GROQ is kind of one of the most, I guess, misunderstood things when we talk to clients about this. Because I think if you use, going back to the same idea, the principle of a pain point, you could say something along the lines of, we have GROQ, you know, there's a real issue with GROQ, sorry, real issue with crop, there's a real issue with performance on websites. And say for example you're taking all the data from all the different pages, all the different blog posts, that's a real issue, because you have to have something compute and read through all of that, and you also have to take the data for all of that. Whereas if you have something like GROQ, you have the ability to kind of whittle down content and make sure that it's very intelligent in the way that you're only pulling essentially the data that you need for the page at that time.

Portable text. So I'm going to ruffle a couple of feathers on this one as well. So portable text is an incredible tool and we think it's absolutely fantastic. It's been one of the things that really differentiated Sanity for us as a platform. But every client we speak to with portable text, it's not at the forefoot, the forefront, sorry, of thought as to when to use this, because it is quite a hard thing to explain as to when this is actually useful. And now for us, one of the things that we always say is, with portable text it's the idea of extending out a rich text editor. So you're essentially adding the ability to do a lot of incredible stuff for the client. And I tell you exactly the way that you might potentially speak about this, is that you say, we're working as, you have a traditional website, you have a traditional blog. What you keep seeing is a common theme, a common design practice, is midway down the page, somewhere after a particularly interesting paragraph, you might get a little newsletter sign up box. Now in the old days, the way that you would do this is by doing it where, for example, it just says, we'll have to, let's say, 500 characters or something along those lines, we pop in a newsletter box. Now with portable text, you can extend the granularity or the control of portable text, and you could literally have inserting a newsletter field where you feel it's necessary on the blog posts. And again, the same applies with related content. Kind of pinning those ethereal ideas into something that is a very tangible, very common design language principle is a great way to basically explain a lot of the functionality there.

So again, we're going back to why does it matter, and it brings it down to these three things, which is performance, scalability and maintainability. So we always talk about performance, and usually when we're talking about performance, there is an arms race at the moment for everybody to try and get the world's fastest website, which is great, but ultimately it's a means to an end: to have a much more accessible experience, to have a much better journey, and to have a much better search engine ranking. So essentially we use those three points rather than kind of "oh, it's just performance". And again, with scalability, it's a return on investment. You build the website, you want to make sure that when you have this website, you have something that you can really build on top of and use for more than just one or two years. And the same with maintainability. This kind of rolls into the scalability aspect, which is that you can consistently keep building block after block after block onto the website. So again, seen it time and time again, the idea is that these pain points are really, really important to contextualize why you're using a headless content management, why you do all of these development features, and it's very, very important to try and help the client choose the correct tool. Two seconds, little water break, apologies, I've been on the talks all day.

And so I thought we would do questions we've been asked by clients, because it's very, very common that we get hit by these. So, how's the editing experience? Now this one comes up quite a lot. I thought I'd go for a little bit of a Family Feud, if you're from America, or I think it's Family Fortunes in the UK, it's basically the same game. But how's the editing experience? This comes up every single time whenever we work with a client, because editing experience, in our opinion, is the be-all and end-all of how much a client appreciates a content management system. And so with the ability, and with thinking about how you actually structure these, I would always advise: spend a little bit of extra time on doing things from a user experience perspective. So the whole idea of having accessibility on Sanity, having things like, something that really makes a difference in our opinion is preparing fields, and using fields where you can actually throw in a title or an image or an icon, something that just basically boosts your work above, you know, the norm. So making a better user experience overall is going to make you seem like a better developer, and as for how this actually works with a client, the editing experience is phenomenal.

Maintainability. Again, we're saying this, we've gone through this a little bit, but essentially the maintainability of working with Sanity is fantastic. Very, very rarely, it's only because we're having such a quantum leap from V2 to V3 that there has been, you know, somewhat of a migration process. For ever so long it's been consistent, and it's been, you know, you wouldn't have to require to do any migration process. So the maintainability is absolutely top-notch. And that, paired with the headless aspect of it, with for example Next.js, there's very, very little other than updating packages that an actual client would need to do. So again, kind of talking about that side of it is always very helpful.

Headless. Headless gets asked as one of our most common questions. So headless has talked about a lot. What it actually means to a client is a totally different kettle of fish. So when you're actually talking about headless to a client, remember this pure and like this core technology kind of exists in a very development heavy environment. So a good way of kind of describing this and ensuring that everybody is on board with this is explaining the difference between monolithic and headless. I think there's a real value to be taken from that, to be able to explain how a technology that you use today might not necessarily be the most viable technology a few years from now for the front end. Or, for example, you may want to use your content management system to multiple different locations, to apps, to other different places. So kind of pushing that idea of the outcome of this, rather than the core functionality, is always very important in my opinion.

Time to market. Again, the beauty of working with Sanity, the beauty of working with Next.js and other headless frameworks, and, you know, for example Gatsby, the time to market is really, really fast. So you are essentially testing very quickly, and again, talking about A/B testing, Optimizely, all that kind of stuff. You can take what is a very simple website from start to finish in a very short period of time, and again, clients are really going to appreciate that honesty about how this would work.

Sanity V3. Of course, we absolutely love this. We're really appreciating it at the moment. We've had a go with a couple of different environments, and it's always great to stay up to date with these kind of things. Explain the developer experience and how that kind of knocks on to the end client. So for example, development experience is better, it means you get a faster turnaround, goes back to the time to market. It's a great way of talking also about the extendable components, but again, not just talking about extendable components, what that actually does to the end clients. So for example, there was a great one on Sanity's documentation where they talk about an opening and closing day from Monday to Friday. Having something that is very, very easy for data entry like that, it makes a massive difference for somebody.

Performance. Now surprisingly, this is a bit of a misnomer one. So we have a lot of people talk to us about performance, but it's very much something that is just a known. It's, after a certain point, less important than the actual designer, the core content management experience, in our opinion. I know that's a bit of a controversial take, but essentially, once you start hitting the 90s, I think people are more interested with how they would actually interact with the website, and more interested with how the editing experience is. Again, this is just completely anecdotal from what we've experienced in the business.

And ultimately, you know, why should we pick Sanity as a content management system? So usually, whenever we have clients come to us, they're debating between two, three different headless content management systems. So what I would always do, just in general, is brush up on other systems, have a look at all the different versions. Ultimately, we've been a big backer of Sanity because, ultimately, ninety percent of all the headless content managed, well, this is completely plucked out of thin air, but the majority of content management systems that we've used, the headless, are almost always a GUI based content management system, which means they'll have issues with scalability. So understanding how that affects a client is very important, especially long term, when you're talking about 100 page websites, 200 page websites.

And then finally, how's the customer experience? So this one actually comes up quite a lot, because we've had a lot of people that have potentially been burnt by other companies. So kind of the reinforcement, and personally the same, I had an incredible experience with Sanity from day one with the community. So I've had a lot of people talk to me, both community members and members of the Sanity team. So it's always great to be honest and say, look, this is a thriving community, speak to some of the people on there, get in touch. Because ultimately, we find that transparency and that honesty about how the tool works, go speak to some of the people in the community, is a great way to essentially win over somebody onto the, you know, the Sanity CMS.

So essentially, that's all the different ways that we would typically approach a client to ensure that everything is absolutely top-notch when we're talking about how we will build a website. So I hope that's helped for somebody that's, you know, aspiring freelancers, or anybody that's going out there to start their own agency. And yeah, thanks for listening. Does anybody got any questions?

Thank you so much, Jonathan. I think you inadvertently started a campaign for making a goblin mascot for GROQ, that's apparently going to happen now. We got one question from Ethan in the chat: are you using the dev preview with clients already? We're using it currently with three separate clients, and we are using it, we have an internal CLI system that basically spins up an environment for us. And we were a bit hesitant, so to anybody else that was considering actually doing this, I was very, very hesitant to run with a development environment with a client, but we have found only one or two bugs with it so far, and to be honest with you, they're fairly like negligible bugs. It's been probably the most solid development preview we've ever experienced. So yeah, I would highly recommend doing it. It's a bit living on the edge, I think Sanity naturally told us that, but it's definitely worth doing. I would definitely recommend it, at the very least check it out in your own time, development wise.

All right, I know you have a very nice blog post about your experience with V3 on your website, which I encourage everyone to check out. Let's see, what are the most challenging terms or concepts to explain about Sanity? Are there some that are just so inscrutable you don't touch it? Oh, that is a good question. Let me think about this for a second. So I think not so much Sanity, but I think something that's very difficult to overcome is somebody that's been burnt by a headless content management system, which does happen to us quite a fair bit. So a lot of our work is actually refactoring to get a headless content management system working, most of the time, and as much as I wouldn't like to say this, it usually does end up having to be a rebuild, because of, you know, previous opinionation and such. So for me, the biggest things that typically come up is: we've used this headless content management system before, we've been burnt by it, how do we know we're not going to get burnt again with Sanity, how do we know it's not a flavor of the month, you know? And I think, if you want my honest way that I would respond to this, is, you know, explain the focus on structured content, explain how they're very much pushing for the user experience, content management wise, which is pretty much unprecedented as far as I'm concerned. For kind of like the whole, well, running an entire event over it is a good example of as to why to use it. So yeah, I guess that would be the trickiest one that comes up, and it does come up quite a lot. I have a feeling that would be something that you might get questioned about if you go into freelance.

That's a very interesting angle. It's kind of like teaching them to love again after being hurt. Yeah, yeah, absolutely. Did you have one? Yep, so I loved your talk. Canoe in the chat said the Sanity marketing team is all eyes and ears, and it's so true. It's like, this is bridging that gap between the content editors and the developers, and so a lot of great content. But what do you find is like the most common aha moment for your clients, and like when does it finally click for them? At what point do you find that most common? I think, do you know what's a great winner for this, in my opinion, is the previews. So previews specifically with Sanity are really impressive. So we always advise anybody that wants to get a nice vote of confidence is get an environment that works with, in our specific way, we always build with Next.js, so I'll speak from a Next.js background, but having a Next.js preview available with an editing experience on the side of it, and the real time seeing that when you make changes it appears on the left and right of the screen, is hugely, hugely valuable. So understanding kind of what the day-to-day life would be of a marketing person that comes along, wants to build a website and wants to edit the website, and trying to basically wow them the most. So yeah, the iframe pane, I think it was incredible for that. That makes sense, that's a good one. Yeah, I love that functionality as well.

All right, thank you so much, Jonathan. You can find Jonathan and Roboto Studio on Twitter, and we'll share his link, and you can also find Jonathan in our community Slack. Great stuff, thanks for having me on both, take care. Thank you, Jono.

## Frequently asked questions

### How do you explain structured content to a client?

Jono's view is that structured content is just data, constructed so you can mix and match the pieces. Older monolithic CMSs locked you into a rigid title, description and body of text, whereas structured content lets a client shuffle content around and tailor how it presents. He suggests grounding it in examples, like the same e-commerce content presented as a luxury experience versus a plain spec sheet.

### What is the content lake, and how do you make it make sense to non-developers?

Jono finds the content lake the concept clients struggle with most, so he sells the strategy rather than the core functionality, which he admits feels ethereal. His go-to example is social sharing images: normally you export one image at a fixed size and it looks great on Facebook but terribly cropped on LinkedIn. With the content lake, you upload one image and query multiple crops of it, so every platform gets a pixel-perfect version.

### Why does he call Sanity a code-based CMS rather than a GUI-based one?

GUI-based systems are easy to get started with and fine for a simple blog or page builder, but they get problematic as they scale, particularly around validating your schema. Sanity being code-based makes it far more customizable, down to simple things like a conditional field that switches between an internal and external link. His advice is to explain the benefits clients actually get, such as SEO and performance, rather than reciting terms like scalability.

### How do you explain GROQ and portable text to a client?

For GROQ he starts from the pain point: pulling all the data from every page hurts performance, and GROQ lets you whittle content down so you only fetch what the page needs. For portable text he frames it as extending a rich text editor, using a familiar design pattern as the example: instead of a newsletter box appearing automatically after 500 characters, an editor can insert one exactly where it feels right in the post.

### What convinces sceptical clients who have been burnt by a headless CMS before?

This comes up a lot for Roboto, and much of their work is refactoring (often rebuilding) botched headless projects. Jono's response is honesty: explain Sanity's focus on structured content and its unusually strong push on editor user experience, and point people at the community. He finds transparency, telling clients to go and speak to community members themselves, is a great way to win them over.

### What is the most common aha moment for clients?

Previews. Jono says real-time previews with Sanity are really impressive: Roboto builds with Next.js, and having the editing experience on one side of the screen with changes appearing live on the other is hugely valuable. His advice is to think about the day-to-day life of the marketing person who will edit the site and set out to wow them with that experience.

---

# Tools

## Crosspost keyword opportunity bot


> It finds community sites that outrank you for your own keywords and drafts a response you can post for a second touch point.

**Category:** bot | **Updated:** 2026-08-11

## Links

- Related service: /services/geo

---

## What it does

The crosspost bot looks at the keywords you already care about and finds the community threads ranking for them. A Reddit thread sitting above your own page in the results is the exact case it hunts for: threads that outrank you get a scoring bonus and arrive labeled with their position, like "outranks us (SERP #3)". The bot surfaces those threads as places where you could add something useful.

For each one, it drafts a reply you can review, edit, and post yourself. The bot never posts anywhere on its own.

## How it works

The bot starts from your tracked keyword list, expands it with related searches and people-also-ask phrases filtered to buying intent (recommend, best, vs, migrate), then runs the searches and extracts every community thread from the top results. It scores each thread on topical relevance, question intent, and SERP position, with the biggest bonus reserved for threads that outrank your own site. Hiring posts, resume threads, and show-off posts are disqualified, and a dedupe ledger suppresses anything it already surfaced in the last 30 days.

The survivors are capped to a weekly top five. For each one it drafts a reply in a disclosed, no-pitch voice, run through a quality gate that rejects AI-sounding drafts before they reach you. You review and post; the bot does the mining and the first draft.

## What you get

A weekly shortlist of community opportunities tied to your real keywords, each with a draft you can edit and publish. Every run reports in, even a quiet week, so you know it looked. The threads are already winning the search. The bot gives you a reason and a starting point to show up in them.

## How we set it up

We build and run it as part of our [AI SEO and GEO service](/services/geo). The setup covers connecting your keyword list, calibrating the scoring so the shortlist matches your expertise, and tuning the reply voice so drafts sound like your team. It runs on a weekly schedule and delivers the shortlist for review rather than requiring anyone to go looking for it.

---

## hotrod


> Our open-source agent-first Astro starter for sites built and maintained by coding agents like Claude Code and Cursor.

**Category:** starter | **License:** MIT | **Updated:** 2026-08-31

## Install

```bash
git clone https://github.com/robotostudio/hotrod
```

## Links

- Preview: https://hotrod.robotostudio.com
- Source: https://github.com/robotostudio/hotrod
- Related service: /services/agentic-websites

---

## What it is

hotrod is an Astro 6 starter built for sites that a coding agent will build and maintain. The conventions, file layout, and content schema are arranged so Claude Code, Cursor, or any other coding agent can ship pages, posts, and updates without fighting the framework or producing inconsistent output.

Content lives in `src/content/` under strict Zod schemas for three collections: pages, blog posts, and author profiles. Build failures are intentional when schema validation fails, so an agent gets immediate, precise feedback instead of shipping a malformed page. Images go to Vercel Blob, video to Mux, so binary files stay out of the repository.

The guardrails go further than most starters: meta descriptions are Zod-enforced to 80 to 220 characters, so an agent that writes a lazy one-liner gets a build failure, not a quietly bad search snippet. Our own instance runs at [hotrod.robotostudio.com](https://hotrod.robotostudio.com).

It is the practical side of our work on [agentic websites](/services/agentic-websites).

## What you get

- An Astro framework foundation with Tailwind CSS, Geist font, and a yellow-cab-themed design system.
- Strict Zod content schemas for pages, blog, and authors, with build-time validation.
- Auto-generated Open Graph images via Takumi, with no manual image creation needed.
- Built-in SEO: meta tags, JSON-LD structured data, sitemaps, and RSS feeds.
- Explicit allow-list for AI crawlers (GPTBot, ClaudeBot, PerplexityBot, and others).
- Markdown twins for blog posts plus `llms.txt` and `llms-full.txt` indices so AI tools can read the site's content.
- Icons and the web manifest rendered at build time from a single source design, alongside the Takumi OG images.
- External media storage via Vercel Blob and Mux, so binary files never touch the repository.

## How to use it

Clone the repository and install dependencies.

```bash
git clone https://github.com/robotostudio/hotrod
cd hotrod
pnpm install
pnpm dev
```

The dev server starts at `localhost:4321`. Add your Vercel Blob token and Mux credentials to the environment variables if you plan to use the media upload workflows.

## How we use it

hotrod is the starting point for our [agentic website](/services/agentic-websites) projects. A coding agent handles the ongoing editing and maintenance rather than a CMS editor.

---

## OG image generator


> Free open graph image generator running turbo-start-sanity's OG template live. 1200x630, 1080x1080, and 1080x1350 PNGs, no watermark, no sign-up.

**Category:** generator | **License:** MIT | **Updated:** 2026-08-21

## Links

- Source: https://github.com/robotostudio/turbo-start-sanity
- Related service: /services/sanity

---

## Generate an OG image

Type a title, pick a ratio, download the PNG. That's the whole tool.

### Generate one without the browser UI

The form calls a public GET endpoint. Request it directly for a PNG:

```text
GET /api/og-playground?ratio=og&title=Your%20title&site=Your%20site
```

| Parameter | Values | Default |
| --- | --- | --- |
| `ratio` | `og` (1200x630), `square` (1080x1080), `portrait` (1080x1350) | `og` |
| `title` | up to 120 characters | `Never design an OG again` |
| `site` | up to 40 characters | `Turbo Start` |
| `pill` | `0` hides the badge | shown |

The response is a PNG. No key, no sign-up, no watermark.

## What's rendering it

This is not a canvas mockup. Every preview is a live render from [turbo-start-sanity](https://www.sanity.io/templates/turbo-start-sanity)'s OG route, the same `ImageResponse` code the template ships, running on this site's edge runtime with a year-long immutable cache in front of it. The card you download is pixel-identical to what a site built on the template serves to crawlers.

The three sizes cover the jobs that matter: 1200x630 for link unfurls everywhere (X, LinkedIn, Slack, iMessage), 1080x1080 for square feed posts, and 1080x1350 for Instagram portrait.

## Want it automated instead

Downloading PNGs one at a time is fine for a landing page. For a site, wire the route in so every page gets its card generated on demand. The code is MIT-licensed in the [turbo-start-sanity repo](https://github.com/robotostudio/turbo-start-sanity), and [Never "design" an OG again](/blog/one-og-template-every-aspect-ratio) walks through extending this exact template to render every aspect ratio from one design, with real benchmarks and the production failure modes.

If you'd rather someone else wire it up, [that's what we do](/services/sanity).

---

## Page updater bot


> A background agent that researches new information and updates a page to match. Our own CMS freshness bot is a tailored version of it.

**Category:** bot | **Updated:** 2026-07-27

## Links

- Related service: /services/agentic-workflows

---

## What it does

The page updater bot uses background agents to research a subject and update a page to match new information. The use cases are wide: a pricing table that drifts out of date, a comparison page that needs checking against a competitor's changelog.

Our own CMS freshness bot, the one that keeps our migration comparison pages current, is a tailored version of this.

## How it works

The bot watches a set of pinned sources per page, fetches them on a schedule, and compares what it finds against the current content. It works primary sources first: the vendor's pricing page and changelog before review platforms, and community chatter last. When it detects a material difference, it opens a pull request with the exact before-and-after diff, each change carrying a quote and the source URL it came from. Nothing goes live automatically. The agent handles the research pass; a person reads the diff and makes the call on whether to merge.

Two rules keep the changes honest. Every edit must cite a source the bot actually fetched that run, or the edit is dropped. And it can correct a stale fact inside a criticism, but it is blocked from deleting the criticism itself, so a price update can never quietly soften a judgement.

## What you get

The agent watches the sources, drafts the changes, and opens the pull request. Your team reads a sourced diff instead of doing the research themselves. Our own version runs two passes: a weekly sweep that verifies the volatile claims, prices, plan names, dated market claims, across every comparison page, and a deeper weekly rotation that gives the stalest page a full research pass.

## How we set it up

We build it in-house as part of our [agentic workflows service](/services/agentic-workflows). The setup covers identifying which pages and sources to watch, writing the comparison logic that matters for your content type, and configuring the review flow so changes land in a place your team already looks. Retainer clients get it running alongside the broader automation work.

---

## pointer


> Our open-source Next.js and MDX starter for marketing sites. Pages are MDX files composed from React components, managed as code in git.

**Category:** starter | **License:** MIT | **Updated:** 2026-08-31

## Install

```bash
git clone https://github.com/robotostudio/pointer
```

## Links

- Preview: https://pointer-roboto.vercel.app
- Source: https://github.com/robotostudio/pointer
- Related service: /services/nextjs

---

## What it is

pointer is a Next.js 16 starter for marketing sites where the content lives in the repository rather than a CMS. Each page is one MDX file in `content/pages/`, each post one file in `app/blog/posts/`, and both compose the same library of React components. There is no database and no runtime fetching: everything is statically generated at build time. You can see it running at [pointer-roboto.vercel.app](https://pointer-roboto.vercel.app).

The component library is the part that makes it usable for a full marketing site rather than a blog with extra steps. Hero, Feature, CTA, and stats sections cover page layout; pricing, testimonial, changelog, and feature cards cover the blocks that usually get rebuilt from scratch on every project; FAQ, logo cloud, callout, and button handle the rest. A pricing page is a few nested components in an MDX file, not a bespoke route.

Because content is code, everything git already does applies to it: full history, review on a pull request, a preview deployment per branch, and a coding agent that can edit pages without a CMS API in the way.

It runs on React 19, Tailwind CSS v4, and Zod v4, and it's the starting point for our [Next.js development](/services/nextjs) work.

## What you get

- File-based MDX content for pages and blog posts, with no CMS or database to run.
- A composable component library covering heroes, features, pricing, testimonials, changelogs, FAQs, and logo clouds.
- A blog with categories, filtering, and post-to-post navigation.
- Dynamic Open Graph images generated per page with custom fonts.
- SEO built in: sitemap, `robots.txt`, RSS feed, and JSON-LD structured data.
- System-aware dark mode with a light and dark toggle.
- Static generation throughout, so builds are fast and pages ship as static output.

## How to use it

Clone the repository and install dependencies.

```bash
git clone https://github.com/robotostudio/pointer
cd pointer
pnpm install
pnpm dev
```

Component props and examples are documented in `docs/MDX_COMPONENTS.md` in the repo.

## How we use it

pointer is where we start when a client needs a marketing site their developers will maintain in git, rather than an editorial workflow that calls for [Sanity](/services/sanity).

---

## Sanity documentation bot


> Ask it anything and it reads your documentation and your site's code to give a rich, grounded answer.

**Category:** bot | **Updated:** 2026-07-28

## Links

- Related service: /services/sanity

---

## What it does

The Sanity documentation bot answers questions about your product by reading your documentation and your site's code. Ask it anything about how your schema works, where a field comes from, or why a page renders a certain way, and it works through the source material before it answers.

The answers are grounded in your own material.

## How it works

When someone asks a question, the bot searches your documentation and code at the same time. It pulls the relevant sections, cross-references them, and builds an answer that cites what it found. If the code and the docs disagree, it surfaces both. It stays current with your codebase because it reads the live source rather than a snapshot.

## What you get

A bot your team and your users can ask in plain language, that cites its sources and keeps pace with your codebase as it changes. Editors and developers both use it. Questions that used to mean a full search through the repo take seconds.

## How we set it up

We build it in-house, typically as part of a [Sanity website development](/services/sanity) engagement. The setup covers connecting it to your documentation and your codebase, tuning how it searches and ranks what it finds, and giving it a way to stay in sync as your project evolves. Retainer clients get it wired in alongside the broader build.

---

## sanity-plugin-asset-source-openai


> Our open-source Sanity asset source plugin that generates images from OpenAI on the fly, right where you pick assets.

**Category:** plugin | **License:** MIT | **Updated:** 2026-08-19

## Install

```bash
npm i sanity-plugin-asset-source-openai
```

## Links

- Source: https://github.com/robotostudio/sanity-plugin-asset-source-openai
- Package: https://www.npmjs.com/package/sanity-plugin-asset-source-openai
- Sanity Exchange: https://www.sanity.io/plugins/sanity-plugin-asset-source-openai
- Related service: /services/sanity

---

## What it is

sanity-plugin-asset-source-openai adds OpenAI image generation as a native asset source in Sanity Studio v3. When an editor opens the asset picker on any image field, they see an extra tab alongside the file upload and existing media options. They write a prompt, generate an image with DALL-E, and it lands straight in the asset library.

The distinction from sanity-plugin-image-gen is where the generation surface lives: this one slots into the asset picker itself rather than a dedicated field action. If your editorial flow already centers on the picker, this fits in without any extra steps.

## What you get

- OpenAI image generation as a first-class asset source tab in the standard Sanity picker.
- Generated images saved directly to the project's asset library, available for reuse.
- Simple API key configuration with no extra infrastructure needed on the server side.
- Compatible with Sanity Studio v3 schemas and field types.

## How to use it

Install it from the Sanity Exchange or from npm:

```bash
npm i sanity-plugin-asset-source-openai
```

Then register it in your studio config with your OpenAI key:

```ts
// sanity.config.ts
import { defineConfig } from "sanity";
import { openaiImageAsset } from "sanity-plugin-asset-source-openai";

export default defineConfig({
  plugins: [
    openaiImageAsset({
      API_KEY: "your_api_key_from_openai",
    }),
  ],
});
```

Keep the key in an environment variable and read it in at config time; avoid committing it to source control.

## How we use it

On projects where editors do most of their work through the asset picker, this fits the generation step into a workflow they already know. We open-sourced it so other teams building Sanity studios can add the same capability without writing the integration from scratch.

---

## sanity-plugin-image-gen


> Our open-source Sanity Studio plugin for generating images with AI, directly inside the studio, through your own Next.js API routes.

**Category:** plugin | **License:** MIT | **Updated:** 2026-08-19

## Install

```bash
npm i sanity-plugin-image-gen
```

## Links

- Source: https://github.com/robotostudio/sanity-plugin-image-gen
- Package: https://www.npmjs.com/package/sanity-plugin-image-gen
- Sanity Exchange: https://www.sanity.io/plugins/sanity-plugin-image-gen
- Related service: /services/sanity

---

## What it is

sanity-plugin-image-gen puts AI image generation inside Sanity Studio v3, wired through your own Next.js API route. Editors open any image field, pick "AI Generate" from the asset source menu, write a prompt, and pick from up to four generated options. Nothing leaves the studio to reach a separate tool.

Because the plugin calls your API route rather than hitting a model directly, you decide which model runs, how prompts are processed, and what the bill looks like. Out of the box it supports FLUX via Replicate, with `flux-schnell` as the fast default and `flux-pro` available when quality matters more than speed, and TypeScript types throughout. It needs Node 18+, React 18, and Sanity Studio v3.

## What you get

- AI image generation available on any Sanity image field, no custom field type needed.
- Aspect ratio control across four presets (1:1, 16:9, 4:3, 3:2) and four size tiers.
- Up to four variants per generation, so editors can pick without regenerating.
- Negative prompt support for steering the model away from unwanted elements.
- Full integration with Sanity's asset pipeline: generated images land in your project's media library.
- TypeScript types throughout, with no runtime surprises.

## How to use it

Install it from the Sanity Exchange or from npm:

```bash
npm i sanity-plugin-image-gen
```

Then register it in your studio config, pointing it at your Next.js API route:

```ts
// sanity.config.ts
import { defineConfig } from "sanity";
import { imageGen } from "sanity-plugin-image-gen";

export default defineConfig({
  plugins: [
    imageGen({
      apiEndpoint: "https://your-nextjs-app.com/api/generate-image",
    }),
  ],
});
```

The API route itself uses `@ai-sdk/replicate` and sets `REPLICATE_API_TOKEN` in your environment. The README has a full route example if you want to start from there.

## How we use it

This plugin came out of our own need to keep AI image generation inside the editorial workflow on client projects. When a team is already editing in Sanity, adding a separate generation tool adds context-switching without much benefit. We open-sourced it so anyone building on Sanity can wire in the same pattern without starting from scratch.

---

## sanity-plugin-md-notes


> Our MIT-licensed Sanity plugin that turns a .help.md file next to any schema into a native help panel for editors.

**Category:** plugin | **License:** MIT | **Updated:** 2026-08-19

## Install

```bash
npm i sanity-plugin-md-notes
```

## Links

- Package: https://www.npmjs.com/package/sanity-plugin-md-notes
- Related service: /services/sanity

---

## What it is

sanity-plugin-md-notes lets you drop a `.help.md` file next to any Sanity schema file. Editors then see a native help panel in the document inspector, the editor-pane view tab, and the kebab dialog, all driven by the same markdown file. The notes are version-controlled alongside the schema, so they stay in sync without a separate CMS or wiki.

The plugin is opt-in at the schema level. You wrap a schema with `withHelp()` once; help panels only appear for schemas that explicitly ask for them, even if a stray `.help.md` file exists nearby. This makes it safe to add to an existing studio without affecting documents that don't need help copy.

## What you get

- One `.help.md` file drives three surfaces: inspector panel, view tab, and kebab dialog.
- Schema opt-in via `withHelp()` so panels never appear where you didn't intend them.
- GFM tables, fenced code blocks with copy buttons, admonitions, heading anchors, and inline video embeds for Loom, YouTube, Vimeo, and Wistia.
- Singleton-friendly helpers (`helpDocument` / `helpView`) for documents built via `S.document()`.
- Bundler-agnostic: works with Vite, Webpack, and Turbopack via a CLI codegen step for the latter.
- The widest compatibility range of our plugins: Sanity Studio v3, v4, and v5, with React 18 or 19.
- An optional "Edit on GitHub" footer link, auto-detected from `.git/config` via the included Vite plugin.

## How to use it

Install it from npm:

```bash
npm i sanity-plugin-md-notes
```

For a Vite-based Sanity studio, register the Vite plugin and then wire up `helpPlugin` and `withHelpDefaultDocumentNode` in `sanity.config.ts`:

```ts
// sanity.config.ts
import { defineConfig } from "sanity";
import { structureTool } from "sanity/structure";
import { helpPlugin, withHelpDefaultDocumentNode } from "sanity-plugin-md-notes";

const helpFiles = import.meta.glob("./schemaTypes/**/*.help.md", {
  eager: true,
  query: "?raw",
  import: "default",
}) as Record<string, string>;

export default defineConfig({
  plugins: [
    helpPlugin({ files: helpFiles }),
    structureTool({
      defaultDocumentNode: withHelpDefaultDocumentNode(),
    }),
  ],
});
```

For Next.js / Turbopack setups, the plugin ships a CLI that generates a file map at build time instead of using `import.meta.glob`. The README covers both paths in detail.

## How we use it

Content models on real projects tend to accumulate edge cases that developers understand but editors don't. Putting that guidance in a wiki means it drifts out of date or never gets read. Keeping it in a `.help.md` file next to the schema puts it where the decision was made, in the same diff, and surfaces it exactly where the editor is working.

---

## sanity-plugin-roboto-ab-test


> Our open-source Sanity plugin for authoring A/B test variants directly in the studio.

**Category:** plugin | **License:** MIT | **Updated:** 2026-08-19

## Install

```bash
npm i sanity-plugin-roboto-ab-test
```

## Links

- Source: https://github.com/robotostudio/sanity-plugin-roboto-ab-test
- Package: https://www.npmjs.com/package/sanity-plugin-roboto-ab-test
- Related service: /services/sanity

---

## What it is

sanity-plugin-roboto-ab-test gives editors a way to author and manage A/B test variants from inside Sanity Studio v3. Installing it adds an `abTest` document type to your schema. Editors create test entries that attach variant content to a page, then a Next.js middleware reads a cookie to decide which variant to serve on each request.

The pattern keeps experiment content alongside the rest of the document, rather than in a separate tool that only developers can access. Variants live in Sanity, get the same editorial workflow as any other content, and don't require a code deployment each time something changes.

## What you get

- An `abTest` document type added to your schema, with a matching structure list helper for the studio sidebar.
- Cookie-based variant assignment via a small Next.js middleware snippet the README supplies: visitors are bucketed once, then rewritten at the edge to a `/test/[variant]/[slug]` route.
- Because the variant is chosen by an edge rewrite rather than client-side JavaScript, there's no flicker on page load, and the README ships the full variant page implementation with `generateStaticParams` so each variant pre-renders.
- Content for each variant stays in Sanity, so editors can update copy without a developer involved.

## How to use it

Install it from npm:

```bash
npm i sanity-plugin-roboto-ab-test
```

Then register it in your studio config, specifying which schema type the tests attach to:

```ts
// sanity.config.ts
import { defineConfig } from "sanity";
import { abTest } from "sanity-plugin-roboto-ab-test";

export default defineConfig({
  plugins: [
    abTest({
      schemaType: "page",
    }),
  ],
});
```

You will also need to add `abTestStructureList` to your structure builder so the document type appears in the sidebar, and wire in the middleware snippet from the README to handle cookie assignment and URL rewriting.

## How we use it

Running an experiment usually means either a developer writing variant logic in code or an editor working in a tool that is disconnected from the CMS. This plugin puts both sides in the same place: variant content lives in Sanity, editors can adjust it on their own schedule, and no code deployment is needed to change copy.

---

## SEO AI bot


> A weekly agent that audits your analytics platforms, condenses everything into one place, and hands you the next steps to take on your site.

**Category:** bot | **Updated:** 2026-07-27

## Links

- Related service: /services/geo

---

## What it does

The SEO AI bot audits the analytics platforms you already use, pulls out the signals that matter, and condenses them into a single weekly read. Instead of five dashboards sitting open and half-checked, you get one clear view of what changed and why.

It runs on a schedule, every week, without anyone having to remember to look.

## How it works

The bot connects to your existing analytics sources, things like Ahrefs, Google Search Console, and PostHog, and compares a rolling two-week window against the two weeks before it. It flags the pages that moved, then verifies each one with a live fetch, checking the status code, canonical, and title, so it never reports on a page it hasn't actually looked at. Every movement gets a verdict: confirmed, partly explained, or ruled out, ranked by the size of the opportunity.

The output is a versioned HTML report that looks identical every week, so you compare data instead of re-learning a layout, plus a short list of the five priorities for the week posted where your team already reads. The report only goes out once the deploy is confirmed live, so nobody clicks through to a broken link.

## What you get

Five prioritised next steps a week you can actually act on, written in plain language and grounded in your own data. Alongside the readable report, the bot writes a machine-actionable markdown twin of the plan, so you can point a coding agent at it and say "action these." The bot does the reading and the triage so your team can spend its time on the work rather than the wrangling.

## How we set it up

We build and host it as part of our [AI SEO and GEO service](/services/geo). The setup covers connecting your analytics sources, calibrating the thresholds that matter for your site, and making sure the weekly output goes to the right people. Retainer clients get it as part of the ongoing relationship.

---

## turbo-start-contentful


> Our open-source Contentful + Next.js starter with a page builder, Shadcn UI and Turborepo.

**Category:** starter | **License:** MIT | **Updated:** 2026-08-31

## Install

```bash
git clone https://github.com/robotostudio/turbo-start-contentful
```

## Links

- Preview: https://contentful.robotostudio.com
- Source: https://github.com/robotostudio/turbo-start-contentful
- Related service: /services/contentful

---

## What it is

turbo-start-contentful is the Contentful counterpart to our Sanity starter. It connects a Next.js 16 App Router front end to Contentful's headless CMS, with a component-driven page builder, Shadcn UI primitives, and the same Turborepo monorepo structure we use across our starter templates.

The content model ships ready to use: page builder blocks, a full-featured blog with rich text, and live preview of draft content via Preview Mode. Contentful handles image optimization automatically, so the asset pipeline works without extra configuration.

It is the base for our [Contentful development](/services/contentful) work, open-sourced so any Contentful project can start from a known-good foundation.

## What you get

- Next.js 16 App Router with TypeScript and React Server Components throughout.
- A dynamic page builder for flexible content layouts, connected to Contentful's content model.
- Full-featured blog with rich text rendering and custom component support.
- Live preview of draft content via Contentful's Preview Mode.
- Shadcn UI components on Tailwind CSS v4, with SEO metadata, a dynamic robots.txt, sitemaps, and structured data baked in.
- Generated TypeScript types from your Contentful schema via `pnpm --filter web typegen`, so a content model change surfaces as a type error.
- Ready-made content types for pages, blog posts, global settings, navigation, and reusable sections like heroes, CTAs, FAQs, and feature cards.
- Turborepo monorepo with task caching, so unchanged packages skip rebuilding.

## How to use it

Clone the repository, install dependencies, and point it at your Contentful space.

```bash
git clone https://github.com/robotostudio/turbo-start-contentful
cd turbo-start-contentful
pnpm install
```

Add your Contentful Space ID, Content Delivery API token, and preview access token plus preview secret (Preview Mode needs both) to `apps/web/.env.local`, then run `pnpm dev` to start the local server. There's a live demo at [contentful.robotostudio.com](https://contentful.robotostudio.com).

## How we use it

It is the starting point for our [Contentful engagements](/services/contentful). When a client already has Contentful and needs a front end that fits their existing content model, we branch from here.

---

## turbo-start-sanity


> Our open-source Sanity + Next.js page-builder template. A type-safe monorepo with a real editorial experience, ready to clone and ship.

**Category:** starter | **License:** MIT | **Updated:** 2026-08-31

## Install

```bash
npm create sanity@latest -- --template robotostudio/turbo-start-sanity
```

## Links

- Preview: https://sanity.robotostudio.com
- Source: https://github.com/robotostudio/turbo-start-sanity
- Related service: /services/sanity

---

## What it is

turbo-start-sanity is the starter we reach for on most Sanity builds. It pairs a Next.js 16 front end with Sanity Studio 6 in a single Turborepo, wired up with a flexible page builder, visual editing, and type safety that runs from the GROQ query through to the React prop. It runs on React 19 and Tailwind CSS v4, and you can see it live at [sanity.robotostudio.com](https://sanity.robotostudio.com).

The monorepo holds a web app and a studio app under one roof, with a shared `sanity-blocks` package that keeps block schemas, GROQ fragments, and their React renderers in one place. It ships with a blog system, custom document types for pages, FAQs, and redirects, and an editorial experience editors can use without help from a developer.

The part worth studying is the query file. The first hundred or so lines of `packages/sanity/src/query.ts` define the base GROQ fragments everything else composes from: `imageFields` (asset ref, LQIP preview, a four-way alt text fallback, hotspot and crop), a `customLink` fragment that resolves internal references and external URLs into one `href`, and a rich text fragment that layers the link handling into portable text mark defs and inline images. Higher fragments nest the lower ones, so a blog card is the image fragment plus the author fragment, and the page builder projection is one fragment per block type, each imported from the block's own package. Every query in the project projects images, links, and portable text the same way, and a fix to any of them lands everywhere at once. When you add your own document types, extending these fragments instead of writing ad hoc projections is what keeps the type safety and the editorial experience intact.

It is the foundation behind our [Sanity website development](/services/sanity) work, open-sourced so you can start from the same place we do.

## What you get

- A page builder your editors can use without a developer explaining every field.
- Generated TypeScript types for every query, so a schema change shows up as a type error before it ships.
- Visual editing and live preview wired up out of the box.
- A blog system with rich text, table of contents generation, and responsive layouts.
- Shadcn-style UI components on Tailwind CSS v4, with SEO metadata, sitemaps, and structured data included.
- Markdown twins for every page (append `.md` to the URL) and generated `llms.txt`, so AI assistants can read the site as plain text.
- Redirects managed as Sanity documents, so editors can fix a moved URL without a deploy.
- Playwright smoke tests and CI workflows included, plus seed data to import so the demo content is one command away.
- Sensible project structure that holds together past the first ten pages.

## How to use it

Initialize a new project with the Sanity CLI. It scaffolds the full monorepo, prompts for a project name, and connects to your Sanity account.

```bash
npm create sanity@latest -- --template robotostudio/turbo-start-sanity
```

From there: `pnpm install`, copy the `.env.example` files in `apps/web` and `apps/studio`, and run `pnpm dev` to get the Next.js front end on port 3000 and the Studio on port 3333. You'll need Node 22.12 or later. To start with content in place, import the bundled seed data:

```bash
cd apps/studio && npx sanity dataset import ./seed-data.tar.gz <your-dataset> --replace
```

## How we use it

It is the starting point for our [Sanity engagements](/services/sanity). When a build calls for something bespoke, we branch from here rather than from an empty folder.

---

## turbo-start-shopify


> Our open-source headless Shopify starter: Shopify + Sanity + Next.js with visual editing and a type-safe Storefront API.

**Category:** starter | **License:** MIT | **Updated:** 2026-09-22

## Install

```bash
npx create-sanity@latest -- --template robotostudio/turbo-start-shopify
```

## Links

- Preview: https://turbo-start-shopify-web.vercel.app
- Source: https://github.com/robotostudio/turbo-start-shopify
- Related service: /services/shopify

## Used by

- [Slingshot Bio](/case-study/slingshot-bio)
- [Jamb](/case-study/jamb)

---

## What it is

turbo-start-shopify is the starting point for stores that have outgrown a theme. It puts a Next.js 16 front end in front of Shopify, with Sanity Studio v5 handling the editorial content the Shopify admin was never designed for, and a type-safe Storefront API layer connecting the two.

Three systems that are often bolted together awkwardly are set up here to work as a single project: commerce data from Shopify, editorial content from Sanity, and a React front end that renders both. Visual editing works across the Sanity-managed pages, and the Storefront API integration covers products, collections, cart, and checkout.

It is the template behind our [headless Shopify development](/services/shopify) work, open-sourced so you can see exactly how the pieces fit together.

## What you get

- Products, collections, cart, and checkout wired to the Shopify Storefront API 2025-01.
- Sanity Studio v5 with a page builder for marketing and content pages, visual editing, and live preview.
- Auto-generated Sanity TypeScript types and Zod environment validation so type errors surface before deployment.
- Tailwind CSS v4 with OKLCH color tokens, dark mode, and Shadcn UI components.
- Dynamic OG images, sitemaps, JSON-LD structured data, and automatic redirects when a slug changes.
- Seed and verify scripts for the Shopify side: `pnpm seed:shopify` populates a dev store with demo products and `pnpm verify:shopify` reports on the connection health.
- Turborepo monorepo with React Compiler and Turbopack for fast local development, plus a GitHub Action that deploys a preview Studio for every pull request.

## How to use it

Initialize a new project with the Sanity CLI. It scaffolds the monorepo and connects to both your Sanity account and your Shopify store credentials.

```bash
npx create-sanity@latest -- --template robotostudio/turbo-start-shopify
```

Add your Shopify Storefront API token and Sanity project ID to the environment variables, then run `pnpm dev` to get the front end on port 3000 and the Studio on port 3333. You'll need Node 22 or later. There's a live demo at [turbo-start-shopify-web.vercel.app](https://turbo-start-shopify-web.vercel.app).

## How we use it

It is the starting point for our [headless Shopify engagements](/services/shopify). Slingshot Bio is one project that shipped on this stack.

---

# Careers

## Social media & growth marketer


> We are hiring a social media and growth marketer to run our channels, publish content people want to share, and keep our business development moving.

**Published:** 2026-06-29 | **Updated:** 2026-07-23 | **Location:** Remote | **Type:** Full-time
---

## Intro

We're Roboto Studio, a boutique studio that builds agentic infrastructure, modern websites, web apps, and ecommerce architecture. We love working at the bleeding edge, and we use tools like Sanity, Next.js, and Shopify to craft work that holds up in production.

We're looking for a social media and growth marketer to own how we show up across social, content, and community, and to keep our business development moving. You'll work alongside the design team and get close enough to the work to write about it credibly.

We handle the technical growth of the website ourselves. Your job is the human side: managing our channels every day, publishing content our audience wants to share, and making sure no lead or conversation goes cold.

## What you'll do

- Own and manage our social channels: X, Reddit, LinkedIn, dev.to, YouTube, and our newsletter, engaging with these communities every day
- Plan, create, and publish content for a technical audience, including high-quality marketing videos
- Support business development: track inbound leads, follow up fast, and keep the pipeline tidy
- Watch what competitors and the wider industry are doing, and turn what you find into content and outreach ideas
- Report on what's working across channels using our analytics (PostHog)
- Use our AI and agent tooling to scale content and reporting instead of doing everything by hand

## What we're looking for

- A proven track record of building a high following, whether for yourself or a company you've worked with. It's the clearest signal of real marketing skill, so come ready to show the numbers
- Great communication, with a clear, sharp writing voice that lands with a technical audience
- Confident running multiple social channels and a content calendar without dropping threads
- Organized and responsive, comfortable owning follow-ups and keeping a CRM up to date
- High agency, self-motivated, and an independent thinker

We're a small team where everyone owns their work, so there's no hand-holding and nowhere to hide. Your work speaks for itself, and there's real room to make a name for yourself.

## Nice to have

- Experience with sales or business development at an agency or studio (major bonus)
- A working knowledge of modern SEO and AI search
- Comfortable with ScreenStudio (or similar) for recording high-quality marketing video
- Comfort using AI tooling (Claude, Cursor, v0, or similar) to move faster
- An understanding of how modern websites get built (Next.js, headless CMS, Shopify)

## Why join Roboto Studio?

- Fully-remote work with flexibility of working the usual 9-5 from your local time
- One of the best teams in the headless CMS industry
- Incredibly driven and forward thinking work environment to grow your skills
- Access to the latest and niche technologies to help you progress in the field
- Receptive team that takes onboard new technologies and opinions
- Competitive salary with progression
- Flexible meeting hours with no restrictions
- Support for hardware/software setup and purchases
- Support with training from industry leading consultants and encouragement to pursue certifications
- National holidays, 21 days of annual leave and any emergency leave
- Latest Macbook (after work trial period)

## The nature of your contract

We believe in finding only the ***very*** best fit for our business. We are an incredibly tight-knit, agile team, and because of this every member must either be at the *'top of their game'*, or be willing to put in the blood sweat and tears it takes to achieve that.

Therefore, we want to ensure you're **the right fit for us**, and we're **the right fit for you.** We offer a 3-month fixed-contract period and paid work trials that allow candidates to engage in real projects that reflect our startup environment. This method tests the skills and attributes that matter in our fast-moving setting but also ensures a mutual fit for both parties involved.

At the end of the 3-month contract, if you feel you would like to continue with our team and the feeling is mutual, we can offer a permanent position for this role.

---

## Motion brand designer


> We're looking for a motion brand designer to bring our case studies, client work, and team animation to life with thoughtful easings and considered motion.

**Published:** 2026-04-27 | **Updated:** 2026-07-23 | **Location:** Remote | **Type:** Full-time
---

## Intro

We're Roboto Studio, a web agency that builds editorial experiences with tools like Sanity, Contentful, Next.js, and Shopify. We're looking for a motion brand designer to add movement and personality to the brands we work with, the case studies we publish, and the work our wider team produces.

## What you'll do

- Design and animate motion for client brand systems, covering logos, typography, transitions, and signature moments
- Produce case study videos and motion sequences that show our client work
- Build motion brand guidelines that define easings, timings, and principles for each client
- Create reusable motion components and templates the team can build on
- Review and feed back on animation work from the wider design and engineering team
- Translate handover from After Effects and Jitter into specs the dev team can implement faithfully
- Own motion consistency across everything we put out, from social to long-form case studies

## What we're looking for

- 3+ years in motion design with a strong portfolio of brand and editorial work
- Deep proficiency in After Effects and Jitter
- A genuine obsession with easings, timing, and the feel of motion
- Experience producing case studies or marketing videos end to end
- Comfortable giving constructive feedback on other people's animation
- High attention to detail and care for craft

## Nice to have

- Familiarity with web animation libraries (Motion for React, Rive, GSAP)
- Experience exporting Lottie or video for production handoff
- Background in brand design or working closely with brand designers
- Sound design or basic video editing chops

## Why join Roboto Studio?

- Fully-remote work with flexibility of working the usual 9-5 from your local time
- One of the best teams in the headless CMS industry
- Incredibly driven and forward thinking work environment to grow your skills
- Access to the latest and niche technologies to help you progress in the field
- Receptive team that takes onboard new technologies and opinions
- Competitive salary with progression
- Flexible meeting hours with no restrictions
- Support for hardware/software setup and purchases
- Support with training from industry leading consultants and encouragement to pursue certifications
- National holidays, 21 days of annual leave and any emergency leave
- Latest Macbook (after work trial period)

---

## Design engineer


> We are looking for a creative design engineer who lives between design and code. Deep Next.js and Tailwind, obsessed with motion and pixel-perfect detail.

**Published:** 2026-04-15 | **Updated:** 2026-07-23 | **Location:** Remote | **Type:** Full-time
---

## Intro
We’re Roboto Studio, the Sanity & Next.js experts. We move extremely fast and build websites and applications using bleeding-edge tech. If there’s a new feature in Next.js, Sanity, Vercel, we want to be using it ***right this second***.

## Who we are looking for
We are looking for an experienced design engineer, who is creative and fun to work with, understands the pace and culture of Roboto Studio, and pays attention to details.

We are a boutique development house – we care about the craft, not just making profit. Therefore, the person in the team would be expected to work with the same mind-set. Instead of bulk fixing and shabby editing, the focus is always on creating truly unique web solutions for the clients.

## Essential skills
- Next.js/React knowledge
- Tailwindcss
- Familiar with UI libraries (Shadcn/ui, Radix, etc)
- Knowledge of CSS
- Git branching strategies
- Being able to use Figma dev mode
- Understand design patterns

## Skills that would be great
- Headless CMS experience
- Management of functional design system
- Knowledge of an animation library
  - Framer Motion
  - Motion One
  - Rive App
  - React Spring
- Knowledge of AI & use of Cursor AI/v0 or similar tools

## Why join Roboto Studio?
- Fully-remote work with flexibility of working the usual 9-5 from your local time
- One of the best teams in the headless CMS industry
- Incredibly driven and forward thinking work environment to grow your skills
- Access to the latest and niche technologies to help you progress in the field
- Receptive team, that takes onboard new technologies and opinions
- Competitive salary with progression
- Flexible meeting hours with no restrictions
- Support for hardware/software setup and purchases
- Support with training from industry leading consultants & encouragement to pursue certifications
- National holidays, 21 days of annual leave and any emergency leave
- Latest Macbook (After work trial period)

## The nature of your contract
We believe in finding only the ***very*** best fit for our business. We are an incredibly tight-knit, agile team, and because of this every member must either be at the *‘top of their game’,* or be willing to put in the blood sweat and tears it takes to achieve that.

Therefore, we want to ensure you’re **the right fit for us**, and we’re **the right fit for you.** We offer a 3-month fixed-contract period and paid work trials that allow candidates to engage in real projects that reflect our startup environment. This method tests the skills and attributes that matter in our fast-moving setting but also ensures a mutual fit for both parties involved.

At the end of the 3-month contract, if you feel you would like to continue with our team and the feeling is mutual, we can offer a permanent position for this role.

---

## Digital brand designer


> We are looking for a digital brand designer to craft brand identities for SaaS companies and carry them through to marketing-site wireframes, polished case studies, and design systems.

**Published:** 2026-03-17 | **Updated:** 2026-08-20 | **Location:** Remote | **Type:** Full-time
---

## Intro

We're Roboto Studio, a boutique studio that builds modern websites, web apps, ecommerce, and agentic infrastructure with tools like Sanity, Contentful, Next.js, and Shopify. Most of the brands we work with are SaaS companies, and we're looking for a digital brand designer to shape their visual identities end to end, from brand direction through to the wireframes for the websites we build, as well as building and improving Roboto's own design system and marketing assets.

This is a digital-first role: no print, ever. The brand work you make won't sit in a slide deck. It ships into live sites, design systems, and everything we put out, so it has to hold up.

We're a small, tight-knit team where everyone takes ownership, has real taste, and moves fast.

## What you'll do

- Understand the client's requirements and craft the brand and its design assets end to end, taking feedback and working alongside internal and external teams
- Define and deliver brand guidelines covering typography, colour palettes, imagery, iconography, patterns, and graphic devices
- Carry brand direction through to wireframes for SaaS marketing sites, working with our developers to take them into production
- Create polished case study designs and mockups that show our client work
- Build and maintain design systems and design tokens to keep things consistent across digital touchpoints
- Produce brand assets for web, social, presentations, and marketing collateral
- Own brand consistency across everything we put out

## What we're looking for

- Above all else: taste, pace, and care for craft. You've got a great eye, you want to move fast, and you sweat the details
- Strong communication. We're spread across the world, so you talk openly about your work and share your thinking, rather than leaving the PM to dig through Figma layers to figure out what you meant
- Pragmatic in your decisions. Design has to translate into code without a performance hit and ship on time, so you balance sweating the details with actually getting work out the door
- 3+ years in brand design with a solid digital portfolio, ideally with SaaS or tech brands in it
- Proficient in Figma and Adobe Creative Suite
- Experience building and managing design systems and design tokens
- Comfortable creating mockups and presentation-ready case studies
- Good understanding of typography, colour theory, layout, and hierarchy

We're a small team where everyone owns their work, so there's no hand-holding and nowhere to hide. You'll QA your own output, catch your own details, and ship brand work you can stand behind without someone checking in over your shoulder. Your work speaks for itself, and there's real room to make a name for yourself.

## Nice to have

- UI or product design skills. Brand is the core of this role, but if you can do UI too, that's phenomenal
- Familiarity with how design tokens feed into front-end development
- Motion or animation skills

## Compensation

- $2,500–3,500 USD per month, depending on experience
- Full-time contractor, paid monthly in USD (via Wise or similar)
- 3-month fixed-contract trial, then a permanent position if the fit is mutual (see below)

## Why join Roboto Studio?

- Fully-remote work with flexibility of working the usual 9-5 from your local time
- One of the best teams in the headless CMS industry
- Incredibly driven and forward thinking work environment to grow your skills
- Access to the latest and niche technologies to help you progress in the field
- Receptive team that takes onboard new technologies and opinions
- Competitive salary with progression
- Flexible meeting hours with no restrictions
- Support for hardware/software setup and purchases
- Support with training from industry leading consultants and encouragement to pursue certifications
- National holidays, 21 days of annual leave and any emergency leave
- Latest Macbook (after work trial period)

## The nature of your contract

We believe in finding only the ***very*** best fit for our business. We are an incredibly tight-knit, agile team, and because of this every member must either be at the *'top of their game'*, or be willing to put in the blood sweat and tears it takes to achieve that.

Therefore, we want to ensure you're **the right fit for us**, and we're **the right fit for you.** We offer a 3-month fixed-contract period and paid work trials that allow candidates to engage in real projects that reflect our startup environment. This method tests the skills and attributes that matter in our fast-moving setting but also ensures a mutual fit for both parties involved.

At the end of the 3-month contract, if you feel you would like to continue with our team and the feeling is mutual, we can offer a permanent position for this role.

---

## Frontend developer


> We are looking for Next.js, Tailwind CSS, Radix, and headless CMS experience. We want folks who sweat the details and know their accessibility standards.

**Published:** 2025-11-12 | **Updated:** 2026-07-23 | **Location:** Remote | **Type:** Full-time
---

## Intro
We’re Roboto Studio, the Sanity & Next.js experts. We move extremely fast and build websites and applications using bleeding-edge tech. If there’s a new feature in Next.js, Sanity, Vercel, we want to be using it ***right this second***.

## Who we are looking for
We are looking for an experienced Frontend developer, who is creative and fun to work with, understands the pace and culture of Roboto Studio, and pays attention to details.

We are a boutique development house – we care about the craft, not just making profit. Therefore, the person in the team would be expected to work with the same mind-set. Instead of bulk fixing and shabby editing, the focus is always on creating truly unique web solutions for the clients.

## Essential skills
- Next.js/React knowledge
- Tailwindcss
- Familiar with UI libraries (Shadcn/ui, Radix, etc)
- Knowledge of CSS
- Git branching strategies
- Being able to use Figma dev mode
- Understand design patterns

## Skills that would be great
- Headless CMS experience
- Management of functional design system
- Knowledge of an animation library
  - Framer Motion
  - GSAP
  - Motion One
  - Rive App
  - React Spring
- Knowledge of AI & use of Cursor AI/v0 or similar tools

## Why join Roboto Studio?
- Fully-remote work with flexibility of working the usual 9-5 from your local time
- One of the best teams in the headless CMS industry
- Incredibly driven and forward thinking work environment to grow your skills
- Access to the latest and niche technologies to help you progress in the field
- Receptive team, that takes onboard new technologies and opinions
- Competitive salary with progression
- Flexible meeting hours with no restrictions
- Support for hardware/software setup and purchases
- Support with training from industry leading consultants & encouragement to pursue certifications
- National holidays, 21 days of annual leave and any emergency leave
- Latest Macbook (After work trial period)

## The nature of your contract
We believe in finding only the ***very*** best fit for our business. We are an incredibly tight-knit, agile team, and because of this every member must either be at the *‘top of their game’,* or be willing to put in the blood sweat and tears it takes to achieve that.

Therefore, we want to ensure you’re **the right fit for us**, and we’re **the right fit for you.** We offer a 3-month fixed-contract period, paid work trials that allow candidates to engage in real projects reflective of our startup environment. This method tests the skills and attributes that matter in our fast-moving setting but also ensures a mutual fit for both parties involved.

At the end of the 3-month contract, if you feel as though you would like to continue with our team, and the feeling is mutual, we will be able to offer a permanent position for this role.

---

## Project manager


> Looking for a cracked PM with autonomous leadership skills, extremely organized, great at communication, and relentless about delivering projects on time.

**Published:** 2025-11-12 | **Updated:** 2026-08-11 | **Location:** Remote | **Type:** Full-time
---

> We need a PM who ships. You'll run technical projects at speed, use AI to eliminate busywork, and keep our dev teams unblocked.
## The role
You'll manage web projects from kickoff to launch: coordinating devs, clients, and timelines. No standups for the sake of standups. No Jira ticket theatre. Just clear communication and relentless delivery.

## What you'll do
- Lead multiple Next.js/headless CMS projects simultaneously
- Use AI tools (Cursor, Claude, ChatGPT) to draft specs, summarize client calls, and automate repetitive PM tasks
- Manage everything in Linear: sprints, tasks, progress
- Translate client requirements into actionable technical briefs
- Spot blockers early and fix them before they derail timelines
- Own budgets, scope, and client comms

## You should have
- 2+ years managing technical/web projects
- Working knowledge of modern web stack (Next.js, React, Git, CI/CD, Vercel)
- Experience with Linear or similar tools
- Comfort using AI assistants daily to move faster
- Ability to read a PR description and understand what's happening
- Strong async communication (Slack, Loom, docs)

## Bonus
- Can spin up a basic Next.js project or read code
- Experience with headless CMS (Sanity, Contentful)
- Have built your own AI workflows or automations

## What we offer
- Fully remote
- Latest hardware + AI tool subscriptions
- Competitive salary + benefits
- Work on modern tech with a team that moves fast

---

## Backend developer


> Develop and maintain server-side logic, manage databases, implement APIs, and work with frontend teams to keep integrations fast and reliable.

**Published:** 2025-07-20 | **Updated:** 2026-07-23 | **Location:** Remote | **Type:** Full-time
---

## Position overview
This is a full-time, fully remote role for a Backend Developer at Roboto Studio. As a Backend Developer, you will be responsible for the development and maintenance of server-side logic, database management, and ensuring high performance and responsiveness to requests from the front-end.

## Company description
Roboto Studio is dedicated to creating the best editorial experience on the web. We prioritize simplicity and efficiency, adopting new web technologies and AI-powered tools early. Our early adoption of v0.dev allows us to rapidly prototype and iterate, cutting steps out of our development process. If you're interested in utilizing JAMstack and AI for development, content, and tooling, Roboto Studio is the ideal place for you.

## Role description
Your daily tasks will include implementing APIs, managing data storage solutions, collaborating with front-end developers, and integrating user-facing elements with server-side logic. You'll work with the latest web frameworks and AI-powered tools to build scalable, high-performance backend systems.

## Key responsibilities
- Develop and maintain server-side logic and database management systems.
- Implement APIs and ensure high performance and responsiveness to requests from the front-end.
- Optimize backend systems for performance, reliability, and scalability (caching, load balancing, monitoring).
- Build and maintain integrations with third-party platforms (Salesforce, CRM, analytics, marketing automation tools).
- Collaborate with frontend developers, designers, and stakeholders to deliver cohesive solutions.
- Manage data storage solutions and integrate user-facing elements with server-side logic.

## Required skills
- Proficiency in Back-End Web Development, Software Development, and Object-Oriented Programming (OOP).
- Experience with Front-End Development and general Programming skills.
- Strong problem-solving abilities and attention to detail.
- Familiarity with database management and meta frameworks (we only use Next.js).
- Excellent communication and teamwork skills.
- Experience with AI-powered tools and JAMstack is a plus.

## Bonus skills
- Lots of experience with Next.js.
- Familiarity with frontend, but not a requirement.
- Knowledge of event-driven architectures and serverless patterns.
- Contributions to open-source or developer communities.

## What we offer
- Fully remote work opportunity.
- Collaborative, growth-oriented team culture.
- Support for experimenting with new technologies and AI-driven solutions.
- Professional development courses [Epic react](https://www.epicreact.dev/), [animations.dev](https://animations.dev/), etc.

If you're passionate about building the scalable, composable backends that power the web's next generation, and you love bringing new ideas and tech to the table, we'd love to hear from you.

---

# Pages

## Call


> Book a call with Jono at Roboto Studio to plan or improve your Sanity CMS setup and get clear, practical advice for your next steps.

**Updated:** 2026-04-01
---

---

## Contact


> Let's build the best editorial experience together. We're your consultants, your content structure strategist, and your marketing team's new best friends.

**Updated:** 2026-07-23
---

---

## Privacy


> How Roboto Studio collects, uses, and protects your personal data. Our privacy policy explains analytics, forms, cookies, and your rights under GDPR.

**Updated:** 2026-07-23
---

This page explains what we collect when you visit robotostudio.com, why we collect it, who we work with, and what your rights are.

Questions? If anything here doesn't make sense, email us and we'll explain it like normal people: hello@roboto.studio

### Who "we" are

"Roboto Studio", "we", or "us" means Roboto Studio Ltd, registered in England & Wales.

For anything privacy-related, the data controller is: Roboto Studio Ltd, hello@roboto.studio

We're responsible for how personal data is collected and used on this website.

### What we collect (and why)

We only collect what we need to:

- Keep the site running on Vercel
- Understand what's working (and what's not)
- Reply when you reach out to discuss a project
- Send you things you explicitly sign up for (like the newsletter)

1. Things your browser sends anyway

When you visit the site, some information is automatically collected by our infrastructure and analytics:

- IP address: Security, debugging, rough geographic stats
- Browser type and version: Making sure the site works everywhere
- Device and operating system: Same as above
- Pages you visit, links you click, time on page: Understanding what content resonates
- Referrer (how you got here): Knowing which channels actually work

Legal basis: Legitimate interests (running and improving our website, security, debugging).

2. Forms (contact, "get in touch", etc.)

If you fill out a form on the site, we'll collect:

- Your name
- Your email
- Anything you write in the message box
- The fact that you ticked the consent box

What we do with it:

- Reply to your message: Email + internal tools
- Keep a light-touch record: So we remember what we talked about
- Improve lead qualification: So we can respond faster and smarter

We use Formspark (or equivalent) to handle submissions securely, then our own systems to respond and follow up.

Legal basis:

- Contract / taking steps at your request (you asked us to contact you)
- Legitimate interests (running a B2B agency, keeping track of conversations)

Want us to stop? If you ask us to stop contacting you, we will. No questions asked.

3. Analytics & session recording (PostHog)

We use PostHog to understand how people actually use the site. That includes:

- Page views and navigation paths: what's getting read
- Events: form submissions, clicks on key calls-to-action
- Heatmaps and session recordings: so we can see where people rage-click when something is broken

Where we connect events to a person (for example, capturing your email when you submit a form), this may include:

- Email address
- Name
- High-level site interaction (e.g. "submitted contact form", "subscribed to newsletter")

We do not use this to make automated decisions about you with legal effects. It's there so we can ship a better website and fix UX issues.

Legal basis:

- Legitimate interests (understanding how people use the site, improving UX, measuring marketing performance)
- Consent where required (e.g. for non-essential cookies in certain jurisdictions)

Consent controls: Where local law requires explicit consent for analytics, we'll only run these scripts once you've agreed via a cookie banner or similar control.

4. Newsletter

If you subscribe to our newsletter:

- Email address (and possibly name): Store with our email provider
- Opens and clicks: Track basic metrics so we know if the content is actually useful

Unsubscribe anytime via the link in the email or by emailing us directly.

Legal basis: Consent. You can withdraw it whenever you like; we'll stop sending marketing emails. We may keep a minimal record to make sure we don't accidentally re-add you.

### Cookies and similar tech

We use a mix of:

- Strictly necessary: Keep the site functioning, security, basic performance
- Analytics: PostHog, understanding what's working
- Preference: Remembering things like closed banners or submitted forms

Where the law requires it, we'll:

- Ask for your consent before dropping non-essential cookies
- Give you a way to change your mind

You can also control cookies from your browser settings.

### Where your data lives (and who processes it)

Our site is built with Next.js and hosted on Vercel. That means some technical data (like IP addresses and logs) may be processed in data centres outside the UK/EU.

Third parties we work with:

- Vercel: Hosting and deployment
- PostHog: Analytics, events, heatmaps, session recordings
- Formspark: Processing form submissions
- Email & CRM providers: Sending emails, keeping track of conversations

Some of these providers are based outside the UK/EU (particularly in the US).

International transfers: When personal data is transferred out of the UK/EU, we rely on legally recognised safeguards:

- Standard Contractual Clauses (SCCs)
- The UK Addendum
- Additional technical and organisational measures (encryption, access controls)

### How long we keep things

We don't keep personal data forever.

- Analytics data: Per our PostHog configuration, only as long as needed to understand performance
- Server/security logs: Limited period for security and debugging
- Contact emails & form submissions: As long as reasonably needed to manage our relationship (sales cycle, project history)
- Newsletter data: Until you unsubscribe; minimal suppression record after

Legal requirements: If we're legally required to keep something for longer (tax, legal, regulatory), we'll do so, then delete or anonymise it.

### Global Privacy Control (GPC)

If your browser sends the `Sec-GPC: 1` signal (Brave, Firefox with the toggle on, DuckDuckGo, or any extension that flips it), we treat that as a request to opt out of analytics and marketing tracking. You don't need to interact with the cookie banner; the signal is enough. We don't sell or share personal data with third parties for cross-context behavioural advertising, regardless of GPC.

### Your rights

If you're in the UK or EU (and we choose to apply these rights globally anyway), you have:

- Access: Ask what we hold about you and get a copy
- Rectification: Fix incorrect or incomplete data
- Erasure: Ask us to delete your data, in certain circumstances
- Restrict processing: Ask us to limit how we use your data
- Object: Especially to analytics/marketing based on legitimate interests
- Data portability: Have some data sent to you in a portable format
- Withdraw consent: For anything based on consent (like newsletters)

To exercise these rights: Email hello@roboto.studio. We may need to verify you're actually you before we act.

### Complaints

If you're not happy with how we handle your data:

1. Email us first at hello@roboto.studio (we'd genuinely like to fix it)
1. UK residents: Complain to the Information Commissioner's Office (ICO)
1. EU residents: Complain to your local Data Protection Authority

### Security and ISO 27001

We use HTTPS everywhere and work with reputable providers (Vercel, PostHog) that take security seriously. Access to systems is restricted to people who need it to do their job.

We are working towards ISO 27001 certification, which means formalising and independently auditing the way we manage information security.

No system is perfect, but we take reasonable steps to keep your data safe.

### Changes to this policy

We may update this policy when:

- We change analytics or infrastructure
- Privacy laws change
- We start doing something new with your data

We'll update the text on this page and change the "last updated" date. If we make big changes, we'll be more explicit about it.

Continued use: If you keep using the site after an update, we'll take that as you having read and understood the new version (or at least scrolled past it).

---

## Team


> We're all hell-bent on building the best editorial experiences on the web and outpacing teams 10 times our size. Meet the people who make it happen. 

**Updated:** 2026-04-01
---

## The dream team

### Jono Alford

**Founder**

Founder of Roboto Studio, specializing in headless CMS implementations with Sanity and Next.js. A Sanity Pioneer and first-cohort Sanity Community Ambassador, focused on editorial experiences that help teams ship faster.

[LinkedIn](https://www.linkedin.com/in/jonoalford/) · [X](https://x.com/jonoalford) · [Peerlist](https://peerlist.io/jonoroboto)

### Hrithik Prasad

**Tech Lead**

Tech Lead with expertise in React, Next.js, and Sanity CMS. Loves building performant web applications and sharing knowledge through technical content.

[LinkedIn](https://www.linkedin.com/in/hrithikprasad) · [X](https://twitter.com/hrithikprasad_) · [Peerlist](https://peerlist.io/hrithik)

### Aayush Bharti

**Frontend Developer**

Frontend Developer focused on creating beautiful, accessible user interfaces. Enthusiastic about modern web technologies and design systems.

[LinkedIn](https://www.linkedin.com/in/iaayushbharti/) · [Peerlist](https://peerlist.io/aayushbharti)

### Sne Tripathi

**Account Executive**

Account Executive at Roboto Studio, bridging the gap between client needs and technical solutions. Ensures every project delivers real business value.

[LinkedIn](https://www.linkedin.com/in/sne-tripathi/) · [X](https://x.com/sne_hil)

### Francesco

**SEO Consultant**

SEO Consultant helping businesses improve their search visibility and organic traffic through technical optimization and content strategy.

### Jenil Thummar

**UI Designer**

UI Designer crafting intuitive and visually appealing interfaces that enhance user experiences across web and mobile platforms.

[LinkedIn](https://www.linkedin.com/in/jenil-thummar)

### Tope Akintola

**Frontend Developer**

Frontend Developer with a sharp eye for interaction design and component architecture. Brings ideas to life in the browser with a focus on speed, polish, and maintainability.

[LinkedIn](https://www.linkedin.com/in/tope-akintola-b47b381b9/) · [X](https://x.com/photofola)

### Ansh Kumar

**Frontend Developer**

Frontend Developer crafting clean, production-ready interfaces with Next.js. Loves work that feels effortless to use and easy to find in search.

[LinkedIn](https://www.linkedin.com/in/ansh-kumar-715b60242/) · [X](https://x.com/anshkumar8710)

### Chibuike Maduabuchi

**Design Engineer**

Design Engineer building digital products with a focus on structure, usability, and craft. Works across product thinking, interface design, and frontend engineering for complex workflows and data-intensive systems.

[LinkedIn](https://www.linkedin.com/in/chibuike-maduabuchi/)

---

## Terms & Conditions


> Terms and conditions for using the Roboto Studio website, including information about analytics, form handling, GDPR compliance, and data security.

**Updated:** 2026-07-23
---

Welcome to Roboto Studio. By using our website, you agree to comply with the following terms and conditions.

### Analytics (PostHog)

We use PostHog to track and analyze web traffic. This helps us understand how you engage with our website. PostHog may use cookies and collect data like IP addresses to provide analytics. See our privacy policy for the full detail on what we collect and why.

### Formspark

Our website features forms that capture information for various purposes, like contact or inquiry. We use Formspark to handle this data securely. By filling out any form on this website, you consent to your data being stored and processed by Formspark.

### GDPR Compliance

We adhere to General Data Protection Regulation (GDPR) best practices to keep your data safe. You have the right to request, modify, or delete your personal data at any time.

### ISO 27001 certification

We are in the process of becoming ISO 27001 certified, reinforcing our commitment to data security.

### Changes to Terms

We reserve the right to change these terms at any time. It's your responsibility to check for updates.

---