Auditamos 50 sitios web de distritos escolares la semana pasada. Esto es lo que encontramos:

Métrica Resultado
Ejecutando WordPress Multisite 38 (76%)
Puntuación promedio de Lighthouse móvil 41
Plugins promedio por sitio 23
Búsqueda funcional 12 (24%)
Optimizado para móvil 18 (36%)
Cumplimiento de ADA 7 (14%)
Actualizado en los últimos 6 meses 22 (44%)

Estos son los sitios web que 5 millones de familias utilizan para encontrar horarios de autobús, cierres de escuelas, menús de almuerzo e información de contacto de maestros. Se merecen algo mejor.

He pasado la última década construyendo plataformas web, y nunca he visto un sector donde la brecha entre lo que los usuarios necesitan y lo que obtienen sea tan amplia. Los sitios web de distritos escolares no son tiendas de comercio electrónico ni páginas de marketing de SaaS. Son infraestructura pública crítica. Cuando un padre no puede encontrar el anuncio del día de nieve a las 6 AM en su teléfono, ese es un fallo real con consecuencias reales. Cuando una familia hispanohablante no puede encontrar la solicitud de almuerzo gratuito, los niños se quedan sin comer.

Este artículo detalla exactamente por qué los sitios web K-12 están atascados, qué aspecto tiene una arquitectura de reemplazo moderna, y las matemáticas reales de costos que hacen que el cambio sea obvio.

Tabla de contenidos

Sitios web de distritos escolares aún en WordPress Multisite: La solución de $30K

Los cuatro problemas que matan los sitios web K-12

Los sitios web de distritos escolares no fracasan por una razón. Fracasan porque cuatro problemas se refuerzan mutuamente, y nadie tiene el ancho de banda para desentrañarlos.

La crisis del personal de TI

Aquí hay un número que debería sorprenderte pero no sorprenderá a nadie que trabaje en educación: el equipo promedio de TI de un distrito escolar tiene 2-3 personas. Estos 2-3 seres humanos están gestionando 20-50 sitios web escolares MÁS correo electrónico, el sistema de información estudiantil (SIS), el sistema de gestión del aprendizaje (LMS), la infraestructura de red, y aproximadamente 10,000 dispositivos (Chromebooks, laptops de maestros, pizarras interactivas, impresoras).

No hay ancho de banda para la gestión de sitios web. Cero.

Hablé con un director de TI de un distrito de tamaño medio en Texas el año pasado. Me dijo que su equipo no había tocado la instalación de WordPress Multisite en ocho meses. No porque no les importara -- sino porque estaban abrumados con reparaciones de Chromebooks, migraciones de Google Workspace, y un susto de ransomware que consumió tres semanas de la vida de todos.

¿El resultado? Los sitios quedan sin actualizar durante meses. Los enlaces rotos se acumulan. La información desactualizada permanece activa. El subdirector que se jubiló hace dos años sigue siendo el contacto principal. El menú del almuerzo muestra septiembre de 2023. El formulario de inscripción redirige a un 404.

Esto no es pereza. Es una crisis de asignación de recursos. Cuando obligas al personal de TI a elegir entre mantener la red funcionando y actualizar el sitio web, el sitio web pierde cada vez.

El colapso de actualizaciones de contenido de maestros

Los maestros quieren actualizar sus páginas de clase. Genuinamente lo desean. Quieren publicar el programa, compartir tareas y poner anuncios sobre la feria de ciencias.

Pero WordPress es demasiado complejo para personal no técnico. No lo digo de manera condescendiente -- quiero decir que la interfaz de administración de WordPress fue diseñada para personas que construyen sitios web, no para personas que enseñan matemáticas de tercer grado. El editor Gutenberg, los conflictos de plugins, la biblioteca de medios, el sistema de taxonomía, el historial de revisiones... es mucho.

Entonces, aquí es lo que realmente sucede:

  1. El maestro intenta actualizar su página
  2. Algo se rompe (plantilla incorrecta, problema de formato, eliminó accidentalmente un widget)
  3. El maestro envía un correo electrónico a TI
  4. TI tiene un acumulado de 3 semanas
  5. El maestro se rinde
  6. El maestro publica todo en Google Classroom en su lugar

Ahora el sitio web oficial de la escuela es irrelevante para la comunicación diaria de la escuela. Los padres terminan haciendo malabarismos con 3-5 aplicaciones diferentes: el sitio web de la escuela (para lo que sigue ahí), Google Classroom (para tareas reales), ParentSquare (para anuncios), Remind (para mensajes rápidos), y quizás un grupo de Facebook para mayor medida.

Y todavía no pueden encontrar el horario del autobús.

Esta fragmentación es exasperante para las familias. Es especialmente brutal para los padres que no son expertos en tecnología o que tienen hijos en múltiples escuelas del distrito. El sitio web de la escuela debería ser la única fuente de verdad. En su lugar, es el único lugar donde nadie mira.

Cumplimiento de ADA como una demanda en ciernes

Este mantiene despiertos a los superintendentes por las noches -- o debería.

Los distritos escolares son cada vez más objetivos de demandas de ADA por sitios web inaccesibles. Y los acuerdos no son baratos. Una sola demanda de ADA puede costarle a un distrito $30,000 a $100,000+ en honorarios legales y costos de remediación. En 2024, el DOJ finalizó reglas específicamente que requieren que los sitios web del gobierno estatal y local (incluyendo distritos escolares) cumplan con WCAG 2.1 Nivel AA, con plazos que comienzan en abril de 2026 para entidades más grandes.

Ahora piensa en WordPress Multisite con 50 sitios escolares. Esos son 50 sitios potencialmente no conformes. Cada uno mantenido por una persona diferente (o nadie). Cada uno con un conjunto diferente de plugins, una configuración de plantilla diferente, diferentes hábitos de texto alternativo de imagen (o la falta de ellos), y diferentes enfoques para la jerarquía de encabezados.

¿Auditar 50 sitios individualmente? ¿Remediar 50 sitios individualmente? Eso es cientos de horas de trabajo. Y tiene que hacerse de nuevo cada vez que alguien agrega contenido, porque un maestro cargando un PDF sin etiquetado adecuado o una imagen sin texto alternativo pone la página de esa escuela fuera de conformidad nuevamente.

Aquí es lo que una arquitectura multi-tenant te da: un codebase conforme significa que los 50 sitios son conformes automáticamente. Los componentes refuerzan la accesibilidad. La estructura de encabezados es correcta por defecto. Las cargas de imágenes requieren texto alternativo. Los PDFs se marcan si no están etiquetados. Corriges un problema de accesibilidad una vez, y se corrige en todas partes.

El fracaso de la traducción es una crisis de equidad

En distritos escolares diversos, 30-50% de las familias hablan un idioma distinto al inglés en casa. Español, vietnamita, árabe, mandarín, criollo haitiano -- depende de la comunidad, pero los números son significativos.

¿Y sus sitios web escolares? Solo en inglés.

Estas familias no pueden encontrar información de inscripción. No pueden navegar por el proceso de solicitud de almuerzo gratuito y reducido. No pueden entender las rutas de transporte. Se pierden eventos, plazos y oportunidades.

Esto no es un "lindo de tener". El Título VI de la Ley de Derechos Civiles requiere que los distritos escolares que reciben financiamiento federal se comuniquen efectivamente con padres con dominio limitado del inglés (LEP). Un sitio web solo en inglés es un riesgo de cumplimiento además de ser un fracaso de equidad.

Veamos el costo de arreglarlo:

Solución Costo anual
WPML en WordPress (50 sitios × $199/año) $9,950/año + costos de traducción continuos
Finalsite Sin soporte real de múltiples idiomas
Widget de Google Translate Inexacto, rompe el diseño, pesadilla de ADA
Next.js + next-intl + traducción por lotes ~$110 único para 5 idiomas

Esa cifra de $110 no es un error tipográfico. Con una aplicación Next.js adecuadamente internacionalizada usando next-intl, extraes todas las cadenas de contenido, las ejecutas a través de una API de traducción aproximadamente $22 por idioma, revisas con hablantes nativos, y listo. Agrega un idioma según lo necesite tu comunidad. El enrutamiento maneja /es/schools/lincoln-elementary automáticamente.

¿El widget de Google Translate que usa la mitad de estos distritos? Produce traducciones gramaticalmente rotas, rompe el diseño de la página, crea problemas de accesibilidad, y -- de manera crítica -- no traduce contenido dentro de imágenes o PDFs. Es un parche que señala a las familias: "No nos importa lo suficiente como para hacer esto correctamente".

Por qué WordPress Multisite fue la apuesta equivocada

Para ser justos, WordPress Multisite no era una opción irrazonable en 2014-2016. Era gratis (más o menos). Técnicamente podía ejecutar múltiples sitios desde una instalación. Había un ecosistema enorme de plugins. Y los distritos podían encontrar desarrolladores de WordPress.

Pero aquí es lo que sucedió durante la próxima década:

  • Proliferación de plugins: Cada sitio acumuló plugins para cosas que el núcleo no podía hacer. SEO, formularios, calendarios, superposiciones de accesibilidad (que en realidad no funcionan, por cierto), traducción, almacenamiento en caché, seguridad. Nuestro auditoría encontró un promedio de 23 plugins por sitio. Esos son 23 vulnerabilidades de seguridad potenciales, 23 cosas que pueden entrar en conflicto, 23 cosas que necesitan actualizaciones.
  • Deuda de versión de PHP: Muchas de estas instalaciones se están ejecutando en versiones de PHP que han alcanzado el final de su vida útil. Actualizar PHP corre el riesgo de romper plugins. No actualizar PHP es un agujero de seguridad.
  • El desorden de Gutenberg: El cambio de WordPress al editor de bloques rompió los flujos de trabajo para maestros que apenas habían aprendido el editor clásico. Muchos distritos aún están ejecutando el plugin Classic Editor, que en sí mismo está envejeciendo.
  • Espiral de muerte de rendimiento: WordPress sirve HTML procesado en el servidor desde una base de datos MySQL para cada solicitud. Agrega WooCommerce (sí, algunas escuelas ejecutan tiendas de mercancía), BuddyPress, o cualquier plugin pesado, y estás viendo tiempos de carga de 3-5 segundos. ¿En móvil sobre una conexión celular del lote de una escuela? Olvídalo.
  • Área de superficie de seguridad: WordPress alimenta el 43% de la web, lo que lo hace el objetivo #1 para ataques automatizados. ¿Un solo plugin comprometido en tu multisite? Cada sitio escolar está expuesto.

WordPress Multisite fue la opción pragmática hace una década. Ahora es deuda técnica.

La trampa del proveedor: Finalsite, Blackboard y SchoolPointe

La alternativa que la mayoría de los distritos consideran es un proveedor de sitios web K-12. Finalsite es el nombre más grande. También está Blackboard (ahora Anthology), SchoolPointe, Apptegy (Thrillshare), y algunos otros.

Estas plataformas resuelven algunos problemas. Manejan el hosting. Proporcionan plantillas. Tienen algunas características de accesibilidad. Pero vienen con compensaciones serias:

Costo: Finalsite para un distrito con 45 escuelas corre $135,000 a $360,000 por año. Eso no es un costo único. Eso es recurrente. Cada año. Siempre. Si quieres irte, estás comenzando de cero -- no hay una exportación fácil de tu contenido y estructura.

Inflexibilidad: Obtienes lo que te dan. ¿Necesitas una integración personalizada con tu SIS? Eso será un compromiso de servicios profesionales. ¿Quieres cambiar cómo funciona el calendario? Envía una solicitud de función y espera. ¿Tu distrito tiene un programa bilingüe único que necesita enrutamiento personalizado? Lo siento, eso no está en la plantilla.

Rendimiento: Ejecuté auditorías de Lighthouse en varios sitios de distrito alojados en Finalsite. Las puntuaciones oscilaron entre 35 y 62 en móvil. Estos son sitios web de marketing, esencialmente -- páginas procesadas en el servidor con paquetes JavaScript pesados, scripts de seguimiento de terceros e imágenes no optimizadas. No son rápidos.

Bloqueo: Este es el grande. Tu contenido vive en su CMS. Tus URLs se estructuran de su manera. Tu modelo de datos sigue su esquema. Tres años después, los costos de cambio son enormes. Lo saben. Ese es el modelo comercial.

No estoy diciendo que estos proveedores sean malvados. Proporcionan un servicio real para distritos que tienen cero capacidad técnica. Pero si tienes la opción de invertir en infraestructura que posees, las matemáticas apuntan abrumadoramente en esa dirección.

Sitios web de distritos escolares aún en WordPress Multisite: La solución de $30K - arquitectura

La solución: Arquitectura Multi-Tenant Next.js

Aquí es lo que realmente construimos. Una aplicación. Desplegada una vez. Sirviendo a cada escuela en el distrito.

/                          → Página de inicio del distrito
/schools/[slug]            → Página de inicio escolar (45 escuelas)
/schools/[slug]/calendar   → Eventos específicos de la escuela
/schools/[slug]/staff      → Directorio de personal
/schools/[slug]/staff/[id] → Página de clase del maestro
/[lang]/schools/[slug]     → Versión traducida (es, vi, ar, zh, ht)
/portal                    → Portal de padres (autenticación requerida)
/admin                     → Portal de contenido de maestros/personal

45 escuelas = 45 rutas programáticas desde un codebase. Un despliegue. Un lugar para corregir errores. Un lugar para reforzar la accesibilidad. Un lugar para agregar funciones.

El stack de tecnología

Framework:     Next.js 15 (App Router)
CMS:           Headless (Sanity o Payload CMS)
Auth:          Supabase Auth + Row-Level Security
i18n:          next-intl
Hosting:       Vercel (o Cloudflare Pages)
Search:        Algolia o Typesense
Accessibility: axe-core en pipeline de CI/CD

Portal de maestros

Esta es la pieza que lo cambia todo para operaciones diarias. Los maestros inician sesión con su cuenta de Google del distrito (SSO a través de Supabase Auth). Ven su página de clase. Pueden:

  • Actualizar su programa (editor de texto enriquecido, no WordPress Gutenberg)
  • Publicar tareas con archivos adjuntos
  • Agregar anuncios
  • Actualizar horarios de oficina e información de contacto

Eso es todo. Sin barras laterales, sin widgets, sin configuraciones de plugin, sin confirmaciones "¿Estás seguro de que deseas actualizar?". Una interfaz enfocada que hace cuatro cosas bien.

Row-Level Security (RLS) en Supabase significa que los maestros solo pueden editar su propio contenido. No se necesita supervisión administrativa. Sin boletos de TI.

-- Política de RLS de Supabase: los maestros solo pueden actualizar su propio contenido
CREATE POLICY "Teachers can update own content"
  ON class_pages
  FOR UPDATE
  USING (auth.uid() = teacher_id);

Portal de padres

Los padres se autentican y ven una vista personalizada basada en sus hijos inscritos. Ruta de autobús para su hijo. Menú de almuerzo para su escuela. Próximos eventos filtrados a escuelas relevantes. Información de contacto del maestro para los maestros actuales de su hijo.

No más buscar a través de 45 sitios escolares para encontrar información sobre tus tres hijos en tres escuelas diferentes.

Accesibilidad por defecto

La biblioteca de componentes refuerza WCAG AA. Cada componente <Image> requiere texto alternativo. La jerarquía de encabezados se refuerza mediante la plantilla de página. El contraste de color se valida en el tiempo de compilación. La gestión de enfoque se maneja en los componentes de navegación.

Ejecutamos axe-core en el pipeline de CI/CD. Cada solicitud de extracción obtiene una auditoría de accesibilidad. Si falla, no se implementa. Punto.

Esto importa cuando tienes 200 maestros agregando contenido. No puedes capacitar a 200 personas en accesibilidad. Puedes construir un sistema que hace que el incumplimiento sea estructuralmente imposible.

Rendimiento

Next.js con generación estática significa que las páginas escolares se pre-renderizan en tiempo de compilación y se sirven desde un CDN. Un padre en el lote de la escuela en una conexión 3G obtiene la página en menos de un segundo. Las puntuaciones de Lighthouse consistentemente alcanzan 90+.

Hablamos de la diferencia entre una puntuación de Lighthouse de 41 (promedio de WordPress Multisite de nuestro auditoría) y 95. Eso no es una mejora incremental. Es una experiencia diferente.

Las matemáticas que hacen esto obvio

Hagamos el costo total de propiedad de tres años para un distrito con 45 escuelas:

Solución Año 1 Año 2 Año 3 Total 3 años
Finalsite $135-360K $135-360K $135-360K $405K-$1.080K
WordPress Multisite (mantener existente) $30-50K $30-50K $30-50K $90-150K
Next.js Multi-Tenant (construir + host) $60-100K + $540 $540 $540 $61-101K

El costo de hosting de Next.js es $45/mes en Vercel Pro, o incluso menos en Cloudflare Pages. Eso es $540/año para una plataforma que sirve 45 escuelas. El solo hosting de WordPress es típicamente $500-1,500/mes para una instalación de multisite administrada.

Punto de equilibrio versus Finalsite: 3-6 meses. Punto de equilibrio versus mantenimiento continuo de WordPress: año uno.

Y aquí es lo que la columna de costo de WordPress no captura: el tiempo del personal de TI. Esas 2-3 personas de TI pasando 10-15 horas a la semana en extinción de incendios de sitios web? Eso es $30-50K en asignación de salario que podría ir hacia literalmente cualquier otra cosa. Gestión de Chromebooks. Ciberseguridad. Realmente dormir toda la noche.

El costo de construcción de $60-100K para la plataforma Next.js es una inversión única. La posees. Sin licencia anual. Sin tarifas por escuela. Sin bloqueo de proveedor. ¿Agregar una 46ª escuela? Es una nueva entrada en el CMS, no una llamada de ventas.

Cómo se ve realmente la migración

No vamos a pretender que esto es trivial. Migrar 45 sitios web escolares es un proyecto. Aquí es cómo se divide:

Semanas 1-3: Descubrimiento y auditoría de contenido

  • Inventariar todo el contenido existente en 45 sitios
  • Identificar lo que realmente está actualizado versus lo que está abandonado
  • Asignar la arquitectura de información
  • Entrevistar al personal de TI, maestros y padres sobre puntos de dolor

Semanas 4-8: Construcción de la plataforma

  • Aplicación Next.js multi-tenant con integración de CMS headless
  • Portal de maestros con Supabase Auth
  • Biblioteca de componentes con accesibilidad incorporada
  • Configuración de i18n con next-intl
  • Pipeline de CI/CD con pruebas automatizadas de accesibilidad

Semanas 9-12: Migración de contenido y capacitación

  • Scripts de migración de contenido automatizados (API REST de WordPress → CMS headless)
  • Revisión y limpieza manual de contenido
  • Capacitación de maestros (sesiones de 30 minutos -- si toma más tiempo, la UX necesita mejorar)
  • Lanzamiento suave del portal de padres

Semanas 13-14: Lanzamiento

  • Cambio de DNS
  • Mapeo de redirección (cada URL antigua obtiene un 301)
  • Monitoreo y soporte

Línea de tiempo total: 14 semanas. Eso es un semestre. Puedes lanzar durante el receso de invierno cuando el tráfico es más bajo.

El concepto clave: no estás reconstruyendo 45 sitios web. Estás construyendo un sitio web que sirve 45 escuelas. Esa es una reducción de complejidad de orden de magnitud.

Si tu distrito está explorando este tipo de migración, hemos hecho este trabajo antes. Comunícate con nosotros y podemos recorrer los detalles específicos para el tamaño y necesidades de tu distrito. También puedes ver nuestra página de precios para rangos aproximados en proyectos como este.

Preguntas frecuentes

¿Cuánto cuesta un rediseño de sitio web de distrito escolar? Depende del enfoque. Las plataformas de proveedores como Finalsite corren $135,000-$360,000 por año para un distrito de 45 escuelas. Mantener un WordPress Multisite existente cuesta $30,000-$50,000 por año en tiempo de TI, hosting y soporte de desarrollo. Una construcción personalizada de Next.js multi-tenant corre $60,000-$100,000 como una inversión única con aproximadamente $540/año en hosting. Durante tres años, la construcción personalizada es la opción más económica por un amplio margen -- y posees la plataforma.

¿Es WordPress Multisite bueno para distritos escolares? Era una opción razonable en 2014-2016, pero se ha convertido en un pasivo. La proliferación de plugins, el área de superficie de seguridad, el pobre rendimiento móvil, y la incapacidad de reforzar la accesibilidad en 50 sitios lo hacen un mal encaje para requisitos modernos de K-12. Cada sitio en la red puede derivar en direcciones diferentes, y con 2-3 personal de TI gestionando todo lo demás en el distrito, nadie tiene tiempo para mantenerlo. Los distritos ejecutando WordPress Multisite desde 2016 están cargando deuda técnica significativa.

¿Cuáles son los requisitos de cumplimiento de ADA para sitios web de distritos escolares? El DOJ finalizó reglas en 2024 que requieren que sitios web del gobierno estatal y local -- incluyendo distritos de escuelas públicas -- cumplan con estándares WCAG 2.1 Nivel AA. Las entidades más grandes enfrentan plazos comenzando abril de 2026. El incumplimiento puede resultar en demandas con acuerdos que van desde $30,000 a más de $100,000 en honorarios legales y remediación. El desafío clave para los distritos es que el cumplimiento no es una corrección única -- cada pieza de contenido agregada debe mantener el cumplimiento, es por eso que construir refuerzo de accesibilidad en la plataforma misma es el único enfoque sostenible.

¿Cómo manejas múltiples idiomas en un sitio web escolar? Con una aplicación Next.js usando next-intl, la internacionalización está incorporada en la estructura de enrutamiento. Cada idioma obtiene su propio prefijo de URL (/es/, /vi/, /ar/), que es mejor para SEO y accesibilidad que un widget de Google Translate. La traducción de contenido para 5 idiomas cuesta aproximadamente $110 usando APIs de traducción con revisión de hablantes nativos. Compara eso con WPML en WordPress a $199/año por sitio ($9,950/año para 50 sitios), y los ahorros son dramáticos. Más importante, las traducciones son precisas, están correctamente formateadas, y no rompen el diseño de la página.

¿Pueden los maestros actualizar sus propias páginas sin soporte de TI? Sí -- ese es el punto completo del portal de maestros. Los maestros se autentican con su cuenta de Google del distrito, ven un editor simplificado para su página de clase, y pueden actualizar su programa, publicar tareas, agregar anuncios, y actualizar información de contacto. Row-Level Security asegura que solo pueden editar su propio contenido. Sin boletos de TI, sin acumulado de 3 semanas, sin rendirse y publicar todo en Google Classroom en su lugar. Si la interfaz de edición requiere una sesión de capacitación más larga que 30 minutos, consideramos eso un fallo de UX y la rediseñamos.

¿Cuánto tiempo toma migrar un sitio web de distrito escolar? Para un distrito de 45 escuelas, espera una línea de tiempo de 14 semanas: 3 semanas para descubrimiento y auditoría de contenido, 5 semanas para construcción de plataforma, 4 semanas para migración de contenido y capacitación, y 2 semanas para lanzamiento. El mejor momento para lanzar es durante el receso de invierno o verano cuando el tráfico del sitio web es más bajo. La migración de contenido es parcialmente automatizada usando la API REST de WordPress para extraer contenido en el nuevo CMS headless, pero se necesita revisión y limpieza manual ya que mucho del contenido antiguo está desactualizado.

¿Qué es mejor para sitios web escolares: Finalsite o una construcción personalizada? Finalsite tiene sentido para distritos con absolutamente cero capacidad técnica y presupuesto para licenciamiento continuo. Para distritos que pueden invertir en una construcción única, una plataforma Next.js multi-tenant personalizada cuesta menos durante tres años ($61-101K versus $405K-$1.08M), funciona mejor (Lighthouse 95+ versus 35-62), ofrece propiedad completa del contenido e infraestructura, y proporciona flexibilidad para integraciones personalizadas con SIS, LMS y otros sistemas de distrito. La compensación es que necesitas un socio de desarrollo para la construcción inicial y desarrollo de funciones continuas.

¿Por qué los sitios web de distritos escolares son tan lentos en móvil? La mayoría de sitios de distrito ejecutan WordPress con 20+ plugins, cada uno agregando JavaScript y CSS a cada carga de página. Las páginas renderizadas en el servidor requieren una consulta a la base de datos para cada solicitud. Las imágenes a menudo están sin optimizar. No hay CDN, o el CDN está mal configurado. Agrega un entorno de hosting compartido y estás viendo tiempos de carga de 3-5 segundos. En una conexión móvil en un lote de escuela, es aún peor. Un sitio Next.js generado estáticamente sirve HTML pre-construido desde servidores periféricos en todo el mundo, típicamente cargando en menos de un segundo. Eso importa cuando un padre está verificando un día de nieve a las 6 AM en su teléfono.

¿Los distritos escolares poseen su sitio web si usan un proveedor como Finalsite? No. Tu contenido vive en su CMS, estructurado de acuerdo con su modelo de datos, alojado en su infraestructura. Si decides irte, estás esencialmente comenzando de nuevo. No hay una exportación limpia de tu contenido, plantillas o configuración. Este bloqueo es por diseño -- es lo que hace que el modelo de ingresos recurrentes funcione. Con una construcción personalizada usando un CMS headless como Sanity o Payload, posees cada pieza de contenido, cada línea de código, y cada configuración de despliegue. Puedes cambiar proveedores de hosting, cambiar tu framework front-end, o traer desarrollo internamente sin perder nada.

Tu sitio web de distrito es la puerta de entrada para 10,000 familias. Si esa puerta de entrada no abre en un teléfono, no habla su idioma, y no deja que los maestros actualicen sus propias páginas -- está fallando a todos a quienes se supone que debe servir.