Por qué construí mi propio CMS en lugar de usar un SaaS

Hoy hay muchísimos CMS: Strapi, Ghost, Notion como parte del flujo de publicación o herramientas flexibles como Sanity. Probé varios conectados a este blog porque quería escribir con más comodidad.

Pero cuanto más herramientas usaba, más clara se volvía otra pregunta: no “¿cuál debería usar?”, sino “¿qué problema quiero resolver de verdad?”.

Durante un tiempo fui nómada de CMS. Probé Strapi, conecté Ghost, intenté simplificar la operación con Notion y volví a estructurar el sitio con Sanity. Cada uno tenía ventajas claras: algunos permitían empezar rápido, otros ofrecían un modelado de contenido flexible y otros daban una experiencia sofisticada para publicar un blog.

También renové este blog de SikLimited cinco o seis veces porque no terminaba de gustarme ni el CMS ni el diseño. No lograba asentarlo. Como me daba demasiada pereza crear algo nuevo, lo fui posponiendo; al final lo hice yo mismo. Los CMS existentes no ofrecían ciertas funciones tal como las necesitaba y resultaban difíciles de adaptar. Pensé que, al menos si tenía que mantenerlo, quizá escribiría más.

La incomodidad que se repetía era una: mi sitio no se explica como un simple blog.

Necesitaba artículos y trabajos; algunas páginas debían ser públicas y otras, accesibles solo para personas que recibieran un enlace concreto. Tras publicar, quería también integrar la indexación en buscadores, herramientas de SEO y GEO —optimización para que motores generativos y agentes de IA entiendan y citen el contenido—, orden de metadatos, analítica, seguimiento y un flujo editorial conectado con herramientas de IA. Solo publicar textos siempre se quedaba corto. Lo que buscaba no era un CMS aislado, sino una estructura de operación ajustada a mi manera de trabajar.

La idea se volvió más clara al encontrarme con los términos AX y GEO. No intento presentar una gran teoría de época. Pero al operar un sitio personal algo es evidente: antes de que una persona lea, los motores de búsqueda y distintos agentes ya lo están leyendo, resumiendo, citando y evaluando. Un sitio personal ya no se diseña solo con páginas bonitas y algunos artículos; también hay que pensar cómo se descubre, qué estructura permite comprenderlo y qué frases podrían citarse.

El punto de inflexión fue sorprendentemente sencillo: un cupón de uso de Codex que recibí a través de Kakao, una plataforma digital surcoreana. Más que querer construir un producto ambicioso, pensé que quizá podría reorganizar un poco mi flujo de trabajo. Ese pequeño impulso me llevó a dejar de buscar una herramienta menos incómoda y a reunir herramientas según mis propios criterios.

Ahora opero por separado la capa pública de portafolio y blog, y la capa de CMS. Está montado sobre Cloudflare Workers y D1: el CMS administra directamente artículos y trabajos, mientras la capa pública presenta el portafolio y el blog. Poco a poco añado indexación automática, Google Analytics, seguimiento con Umami, conexión a servidores MCP y automatización para SEO y GEO.

Lo importante no es tener muchas funciones, sino que todas apunten al mismo problema. No quería crear una herramienta para guardar contenido: quería una estructura que ayudara a que el trabajo que hago bajo mi propio nombre se descubra, se lea y se transmita con mayor precisión.

Por ejemplo, no quería que todos los trabajos fueran públicos como una entrada. En procesos de contratación o propuestas de colaboración, a veces necesitaba que solo los viera quien recibiera un enlace específico. Por eso también estoy incorporando enlaces de acceso y seguimiento del recorrido de quienes llegan desde ellos. Hace poco, al cambiar la estructura de rutas, se rompió el seguimiento de Umami. Fue un recordatorio: tener la propia estructura operativa da libertad, pero exige mantener esa libertad alineada.

Este texto no pretende afirmar que mi CMS sea mejor que Strapi, Ghost, Notion o Sanity. Son buenas herramientas. En mi caso, el portafolio, la escritura, el acceso restringido, la visibilidad en buscadores, la analítica y los flujos de IA quedaban dispersos en direcciones distintas, y necesitaba reunirlos.

Gestionar un sitio personal se parece cada vez menos a “publicar un texto” y más a diseñar por qué rutas circularán esos textos y trabajos. En vez de interpretar ese cambio de forma grandilocuente, elegí operarlo yo mismo, a pequeña escala. El resultado es este CMS.

En el próximo artículo explicaré con más detalle por qué terminé tratando esta estructura no solo como un depósito de textos, sino como un sistema de distribución, y cómo separo mentalmente la capa de portafolio de la capa de CMS.