Lo que Construir una Web para una Iglesia Me Enseñó Sobre Diseñar para Usuarios Reales
Acabo de cerrar el último commit de CCL Guadalajara y me di cuenta de algo que llevo meses ignorando:
Toda mi experiencia previa con Sanity, ISR y webhooks estaba pensada para mí. Para un developer que entiende el modelo de datos, que sabe qué es un slug y que no le da miedo el Studio.
Esta vez el usuario no era yo. Era un pastor.
El proyecto: qué es CCL Guadalajara
La Comunidad Cristiana de Guadalajara (CCG) es la rama española de CCL International, una iglesia evangélica. Me encargaron construir su presencia digital desde cero.
El stack que elegí:
- Next.js 16 con App Router
- Sanity CMS (embedded Studio en
/studio) - TypeScript strict mode
- Tailwind CSS v4 vía PostCSS
- ISR con webhooks para revalidación bajo demanda
Nada revolucionario. Pero el reto no era técnico.
El problema real: ¿quién edita el contenido?
Cuando construyo una herramienta para mí, asumo conocimiento técnico. Puedo hacer un schema “suficientemente bueno” y ya.
Cuando el editor de contenido es el equipo pastoral de una iglesia — personas que tienen que gestionar prédicas, eventos, testimonios y ministerios sin experiencia en desarrollo — el diseño del CMS se convierte en el producto real.
Eso cambió todo.
Los schemas que construí
Diseñé más de 10 modelos de contenido específicos para operaciones de una iglesia evangélica:
Sermon→ con campos para predicador, serie bíblica, pasajes, notas en Portable Text, y URL de vídeo/audioEvento→ con tipo de evento (cultos,conferencias,retiros), flag de inscripción requerida, y soporte de vídeo localTestimonio→ conSanityImage, campoordenpara curación editorial, y flagdestacadoMinisterio→ con referencia a líder,contactoWhatsApp,colorGradiente, y flagactivo
Cada campo tiene una razón de ser que va más allá de “era lo más fácil de implementar”. El campo contactoWhatsApp en Ministerio, por ejemplo, refleja cómo comunican las iglesias hoy en España: directamente por WhatsApp, no por formularios.
La decisión más importante: Studio embebido en /studio
Podría haber dado acceso al dashboard de Sanity en sanity.io. Técnicamente es lo mismo.
Pero haber embebido el Studio directamente en la web de la iglesia (en la ruta /studio) cambia la experiencia por completo.
El equipo no tiene que salir a otra plataforma. No tiene que recordar otra URL. No tiene que logearse en otro sitio. La gestión del contenido vive donde vive la web.
Es un detalle de UX pequeño que para un usuario no-técnico es la diferencia entre usar el sistema o no usarlo.
ISR + webhooks: por qué importa para una iglesia
Una iglesia actualiza su contenido con mucha frecuencia: nueva prédica cada semana, eventos que cambian, testimonios nuevos.
La arquitectura que implementé usa Incremental Static Regeneration con revalidación bajo demanda desde Sanity:
El resultado: cuando alguien del equipo publica una prédica nueva en el Studio, la web se actualiza en segundos. Sin deploy. Sin que tengan que avisarme.
Eso es autonomía real para un equipo no técnico.
El commit que más me gustó: el banner de cambio de local
En febrero de 2026, la iglesia cambió de ubicación. Eso generó tres commits seguidos:
chore: actualizar dirección a Calle Francisco Aritio, 107 (Dinoaventura)— 3 febfeat(ui): agregar banner de cambio de local— 9 febfix(predicas): corregir alias de campos en queries de sermones— 10 feb
El banner no es sofisticado. Es un componente persistente en el layout que anuncia el cambio y se puede cerrar (con gestión de estado via cookies, cumpliendo LSSI).
Pero lo interesante es esto: sin esa infraestructura técnica, un cambio de local hubiera sido una crisis de comunicación. Con ella, fue tres commits y listo.
Soporte de vídeo local: la decisión que nadie menciona
La mayoría de webs de iglesias dependen exclusivamente de YouTube para sus prédicas. Es cómodo, pero crea una dependencia dura.
Implementé un campo videoLocal en el schema de Evento para permitir vídeo auto-hospedado junto con las URLs externas:
Los cultos de primicias, retiros internos, testimoniales en vídeo — todo puede vivir en la plataforma propia sin depender de algoritmos externos ni monetización de terceros.
Es la misma lógica que aplico en mis proyectos SaaS: no construyas sobre arena que no controlas.
Lo que este proyecto cambió en cómo pienso
Construir CCL Guadalajara en 2026 me recordó tres cosas que fácilmente olvido cuando trabajo solo:
1. El usuario real define la arquitectura, no al revés.
Si el usuario es un pastor que gestiona contenido entre semana, el Studio embebido no es un detalle: es el núcleo del producto.
2. Los schemas son UX.
Cada campo que añades o eliminas es una decisión de producto. contactoWhatsApp en Ministerio no es un campo de base de datos: es una decisión de cómo funciona la comunicación en una comunidad española en 2026.
3. La autonomía del usuario es el éxito del proyecto.
Si cada vez que hay una prédica nueva me tienen que llamar, he fallado. El objetivo es que no me necesiten para el día a día.
Takeaway
Si estás construyendo para usuarios no técnicos — sea una iglesia, una gestoría, un restaurante — hazte esta pregunta antes de escribir una línea de código:
¿Puede esta persona gestionar su contenido sola, sin ayuda, dentro de seis meses?
Si la respuesta es no, tienes un problema de diseño, no de implementación.
El código de CCL Guadalajara no es el más complejo que he escrito. Pero la claridad de ese criterio hizo que cada decisión técnica fuera más fácil.
Seguimos construyendo.
