Cómo crear un portal de empleo sin código, paso a paso

Un portal de empleo sin código se construye describiendo tres cosas: los campos de una oferta, cómo se busca entre ellas y quién puede publicar. Zugo genera la plataforma a partir de ese texto, la arranca en un entorno aislado y la publica. Una plataforma multipágina tarda varios minutos.

Lo difícil de un portal de empleo no es el software. Es que arranca vacío por los dos lados: sin ofertas nadie entra y sin visitas nadie publica. Esta guía está escrita alrededor de ese problema, porque es el que decide si el proyecto vive.

¿Cuál es la versión mínima que vale la pena lanzar?

Un listado con buscador y un formulario de contacto por oferta. Sin cuentas, sin pagos, sin panel de empresa. Las primeras veinte ofertas las publicas tú a mano, copiándolas de donde ya existen o llamando a tres empresas que conozcas.

Esa versión responde la única pregunta que importa al principio: ¿alguien busca trabajo aquí? Si en dos semanas no hay candidaturas, ninguna funcionalidad extra lo va a arreglar, y habrás gastado 18 créditos en vez de doscientos.

El nicho es el otro factor. Un portal generalista compite con plataformas que llevan quince años indexadas, y esa pelea está perdida. Un portal de un sector concreto y una ciudad concreta, en cambio, tiene una ventaja real: las ofertas se pueden verificar una a una y el candidato lo nota.

Cuando el listado ya recibe candidaturas constantes, entonces sí tiene sentido añadir cuentas de empresa, publicación automática y cobro. Antes es construir tuberías para agua que todavía no existe.

¿Qué campos lleva una oferta de empleo?

Ocho, y el que más se omite es el que más filtra. Un portal donde el salario se oculta recibe menos candidaturas útiles, porque quien busca gasta su tiempo en las ofertas que sí lo dicen.

La fecha merece atención aparte. Un portal se muere el día en que la oferta más reciente tiene dos meses. Conviene caducar las ofertas automáticamente a los treinta días y obligar a renovarlas, aunque eso reduzca el número visible.

¿Qué prompt genera el portal entero?

Describe la estructura de datos antes que el aspecto. Un portal es, en el fondo, una tabla con buscador, y si la tabla está mal definida todo lo demás se hereda mal.

Crea un portal de empleo para el sector de hostelería en Valencia.
Páginas:
1. Inicio: buscador por palabra, filtros por modalidad y por
   rango salarial, últimas doce ofertas en tarjetas.
2. Listado: resultados paginados con filtros laterales
   (modalidad, tipo de contrato, salario, fecha).
3. Ficha de oferta: puesto, empresa, ubicación, salario,
   contrato, descripción, requisitos, fecha, formulario
   de candidatura con nombre, correo, CV y mensaje.
4. Publicar oferta: formulario para empresas con los mismos
   campos, revisión manual antes de aparecer.
5. Sobre el portal: qué se publica y qué no.
Guarda ofertas y candidaturas en base de datos.

La frase "revisión manual antes de aparecer" es la más importante del prompt. Un portal que publica sin revisar se llena de spam y de ofertas de comisión pura en la primera semana, y recuperar la confianza cuesta más que ganarla.

¿Cuánto cuesta en créditos y qué plan hace falta?

El precio va por acción. Una plataforma multipágina cuesta 12 créditos e incluye las tres primeras páginas, con 3 créditos por cada página adicional. Cada edición cuesta 3 y una construcción de una sola página cuesta 6.

Un portal de cinco páginas son 18 créditos de partida. Sumando unas veinticinco ediciones para ajustar filtros, textos y el formulario de candidatura, el total ronda los 93. Con Pro, que son 25 dólares al mes por 200 créditos, cabe el portal completo y todavía queda margen para el mes siguiente. El plan gratuito, con 5 créditos, sirve para probar una página suelta, no para esto.

El modo Hi-Fi duplica el precio, con 12 créditos por construcción y 6 por edición. En un portal de empleo aporta poco: aquí gana la densidad de información, no el acabado visual. Guarda ese presupuesto para las ediciones, que es donde se decide si los filtros son útiles.

¿Cómo se cobra a las empresas por publicar?

Con Stripe, y con una decisión previa que no es técnica: qué se cobra. Hay tres modelos habituales y solo uno funciona bien al principio.

Cobrar por oferta publicada es lo más simple y lo más honesto cuando el tráfico todavía es pequeño: la empresa paga por algo que ocurre una vez y ve el resultado. Una suscripción mensual solo se sostiene cuando el portal ya entrega candidaturas de forma constante, porque el segundo mes se renueva o se cancela mirando los números.

El tercer modelo, cobrar por destacar una oferta dentro de un listado gratuito, es el que mejor combina con un portal joven: el catálogo crece solo y los ingresos llegan de quien tiene prisa. La conexión con Stripe cubre pagos únicos y suscripciones, y el detalle de la configuración está en la guía de pagos con Stripe.

Sea cual sea el modelo, la regla es la misma: no cobres hasta que puedas decirle a la empresa cuántas personas vieron la oferta anterior. Google Analytics, conectado desde el primer día, es lo que te permite tener esa conversación con datos en lugar de con adjetivos.

¿Cómo llegan los primeros candidatos?

Por donde ya estás, no por buscadores. Una web nueva tarda meses en aparecer en resultados de búsqueda, y un portal vacío no aparece nunca, porque no hay nada que indexar todavía.

Los tres canales que funcionan al principio son manuales. El primero son los grupos donde la gente del sector ya pregunta por trabajo: publicar allí una oferta concreta con enlace a la ficha trae visitas el mismo día. El segundo son las propias empresas, que comparten el enlace de su oferta con sus contactos. El tercero es el correo: una lista de veinte personas interesadas vale más que mil visitas sueltas.

Para que ese trabajo no se pierda, la ficha de oferta tiene que ser compartible por sí sola. Título claro en la dirección, descripción visible al pegar el enlace en una red social y botón de candidatura por encima del pliegue. Cada una de esas tres cosas se pide como edición, y cada edición cuesta 3 créditos.

¿Dónde se detiene un constructor con IA en este proyecto?

Cuatro límites concretos.

No trae las ofertas. El contenido inicial sigue siendo trabajo manual o acuerdos con empresas. Ninguna herramienta resuelve el arranque en vacío de una plataforma de dos lados.

El emparejamiento automático no sale de un prompt. Puntuar candidaturas contra requisitos, deduplicar perfiles o detectar ofertas fraudulentas es lógica de negocio específica que se afina con ediciones sucesivas.

La gestión de datos personales es tu responsabilidad. Un portal guarda currículums, y eso implica obligaciones legales que el generador no conoce: consentimiento, plazo de conservación y derecho de supresión. Decide esas reglas antes de recibir la primera candidatura.

Un producto complejo necesita equipo. Zugo no sustituye a un equipo de desarrollo cuando el portal crece hacia integraciones con sistemas de selección, importación masiva de ofertas o una API pública. En ese momento, la exportación a GitHub te entrega el código y el proyecto sigue siendo tuyo.

Con esos límites claros, un portal de nicho publicable esta semana es un objetivo razonable. Si tu idea se parece más a un mercado de servicios que a un listado de empleo, empieza por cómo se plantea un marketplace; si lo que necesitas es organizar el proceso de selección por dentro, mira cómo montar un tablero kanban. Cuando tengas las primeras veinte ofertas apuntadas, descríbelo en zugo.dev.