Por qué dejé de usar Strapi para proyectos nuevos (y qué uso ahora)

Strapi fue mi CMS headless de cabecera durante años. Hoy ya no lo uso para proyectos nuevos. Esto es lo que cambió.

Empecé a utilizar Strapi cuando el mercado buscaba una alternativa robusta a WordPress y Strapi funcionaba de maravilla: API REST y GraphQL listas, panel de administración claro, self-hosted, open source. Lo usé en varios proyectos y lo recomendé sin dudar.

Con el tiempo, algunas cosas me hicieron replantearlo:

1. El costo real no es la licencia, es el mantenimiento.

La única opción realmente gratuita que encontré para hostear Strapi fue Render.com. Soporta bien los requisitos y funciona sin colgarse para proyectos no muy grandes, pero es lento. Strapi Cloud es una buena alternativa y económica, pero sus limitaciones no dan mucho margen antes de pasar al plan de pago. Self-hosted en Digital Ocean da buen rendimiento, pero implica tiempo constante en actualizaciones y mantenimiento. Para proyectos pequeños, ese costo oculto pesa más que el ahorro.

2. La rigidez del modelo.

Cuando el cliente quiere algo fuera del esquema (campos condicionales, flujos de aprobación, permisos granulares), o pagas Enterprise o desarrollas plugins propios. Y ahí ya no estás ahorrando tiempo. El ecosistema de plugins ha crecido, pero muchos tienen fallos o no hacen exactamente lo que necesitas.

3. Desarrollo de componentes.

Desarrollar componentes propios en Strapi es versátil, pero mantenerlos alineados con tu repositorio de front-end (en mi caso Next.js) resulta complicado. Un cambio sencillo te obliga a modificar dos repositorios. Trabajas doble.

4. El mercado cambió.

En 2026, para el 80% de los proyectos de contenido que hago, archivos Markdown con validación en build o APIs propias sobre Supabase resuelven más rápido y con menos mantenimiento. Las cuotas gratuitas de Supabase son generosas para proyectos pequeños. Ya no necesitas administrar un servidor completo de Strapi para gestionar contenido.

Lo que no cambió:

No creo que Strapi sea malo. Fue la respuesta correcta para 2020-2024. Mi sitio enriquemontes.com sigue funcionando con Strapi y en desarrollos grandes como GmVykon.com, el mantenimiento de un servidor Strapi está plenamente justificado.

El caso de Turista.com.mx:

Cuando empecé a plantear la migración de esta plataforma activa desde 1999, Strapi parecía la opción natural. De los primeros experimentos con Gatsby antes de llegar a Next.js, Strapi encajaba por la facilidad de conectar con GraphQL.

Pero mis rutinas no eran estrictamente "contenido". Eran lógica de negocio densa: reglas, flujos de aprobación, cálculos, integraciones con APIs externas. Migrar todo eso a Strapi habría requerido reescribirlo desde cero, con un resultado más lento y más frágil que lo que ya tenía.

Entonces tomé una decisión que no es la más elegante en el papel:

Migré el front-end de PHP con Zend Framework a Next.js, y dejé el backend en Apigility (hoy Laminas). Gracias a la robustez de PHP/MySQL, el servidor necesario para los enormes volúmenes de operaciones de Turista.com.mx es pequeño, sobre todo por el soporte de SSR.

En el papel, uno quiere "todo moderno". Pero la decisión correcta no es la más elegante. Es la que respeta lo que ya funciona y no rompe lo que ya está probado.

Si no está roto, no lo arregles.

Lo que aprendí:

1. Strapi no es la respuesta universal. Es excelente para contenido editorial, portafolios, blogs, e-commerce simple. Para lógica de negocio compleja, no es su terreno. Forzarlo ahí es un error.

2. Migrar no significa reescribir todo. A veces la mejor migración es híbrida: modernizas donde aporta valor y conservas lo que ya funciona.

3. 27 años de código no son deuda técnica. Son activo probado. No todo lo viejo hay que tirarlo. Hay que saber qué se queda y por qué.

#Nextjs #Strapi #HeadlessCMS #WebDevelopment #TypeScript