Por qué decidimos no construir un CMS para Opexius

Cuando decidimos agregar una sección de artículos a la web de Opexius, la idea parecía bastante simple. Queríamos compartir experiencias, aprendizajes y casos reales surgidos de proyectos en los que habíamos trabajado. Sin embargo, como suele ocurrir cuando uno se dedica al desarrollo de software, una necesidad relativamente pequeña empezó a transformarse rápidamente en algo mucho más ambicioso. Antes de escribir el primer artículo ya estábamos imaginando un CMS propio, generación automática de contenido mediante inteligencia artificial, categorías avanzadas, estadísticas, programación de publicaciones, integración con redes sociales y hasta herramientas para transformar notas de voz en borradores listos para publicar.

Desde el punto de vista técnico, nada de eso resultaba especialmente complejo. De hecho, probablemente podríamos haber tenido una primera versión funcionando en poco tiempo. El problema era otro. Cada nueva funcionalidad que agregábamos mentalmente al proyecto también incorporaba nuevas responsabilidades futuras. Un CMS no termina cuando se publica la primera versión. Después aparecen correcciones, mantenimiento, mejoras, actualizaciones y nuevas necesidades que inevitablemente consumen tiempo. Cuanto más analizábamos la situación, más evidente se volvía que estábamos diseñando una solución cada vez más sofisticada para resolver un problema que, en el fondo, seguía siendo bastante sencillo.

Por eso decidimos hacer algo que también solemos recomendar a nuestros clientes: detenernos por un momento y volver a la pregunta original. ¿Cuál era exactamente el problema que intentábamos resolver? Después de darle varias vueltas, la respuesta resultó mucho más simple de lo que habíamos imaginado. Necesitábamos una forma práctica de escribir artículos y publicarlos en la web. Nada más. No necesitábamos usuarios, permisos, flujos editoriales complejos ni automatizaciones avanzadas. Tampoco necesitábamos una base de datos o un panel administrativo. Todo eso podía ser útil algún día, pero no era necesario para cumplir el objetivo que teníamos delante.

A partir de esa conclusión, muchas decisiones comenzaron a ordenarse solas. En lugar de construir una plataforma para administrar contenido, decidimos construir únicamente una sección de contenido. La diferencia parece menor, pero cambió completamente el enfoque del proyecto. Terminamos utilizando Next.js con generación estática y almacenando cada artículo como un archivo Markdown dentro del propio repositorio. Los contenidos viven junto al código, Git se encarga del versionado y el proceso de publicación es extremadamente simple. No hay infraestructura adicional que mantener ni componentes que existan únicamente para resolver problemas hipotéticos del futuro.

Lo más interesante fue comprobar lo rápido que avanzó todo una vez que eliminamos complejidad innecesaria. En menos de veinticuatro horas teníamos una sección de artículos completamente funcional, integrada al sitio, optimizada para SEO y lista para comenzar a publicar contenido. Además, al reducir la cantidad de piezas involucradas también redujimos puntos de falla, simplificamos los despliegues y minimizamos las tareas de mantenimiento. La solución no era la más sofisticada que podíamos construir, pero sí era la más adecuada para el problema que teníamos delante.

Por supuesto, toda decisión implica concesiones. Actualmente no contamos con un editor visual, no podemos programar publicaciones futuras y tampoco existe un panel para que personas sin conocimientos técnicos carguen contenido por su cuenta. Del mismo modo, las estadísticas avanzadas y otras funcionalidades más complejas quedaron fuera de esta primera versión. Sin embargo, esa fue una decisión consciente. Preferimos incorporar esas capacidades únicamente cuando exista una necesidad real que las justifique y no antes.

Mirando hacia atrás, probablemente esa sea la principal enseñanza que nos dejó este proyecto. Las herramientas actuales, especialmente las relacionadas con inteligencia artificial, hacen que construir software sea más rápido que nunca. Paradójicamente, eso también vuelve más fácil caer en la tentación de construir cosas que todavía no necesitamos. Cuando el costo inicial de desarrollar una funcionalidad disminuye, es fácil olvidar que el verdadero costo suele aparecer después, durante años de mantenimiento, evolución y soporte.

En nuestro caso, el objetivo era empezar a publicar contenido y validar una idea. Si hubiéramos seguido el plan original, es muy probable que hoy todavía estuviéramos diseñando nuevas funcionalidades para un CMS mientras la sección de artículos seguía vacía. En cambio, elegimos resolver el problema real, poner la solución en producción rápidamente y concentrar nuestro tiempo en aquello que realmente aporta valor.

Al final, la lección trasciende a este proyecto en particular. En tecnología solemos dedicar mucho esfuerzo a decidir qué construir, qué herramientas utilizar o qué arquitectura adoptar. Sin embargo, algunas de las mejores decisiones nacen de una pregunta mucho más simple: ¿qué podemos dejar de construir? Porque muchas veces la solución más efectiva no es la más compleja ni la más innovadora. Es simplemente la que resuelve el problema correcto con la menor cantidad de fricción posible.