Resumonkey
Cifras a noviembre de 2026
Un digest diario de empleos que busca en tres mercados, puntúa cada oferta de 0 a 10 y explica el puntaje.
- Rol
- Producto y construcción en solitario
- Stack
- Python/FastAPI, Next.js, Supabase, Render (cron), Resend, GitHub
El problema
Buscar en varios mercados significa leer cada día las mismas ofertas con ruido. Muchas son del país equivocado, exigen un idioma que la búsqueda excluye o ya están vencidas. Un ranking que no puede explicarse es difícil de creer y difícil de corregir.
Lo construí primero para mi propia búsqueda en Canadá, Chile y roles remotos. Funciona como piloto, así que cada decisión de diseño se juzga con uso diario real antes de agregar nada más.
Descubrimiento
Tres preguntas dieron forma al producto. ¿Qué no debe llegar nunca al digest? Filtros duros por país, idioma requerido y antigüedad de la oferta. ¿Cómo gana su puntaje una oferta? Con una rúbrica por componentes y el razonamiento a la vista, no una sola opinión. ¿Cómo sé que el puntaje sigue comportándose bien tras un cambio? Con un conjunto de casos conocidos que debe pasar primero.
Decisiones clave
- ▹Filtros duros antes de puntuar. País, idioma requerido y antigüedad son reglas, no criterio del modelo. El costo es que un filtro vale lo que vale su regla.
- ▹Un puntaje de 0 a 10 construido por componentes, con explicación. Hay más que mantener que con un solo número, pero cada puntaje se puede cuestionar y corregir.
- ▹Una suite de calibración de 8 casos conocidos antes de cada envío real. Cambiar algo toma más tiempo, a cambio de detectar un puntaje que se desvía antes de que llegue al digest.
- ▹Trabajo repartido entre modelos de lenguaje. Más piezas que coordinar, a cambio de un tiempo de ejecución que bajó de 8,3 a 3,2 minutos.
- ▹Texto completo de cada oferta guardado en Supabase. Los puntajes se pueden auditar y volver a ejecutar sobre exactamente lo que se puntuó.
Qué construí
- ▹Servicio de filtrado y puntaje: Python/FastAPI.
- ▹Interfaz web: Next.js.
- ▹Almacenamiento: Supabase, con el texto completo de cada oferta.
- ▹Ejecución diaria: una tarea programada (cron) en Render.
- ▹Envío: el digest se despacha con Resend.
- ▹Código: GitHub.
Estado y resultados
Piloto. El tiempo de ejecución bajó de 8,3 minutos a 3,2. Ocho casos de calibración conocidos deben pasar antes de cada envío real. El digest cubre tres mercados: Canadá, Chile y remoto.
Qué sigue
El piloto decide. Donde un puntaje se cuestiona, se ajusta la rúbrica; donde el digest me sorprende, ese caso entra a la suite de calibración.