«Es solo un blog, lo sacamos en un sprint» es una frase que tarde o temprano se oye en el canal de ingeniería de cualquier SaaS, y hasta tiene algo de verdad. Una tabla de posts, un par de rutas, un campo Markdown: un sprint. Lo que esa estimación no ve es todo lo que le falta a la versión del sprint y todo lo que cuestan los años que vienen después. Yo he construido este stack, y Kookee existe porque creo que la mayoría de los equipos no deberían hacerlo; estas son las cuentas, sin maquillar.
En qué se convierte «solo un blog»
La versión del sprint no tiene un editor digno de ese nombre, así que la expansión empieza de inmediato:
El editor. Marketing no va a escribir en archivos Markdown detrás de un pull request. Un editor de texto enriquecido de verdad (imágenes, contenido incrustado, bloques de código, un deshacer que funcione) lleva semanas de trabajo aunque partas de un framework de editor de código abierto, y nunca deja de pedir atención.
Gestión de medios. Subidas, almacenamiento, redimensionado de imágenes, una ruta por CDN, límites de tamaño. Todo sistema de contenido acaba teniendo una; el tuyo también.
Flujo de trabajo. Borradores, publicación programada, enlaces de vista previa y un historial de revisiones que alguien va a suplicar la primera vez que un editor sobrescriba una hora de trabajo.
Los campos alrededor del contenido. Slugs y su unicidad, etiquetas, categorías, metadatos de SEO, imágenes de Open Graph, fechas.
Luego llega la segunda superficie. Un registro de cambios pide tipos y versiones; un centro de ayuda pide categorías y búsqueda; un tablero de comentarios pide votos, estados e hilos de comentarios. Cada uno es «pequeño», cada uno vuelve a implementar la edición, el almacenamiento y la entrega con alguna variante, y cada uno se convierte en otro producto interno cuyo único mantenedor eres tú.
Un cálculo conservador para blog, registro de cambios y centro de ayuda con una interfaz de administración usable se mide en meses de ingeniería, no en sprints. Con lo que cuesta de verdad un ingeniero (salario más cargas), eso es dinero real antes de que un solo usuario vea una página, y es la parte barata.
La partida que todos olvidan: para siempre
La estimación de construcción termina en el lanzamiento. El sistema no:
Seguridad y dependencias. Tu sistema de contenido ahora es superficie de ataque (autenticación, subidas, una API pública) que parcheas tú, a tu ritmo, para siempre. Actualizaciones de dependencias, migraciones de framework, la nueva versión mayor e incompatible de la biblioteca del editor: impuestos anuales.
Infraestructura. Hosting, base de datos, almacenamiento de objetos, CDN, monitoreo, copias de seguridad. Cada cosa es pequeña por separado; juntas son una factura fija y una guardia permanente.
La cinta de correr de las funcionalidades. Una búsqueda que de verdad encuentre las cosas (hoy eso significa búsqueda semántica y embeddings), traducciones cuando sales al mercado internacional, respuestas con IA cuando los centros de ayuda de tu competencia las tienen. Cada una es un proyecto sobre un sistema que nadie quiere mantener.
El mantenimiento de un stack de contenido propio puede llevar, siendo realistas, semanas de ingeniería al año, repartidas sin hacer ruido en «arreglos rápidos» que nunca son rápidos. El costo de fondo es de oportunidad: cada hora que va ahí es una hora que no va al producto por el que pagan tus clientes. La infraestructura de contenido es algo que cualquiera puede comprar hecho; tu producto no. Gastar horas de ingeniería, que son escasas, en lo que se compra hecho es el verdadero error, sea cual sea la factura.
Razones para construirlo de todos modos
Los artículos sobre construir o comprar que nunca le dan la razón a construir son publicidad. Hay razones reales para construir:
El contenido es tu producto. Si eres una plataforma de publicación, una empresa de documentación, o tus flujos de contenido son lo que te diferencia, construye. La herramienta genérica te va a poner trabas.
Restricciones duras. Entornos regulados donde el contenido debe vivir en tu infraestructura, despliegues aislados de la red (air-gapped), normas de residencia de datos que un proveedor no puede cumplir.
Modelos realmente atípicos. Tu contenido no se parece en nada a entradas con campos. Eso sí, antes de darlo por hecho, comprueba si lo cubren los tipos de entrada personalizados de una plataforma.
Lo que no se sostiene: «construiremos exactamente lo que necesitamos, ni más ni menos». La lista de necesidades de arriba no es el exceso de funciones de un proveedor: es el punto al que llega todo sistema de contenido, porque los editores, el equipo de marketing y los lectores piden una y otra vez las mismas cosas.
Lo que deberías obtener si compras
Si compras, exige al proveedor el nivel que justifica no construir:
Tu dominio y tu frontend. Contenido entregado como JSON a través de una API y un SDK, renderizado por tu app con tu sistema de diseño, para que el SEO juegue a tu favor y nada parezca un añadido pegado por fuera. Si el proveedor insiste en alojar tus páginas, has comprado un creador de sitios web, no infraestructura.
Sin dependencia del proveedor. Todo se puede recuperar como JSON documentado con tu clave de API. Que la puerta de salida esté abierta es justo lo que hace seguro entrar.
Toda la superficie en un solo sistema. Blog, registro de cambios, centro de ayuda, comentarios, páginas: el valor se multiplica cuando el tablero de comentarios enlaza con la entrada del registro de cambios y el centro de ayuda alimenta las respuestas de IA, con un solo panel y una sola API en lugar de cuatro proveedores cosidos entre sí, cuyas suscripciones juntas suelen costar más que una sola plataforma.
Una forma gratuita de empezar. Deberías poder validar la integración antes de pagar nada.
Para eso está hecho Kookee: un backend de contenido con los módulos que de verdad necesitan los productos SaaS, un SDK tipado y hooks de React para la capa de renderizado, un portal alojado para el primer día y la API como vía principal de entrega, de modo que el único código que mantienes es la parte fina que siempre fue tuya: el renderizado.
Un procedimiento para decidir
¿El contenido es lo que te diferencia, o hay una restricción dura de por medio? Si es así, construye, a conciencia y con gente asignada.
Si no, haz un prototipo de la vía de comprar: renderiza la lista de tu blog y un artículo de ayuda con el SDK de una plataforma en tu dominio. Resérvale un día.
Calcula con honestidad lo que cuesta construir: los meses iniciales más el mantenimiento anual, a costo real, frente a la suscripción.
Decide una vez, por escrito, y deja de reabrir el debate cada vez que alguien diga «es solo un blog».
El blog del tamaño de un sprint existe: puedes tenerlo el viernes. Lo que pesa frente al precio de comprar son los cinco años que vienen después de ese viernes.