Qué construimos con él
Strapi resuelve un problema concreto y muy común: el cliente necesita cambiar contenido sin un desarrollador, y el producto necesita ese contenido a través de una API en lugar de como páginas ya renderizadas.
Defines tipos de contenido y obtienes una interfaz de administración, permisos por rol, gestión de medios y una API REST o GraphQL. El front-end —un sitio en Nuxt, una app en Vue, un cliente Flutter— consume esa API y permanece completamente ajeno a cómo trabajan los editores.
Es autoalojado y extensible por código, que es lo que lo separa de un CMS SaaS: los datos están en tu propio PostgreSQL, y los endpoints a medida o los hooks de ciclo de vida son código corriente en tu repositorio en vez de una petición de funcionalidad a un proveedor.
Dónde encaja
En productos guiados por el contenido donde un equipo de marketing o editorial publica de forma independiente: landings, catálogos, centros de ayuda, textos dentro de la app que cambian sin una release.
Cuándo lo recomendamos
Cuando personas que no son desarrolladores necesitan de verdad editar contenido, y cuando quieres ser dueño de los datos y del despliegue.
No para contenido que solo tocan los desarrolladores. El contenido de este sitio es Markdown en el repositorio, revisado junto al código, porque quienes lo escriben son quienes lo publican: un CMS ahí añadiría una administración, una base de datos y un despliegue para resolver un problema que nadie tiene. Y si el modelo de contenido es trivial y no cambia nunca, un CMS son más piezas móviles de las que el trabajo necesita.
