What Building a Church Website Taught Me About Designing for Real Users

I just closed the last commit on CCL Guadalajara and realized something I’d been ignoring for months:

All my previous experience with Sanity, ISR, and webhooks was designed around me. Around a developer who understands data models, knows what a slug is, and isn’t intimidated by the Studio.

This time the user wasn’t me. It was a pastor.

The project: what is CCL Guadalajara

Comunidad Cristiana de Guadalajara (CCG) is the Spanish branch of CCL International, an evangelical church. They asked me to build their digital presence from scratch.

The stack I chose:

• Next.js 16 with App Router
• Sanity CMS (embedded Studio at /studio)
• TypeScript strict mode
• Tailwind CSS v4 via PostCSS
• ISR with webhooks for on-demand revalidation

Nothing revolutionary. But the challenge wasn’t technical.

The real problem: who edits the content?

When I build a tool for myself, I assume technical knowledge. I can make a “good enough” schema and move on.

When the content editor is a church’s pastoral team — people who need to manage sermons, events, testimonials, and ministries without development experience — the CMS design becomes the actual product.

That changed everything.

The schemas I built

I designed over 10 content models specific to evangelical church operations:

• Sermon → with fields for preacher, biblical series, passages, Portable Text notes, and video/audio URL
• Evento → with event type (cultos, conferences, retreats), required registration flag, and local video support
• Testimonio → with SanityImage, orden field for editorial curation, and destacado flag
• Ministerio → with leader reference, contactoWhatsApp, colorGradiente, and activo flag

Every field exists for a reason beyond “it was easiest to implement.” The contactoWhatsApp field on Ministerio, for example, reflects how churches in Spain actually communicate today: directly via WhatsApp, not contact forms.

The most important decision: Studio embedded at /studio

I could have given them access to the Sanity dashboard at sanity.io. Technically identical.

But embedding the Studio directly into the church website (at the /studio route) completely changes the experience.

The team doesn’t need to navigate to another platform. Doesn’t need to remember another URL. Doesn’t need to log in somewhere else. Content management lives where the website lives.

It’s a small UX detail that for a non-technical user is the difference between actually using the system or not.

ISR + webhooks: why it matters for a church

A church updates content constantly: new sermon every week, changing events, new testimonials.

The architecture uses Incremental Static Regeneration with on-demand revalidation from Sanity:

The result: when someone on the team publishes a new sermon in the Studio, the site updates in seconds. No deploy. No need to notify me.

That’s real autonomy for a non-technical team.

The commit I liked most: the location change banner

In February 2026, the church moved locations. That generated three commits in sequence:

• chore: update address to Calle Francisco Aritio, 107 (Dinoaventura) — Feb 3
• feat(ui): add location change banner — Feb 9
• fix(predicas): fix field aliases in sermon queries — Feb 10

The banner isn’t sophisticated. It’s a persistent layout component announcing the change, dismissible via cookie state management (GDPR/LSSI compliant for Spain).

But here’s what’s interesting: without that technical infrastructure, a location change would have been a communication crisis. With it, it was three commits and done.

Local video support: the decision nobody mentions

Most church websites rely exclusively on YouTube for sermons. Convenient, but it creates hard dependency.

I implemented a videoLocal field in the Evento schema for self-hosted video alongside external URLs:

First-fruit services, internal retreats, video testimonials — everything can live on the owned platform without depending on external algorithms or third-party monetization.

Same logic I apply to my SaaS projects: don’t build on sand you don’t control.

What this project changed in how I think

Building CCL Guadalajara in 2026 reminded me of three things I easily forget when working alone:

1. The real user defines the architecture, not the other way around.
If the user is a pastor managing content between weekdays, the embedded Studio isn’t a detail: it’s the core of the product.

2. Schemas are UX.
Every field you add or remove is a product decision. contactoWhatsApp in Ministerio isn’t a database field: it’s a decision about how communication works in a Spanish community in 2026.

3. User autonomy is project success.
If every new sermon requires them to call me, I’ve failed. The goal is that they don’t need me for day-to-day operations.

Takeaway

If you’re building for non-technical users — whether a church, an accountancy, or a restaurant — ask yourself this before writing a single line of code:

Can this person manage their own content, independently, six months from now?

If the answer is no, you have a design problem, not an implementation problem.

The CCL Guadalajara code isn’t the most complex I’ve written. But the clarity of that criterion made every technical decision easier.

We keep building.