
Cuando decides abrir un blog en 2026, la primera reacción del mundo es predecible. "Usa WordPress", "monta un Ghost", "prueba con Substack". Y tiene sentido, porque esas plataformas llevan años resolviendo el mismo problema y lo hacen razonablemente bien.
Nosotros las evaluamos todas. Y al final decidimos construir el nuestro desde cero. No por capricho, sino porque cada plataforma nos obligaba a elegir entre lo que queríamos hacer y lo que nos dejaban hacer.
El objetivo nunca fue "tener un blog". Era tener un espacio técnico donde pudiéramos publicar artículos con código fuente resaltado, bloques de terminal, tablas comparativas, imágenes optimizadas y series de posts conectados. Todo eso con un panel de administración que no nos obligara a tocar FTP ni instalar dieciséis plugins.
También queríamos control total sobre la experiencia del lector. Sin banners de cookies invasivos, sin scripts de terceros innecesarios, sin tiempos de carga que hicieran dudar de si la página había muerto. Y con SEO de verdad, no el SEO de "instala Yoast y reza".
WordPress sigue siendo el CMS más popular del mundo y eso dice mucho de su flexibilidad. Pero también dice mucho de su deuda técnica. Para conseguir un blog con buen rendimiento, código resaltado y un editor decente necesitábamos al menos media docena de plugins. Cada plugin es una dependencia que puede romperse, tener vulnerabilidades o dejar de mantenerse.
Además, WordPress usa PHP y MySQL. No tenemos nada en contra de ninguno de los dos, pero nuestro día a día gira alrededor de TypeScript y Node.js. Mantener un stack completamente diferente solo para el blog nos parecía un coste de contexto innecesario.
Y luego está la seguridad. WordPress es el objetivo número uno de ataques automatizados en la web. No porque sea inseguro de fábrica, sino porque su popularidad lo convierte en un imán. Mantenerlo actualizado, parchear plugins y vigilar que nadie inyecte código es un trabajo continuo que preferíamos evitar.
Ghost fue la opción que más cerca estuvo de convencernos. Es elegante, rápido y tiene un editor limpio. Pero su modelo de membresías y newsletter está tan integrado en el core que el blog sin esas features se siente incompleto. Además, auto-alojar Ghost requiere Node.js con MySQL, y la configuración no es trivial cuando quieres personalizar más allá de lo que permite el tema.
Astro es brillante para sitios estáticos, pero nuestro blog necesitaba un panel de administración con autenticación, un editor WYSIWYG, borradores, programación de publicaciones y búsqueda full-text. Eso encaja mejor con una aplicación server-side que con un generador estático.
Hay más opciones, claro. Hugo, Eleventy, Jekyll. Todas tienen su nicho. Pero todas nos obligaban a trabajar con ficheros Markdown en un repositorio Git, compilar el sitio y desplegarlo. Para un blog personal eso puede funcionar, pero para un flujo donde queremos escribir, previsualizar, programar y publicar desde cualquier dispositivo no era suficiente.
Después de evaluar las opciones, la conclusión fue sorprendentemente clara. Necesitábamos un blog que funcionara como una aplicación web completa, con el stack que ya conocemos. Next.js nos daba el framework, SQLite nos daba la base de datos sin gestionar un servidor externo, y Docker nos permitía empaquetar todo para desplegarlo donde quisiéramos.
La inversión inicial era mayor, sin duda. Pero a cambio ganábamos algo que ninguna plataforma nos podía dar por completo.
Hay que ser honesto. Construir un blog desde cero lleva más tiempo del que piensas al principio. Las primeras semanas fueron rápidas, porque el esqueleto básico (posts, categorías, editor) sale relativamente rápido con Next.js y Drizzle ORM. Pero luego aparecen los detalles que hacen la diferencia entre un prototipo y algo que puedes usar de verdad.
El feed RSS, el sitemap dinámico, las imágenes Open Graph generadas automáticamente, la búsqueda full-text, el sistema de revisiones, las cabeceras de seguridad, el rate limiting. Todo eso suma semanas de trabajo que WordPress te regala de serie con un par de plugins.
La diferencia es que al construirlo nosotros, entendemos cada línea. Cuando algo falla, sabemos dónde mirar. Cuando queremos una feature nueva, sabemos exactamente dónde encaja. Y cuando llega una vulnerabilidad, no dependemos de que un tercero publique un parche.
Si tu objetivo es publicar contenido lo antes posible y no te importa el stack ni la personalización profunda, WordPress o Ghost son la respuesta correcta. No hay que reinventar la rueda cuando la rueda existente funciona para tu caso.
Pero si eres desarrollador, si quieres un espacio que funcione exactamente como necesitas, si valoras la propiedad total de tu contenido y tu infraestructura, y si lo ves como una inversión en aprendizaje además de como un blog, entonces construir desde cero merece la pena.
En los siguientes artículos de esta serie vamos a entrar en detalle. El stack técnico, el editor personalizado, las decisiones de seguridad y rendimiento, y las funcionalidades que nos dimos cuenta de que necesitábamos solo después de usarlo durante semanas. Si quieres profundizar, en la infraestructura con Dokploy lo cubrimos en detalle.
"La mejor herramienta no es la más popular ni la más nueva. Es la que encaja con tu forma de trabajar."

Autoalojar un blog significa que la seguridad, el SEO y el rendimiento son tu responsabilidad. Cabeceras CSP, rate limiting, imágenes OG generadas, ISR y las lecciones que aprendimos configurándolo todo.

Cada decisión técnica tiene un porqué. Elegimos Next.js sobre Astro, SQLite sobre PostgreSQL y Docker con Dokploy sobre Vercel. Aquí explicamos las razones y lo que aprendimos por el camino.