Plataforma de selección de personal para hostelería: cómo construimos Talia Gastro

Este artículo cuenta un caso real nuestro, en producción y un éxito rotundo: Talia Gastro (taliagastro.com), la web y la plataforma de selección de personal y consultoría de apertura de Talia Bergman, operadora hostelera de Madrid. Salió a producción en mayo de 2026 con dos mitades pensadas desde el día cero: una web que la encuentren en Google y en los asistentes de IA, y una plataforma de tres roles con un motor de matching explicable. Lo que sigue es la arquitectura, las decisiones de diseño, los números reales y lo que aprendimos.

En este artículo:

• El problema: seleccionar personal a mano no escala
• Qué construimos: dos mitades y tres roles
• El motor de matching explicable
• Una web pensada para que la encuentren
• Cómo se opera después del lanzamiento
• Los números del caso
• Lo que aprendimos
• Cómo encarar un proyecto así en tu negocio
• Preguntas frecuentes

El problema: seleccionar personal a mano no escala

Una consultora de selección de personal para restaurantes vive de un proceso que casi nunca está sistematizado. Los candidatos llegan por WhatsApp o por recomendación, los restaurantes piden gente por llamada, la consultora cruza las dos listas de memoria, coordina entrevistas a mano y cobra recién cuando hay un contrato firmado. Cada paso depende de una persona, y esa persona es el cuello de botella.

Talia Bergman tiene más de diez años en proyectos exigentes de Madrid y dos líneas de negocio: selección de personal para restaurantes y hoteles, y consultoría de apertura, en buena parte para quien viene de afuera a abrir en Madrid. Su pedido no fue "una web". Fue una plataforma que digitalizara el matching entre trabajadores del sector y restaurantes que buscan personal, y una presencia digital que la posicionara con su propia voz, no con una plantilla de consultora.

Tres restricciones marcaron el diseño:

• La operadora tiene que seguir en el medio, pero sin estar en cada paso. Cobra solo con contrato firmado, así que la plataforma tenía que darle control sobre a quién propone, sin obligarla a coordinar cada entrevista a mano.
• Datos personales de candidatos. CV, teléfono, fecha de nacimiento: el acceso tenía que estar separado por rol desde la base de datos, no desde la interfaz.
• Cumplimiento español desde el día uno. RGPD y LSSI, con aviso legal, política de privacidad y retención de datos definida.

Qué construimos: dos mitades y tres roles

La plataforma corre sobre Next.js y Supabase (Postgres, Auth y Storage), desplegada en Vercel. Elegimos ese stack porque permite servir la web pública como páginas estáticas rápidas y, en el mismo proyecto, correr una aplicación con autenticación, base de datos y archivos, sin un backend aparte que mantener.

Cuatro decisiones de arquitectura que valen para cualquier plataforma de este tipo:

• 1. Seguridad por filas en la base de datos. Cada usuario solo puede leer y escribir sus propias filas, y eso lo garantiza Postgres con políticas de acceso, no el código de la interfaz. Un bug en una pantalla no expone el CV de otro candidato.
• 2. El formulario de candidatos es público y anónimo. Un trabajador de hostelería no se crea una cuenta para aplicar: carga sus datos y su CV, y la operadora decide desde su panel si lo promueve al pool. Baja la fricción del lado que más volumen tiene.
• 3. Login del administrador por magic link al mail del negocio, sin contraseña que perder.
• 4. Notificaciones transaccionales desde el dominio propio: cada registro de candidato y cada solicitud nueva de un restaurante le llegan a la operadora por mail en el momento.

El motor de matching explicable

El corazón de la plataforma es el matching: al abrir una solicitud de un restaurante, el panel muestra los datos del puesto a la izquierda y los candidatos ordenados por porcentaje de compatibilidad a la derecha, con un semáforo (verde de 80 a 100%, amarillo de 60 a 79%, naranja por debajo). La primera versión usó cinco criterios ponderados, definidos con la operadora antes de escribir código:

Dos decisiones que importan más que los pesos:

• Reglas, no un modelo opaco. Cada porcentaje se explica: la segunda versión del motor muestra las razones al lado del número, y la operadora ajusta los pesos desde su panel de configuración, con historial de cambios. Cuando una persona va a proponer a un candidato para un puesto real, tiene que poder defender por qué ese y no otro.
• El matching ordena, no decide. La propuesta al restaurante la hace la operadora, con un click. El sistema le ahorra el cruce, no el criterio.

Una web pensada para que la encuentren

La otra mitad del proyecto fue la web pública, y la regla fue hacer el SEO antes de diseñar, no después. Antes de escribir una línea de copy:

• Keyword research del sector hostelería en España: 16 búsquedas priorizadas, clasificadas por intención (restaurantes que buscan personal vs. trabajadores que buscan empleo) y asignadas a cada página.
• Análisis de 6 SERPs del nicho, para saber contra quién compite cada página y con qué formato.
• 6 piezas de contenido SEO/GEO: 3 páginas de servicio y 3 artículos con estructura de pregunta y respuesta directa y FAQ extractable, escritas con el ángulo editorial de la operadora.

Del lado técnico, la web salió con 8 tipos de datos estructurados (organización, persona, servicios, artículos, FAQ, breadcrumbs, sitio web y negocio local), llms.txt, robots.txt abierto a los crawlers de IA, sitemap dinámico, Open Graph y headers de seguridad. La auditoría técnica de salida dio 80 sobre 100, con los puntos flojos identificados y corregidos antes del lanzamiento. Cómo hacemos esto para cualquier web está en nuestro servicio de desarrollo con Claude Code.

Cómo se opera después del lanzamiento

Una plataforma que se entrega y se abandona se degrada en semanas. Desde agosto de 2026 Talia Gastro evoluciona con un abono mensual, y esa operación tiene tres piezas que ya están en producción:

• Integración continua con 80 archivos de tests automáticos (unitarios y de extremo a extremo con Playwright), que corren en cada cambio antes de llegar a producción. La primera corrida completa del CI destapó cuatro defectos que ningún usuario había reportado.
• Tareas programadas de retención de datos: los perfiles inactivos se notifican y se eliminan según la política de privacidad, sin intervención manual.
• Ajustes del motor de matching con lo que la operadora ve en su panel, no con supuestos.

La regla del abono es evolución sobre evidencia: primero se mide qué imprime y qué convierte, después se construye.

Los números del caso

Las impresiones son de Google Search Console, vistas con la cliente el 15 de septiembre de 2026, con la temporada de hostelería recién arrancada y sin pauta. Los demás números salen del repositorio y de los documentos del proyecto.

Lo que aprendimos

• 1. El SEO desde el diseño paga en la primera temporada. Sin pauta y con cuatro meses de vida, la web ya se muestra 2.500 veces por mes en Google, casi todo en España. Una web que se diseña primero y se optimiza después tarda mucho más en llegar ahí.
• 2. Un motor de matching por reglas explicables vale más que uno "inteligente". La operadora lo entiende, lo ajusta y lo defiende frente al restaurante. Un modelo opaco habría sido más impresionante en la demo y menos útil el día que hay que proponer a alguien.
• 3. Lo que sigue es conversión. Que Google muestre la web es la mitad del trabajo; la otra mitad es que el restaurante que la ve pida personal. Ese es el trabajo del abono ahora: títulos, descripciones y llamados a la acción medidos contra Search Console, más contenido que haga la cuenta de lo que cuesta contratar mal.

Cómo encarar un proyecto así en tu negocio

Si tenés un proceso de selección, de pedidos o de matching que hoy vive en WhatsApp y planillas, el orden que funciona es:

• 1. Escribí el proceso como es hoy, con quién hace cada paso y dónde se traba. El documento de requisitos de Talia Gastro nació de eso.
• 2. Definí los roles y qué ve cada uno. Los permisos se diseñan antes que las pantallas.
• 3. Decidí las reglas del matching con quien selecciona, con pesos explícitos. Se pueden cambiar después; lo que no se puede es arrancar sin ellas.
• 4. Hacé el keyword research antes del diseño, para que cada página nazca apuntada a una búsqueda real.
• 5. Lanzá con tests y con un plan de evolución mensual. La plataforma que no se opera se degrada.

Preguntas frecuentes