Un CMS que tu equipo use de verdad (no uno que solo entiende el programador)

Hay dos formas de acabar mal con un CMS. La primera: no tener ninguno, y depender del programador para cambiar un titular. La segunda: tener uno tan complejo que solo el programador sabe usarlo, que es exactamente el mismo problema con más pasos.

La primera pregunta no es técnica

Antes de elegir plataforma, hay que responder algo mucho más simple: ¿quién va a escribir contenido cada semana, y qué tan cómodo está esa persona con herramientas digitales? La respuesta cambia completamente la solución.

Si nadie del equipo va a tocar el contenido más de una vez al trimestre, probablemente no necesitáis un CMS: un cambio puntual por email al equipo de desarrollo es más barato que mantener un panel que nadie usa.

Si hay una persona de marketing publicando cada semana, necesita un editor visual, previsualización antes de publicar y la posibilidad de programar contenido, sin tener que entender qué es un componente ni un campo de tipo richtext.

Los errores más frecuentes al elegir CMS

Elegir por lo que usa la competencia, no por quién va a usarlo en tu equipo. Un CMS “de moda” que nadie sabe manejar no aporta nada.

Sobrediseñar los campos. Cuantos más campos obligatorios y reglas tenga el formulario de publicación, más fricción hay para publicar y menos se publica.

No pensar en la salida. Si el contenido queda atrapado en un formato propietario del CMS, cambiar de proveedor dentro de dos años significa reescribir todo desde cero. Un buen CMS exporta en formatos estándar (Markdown, JSON) sin fricción.

Ojo: el mejor CMS no es el que tiene más funciones, es el que tu equipo abre sin dudar cada semana.

Cuándo un CMS “sin cabeza” (headless) tiene sentido

Para equipos con web y app, o con varias webs que comparten contenido (por ejemplo, varios idiomas o marcas), un CMS headless separa el contenido de cómo se muestra. El equipo de marketing escribe en un panel simple; el contenido se sirve automáticamente donde haga falta, sin que el editor tenga que preocuparse por el diseño.

Para una web corporativa única con un equipo pequeño, esa separación suele ser complejidad de más. Un panel integrado y sencillo suele ganar.

Cómo lo hacemos en Bitora

Antes de proponer un CMS, preguntamos quién va a usarlo y con qué frecuencia. A partir de ahí decidimos si conviene un panel a medida, un headless CMS conocido, o directamente prescindir de uno si el contenido apenas cambia. En cualquier caso, el contenido siempre se puede exportar: no construimos dependencia donde no hace falta.

Si tu equipo lleva meses pidiéndote cambios de texto que podrían hacer solos, puedes ver cómo lo resolvemos en desarrollo web a medida.