This is a composite-style account of a build I do often: a nonprofit organisation with a lot of different kinds of content, rebuilt on Sanity and Next.js. The client stays unnamed, and I have left out numbers I cannot stand behind. What follows is the scope, the decisions that mattered, and what a buyer should expect from the process in a Sanity Next.js website case study like this one.
The situation we started with
The organisation had an ageing site that a volunteer had built years earlier. Staff dreaded updating it. Events were copied by hand from a spreadsheet, team bios lived in three places, and every annual report was a PDF with no web version. Nobody could say which pages were still accurate.
The brief was not "make it pretty". It was: let a four-person communications team publish without asking a developer, make the content reusable, and keep the site quick on weak mobile connections, because many of their supporters browse on phones.
Scope: nine content types, one rule
Before any code, we listed every kind of thing the organisation publishes. The list came to nine:
| Content type | Who edits it | Where it appears |
|---|---|---|
| Programme | Programmes lead | Programme pages, homepage, funding pages |
| Event | Comms team | Events list, programme pages, homepage |
| News post | Comms team | News, homepage, newsletter export |
| Team member | Operations | About, programme pages |
| Annual report | Director | Reports archive |
| Resource (guide, toolkit) | Programmes lead | Resource library, programme pages |
| Partner | Fundraising | Partners page, footer |
| Story (beneficiary or supporter) | Comms team | Homepage, programme pages |
| Generic page | Anyone | About, policies, contact |
The one rule I set: if a fact appears in two places, it is stored once and referenced. A team member is a document, not text pasted into a page. That rule drove nearly every schema decision. If you are scoping something similar, my notes on what to define before you write a line of code cover the same discipline.
Schema decisions that paid off
References over copies. Programmes reference team members, events, resources and stories. An editor updating a staff title changes it once, and every page reflects it. The cost is query design, which is why I shape schemas with the rendering in mind, as described in structuring Sanity schemas to avoid query waterfalls.
A small set of page-builder blocks. The generic page type has a limited list of blocks: rich text, image with caption, call to action, callout, and a card grid. I resisted a thirty-block library. Every extra block is something an editor has to learn and a developer has to maintain.
Events with real dates. Events use proper datetime fields plus a validation rule that the end cannot precede the start. The site then filters upcoming and past events automatically, with no one archiving anything by hand.
Annual reports as structured content. Instead of linking to a PDF alone, each report has a summary, key figures, sections in Portable Text, and the PDF as a download. That gave the organisation a searchable, linkable web version, which also helps search visibility.
Validation as training. Required alt text on images, a character limit on meta descriptions, and slug checks for uniqueness. Rules like these teach editors the right habits without a manual.
The Next.js side
The front end uses Next.js App Router with server components, so most pages ship little JavaScript. Content pages are cached and refreshed when an editor publishes, using Sanity webhooks to trigger revalidation. Editors see the update within moments, and visitors get cached pages. Draft preview lets the comms team check a story before it goes live.
For a content-heavy nonprofit, I treat performance as a requirement and not a bonus. Images come from Sanity with hotspot data so crops stay sensible, and layout dimensions are set from image metadata so pages do not jump while loading.
Editor training
This is the part most case studies skip, and it decides whether the project works a year later.
We ran one live session of about ninety minutes with the whole communications team, using their real content, not demo text. The structure:
- A tour of the Studio sidebar, which shows only the nine types in the order the team thinks about them.
- Publishing a news post from blank to live, including preview.
- Creating an event and watching it appear on the programme page it belongs to.
- What happens when you make a mistake: version history, unpublish, and who to ask.
They left with a one-page cheat sheet and a short recorded walkthrough. Two weeks later we held a thirty-minute follow-up to answer the questions that only appear once people use the tool. If you want the principles behind this, see what to set up before editors touch the CMS and why editors avoid the Studio and the fix.
Launch
Launch was boring on purpose. We built a redirect map from every old URL before cutover, tested it on a staging address the client could open, and checked that titles, descriptions and canonical tags were present on the new pages. Sitemaps and robots rules were verified, and the old domain's top pages were spot-checked after go-live. The approach follows the same checklist as any redesign that protects search rankings.
The client approved content on staging for a week before launch, which is when most corrections surface. Hold that review window. Compressing it is how typos reach production.
Results, and what I will not claim
I am not going to quote traffic percentages or conversion lifts here, because those depend on the organisation, its starting point and seasonality, and inventing them would be dishonest. What I can describe are the outcomes that were observable:
- Staff publish news and events without developer involvement.
- Team and programme details are edited once, not in several places.
- Pages pass Core Web Vitals checks on mobile in field data once enough visits accumulate.
- Annual reports exist as web pages, not just downloads.
- The organisation owns its content in a structured form, so a future redesign does not mean re-keying everything.
What a buyer should take from this
Three questions would have saved this organisation years of frustration, and they apply to any similar project:
- Can the developer list your content types and relationships before proposing a design?
- Will your actual editors be trained on your actual content?
- At handover, do you receive the code, the Studio, the documentation and the accounts in your name? There is a full list in the handover checklist.
A project like this typically sits within my fixed-price Sanity + Next.js site build, which starts from $4,000, with scope driving the final number. Details are on the services page. If you are weighing a similar rebuild, the hire a Sanity developer page explains how I work and how to start.
Top comments (0)