Sanity

How I use Sanity

I use Sanity to manage every piece of content on this site.

Everything is structured, edited, reviewed, distributed, and automated from a single place.

Most Headless CMSs are built around predefined pages and posts. I wanted something flexible that lets me define my own content models and workflows.

If I can imagine a content type, workflow, or layout, I can build it and bring it to life. It removes a lot of the friction between having an idea and turning it into something I can actually publish.

Content Structure

Each content type has its own fields, URL pattern, preview, and publishing flow. A Quote is nothing like a Build, and the structure reflects that.

I like different types of content to feel like their own collection rather than variations of the same template. By defining the schemas myself, the structure matches how I think about that piece of content, not how a CMS platform decided to categorise it.

Schemas and GROQ queries are customised around what each content type needs. Notes, Library pages, and newsletter issues use a lighter block content setup for headings, lists, quotes, images, and code blocks, while Tools and Builds use a more personalised setup for more structured content.

Not every type of content requires the same structure. If something needs different metadata, relationships, layouts, or workflows, I can add it directly to the schema rather than working around the CMS.

typescript

*[_type == "podcast"]
| order(publishedAt desc) {
  _id,
  _type,
  episodeTitle,
  show,
  shortDesc,
  externalUrl,
  "slug": slug.current,
  "tags": coalesce(tags[]->title, tags[]),
  "coverAssetUrl": cover.asset->url,
  "coverAlt": coalesce(cover.alt, cover.asset->altText)
}

A list query, typical pattern (filter → order → project → coalesce tag shapes):

I also use TypeGen to track changes to schemas and GROQ queries, which keeps the front end aligned as the content structure evolves.

Studio Customisation

I use plugins, custom views, and automations to shape Studio around my publishing workflow alongside Sanity's defaults. Most of the editorial process is done solely in Studio, so I spend less time switching between apps and more time creating.

The Studio is organised around that workflow. These are the views, tools, and customisations I use most often:

A TOUR OF STUDIO

Preview: Editing content live while seeing how it will render before publishing.
JSON: Inspecting the underlying content structure and debugging issues quickly.
SEO: Viewing metadata, descriptions, and search preview criteria inside the same editing flow.
Custom Folders: Organising folders around the things I actually need to access quickly.

SEO score panel showing 8 of 9 checks passing with one warning for missing tags. — seo panel

Webpage preview showing a text article titled "yetty" with a dark background and white text about catastrophe and negligence. — preview

JSON data in a code editor showing book details for "Meditations" by Marcus Aurelius, including URLs, tags, and status. — json view

Sanity + Resend

The newsletter also lives in Sanity. I create, preview, schedule, and send issues from the same place I manage the rest of my content.

I wanted the newsletter to be part of the content system rather than a separate platform. Most newsletter platforms combine the website, editor, and delivery into one product. I want to manage the content and publishing flow while letting Resend handle sending and scheduling.

New issues are written once in Sanity using Portable Text, then rendered across the archive, previews, test sends, and final broadcasts. The site version renders as React components, while the email version is converted into inline-styled HTML using the same visual theme.

Inside Studio, the newsletter has custom actions for test sends, scheduling, delivery monitoring, and subscriber management.

Subscribe, confirmation, and unsubscribe flows are connected to the same system. Delivery data synced from Resend webhooks powers a custom dashboard for newsletter performance, keeping everything integrated with the rest of the site rather than operating as a separate platform.

text

Sanity content → Next.js renderers → Resend delivery → webhooks back to Sanity

ARCHITECTURE

The site is deployed on Vercel, which handles builds and previews triggered by content changes in Sanity.

Automations

I use Sanity Functions and Content Agent to handle repetitive editorial work. My focus is on creating and shipping content, not admin.

Every time content is published, a robot token patches documents and assets automatically. Anything that can be automated is handled in the background, so the publishing process stays consistent.

First Published: Tracks when content was first published with a timestamp that sets once and never overwrites, even when edits are made later.
Auto Summary: Short descriptions are automatically generated for relevant content types.
Auto Tag: Empty tags are populated automatically on publish, with a small set of relevant tags based on the article's theme.
Alt Text to Images: Images receive brief alt text generated from visible content only, for accessibility without manual input.

Sanity is probably overkill for a simple personal site. If all you need is a blog, a simpler CMS will do the job.

But I like building systems. My brain naturally wants to structure, connect, and reshape things until they fit the way I think. Sanity gives me a place to do that with content.

As the site grows, I can keep changing the shape of the system: new content types, different workflows, automations, and whatever else I want to experiment with.