I didn't set out to build an open-source project. I set out to stop rewriting the same code over and over.

That's probably the real reason SanityPress exists, and it's almost certainly why it resonated with other developers once I put it out there.

## The Pioneer recognition

Recently, that reason got a name I wasn't expecting. Evelina and Knut from Sanity reached out to tell me I'd been selected as one of the first [Sanity Pioneers](https://www.sanity.io/pioneers).

I'll be honest, I'm a bit of a Sanity fanboy. The platform has shaped how I think about structured content, and the people behind it are developers I've followed and learned from for years. Getting recognized by them, not just by the community but by the team who built the thing, was something else. It felt like validation that SanityPress was solving a real problem, not just scratching my own itch.

There were never really moments of doubt about whether to keep building SanityPress. When people are using something and finding real value in it, that's enough motivation on its own. But the Pioneer recognition gave the project a different kind of clarity. It stopped feeling like something I could maintain, and started feeling like something I need to.

![Sanity Pioneers 2026](https://cdn.sanity.io/images/cyu7k2r0/production/d1d7736c5a1cd01acb330298bcee42edb7f45cb3-1080x1080.png)

## What I built and why I built it

Working as a solo developer at a marketing agency means living in a constant tension between speed and quality. I'm often juggling two or three client projects at once, shipping something new while iterating on something older. You can't afford to be slow, but you also can't afford to ship something you're not proud of.

For a long time, that tension meant repeated work. Every new client site started close to scratch: new schema files, new component structure, the same boilerplate I'd written a dozen times before. Client work also never stays still. Requirements shift mid-project and scope creeps in from every direction, so whatever I built had to be flexible by default, not flexible as an afterthought.

SanityPress started as my answer to that problem. Not a product, not an open-source project. Just a foundation I kept refining across projects until it became something I trusted to start from every time.

The decision I'm most proud of is the module system. Pages are composed of individual, reusable, reorderable sections, each one a Sanity schema, a React component, and a resolver that connects the two. When a client wants to reorder their homepage, that's a content edit, not a code change. When I need a new section type, I'm adding a module, not restructuring a page.

I've written more about the philosophy behind this in [Architecting Websites with Sanity](/blog/architecting-websites-with-sanity) and [Building Websites with Modules That Convert](/blog/building-websites-with-modules-that-convert).

These days, Claude Code Agent Skills handle most of the module scaffolding for me: the schema, the component, the resolver wiring, all from a single command. I wrote about that workflow in [the `/new-module` Skill](/blog/the-new-module-skill-scaffolding-sanity-modules-with-claude-code) and in [How Sanity MCP Transformed My Coding Experiences](/blog/how-sanity-mcp-transformed-my-coding-experiences) if you want the details.

I open-sourced SanityPress without much expectation. It's since grown to 600+ projects, 120+ unique Sanity users, and 400+ combined GitHub stars. But the number that's hit hardest hasn't been a metric. It's the DMs and GitHub discussions from developers who say it saved them hours or became their default starting point.

It's not just developers, either. Because modules are self-contained and clearly named, the Studio stays organized for content editors too, so both sides of a project end up happier.

## If you're building something in the public

If you want to see what other people have shipped with SanityPress, the [/built-with-sanitypress](/built-with-sanitypress) page showcases community sites, and there's a submission form if you've built something yourself.

I get asked sometimes how to know if a side project is worth continuing. My honest answer: if someone else is using it, that's enough. You don't need a Pioneer nomination or a thousand GitHub stars. You just need to ship something real, put it where people can find it, and let the community tell you whether it's useful.

If you're building in public yourself and think you might be a fit, Sanity is accepting Pioneer applications at [sanity.io/pioneers](https://www.sanity.io/pioneers). It's worth a shot. I certainly didn't expect to hear back either.

As for SanityPress, I'm not chasing big features for the sake of it. There's more I want to add: internationalization support, built-in auth patterns, performance improvements in the Studio, maybe eventually an AI chatbot that understands your specific Sanity content. But I'd rather keep it focused than bloated.

One of my personal mottos is making the world a better place, one great website at a time. SanityPress is my contribution toward that. And now, apparently, it's also made me a Pioneer.

> SanityPress is a free, open-source Next.js + Sanity + Tailwind CSS starter template built for agencies and freelance developers.
> [Start building 🚀](https://sanitypress.dev)