Buscar empleo se ha convertido en un trabajo paralelo: abrir varios portales todos los días, reescribir el currículum para cada vacante y, al final, no saber qué está funcionando. TrackVagas es un SaaS que le quita ese trabajo de encima a quien busca empleo.

Fueron 16 días desde el primer commit hasta el lanzamiento. Pero "construir un SaaS" no es solo programar. En este post cuento lo que entrega el producto y, a continuación, todos los frentes que existieron detrás: diseño del producto, diseño visual y animaciones, ingeniería, seguridad, pruebas automatizadas y manuales, cobros y lanzamiento. Usé la IA como herramienta de trabajo en varios de esos frentes, y cuento dónde ayudó y dónde las decisiones siguieron siendo mías.

El problema que resuelve el producto

Quien se postula a vacantes suele enfrentar el mismo trío de problemas:

  1. Buscar en varios portales es un trabajo manual y repetitivo. Son horas por semana abriendo las mismas búsquedas.

  2. El currículum se reescribe para cada vacante, pero nadie registra qué versión fue adónde. Cuando llega la respuesta (o no llega), no hay cómo vincular el resultado con el currículum enviado.

  3. Las respuestas se pierden. Llegan por correo, WhatsApp y portales, y sin registro no se puede saber si el problema está en el portal, en el currículum o en el tipo de vacante.

El resultado es postularse a ciegas. TrackVagas parte de una pregunta simple: ¿qué genera respuestas de verdad?

Lo que entrega el producto

  • Búsquedas diarias en los principales portales, con filtros (modalidad, seniority, ubicación, etc.). Las vacantes llegan ordenadas según qué tan bien encajan con el currículum.

  • Currículum maestro en portugués, inglés y español, y versiones por tipo de vacante. Una versión aprobada nunca cambia, y la base de datos lo garantiza.

  • Adaptación con IA que reescribe el currículum para la vacante sin inventar experiencia.

  • Respuestas por correo registradas automáticamente: una regla de reenvío en Outlook o Gmail, y la app reconoce entrevista, rechazo y confirmación.

  • Métricas: embudo, tasa de respuesta y de entrevista por portal, por versión de currículum, por tecnología, modalidad y seniority.

  • Tus datos son tuyos: exporta todo (ZIP con JSON, CSV y PDF) y elimina la cuenta desde la app.

Detrás del producto

Un producto de verdad no nace de "escribir código": nace de entender el problema, diseñar la solución, construir con seguridad y probar antes de entregar. Estos son los frentes que existieron detrás de TrackVagas.

1. Diseño del producto: antes de cualquier código

La primera semana no fue de código. Fue de decidir qué construir y qué dejar fuera:

  • Análisis del negocio y del problema en 15 puntos (quién siente el dolor, cuáles son los riesgos, si vale la pena construirlo), con una decisión explícita: empezar como herramienta propia y convertirla en producto solo si tenía sentido. Lo tuvo, y el proyecto se construyó desde el inicio "como si pudiera convertirse en producto": página de presentación pública y datos de cada usuario aislados.

  • Documento de requisitos (PRD) con problema, objetivos medibles, alcance de la primera versión (MVP) y etapas. Cada cambio de alcance quedó en un historial.

  • Etapas pequeñas: currículum maestro, vacantes, importación, postulaciones, respuestas, métricas, currículums por tipo de vacante, IA. Cada una terminaba en producción antes de la siguiente.

  • 91 decisiones registradas en un formato corto (problema, elección, por qué). Se convirtieron en la memoria del proyecto: cuando volvía a un tema, la conversación partía del registro, no de cero.

  • Nombre, logo y dominio elegidos por mí. El producto nació con otro nombre de trabajo; el nombre TrackVagas, la lupa azul con el maletín amarillo y el dominio trackvagas.com.br fueron decisiones mías. La marca es parte del producto, no un adorno.

  • La vacante como centro del modelo. Una decisión de producto que cambió el lenguaje de la página de presentación y abrió camino a un futuro entorno para reclutadores: la postulación es solo el vínculo entre la persona y la vacante.

Una regla guió todo: ningún servicio nuevo entra al proyecto sin una decisión consciente y sin registrar el motivo y el costo.

2. Diseño y animaciones: la IA ayuda, el ojo decide

La identidad visual se decidió temprano (tinta azul marino con amarillo de resaltador y, después, el nombre, el logo de la lupa con el maletín, el favicon y el dominio) y se protege: no se rehace en cada pantalla.

  • Página de presentación con demostraciones animadas: una hoja de cálculo viva arriba y una sección "Registra, adapta, mide" con una app de demostración que muestra búsquedas llegando, vacantes guardándose y respuestas entrando. Es código, no video, y el aviso "datos ficticios" deja claro que son ejemplos.

  • Instrucciones especializadas (skills) que guiaron a la IA en cada tarea de interfaz: una para dirección de diseño y auditoría, otra contra interfaces genéricas, una de acabado y detalle, una de movimiento y otra de revisión de animaciones, una para que la app se sienta nativa en el celular (PWA) y una que intenta romper la pantalla con datos extremos (nombres enormes, listas vacías, textos largos).

  • Ajuste manual, todo el tiempo. La IA genera buenos primeros borradores; el acabado es decisión mía: espaciados, la jerarquía de cada pantalla, el tamaño del toque en el celular, qué se anima y qué queda quieto, el texto de cada botón. Buena parte de las revisiones fue mirar la app en el navegador y en el celular y pedir (o hacer) el ajuste.

  • Accesibilidad y tema oscuro tratados como parte del trabajo, no como un extra.

Lección de diseño: la IA acelera el borrador, pero "bonito" y "claro" siguen siendo juicios humanos.

3. Ingeniería

  • Nuxt 4 y TypeScript para pantallas y rutas de servidor en un solo framework.

  • Nuxt UI (Tailwind 4) para componentes accesibles y temas por tokens.

  • Supabase (Postgres, Auth, Storage): SQL de verdad para las métricas y RLS para aislar los datos.

  • Cloudflare Workers para el alojamiento: barato, rápido, con despliegue en cada merge.

  • Apify para las búsquedas, porque los portales no tienen una API abierta.

  • Resend para recibir el correo reenviado y avisar a la app por webhook.

  • Gemini para la IA, detrás de una capa que permite cambiar de proveedor.

  • Asaas para los cobros: tarjeta recurrente en reales, con webhook.

  • Zod para validar: el mismo esquema sirve para el formulario, la API y la respuesta de la IA.

Algunos problemas difíciles vale la pena contarlos:

  • Los datos de cada persona aislados en la base de datos. Cada tabla tiene user_id y una política de RLS. No confío solo en el código de la aplicación.

  • El servidor es dueño del estado sensible. El plan, los límites y el uso de IA no pueden ser escritos por el navegador.

  • IA que no inventa. El prompt solo permite reordenar y reformular lo que existe en el currículum maestro; la salida se valida; la pantalla muestra "qué cambió respecto al maestro", con vuelta al original. También probé una vacante que intenta enviar instrucciones al modelo.

  • Respuestas por correo sin leer la bandeja de nadie. Cada usuario tiene una dirección propia y crea una regla de reenvío; nunca pido acceso a la bandeja.

  • Límites de la plataforma. El límite de CPU del Worker me llevó a mover trabajo pesado al navegador y a mantener pantallas estáticas.

4. Seguridad

  • Aislamiento por cuenta probado en la base de datos, no solo en el código.

  • Entorno de administración separado: subdominio propio, segundo factor obligatorio y registro de auditoría de cada acción administrativa.

  • Claves de producción solo como secrets en el alojamiento, nunca en el código ni en prompts de IA. Cuando una clave quedó visible, la cambié.

  • Auditoría completa de seguridad antes de abrir, realizada con una skill dedicada. Los hallazgos se corrigieron en pull requests separados, antes del lanzamiento.

  • Protección de datos en el producto: exportar todos los datos y eliminar la cuenta desde la app, política de privacidad y términos de uso.

5. Pruebas: automatizadas y manuales

Automatizadas

  • Más de 350 pruebas de reglas de negocio (métricas, estados de las postulaciones, planes, cobros, validación de la IA).

  • 289 verificaciones en la base de datos (pgTAP): qué puede leer y escribir cada usuario, triggers y reglas del plan.

  • Lint, verificación de tipos y pruebas ejecutándose en cada pull request.

Manuales, y fueron muchas

  • Cada pantalla revisada en el navegador y en el celular, en tema claro y oscuro, con datos normales y extremos.

  • Flujos de punta a punta con cuentas de prueba: registro, restablecimiento de contraseña, búsqueda, guardar, postularse, registrar una respuesta.

  • Cobros en el entorno de simulación y luego en producción con tarjeta real, incluyendo cancelación y reembolso. Ahí apareció el error que la simulación escondía: el reembolso devolvía el dinero y quitaba el acceso de pago de la cuenta, pero la suscripción seguía activa en Asaas y volvería a cobrar al mes siguiente. Lo corregí (el aviso de reembolso ahora cancela la suscripción) y lo cubrí con una prueba. Prueba con dinero de verdad, de punta a punta, con el reembolso incluido.

  • Rondas de ajustes después de cada prueba: fueron varios pull requests solo de "lo usé y me di cuenta de que…".

6. Cobros y operación

Suscripción recurrente con tarjeta, webhook con token comparado en tiempo constante, tarea diaria que cierra las suscripciones vencidas, acceso especial que solo concede el administrador, y un panel de administración con métricas, costos y visitantes. Dominio propio, correos transaccionales y cuenta de empresa configurados.

Lo que entrega este proceso

Mirando hacia atrás, estas son las marcas de un producto construido con cuidado:

  • Un comienzo que no es código: entender el negocio, el problema y lo que no vale la pena construir todavía.

  • Entregas en etapas pequeñas, cada una en producción, para ver y opinar mientras el sistema crece.

  • Diseño y acabado cuidados, con identidad propia, y no solo pantallas funcionales.

  • Seguridad y pruebas desde el inicio, y no como un parche al final.

  • IA como herramienta, con responsabilidad humana sobre lo que sale al aire.

  • Atención a lo entregado: correcciones, ajustes y evolución después del lanzamiento.

Números del proyecto

  • 16 días entre el primer commit (5 de octubre de 2026) y el lanzamiento.

  • Cerca de 170 commits y decenas de pull requests pequeños.

  • 37 migraciones de base de datos y 91 decisiones registradas.

  • 350+ pruebas de reglas y 289 verificaciones en la base de datos.

Lo que haría diferente

  • Probaría el cobro real antes. El error del reembolso solo apareció ahí.

  • Pondría a personas externas a usarlo antes. Detalles pequeños (un clic en el logo que no volvía arriba, contadores que faltaban en las pestañas) solo aparecieron con el uso real.

  • Guardaría menos configuración suelta en variables del panel. Hoy todo va directo como secret.

Lo que viene

El lanzamiento es solo el comienzo. El producto está naciendo, y la próxima fase es hacerlo crecer, con foco en marketing y distribución, además de nuevas funciones (como un entorno para reclutadores, más idiomas y más portales). Y, claro, escuchar a quien lo usa. TrackVagas ya está en línea en trackvagas.com.br.

Si estás buscando empleo, solo pruébalo. Y si tienes una empresa, un proceso manual o una idea de producto que podría convertirse en software, y quieres entender qué haría falta para ponerla en marcha, escríbeme! 😉✌🏽