La tecnología correcta vs optimizar la que tienes [2026]

Pasé más de una década optimizando WordPress con plugins propios. lean-seo, lean-redirects, lean-autolinks, lean-ctas. Livianos, sin JavaScript, hechos a mano. Funcionaban. El problema no fue que no fueran buenos. Fue que estaban optimizando la herramienta equivocada: para un blog personal estático en 2026, WordPress nunca fue la categoría correcta.

Este post es la versión técnica de algo que escribí en febrero sobre cortar lo que no aporta valor. La pregunta filosófica era “¿esto merece mi tiempo?”. La pregunta técnica, más específica, es: ¿esta tecnología le corresponde al problema que estoy resolviendo, o sigo optimizando una categoría de stack que ya no aplica?

Construí plugins propios para WordPress. Eran el problema.

Llegué a tener varios plugins propios publicados en el repositorio de WordPress: lean-seo (reemplazó a Rank Math Pro en cristiantala.com el 8 de junio de 2026), lean-redirects (187 redirects en este blog, una sola consulta indexada a la base de datos, ~475 LOC), lean-autolinks (auto-linking de keywords y glosario), lean-ctas (CTAs dinámicos por categoría más captura de emails vía n8n y Listmonk). Livianos, sin JavaScript, hechos a mano. Funcionaban. Y todo eso fue el material con el que aprendí a hacer producto: la empresa que vendí, Pago Fácil, partió como concepto cuando hacía plugins de WordPress para ayudar a vender en línea con WooCommerce.

Lo que parecía optimización

Cada plugin resolvía un dolor real. Cada uno era código que yo mantenía. Cada actualización de WordPress podía romper algo, y el que debuggeaba era yo. El costo de WordPress no era la suscripción mensual que pagaba de hosting. Era mi tiempo defendiendo infraestructura en vez de creando contenido.

Lo que era en realidad

Hace muchos años no se me rompe un sitio de WordPress. Pero sí es incómodo estar actualizando servidores, versiones de PHP, plugins. Y cada funcionalidad nueva hace que el sitio sea cada vez más pesado por diseño de construcción, no porque se quiera. Eso se soluciona con un sitio estático. Y ahí estaba el ciego de una década: optimizaba los síntomas. El problema de fondo era que un blog personal no necesita WordPress en 2026: necesita un sitio estático, un editor de texto, y un comando git. Los plugins propios no eran ineficientes. Eran work-arounds sofisticados sobre una categoría de tecnología que no le correspondía al problema.

Cuando tu sistema de publicación necesita más mantenimiento que tu contenido, el sistema sobra.

Tres casos donde me equivoqué igual (o casi)

WordPress no fue el único caso donde confundí “optimizar” con “elegir bien”. Me pasó tres veces más en los últimos años, cada una con un stack distinto.

WordPress → Astro: la tecnología que le correspondía al blog

Lo conté hace unas horas. El resultado: 368 contenidos migrados en un día, US$720 al año de hosting ahorrados, Lighthouse 100/100/100, publicar con un git commit. Pero lo que importa acá no es el ahorro ni la velocidad. Es que la solución existía hace más de un año: el podcast ya corría con Astro.

Astro5: del MVP del podcast al sitio que le ganó al blog en performance

La primera vez que ocupé Astro para un sitio en vez de partir con WordPress fue para el sitio de nuestro podcast, eslahoradeaprender.com. Al principio, como era un MVP, el performance no era ideal. Pero con cada versión que lo pulía me quedaba mejor, y todo el contenido lo documenté público como build in public en ctala/landing-es-la-hora-de-aprender. Hoy llegó a un punto en que el performance era considerablemente mejor que el de mi blog. Y es ahí cuando decidí hacer el cambio del blog.

El repositorio del blog, además, fue la primera vez que ocupé Astro. Y la verdad es que solo lo manejo a través de agentes de Claude y/o Hermes en este momento. Editar contenido en un sitio estático, hace 2 años, era caóticamente complejo. Hoy, con agentes, es un comando de chat.

n8n self-hosted: cuando el SaaS no era la opción

Tengo 20 workflows en n8n corriendo en producción. 8.000 ejecuciones al mes, 15 horas semanales ahorradas. El setup: n8n self-hosted en un VPS para desarrollo, otro VPS para producción, y la instancia cloud de n8n solo para webhooks externos que necesitan SLA de uptime. Tres instancias. Costo total: US$20 al mes, contra US$99 que costaba el equivalente en Zapier.

Pero el dato relevante para esta conversación es otro: antes de n8n probé Zapier. Y antes de Zapier probé IFTTT. Y antes de IFTTT scripts propios en Python. Cada capa “optimizaba” la anterior sin preguntarse si la categoría de herramienta era la correcta. La respuesta obvia en retrospectiva: para automatizaciones que viven 24/7 con lógica compleja, la categoría correcta era self-hosted, no SaaS. El ahorro de US$948 al año es consecuencia, no el punto.

Coding agent: Opus no era el modelo correcto para el caso

El caso más reciente. Cambié el cerebro de mi coding agent de Opus a modelos open-source por US$30 al mes. El contexto importa: Opus 4.6 es top 5 en mi benchmark, calidad no era el problema. El problema era que estaba pagando US$11.250 al mes por developer por una capability que no necesitaba en la forma en que la usaba. Para un agente que corre sobre el día editando archivos, la categoría correcta no era “el modelo más capaz del mundo”: era “el modelo más capaz dentro de mi presupuesto de uso continuo”.

Tres casos, tres stacks distintos, mismo patrón. La optimización dentro de la categoría equivocada no te lleva al mejor resultado. Te lleva al resultado más caro dentro de un techo bajo.

El test de la tecnología que le corresponde (3 preguntas)

No tengo un framework formal con nombre ni un deck de slides. Tengo tres preguntas que uso como test para auditar un stack cada vez que estoy por invertir tiempo en optimizar algo. Si falla en dos de tres, sé que la respuesta es cambiar de categoría de tecnología.

¿Se rompe solo a las 3am o te cuesta mantenerlo?

La pregunta más rápida. Si algo se rompe a las 3am y hay una persona específica que tiene que levantarse a arreglarlo, eso ya no es tecnología: es un trabajo disfrazado de software. Pero también cuenta el otro caso: si lleva años sin romperse pero requiere que alguien actualice PHP, plugins, versiones del servidor y dependencias cada cierto tiempo, también está costando tu tiempo aunque no grite. WordPress con plugins propios me pasaba las dos cosas, aunque la primera ya casi no. Astro + Cloudflare Pages no me pasa ninguna de las dos en los meses que llevo. No porque sea mágico, sino porque la categoría correcta para un blog estático es “archivos HTML servidos por un CDN”, y eso no se rompe ni se actualiza.

¿Envejece bien o se rompe con la próxima versión?

Una herramienta bien elegida debería ser aburrida. La próxima versión del lenguaje, del framework, del plugin, del proveedor: si te genera ansiedad, la categoría está mal elegida. La migración de WordPress me dio una pista: cuando armé el plan de redirects, lo hice pensando en “qué pasa si Cloudflare cambia su formato de headers”, no en “qué pasa si mi plugin propio se rompe con PHP 9”. Esa diferencia es la categoría.

¿El costo real es la licencia o tu tiempo defendiéndola?

El test que mejor separa SaaS caro de self-hosted, o comercial de propio. Si estás pagando US$99 al mes por Zapier y dedicando 4 horas al mes a mantener integraciones que se caen, el costo real no es US$99: es US$99 + 4 horas-tuyas-de-investigación-por-cada-rotura. Si el SaaS no te ahorra más tiempo del que consume mantenerlo, la categoría está mal.

Cuándo SÍ vale la pena optimizar lo que tienes

No todo es migrar. El test anterior es para cuando estás por invertir tiempo serio en optimizar algo. Hay optimizaciones que tienen sentido pleno:

• El cuello de botella está dentro de la categoría correcta. Tu base de datos está lenta: optimizas índices. Tu CDN no cachea bien: ajustas headers. Tu modelo de IA se equivoca en una suite específica: ajustas el prompt, no cambias de vendor.
• El costo de migrar es mayor que el costo de optimizar. Cambiar de base de datos toma meses. Cambiar de proveedor de CDN toma una semana. La pregunta no es “qué es mejor en abstracto”: es “qué me duele más, lo que tengo o la migración”.
• Ya entendiste por qué te equivocaste, y la siguiente iteración es con la misma categoría pero mejor implementación. A veces tu SaaS no era el problema, era el plan equivocado dentro del SaaS.

La señal de que NO es optimizar es la más simple: estás parcheando la herramienta, no el problema. Si sumas un plugin por cada dolor, en 3 años tienes 40 plugins y tu sitio es más lento que cuando empezaste.

Lo que cambiaría y lo que no

Si me preguntas hoy, con la data que tengo: usaría Astro desde el día uno en vez de quedarme en WordPress. Habría adoptado n8n self-hosted un año antes. Habría cambiado de Opus a open-source para el coding agent el día que Anthropic removió Claude Code de Pro, no un mes después. Cada una de esas decisiones tardías me costó entre US$1.000 y US$5.000 que no tenía por qué gastar.

Lo que no cambiaría: los plugins propios. Eran buena ingeniería. Eran la decisión correcta dentro de la categoría de tecnología que había elegido. El error fue de categoría, no de ejecución. Y eso es lo más difícil de ver cuando estás del lado de adentro: cuando llevas más de una década optimizando un stack, cuesta admitir que el problema no es la optimización. Es la elección de tecnología de fondo.

La próxima vez que estés por escribir un plugin, comprar una herramienta, o defender una decisión técnica con “ya que estamos aquí”, pará. El build vs buy se responde mejor con estas tres preguntas que con cualquier análisis de costo-beneficio. Tarda 5 minutos aplicarlas. Si falla en dos, no es hora de optimizar el stack. Es hora de cambiar de categoría de tecnología. Y si te toca admitir que llevas años optimizando la herramienta equivocada, no te preocupes: a mí me tomó este año verlo. No lo hubiera hecho antes de este año, no por la tecnología, sino porque los agentes cambiaron el cálculo. La diferencia entre el founder senior y el junior no es no equivocarse. Es cuánto tarda en admitir que la categoría estaba mal desde el principio.