Después de 11 años en la industria, he aprendido que lo más caro que puedes hacer es construir algo que podrías haber comprado—o en este caso, configurado. A menudo sentimos la necesidad de demostrar nuestra profundidad técnica construyendo todo desde cero, pero durante mucho tiempo, esto fue solo un impuesto creativo que pagué por mi propio ego. El verdadero desafío es saber cuándo usar una herramienta para que puedas enfocarte en el arte de la implementación.
Mi portafolio siempre ha sido un proyecto del que estoy orgulloso, pero hasta hace poco, su fundamento técnico parecía una cápsula del tiempo. Durante años, gestioné todo con un backend PHP simple que analizaba datos de archivos INI. Eventualmente, hice la transición a una configuración donde mi frontend leía datos en bruto directamente de archivos JSON locales.
Aunque el frontend estaba pulido, el flujo de trabajo era insostenible. Cada corrección de errores tipográficos o actualización de proyecto requería que abriera mi IDE, editara un archivo e hiciera un commit. Recuerdo la frustración de querer actualizar una sola frase mientras estaba lejos de mi escritorio y darme cuenta de que no podía hacerlo sin un ciclo completo de despliegue. A principios de 2025, decidí que era hora de un cambio profesional. Quería un backend robusto y accesible que me permitiera gestionar contenido desde una interfaz, en cualquier dispositivo, sin tocar una línea de código.
No quería reinventar la rueda construyendo una interfaz administrativa personalizada desde cero, así que comencé a explorar las soluciones profesionales ya disponibles en el mercado. Esa búsqueda me llevó directamente al concepto de "Headless CMS". Para quienes no están familiarizados, esta arquitectura significa que la "cabeza" (el frontend) está completamente separada del repositorio de contenido, permitiendo que los datos se sirvan en cualquier lugar a través de API. Ya había trabajado con esta arquitectura antes a nivel empresarial, pero no estaba familiarizado con cuánto había evolucionado el mercado independiente.
Rápidamente descubrí una amplia gama de opciones, comenzando con los "gigantes de la industria" en el espacio SaaS, como Contentful. Estas plataformas son poderosas, pero a menudo vienen con niveles restrictivos de "pago por registro" y límites de API que se sienten como una bomba de tiempo para un proyecto en crecimiento. Como ingeniero, no quería que mi crecimiento fuera penalizado por una factura de suscripción. Quería Soberanía de Datos—quería poseer el código y la base de datos.
Cambié exclusivamente a opciones autoalojadas, buscando una herramienta que equilibrara "pureza" técnica con facilidad administrativa. Audité los líderes actuales:
Strapi destacó porque representa el punto medio perfecto entre una aplicación "lista para usar" y un framework altamente personalizable. Proporciona una interfaz pulida e intuitiva que es un salvavidas cuando necesito hacer actualizaciones rápidas desde mi teléfono, pero nunca me atrapa en una burbuja "low-code". Como está construido en Node.js, todavía tengo el poder de escribir lifecycle hooks personalizados o extender controllers de API cuando necesito lógica que un CMS estándar no puede proporcionar.
Este equilibrio me permitió escalar mi infraestructura sin la fricción que enfrenté en el pasado. El ecosistema está repleto de características que lo convirtieron en el claro ganador:
Cuando lancé este blog, no tuve que empezar de cero. Simplemente extendí mis modelos Strapi existentes para servir ambos proyectos. Transformó mi backend de un lector de archivos estático en un motor escalable y multi-proyecto.
Creé este blog para inspirar a otros desarrolladores a valorar la eficiencia en ingeniería. Es fácil perderse en lo "genial" de construir desde cero. Es mucho más difícil—y más gratificante—elegir una base que equilibre el control técnico profundo con una interfaz centrada en el ser humano.
La base está establecida. Strapi se encarga del resto. Ahora, es hora de construir.
