/tools Herramientas a medida

Las herramientas con las
que opero mis proyectos.

No uso estas herramientas porque estén de moda: las construí porque las necesitaba. Monitoreo, finanzas, seguimiento de clientes, seguridad y despliegues — todo corre sobre este mismo sitio. Cada caso de estudio cuenta el problema real que lo originó y cómo lo resolví. La misma disciplina que aplico aquí es la que recibe cada cliente.

Monitoreo, SLOs y error budgets

Observabilidad estilo SRE, construida desde cero

El problema

Operar sitios de clientes sin saber si están caídos hasta que alguien avisa. Los servicios de uptime genéricos no detectan un deploy roto que responde 200 con la página equivocada.

La solución

Un motor de checks propio: cada sondeo valida código HTTP, contenido esperado en la respuesta y umbral de latencia. Los fallos se agrupan en incidentes (del primer fallo al primer éxito) y sobre el historial se calculan SLOs y presupuestos de error al estilo Google SRE.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

SLO por servicio con burn rate: no solo "cuánto cayó", sino a qué velocidad se consume el presupuesto de error.
Alertas push instantáneas al móvil vía ntfy cuando un servicio cae o se degrada.
Vigilancia de expiración de certificados TLS y de dominios.
Los datos alimentan la página pública de status: lo que ves ahí es lo mismo que veo yo.

Astro API routes Drizzle ORM Turso cron externo ntfy Ver el status público en vivo →

Costos y P&L por proyecto

Saber qué cuesta operar cada cosa, al centavo

El problema

Hosting, dominios, base de datos, email: cada proyecto acumula servicios con facturación distinta. Sin registro, es imposible saber si un proyecto es rentable o cuánto cuesta mantenerlo al año.

La solución

Un registro de servicios por proyecto (y a nivel de cuenta) con su costo y ciclo de facturación, cruzado con ingresos cobrados, pendientes y proyectados. El resultado es un P&L por proyecto: margen real, no intuición.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

Normalización de ciclos de facturación (mensual, anual) a costo comparable.
Ingresos en tres estados — cobrado, pendiente, proyectado — para separar caja real de expectativa.
La lógica de P&L y manejo de dinero tiene su propia batería de tests unitarios.

Drizzle ORM Turso Vitest Ver el P&L en la demo del panel →

Portal de seguimiento para clientes

Transparencia como práctica, no como promesa

El problema

El cliente que no sabe en qué va su proyecto pregunta por WhatsApp, y la respuesta se pierde. La confianza se erosiona en el silencio entre actualizaciones.

La solución

Cada proyecto tiene una vista de seguimiento donde el cliente ve el avance sin pedirlo: hitos, interacciones y briefings. Las páginas públicas de proyecto muestran solo lo que está marcado como visible; el resto queda en el panel.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

Registro de interacciones por cliente: qué se habló, qué se acordó, cuándo.
Briefings estructurados que documentan los requisitos antes de escribir código.
Control fino de visibilidad: cada dato decide si es público, del cliente o interno.

Astro SSR Drizzle ORM auth con allowlist

Bóveda cifrada de credenciales

Los secretos de los proyectos, nunca en texto plano

El problema

Las credenciales de cada proyecto (API keys, variables de entorno) suelen terminar en notas, chats o archivos sueltos: el peor lugar posible.

La solución

Una bóveda dentro del panel que cifra cada valor con AES-256-GCM antes de tocar la base de datos. La clave de cifrado vive fuera de la BD, en el entorno del servidor: un volcado de la base de datos no expone ningún secreto.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

Cifrado autenticado (GCM): un valor alterado no se descifra en silencio, falla.
Backups del panel que preservan el cifrado: los secretos viajan cifrados también en el respaldo.
La ruta /admin exige sesión con allowlist revalidada en cada request, en cada capa.

AES-256-GCM node:crypto middleware Astro

CI/CD con health check y rollback

Desplegar sin miedo porque el pipeline vigila

El problema

Un deploy que pasa los tests todavía puede romper producción. Si nadie mira en los minutos siguientes, el sitio queda caído hasta que alguien lo nota.

La solución

El pipeline de GitHub Actions despliega, verifica la salud del sitio en vivo y, si el health check falla, revierte automáticamente al deploy anterior. Cada run reporta su resultado al panel, que guarda el historial: éxito, fallo o rollback.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

Health check post-deploy contra el sitio real, no contra un mock.
Rollback automático sin intervención humana cuando la verificación falla.
Historial de runs en el panel con enlace directo a los logs de cada ejecución.

GitHub Actions Vercel Vitest Ver el laboratorio en vivo →

Chaos engineering controlado

Romper el sitio a propósito para confiar en las alertas

El problema

¿Cómo sabes que tu monitoreo detecta una caída si nunca has visto una? Confiar en alertas que jamás se han disparado es fe, no ingeniería.

La solución

Un módulo de inyección de fallos activable desde el panel: latencia extra, errores 500 o servicio muerto, por ruta. Sirve para verificar de punta a punta que los monitores detectan, el incidente se registra y la alerta llega al móvil.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

Fail-open por diseño: si el motor de caos falla, el request pasa limpio. El caos jamás puede volverse un incidente real.
TTL obligatorio en cada flag: ningún fallo inyectado sobrevive más de 15 minutos, ni por olvido.
El panel y la autenticación están excluidos por código: siempre hay un botón de pánico alcanzable.

middleware Astro flags en Turso con TTL Ver los experimentos en vivo →

Observabilidad de seguridad (micro-SIEM propio)

Saber quién intenta entrar, no solo esperar a que lo logre

El problema

Cualquier sitio con IP pública recibe sondeos automáticos desde el primer minuto: CMS ajenos, archivos de configuración, inyecciones en cada parámetro. La reacción normal es ignorar el ruido — pero esos 404 son la superficie de ataque real, y descartarlos es tirar una señal gratis.

La solución

Un motor propio que corre en el middleware de cada request: un clasificador alineado con OWASP Top 10 detecta firmas de ataque, un rate limiter durable de dos capas y una lista de bloqueo frenan el abuso, endpoints señuelo confirman intención maliciosa, y un cron horario agrega eventos, detecta anomalías por estadística y aplica bloqueos automáticos escalonados.

Recreación del panel con datos ilustrativos — los datos reales no se publican.

En producción

Fail-open en cada capa: si el sensor de seguridad falla, el request pasa limpio — nunca puede tumbar el sitio que protege.
Detección de anomalías con z-score sobre una baseline de 30 días, no una caja negra: cada alerta se puede explicar con una frase.
Bloqueos con TTL obligatorio y escalado por reincidencia (1h → 24h → 7d), nunca eternos por defecto.
La vitrina pública muestra agregados reales con OPSEC deliberada: nunca IPs completas, nunca nombres de reglas, nunca qué rutas son señuelo.

middleware Astro Drizzle ORM Turso cron externo estadística propia Ver Security Operations en vivo →

La herramienta que uso contigo es la que uso conmigo.

Si trabajamos juntos, tu proyecto entra a este mismo sistema: monitoreo con SLOs, seguimiento visible, credenciales cifradas y despliegues con red de seguridad.

Hablemos de tu proyecto