Tienes un Tercer Tipo de Deuda Técnica. Nadie Ha Creado una Herramienta para Encontrarla.
Abres tu app de siempre. ERROR. Ya estás cabreado porque no tenías planeado hacer mantenimiento hoy. Así que empiezas a investigar. Mi terminal me escupió ECONNREFUSED 127.0.0.1:46279 en la cara y me tomó exactamente treinta segundos entender que nadie, en ningún lado, iba a lidiar con esto. Sin página de estado. Sin ticket que abrir. Sin SLA que agitar. El servicio gratuito del que dependía una pieza de mi pipeline se había caído, y el único humano en la Tierra al que le importaba era yo.
Por supuesto que nunca había firmado un contrato con ellos. Estaba usando un servicio gratuito. Nunca aparecí en ninguno de sus dashboards. Y sin embargo, a las 9:17 de esa mañana de lunes, me debían algo que ni siquiera sabían que me debían. O en realidad al revés: yo les debía a ellos. Había estado acumulando una deuda durante meses sin darme cuenta, y el acreedor acababa de cobrarla.
TLDR (Conoces la deuda técnica que escribiste. Mides la deuda técnica que heredaste de tus dependencias. Hay una tercera pila de la que nadie habla: la deuda que importas cada vez que conectas un SaaS gratuito a tu pipeline. No aparece en ningún dashboard. Ningún linter la detecta. Dependabot no la ve. Audita tu deuda importada antes de que un lunes por la mañana la audite por ti.)
Las Tres Pilas
Hay tres tipos de deuda técnica y la mayoría de los equipos solo cuentan dos.
La primera es la deuda que escribiste. El hack del viernes por la tarde que sobrevivió. El TODO de 2022 que se volvió crítico. El if-statement que se suponía temporal y ahora tiene su propio historial de commits. Sabes que existe porque la escribiste, y sabes más o menos dónde vive porque el mal olor te persigue. Tu linter detecta una parte. Code review detecta otra parte. El resto se queda en tu cabeza.
La segunda pila es la deuda que heredaste. Lockfiles llenos de dependencias transitivas que nunca elegiste. Librerías que no han lanzado nada en tres años pero aún se instalan. Paquetes con dos mantenedores y uno de ellos se acaba de mudar a una granja. También sabes que esta pila existe, porque hay herramientas para eso. npm audit, Dependabot, Snyk, Renovate. Te gritan cada lunes por la mañana quieras o no. Los gritos son molestos, pero al menos alguien está gritando.
Luego está la tercera pila. La pila para la que no tienes nombre, porque nadie se lo puso. El servicio gratuito que conectas a un paso de tu pipeline porque era más fácil que construir la cosa tú mismo. La API alojada que procesa una parte de tus datos porque tenían un tier gratuito generoso. El webhook endpoint que hace una conversión que nunca ibas a escribir tú mismo. Nada de esta deuda está en tu código base. Nada aparece en package.json. Ninguna herramienta la monitorea. Ni siquiera la cuentas como dependencia en tu propia cabeza, porque las dependencias son cosas que importas y estas cosas son cosas que llamas.
Pero son dependencias. Y son deuda. La deuda simplemente está sentada en otro lugar, en el servidor de otra persona, con los incentivos de otra persona. No la emitiste. La importaste.
La deuda que no emitiste sigue siendo tu deuda en el momento en que se cae.
Por Qué Nadie La Ve
La razón por la que nadie ve esta tercera pila es estructural, no estúpida.
Cada herramienta que construimos para medir deuda técnica mira dentro de tu código base. Los linters analizan tus archivos. Dependabot lee tus manifiestos. Snyk escanea tu lockfile. Code review pasa en tus PRs. Todo el stack de observabilidad asume que la deuda vive en artefactos que posees y puedes grepear. La deuda importada no vive en artefactos que posees. Vive en una URL. Y una URL no es un activo, es una promesa.
Una promesa hecha por una entidad que no te debe nada.
También hay una razón más sutil. No importaste estas cosas a propósito. Las importaste un martes por la tarde cuando necesitabas una conversión rápida, la googleaste, encontraste un endpoint gratuito, pegaste la URL en un archivo de config, y seguiste adelante. Se sintió como usar una herramienta, no como firmar un contrato. Nada en tu editor te dijo que acababas de atornillar la mortalidad de un extraño a tu pipeline. Así que no actualizaste ningún libro mayor mental. No había libro mayor.
Lo gracioso es que el resto de la industria es perfectamente consciente de que estas cosas se rompen. Una encuesta de 2025 a 1,000 ejecutivos senior de tech encontró que el 93% se preocupa por el impacto del downtime y el 100% experimentó pérdidas de ingresos relacionadas con outages ese año. La lista de incidentes públicos lee como un catálogo de horror: AWS us-east-1 cayéndose por horas y arrastrando a proveedores SaaS dependientes, reglas WAF de Cloudflare eliminando un trozo del tráfico global en un solo push, errores de configuración de Azure tumbando Microsoft 365 y Xbox al mismo tiempo. Sabemos que los outages pasan. Los rastreamos públicamente. Escribimos postmortems.
Pero los rastreamos después. No existe una herramienta que entre a tu repo y diga "dependes de un puñado de cosas que podrían desaparecer mañana y tienes un plan para cero de ellas." Esa herramienta no existe porque los inputs no están en tu repo. Están esparcidos por llamadas HTTP en archivos random, URLs hardcodeadas en config, statements de fetch enterrados en módulos de servicio, variables de entorno apuntando a hostnames que escribiste una vez y olvidaste.
Sabes cómo se ve tu package.json. No tienes idea de cómo se ven tus llamadas salientes. Ese es el gap.
La Auditoría Que Nadie Ejecuta
Después de que el backend de Excalidraw de Kroki se crasheó y se negó a volver, me senté por primera vez en años y ejecuté la auditoría. No la de paquetes npm. La de llamadas HTTP salientes a servicios gratuitos por los que nunca había pagado y no podía reemplazar rápidamente.
Me tomó una mañana de sábado grepear todo. El pipeline en el que estaba trabajando en ese momento era una automatización de catálogo de productos para un cliente pequeño de ecommerce, el tipo de cosa que genera diagramas de ensamblaje y especificaciones visuales para páginas de productos en su tienda. No glamoroso, pero se despliega todos los días. Y cada paso del pipeline tenía un SaaS gratuito atornillado en algún lugar.
Llegué a 14 llamadas salientes a servicios por los que nunca había pagado. No te voy a aburrir con el inventario completo. Los números interesantes estaban en otro lado. El número de items que tenían un plan de fallback documentado en algún lugar: cero. El número de items con monitoreo en el servicio upstream: cero. El número de items que alguna vez había stress-testeado matando la dependencia a propósito: también cero.
Estaba ejecutando un pipeline de producción encima de una pila de promesas gratuitas, y lo había estado haciendo por tanto tiempo que ya ni siquiera se registraba como un riesgo. Se registraba como "infraestructura."
El reemplazo de Kroki, el fix real, fue pequeño. Un solo archivo TypeScript que hace exactamente lo que el servicio roto estaba haciendo por mí, ni más, ni menos. Corre en Bun. Llama a una librería directamente en lugar de pasar por un navegador headless. Vive en 47 líneas. Usa 93MB de RAM. Renderiza un diagrama en aproximadamente 2 milisegundos. Corre en un contenedor Docker en un VPS por el que ya estaba pagando $6 al mes, en la misma red interna que el resto del stack. Sin endpoint público. Sin certificados. Sin superficie de ataque. Ha estado corriendo desde el día que lo escribí y no se ha caído ni una vez.
Ahora, la parte que me molesta es reciente. Hace cinco años, ese fix me habría tomado un día completo. Tal vez dos. El costo-beneficio de reemplazar una dependencia gratuita habría sido una pérdida neta para cualquiera de ellas, así que habría hecho lo que hace todo el mundo, que es esperar a que el upstream vuelva y rezar. Hoy, con Claude Code frente a mí, el mismo fix me tomó treinta minutos y lo hice durante un descanso de café. Las matemáticas se voltearon. La cosa que solía ser demasiado cara de arreglar ahora es demasiado barata de ignorar.
De la misma manera que reconstruí un setup pagado que el vendor decidió retirar, por una fracción del costo hace unos meses. El arbitraje ha cambiado bajo nuestros pies, y la mayoría de nosotros seguimos ejecutando los precios viejos en nuestra cabeza.
Cada deuda importada que había estado cargando por años de repente era barata de refinanciar. Simplemente no me había dado cuenta.
El Fix No Es Self-Hosting
Cuidado aquí, porque la versión fácil de esta historia es "self-hostea todo" y esa es la conclusión equivocada.
Self-hosting tiene su propia deuda. Los servidores necesitan parches. Los contenedores necesitan reiniciarse. Los discos se llenan. El hecho de que reemplacé una dependencia gratuita con 47 líneas de mi propio código no significa que gané el juego. Significa que cambié un acreedor por otro. El nuevo acreedor soy yo, y al menos sé dónde encontrarme.
El fix real es mucho más aburrido. El fix real es mantener un balance.
No necesitas una herramienta. Necesitas una lista. Un archivo de texto plano en tu repo, o una sección en tu README, o lo que sea que sobreviva tu propia pereza. Cada servicio externo que tu pipeline llama. Tres columnas. Qué hace, qué muere si se muere, y qué harías al respecto un lunes por la mañana. Eso es todo. El acto de escribirlo te fuerza a mirar cada línea y hacer la única pregunta que importa: ¿tengo un plan, o estoy apostando a que este es demasiado grande para caer?
La mayoría de los tuyos no tendrán un plan. Está bien. El punto de la auditoría no es arreglar todo en un fin de semana, es hacer la tercera pila visible. Una vez que puedes verla, puedes empezar a refinanciar los items más baratos primero. Los reemplazos de dos milisegundos. Los fixes de 47 líneas. Los que donde la librería existe como paquete y lo único por lo que alguna vez estuviste pagando era el wrapper HTTP.
Descubrirás, como yo, que un número sorprendente de tus deudas importadas son exactamente eso: un wrapper HTTP alrededor de algo que podrías haber llamado directamente. La infraestructura se veía impresionante porque había un dashboard alojado y una página de estado y una marca. Quita el wrapper y la lógica real son cincuenta líneas. Este es el mismo patrón que sigo encontrando en otros lados también, y es por eso que escribí una pieza completa sobre cómo la herramienta más barata que hace el trabajo tiende a ganarle a la fancy en producción. Menos superficie, menos que se rompa, menos de lo que depender.
Tres preguntas para poner en el balance, para cada línea.
Primera pregunta: si esta cosa muere un lunes por la mañana a las 9 a.m., ¿qué deja de funcionar? Sé honesto. No digas "nada crítico." Camínalo. Rastrea la llamada. Ve dónde aterriza. Si la respuesta es "el paso de publish" o "la cosa que ve el cliente" o "la parte que hace dinero," encierra la línea en rojo.
Segunda pregunta: ¿tengo un fallback, o simplemente creo que este es demasiado grande para caer? El razonamiento de "demasiado grande para caer" es exactamente el razonamiento que te mata. Cloudflare es demasiado grande para caer. AWS us-east-1 es demasiado grande para caer. Ambos cayeron en 2025. Los tiers gratuitos de mantenedores indie caen cada semana. La creencia no es un fallback.
Tercera pregunta es la barata. ¿Cuántas líneas de código me costaría reconstruir esto yo mismo, ahora mismo, mientras estoy calmado, en lugar de en pánico a las 9:17 de un lunes? Tal vez la respuesta es "miles" y decides vivir con el riesgo. Esa es una decisión real. Tal vez la respuesta es "47" y lo haces durante un descanso de café. Esa también es una decisión real. El punto es tomar la decisión en lugar de que te la tomen.
La mayoría de nosotros nunca hemos tomado la decisión. Simplemente seguimos clickeando el servicio gratuito en el pipeline porque estaba ahí.
Tres días después del incidente, volví a la página de estado de Kroki. El backend de Excalidraw seguía listado como caído. Alguien había posteado un mensaje en su Discord preguntando si alguien estaba trabajando en eso. Nadie había respondido.
Mi pipeline había estado corriendo por 72 horas sin interrupción. Había olvidado que le debía algo a alguien.
AI te hace resiliente o egoísta. Depende de cómo entrecierres los ojos. 🤷
En fin, el punto es este: audita tu deuda importada. No porque necesites arreglarla toda, sino porque necesitas verla. La deuda que puedes ver, puedes planificarla. La deuda que no puedes ver simplemente espera un lunes por la mañana.
Fuentes
- Cockroach Labs, Outages Observer: Why 2025 Failures Demand Unbreakable Systems in 2026 (https://www.cockroachlabs.com/blog/2025-top-outages/)
(*) La imagen de portada fue hecha por una AI, que es en sí misma un servicio gratuito que estoy importando a mi workflow. Interpreta eso como quieras.