Aprende a planear, diseñar y construir una app web para equipos de RRHH que gestione etapas de contratación, entrevistas, feedback, permisos, integraciones e informes.
Antes de dibujar pantallas o elegir una pila tecnológica, sé específico sobre para quién estás construyendo y qué dolor estás resolviendo. Los equipos de RRHH, los reclutadores, los hiring managers y los entrevistadores viven el mismo proceso de contratación de maneras muy diferentes — y una app "one size fits all" suele terminar sin contentar a nadie.
Escribe una breve declaración del problema que describa la fricción actual:
Apunta a algo concreto como: “Los hiring managers no pueden ver dónde están los candidatos y las entrevistas tardan demasiado en coordinarse.”
“Pipeline” puede ser una lista simple de etapas (Aplicado → Criba → Presencial → Oferta) o un flujo más detallado que cambia según rol o ubicación. De igual forma, “gestión de entrevistas” puede incluir solo programación, o también preparación (quién entrevista, qué cubrir), recolección de feedback y decisiones finales.
Captura definiciones con algunos ejemplos reales:
Compara construir contra un applicant tracking system que puedas configurar. Construir suele justificarse cuando necesitas un flujo único, integraciones más profundas o una experiencia más simple para un tamaño de empresa específico.
Si decides construir, escribe qué hace tu app significativamente diferente (por ejemplo: “menos idas y vueltas en la programación” o “visibilidad orientada al manager”).
Elige 3–5 métricas ligadas al trabajo diario, como:
Estas metas guiarán decisiones posteriores como permisos, programación y analítica (ver /blog/create-reporting-and-analytics-hr-will-trust).
Antes de diseñar pantallas o elegir funciones, aclara cómo avanza realmente la contratación en tu organización. Un flujo bien mapeado evita “pasos misteriosos”, nombres de etapa inconsistentes y candidatos estancados.
La mayoría de equipos siguen una ruta como: sourcing → screening → entrevistas → oferta. Escríbelo y define qué significa “hecho” para cada paso (por ejemplo, “Criba completa” puede significar que se registró una screening telefónica y se anotó una decisión de pasar/fallar).
Mantén los nombres de las etapas orientados a la acción y específicos. “Entrevista” es vago; “Entrevista con Hiring Manager” y “Entrevista en Panel” son más claros y fáciles de reportar.
Diferentes departamentos necesitarán pasos distintos. Ventas puede incluir un role-play; ingeniería un ejercicio para llevar a casa; cargos ejecutivos aprobaciones adicionales.
En lugar de un pipeline gigante, mapea:
Esto mantiene la consistencia en los informes y se ajusta a los flujos reales.
Para cada etapa, documenta:
Fíjate dónde se atascan los candidatos —comúnmente entre “criba → programación” y “entrevistas → decisión.” Esos son lugares prime para automatizar luego.
Lista los momentos en que la app debe empujar a alguien:
Vincula los recordatorios al ownership de la etapa para que nada dependa de la memoria o de buscar en bandejas de entrada.
Una aplicación de RRHH puede convertirse rápidamente en un ATS completo. La forma más rápida de lanzar algo útil es acordar un MVP acotado y luego planear próximas entregas para que los stakeholders sepan qué viene (y qué no está intencionalmente en v1).
Tu MVP debería permitir a un equipo mover un candidato real de “aplicado” a “contratado” sin hojas de cálculo. Un baseline práctico es:
Si una feature no ayuda a mover candidatos por etapas o reducir la coordinación, probablemente no es MVP.
Crea una matriz simple con “throughput de candidatos/tiempo ahorrado” en un eje y “complejidad de construcción” en el otro. Considera must-have para v1: estatus de pipeline fiable, programación que realmente funcione y feedback fácil de enviar.
Deja los items nice-to-have (reglas de automatización, analítica avanzada, resúmenes por IA) para fases posteriores —especialmente todo lo que añada riesgos de cumplimiento o datos.
Los equipos de RRHH rara vez trabajan igual. Define qué pueden configurar los admins desde el día uno:
Mantén la configuración acotada para que la UI siga simple y soportable.
Escribe un pequeño conjunto de historias de usuario para:
Estas historias serán tu checklist de aceptación para v1 y una hoja de ruta clara para v2/v3.
Una app de contratación vive o muere por su modelo de datos. Si las relaciones son claras, podrás añadir features (nuevas etapas, programación, reporting) sin reescribir todo.
Planifica un conjunto pequeño de tablas/colecciones “fuente de la verdad”:
En la práctica, Application se convierte en el ancla para la mayor parte de los datos de flujo: cambios de etapa, entrevistas, decisiones y ofertas.
Los candidatos suelen postular a múltiples puestos y los puestos tienen muchos candidatos. Usa:
Esto evita duplicar datos de candidato y permite rastrear el estado, expectativas de compensación e historial de decisiones por cada application.
Para CVs y adjuntos, almacena metadatos en la BD (nombre de archivo, tipo, tamaño, subido_por, timestamps) y guarda los binarios en object storage.
Las notas y mensajes deben ser registros de primera clase:
Esta estructura facilita la búsqueda y el reporting más adelante.
Añade una tabla AuditEvent desde temprano para registrar cambios en etapas, ofertas y evaluaciones:
Esto soporta responsabilidad, debug y confianza de RRHH cuando alguien pregunta: “¿Por qué se movió este candidato a Rechazado?”
Los permisos son donde las apps de RRHH ganan o pierden confianza. Un modelo de acceso claro evita el oversharing accidental (por ejemplo: detalles de compensación) y hace la colaboración más fluida.
Empieza con un conjunto pequeño de roles que reflejen cómo se toman decisiones de contratación:
Mantén roles consistentes y permite excepciones finas con “overrides” en lugar de crear docenas de roles personalizados.
No todos los datos del candidato deben ser visibles para todos. Define reglas de permiso por categoría/campo, no solo por página:
Un patrón práctico: la mayoría de usuarios pueden ver el perfil del candidato, pero solo roles específicos pueden ver o editar campos sensibles.
La contratación suele estar segmentada. Añade “scopes” para limitar acceso por:
Esto evita que un reclutador en una región acceda a candidatos de otra.
Los stakeholders querrán revisar perfiles rápido. Proporciona compartición controlada:
Esto mantiene los perfiles dentro de la app en lugar de copiarse en hilos de email.
Una app de contratación vive o muere según si los reclutadores ocupados pueden entender el estatus de un vistazo y tomar la próxima acción sin pensar. Apunta a un conjunto pequeño de pantallas consistentes con controles previsibles y señales claras de “qué sigue”.
Tablero de pipeline (estilo Kanban): muestra las etapas de cada job como columnas con tarjetas de candidato. Las tarjetas deben mostrar solo lo necesario para decidir el siguiente paso: nombre, etapa actual, fecha de última actividad, propietario y una o dos etiquetas clave (p. ej.: “Necesita agendar”, “Fuerte referencia”). Mantén el tablero enfocado—los detalles pertenecen a la vista de candidato.
Perfil de candidato: una página que responda: quién es esta persona, dónde está en el proceso y qué necesitamos hacer ahora. Usa un layout limpio: encabezado resumen, línea temporal de etapas, feed de notas/actividades, archivos (CV) y un bloque de “Entrevistas”.
Página de job: detalles del puesto, equipo de contratación, definiciones de etapas y un resumen de conteos del funnel. Aquí también los admins ajustan nombres de etapas y feedback requerido.
Calendario de entrevistas: vista de calendario para entrevistadores y reclutadores, con acceso rápido a disponibilidad, tipo de entrevista y detalles de video/ubicación.
Cada pantalla debe resaltar las 3–5 acciones principales: mover etapa, agendar entrevista, solicitar feedback, enviar mensaje, asignar propietario. Usa un único botón primario por vista y colocación consistente (por ejemplo: arriba a la derecha). Confirma acciones destructivas como rechazar/retirar.
Rechazar, etiquetar o asignar propietario en masa es esencial para roles de alto volumen. Reduce errores con contadores de selección, toasts de “Deshacer” y salvaguardas como confirmaciones para “Rechazar 23 candidatos” más plantillas de razón opcionales.
Soporta navegación por teclado en el tablero, estados de foco visibles, contraste suficiente y etiquetas de formulario legibles. Mantén los mensajes de error específicos (“Se requiere hora de entrevista”) y no dependas solo del color para mostrar estatus.
La programación suele frenar los pipelines: demasiados intercambios de email, zonas horarias perdidas y ownership poco claro. Tu app debe hacer que agendar se sienta como un flujo guiado con pasos claros, permitiendo al reclutador sobrepasar el flujo cuando la realidad lo requiera.
Empieza con unas plantillas de entrevista que cubran la mayoría de equipos y deja que los admins personalicen luego:
Cada tipo debe definir duración por defecto, roles de entrevistador requeridos, ubicación (video/presencial) y si se requieren materiales para el candidato.
Un flujo práctico suele necesitar:
Diseña para casos límite: cambios de entrevistador last-minute, paneles divididos o slots en “hold” que expiran si no se confirman.
Si integras calendarios, céntrate en dos esenciales: chequear conflictos y crear eventos.
Incluye siempre un modo manual: recruiters pueden pegar un enlace externo de reunión, marcar un evento como “agendado” y rastrear asistencia sin integración.
Reduce la inconsistencia generando un pack de briefing por evento. Incluye:
Enlaza el pack desde el perfil del candidato y la página del evento para que esté accesible con un clic.
El feedback es donde una app de pipeline gana confianza — o crea fricción. Los equipos de RRHH necesitan evaluaciones estructuradas que sean fáciles de completar, consistentes entre entrevistadores y auditables luego.
Crea scorecards por rol y tipo de entrevista (criba, técnica, hiring manager, cultural). Mantén cada scorecard corto, con criterios claros, definiciones y una escala de valoración (p. ej. 1–4 con anclas como “sin evidencia / algo / sólido / excepcional”). Incluye un campo de “evidencia” para que los entrevistadores describan lo observado en vez de escribir opiniones vagas.
Para un ATS, los scorecards deben poder buscarse y reportarse para alimentar un dashboard de RRHH sin limpieza manual.
Los entrevistadores a menudo necesitan un bloc de notas. Soporta:
Esto reduce el oversharing accidental y soporta control de acceso por rol: reclutadores pueden ver todo, mientras que un entrevistador cross-funcional puede ver solo lo relevante.
Los scorecards tardíos retrasan decisiones y programación. Añade nudges automáticos: un recordatorio tras la entrevista, otro antes de la reunión de decisión y luego una escalada al hiring manager si sigue faltando feedback. Haz los plazos configurables por etapa en el flujo de reclutamiento.
Crea una vista de decisión que resuma señales: promedios por criterio, fortalezas/riesgos y alertas de “feedback faltante”. Para reducir el sesgo de anclaje, considera ocultar las calificaciones de otros hasta que el entrevistador envíe la suya y muestra fragmentos de evidencia junto a las puntuaciones.
Cuando se diseña bien, este módulo se convierte en la “fuente única de verdad” para decisiones de contratación y reduce idas y vueltas por chat y email.
Una app puede tener un pipeline perfecto y aun así sentirse lenta si los reclutadores no pueden comunicarse rápido, encontrar candidatos y mantener un registro limpio. Estas herramientas “pequeñas” son las que realmente logran adopción.
Empieza con unas plantillas reutilizables para los momentos repetidos: confirmación de aplicación, invitación a entrevista, seguimiento, solicitud de disponibilidad y rechazo. Mantén las plantillas editables por rol/equipo y permite personalización rápida (nombre, puesto, ubicación).
Igual de importante: registra cada mensaje. Guarda una línea de tiempo clara de enviado/recibido en el perfil del candidato para que cualquiera pueda responder “¿Lo contactamos ya?” sin buscar en bandejas. Incluye adjuntos y metadata como remitente, hora y job relacionado.
Haz las actualizaciones de estatus fáciles pero estandarizadas. Ofrece una lista controlada de razones de rechazo (p. ej.: “desalineación salarial”, “brecha de competencias”, “no disponible”, “se retiró”) con notas opcionales.
Esto ayuda al reporting y reduce diferencias de redacción entre el equipo. Además, separa campos solo internos de los que se comparten externamente: las razones de rechazo pueden ser solo para análisis.
Añade etiquetas flexibles para habilidades, seniority, idiomas, clearance o canal de sourcing. Combínalas con búsqueda rápida y filtros que los reclutadores usan naturalmente:
Apunta a “encontrar en 10 segundos” tanto en un job individual como en todos los roles.
Los equipos de RRHH aún viven en hojas de cálculo. Provee importación CSV para poblar candidatos y exportación CSV para auditorías, compartir shortlists o revisiones offline. Incluye mapeo de campos, validación (duplicados, emails faltantes) y una exportación que respete permisos.
Más adelante, estas mismas herramientas serán la base de acciones masivas (email masivo, mover etapa en bloque) y operaciones diarias más fluidas.
Las apps de contratación manejan datos muy sensibles: identidad, CVs, notas de entrevistas y a veces información de igualdad o salud. Trata privacidad y seguridad como requisitos de producto, no como un checkbox en el lanzamiento.
Empieza documentando qué regulaciones aplican y qué debes poder demostrar. Para muchos equipos eso incluye GDPR / UK GDPR y reglas laborales locales.
Sé explícito sobre:
Minimiza los campos que recoges por defecto. Si una información no es necesaria para evaluar a un candidato, no la preguntes.
Cuando necesites datos sensibles (p. ej.: monitorización de diversidad, adaptaciones), guárdalos separados del registro principal y restringe el acceso fuertemente. Esto reduce exposiciones accidentales y soporta acceso “need-to-know”.
Como mínimo, encripta datos en tránsito (TLS) y en reposo. Pon atención especial a adjuntos (CVs, portafolios, documentos de identidad): almacena archivos en un bucket privado con URLs firmadas de vida corta y sin acceso público.
Controla descargas y compartición:
Construye un access log que registre quién vio o exportó perfiles y archivos, con timestamps. Los equipos de RRHH suelen necesitar esto para investigaciones y auditorías.
También planea workflows operativos para derechos de sujetos de datos:
Un buen diseño de cumplimiento hace la app más confiable y mucho más fácil de defender en auditorías.
El reporting es donde una app de RRHH gana confianza o genera mensajes interminables de “¿puedes verificar esto?”. Apunta a analíticas fáciles de verificar, consistentes en el tiempo y claras sobre lo que cada número significa.
Construye alrededor de la salud y velocidad del pipeline:
Muestra esto por job, porque cada rol tiene realidades distintas. Un puesto de soporte de alto volumen y un rol senior de ingeniería no deben forzarse al mismo benchmark.
Proporciona dos niveles de vista:
Mantén filtros simples y predecibles (rango de fechas, job, departamento, ubicación, fuente). Si un filtro cambia un número, hazlo obvio.
La mayoría de disputas de reporting vienen de definiciones poco claras. Añade tooltips o un pequeño drawer de “Definiciones” que diga:
Cuando sea posible, permite que RRHH haga clic desde una métrica hasta la lista subyacente de candidatos (“Muéstrame los 12 candidatos en Presencial > 14 días”).
Habilita exportaciones que coincidan con workflows reales: CSV para hojas, PDFs para snapshots y reportes programados por email. Incluye filtros y definiciones en el encabezado de la exportación para que los números no pierdan contexto al re-enviarlos.
Si quieres una vista norte estelar, añade una página /reports con plantillas guardadas (p. ej.: “Revisión trimestral de contratación” y “Funnel de diversidad (si está activado)”) que RRHH pueda reutilizar sin reconstruir gráficos.
Decisiones de integraciones y rollout pueden determinar la adopción. Trátalas como features de producto: alcance claro, comportamiento fiable y ownership para soporte continuo.
Empieza con los sistemas donde los reclutadores ya viven:
Define qué es “fuente de la verdad” para cada tipo de dato (perfil de candidato, eventos de entrevista, documentos de oferta) para evitar conflictos.
Aunque integres después, diseña ahora:
Enfócate en fallos que frustran a los equipos de RRHH:
Si tu objetivo es validar el flujo rápidamente (tablero, programación, scorecards y permisos) antes de invertir en un gran esfuerzo de ingeniería, una plataforma vibe-coding como Koder.ai puede ayudarte a llegar antes a una app interna funcional. Describes el flujo de reclutamiento en chat, iteras las pantallas y generas una app web basada en React con backend Go + PostgreSQL—luego exportas el código fuente cuando estés listo para internalizarla. Funciones como modo planning, snapshots y rollback son útiles cuando pruebas hipótesis de MVP con stakeholders de RRHH y necesitas moverte rápido sin perder estabilidad.
Comienza nombrando 2–4 grupos de usuarios principales (administradores de RRHH, reclutadores, managers de contratación, entrevistadores) y redacta un dolor concreto por grupo.
Luego elabora una frase problema de una oración que puedas validar con las partes interesadas, por ejemplo: “Los hiring managers no pueden ver el estado de los candidatos y las entrevistas tardan demasiado en coordinarse.”
Anota:
Esto evita “pasos misteriosos”, nombres de etapa inconsistentes y candidatos estancados.
Crea:
Mantén los nombres de las etapas orientados a la acción (p. ej.: “Entrevista con Hiring Manager” en lugar de “Entrevista”) para que la analítica siga siendo consistente.
Elige 3–5 métricas vinculadas al trabajo diario, no a métricas de vanidad:
Usa estas métricas para guiar decisiones sobre permisos, programación y analítica.
Un MVP práctico debe soportar un ciclo de contratación sin hojas de cálculo:
Deja automatizaciones avanzadas y features de IA para después de que el loop core sea fiable.
Modela Candidate y Job como entidades separadas y usa Application como el ancla del flujo de trabajo.
Esto gestiona la realidad muchos-a-muchos (un candidato puede postular a varios puestos) mientras mantiene el historial de etapas, entrevistas y decisiones específicas por solicitud.
Comienza con un conjunto pequeño y consistente de roles:
Añade protecciones a nivel de campo para datos sensibles (compensación, notas privadas, datos EEO/diversidad) y soporta ámbitos de acceso por departamento/puesto/ubicación para evitar sobreexposición.
Usa un flujo guiado:
Integra Google/Microsoft Calendars para chequear conflictos y crear eventos, pero mantén un modo manual para equipos sin integraciones.
Usa tarjetas de evaluación cortas, específicas por rol y tipo de entrevista, con criterios claros y una escala de valoración simple.
Separa:
Añade recordatorios y escalados cuando el feedback venza, y considera ocultar las calificaciones de otros hasta que el entrevistador envíe la suya para reducir el sesgo de anclaje.
Haz cada métrica clicable hasta la lista de candidatos subyacente y publica definiciones para los cálculos clave (reglas de entrada a etapa, manejo de withdraws/rechazos, pausas por “on hold”).
Soporta exportaciones prácticas (CSV/PDF) y plantillas de informes guardadas para que stakeholders reutilicen vistas consistentes. Para más detalle sobre analítica, ve a /blog/create-reporting-and-analytics-hr-will-trust.
