Criterios técnicos para elegir el CMS adecuado según el tipo de proyecto

El CMS más popular del momento no necesariamente es el correcto para tu proyecto. Elegir Strapi porque es el que más estrellas tiene en GitHub, o Sanity porque lo usa una empresa famosa, es una heurística que funciona a veces por accidente. La elección correcta depende de factores concretos del proyecto, no de tendencias.

La pregunta que hay que responder primero no es "¿qué CMS es mejor?" sino "¿qué restricciones tiene este proyecto?" Restricciones de presupuesto, de hosting, de perfil del equipo, de tipo de contenido y de velocidad de iteración apuntan a CMS distintos. El que resuelve bien esas restricciones es el correcto, aunque tenga menos stars.

Cinco preguntas concretas ayudan a decidir: ¿Quién edita el contenido (solo desarrolladores o también editores no técnicos)? ¿El contenido necesita estructura fija o modelado flexible? ¿Hay restricciones de dónde viven los datos (on-premise, región específica)? ¿El equipo trabaja principalmente en TypeScript? ¿El presupuesto incluye licencia SaaS o solo hosting propio?

Si los editores son no técnicos y necesitan autonomía, Strapi o Sanity tienen interfaces más accesibles. Si el equipo es TypeScript-first y quiere el CMS como parte del codebase, Payload es la opción más coherente. Si los datos ya existen en una base de datos relacional, Directus evita reescribir el schema.

El costo de un CMS no es solo la licencia. Es el tiempo de onboarding del equipo, el costo de hosting, el costo de mantenimiento de versiones y el costo de las personalizaciones. Sanity puede parecer caro por su precio de API, pero si el equipo tarda la mitad en implementar features porque la DX es mejor, el costo total puede ser menor.

Strapi open source tiene costo cero de licencia, pero requiere que alguien del equipo entienda bien su arquitectura para escalar correctamente. Payload requiere más tiempo inicial de setup, pero ese tiempo se recupera en velocidad de iteración posterior. No existe la opción gratis en ningún caso; el costo se paga en dinero, tiempo o flexibilidad.

El anti-patrón más costoso es elegir el CMS con el que el equipo tiene más experiencia aunque no sea el más adecuado para el proyecto. La familiaridad acelera el arranque pero puede crear problemas estructurales difíciles de resolver cuando el proyecto crece y el CMS muestra sus límites.

Otro anti-patrón es no involucrar a los editores de contenido en la evaluación. Un CMS que el equipo técnico ama pero que los editores no pueden usar sin ayuda constante termina creando un cuello de botella operativo. La experiencia del editor importa tanto como la experiencia del desarrollador.