InfoJobs

InfoJobs és un portal de feina en línia: una plataforma on les empreses publiquen ofertes i els candidats hi pengen el currículum i s'hi inscriuen. Segons la Viquipèdia, opera principalment a l'Estat espanyol i és un dels portals de feina de referència del mercat espanyol.

Segons la Viquipèdia, InfoJobs es va fundar el 1998. La mateixa font situa l'origen de l'empresa a Barcelona. Les dades disponibles no permeten detallar els fundadors ni el capital inicial; aquesta informació no consta al corpus.

El model de negoci és la intermediació laboral digital: les empreses paguen per publicar ofertes i accedir a bases de currículums, i els candidats fan servir la plataforma per cercar feina i inscriure's a les vacants. Segons la Viquipèdia, el servei s'adreça tant a empreses de qualsevol mida com a persones que busquen ocupació, amb cobertura principal del mercat espanyol.

La Viquipèdia recull que InfoJobs va esdevenir un dels portals de feina líders a l'Estat espanyol. La font esmenta que l'empresa va passar a formar part del grup suís JobCloud. El corpus no permet xifrar ingressos, nombre d'ofertes ni quota de mercat per anys concrets; aquestes dades no consten.

InfoJobs no ha tancat. L'estat registral indica que l'empresa és activa i la Viquipèdia la descriu com un portal en funcionament, integrat al grup JobCloud. Per tant, no hi ha cap causa de tancament a documentar.

Segons la Viquipèdia, InfoJobs ha consolidat a l'Estat espanyol el model de portal de feina en línia com a canal habitual de reclutament per a les empreses. El corpus no aporta més detalls sobre l'impacte del portal en el mercat laboral ni sobre productes o marques derivades.

El corpus no identifica els fundadors d'InfoJobs ni en documenta la trajectòria posterior. Aquesta informació no consta. Per completar-la caldria consultar el registre mercantil (BORME i Registre Mercantil de Madrid o Barcelona), notes de premsa de les rondes de finançament i de l'adquisició per JobCloud, i entrevistes o perfils publicats als mitjans econòmics.

• En un portal de feina, l'actiu principal és la base de currículums i la xarxa d'empreses: com més candidats, més valor per a les empreses, i a l'inrevés. Cal prioritzar l'equilibri entre les dues bandes del mercat des del primer dia.
• El mercat espanyol de reclutament en línia s'ha concentrat en pocs portals grans; per competir-hi cal diferenciar-se per nínxol (sector, perfil o geografia) o per serveis afegits, no per volum d'ofertes.
• La integració en un grup internacional com JobCloud dona accés a tecnologia i clients, però també sotmet el portal a la competència interna del grup; cal definir bé el paper de la marca local dins del grup.
• La dependència del cicle econòmic és estructural: quan l'atur puja, baixa la publicació d'ofertes. Un portal de feina ha de diversificar ingressos (formació, serveis a empreses, dades de mercat) per esmorteir els cicles.

La font verificada descriu InfoJobs com una empresa del sector del software i SaaS amb seu a Madrid, registralment activa, vinculada a la interacció entre oferta i demanda de feina. Això és el que es pot afirmar amb seguretat; qualsevol detall addicional sobre el seu model, la seva mida o la seva evolució requeriria altres fonts que aquí no tenim.

La idea reconstruïda, doncs, és la mateixa essència: un mercat digital on les empreses publiquen llocs de treball i les persones hi responen, amb el programari com a producte. El que canvia avui és el context tècnic: fa vint anys un portal de feina era bàsicament un cercador de currículums; avui la mateixa essència es pot construir amb verificació d'empreses, traçabilitat de processos i eines per a l'empresa que vagin més enllà de la publicació d'anuncis.

Proposta (no verificada, és una decisió de disseny): reconstruir-ho com una plataforma de contractació amb verificació real d'empreses i candidats, on la confiança sigui el producte i no un afegit. Això és una proposta meva, no una descripció del que InfoJobs és o era.

El mercat que InfoJobs va ocupar és el de la intermediació laboral digital: empreses que necessiten cobrir vacants i persones que busquen feina. La font verificada no ens dona mida de mercat, quota ni volum de tràfic, de manera que qualsevol xifra que es donés aquí seria inventada.

El que sí que es pot dir amb seguretat és que el sector existeix i que l'empresa hi és registralment activa. A partir d'aquí, tot el que segueix és estimació a validar:

• El mercat espanyol de portals de feina és un mercat madur, amb actors consolidats i competència de plataformes globals (estimació qualitativa, a validar amb dades d'audiència i de despesa publicitària).
• La demanda de verificació i de qualitat de les candidatures és una tendència plausible del sector, però no la puc quantificar amb les fonts disponibles.
• El nínxol on una reconstrucció tindria més sentit és el de segments mal coberts: pimes, sectors tècnics i feines de proximitat (proposta, a validar).

Proposta de model, marcada com a tal i no com a descripció de l'empresa original:

1. Subscripció per a empreses (SaaS): publicació de vacants, accés a candidatures filtrades i eines de gestió del procés. Preu per franja de vacants actives.
2. Pagament per resultat opcional: un complement sobre la subscripció per a processos amb més exigència de verificació.
3. Gratuïtat per a candidats, amb serveis premium de perfil i formació (a validar, perquè el mercat de pagament per part del candidat és difícil).

El que és important: el nucli del negoci ha de ser la subscripció recurrent d'empreses, no la publicitat, perquè la publicitat depèn del tràfic i el tràfic depèn de tenir vacants reals. Aquesta és una lliçó de disseny, no una dada verificada sobre InfoJobs.

Proposta en fases, amb durades estimades i a validar:

• Fase 0 (1-2 mesos): definició del nínxol inicial i de la proposta de verificació. Sense producte, només validació amb 20-30 empreses i 50-100 candidats (estimació).
• Fase 1 (3-4 mesos): producte mínim: publicació de vacants, candidatura i panell d'empresa. Verificació manual d'empreses (estimació).
• Fase 2 (3-6 mesos): primers clients de pagament en un sol sector o territori. Mètrica clau: vacants cobertes, no visites (proposta).
• Fase 3 (6-12 mesos): ampliació de sectors i automatització de la verificació.

El criteri de go/no-go hauria de ser explícit: si en la fase 2 no hi ha un nombre mínim de clients recurrents, no s'amplia (proposta).

Totes les xifres següents són estimacions meves, en rang, i a validar amb pressupostos reals:

• Equip mínim (2-3 persones: producte i desenvolupament, més comercial): rang de 120.000-200.000 € anuals de cost laboral, segons contractació (estimació).
• Desenvolupament del producte mínim: rang de 40.000-90.000 € si es fa amb equip propi, o més si s'externalitza (estimació).
• Màrqueting i adquisició inicial d'empreses: rang de 15.000-40.000 € els primers mesos (estimació).
• Legal, verificació i operacions: rang de 10.000-25.000 € (estimació).
• Total orientatiu per als primers 12 mesos: rang de 180.000-350.000 € (estimació, a validar).

No dono cap xifra com a certa: la font verificada no conté dades financeres de l'empresa.

• Risc de mercat: competir en un sector madur amb actors consolidats i plataformes globals (risc estructural, no quantificat).
• Risc de liquiditat: el model de subscripció triga a arrencar; cal capital per cobrir els primers mesos (estimació).
• Risc de confiança: la verificació és costosa i, si es fa malament, expulsa clients (proposta).
• Risc de dependència de tràfic: si no hi ha vacants reals, no hi ha candidats, i sense candidats no hi ha empreses.
• Risc d'informació: aquest informe parteix d'una sola font verificada; qualsevol decisió d'inversió requeriria contrastar-la.

Aquesta secció recull les lliçons de l'informe original, no un currículum:

• L'essència d'InfoJobs no és la tecnologia sinó la intermediació de confiança entre empreses i persones; qui ho reconstruís hauria de començar per entendre aquesta intermediació, no per construir programari.
• La font verificada és mínima: la lliçó principal és que qualsevol reconstrucció ha de separar rigorosament el que se sap del que se suposa, i marcar cada estimació com a tal.
• El sector és de software i SaaS, amb seu a Madrid i activitat registral: això indica que el negoci és possible a l'Estat, però no diu res sobre com es va fer ni amb quins números.
• Qui ho hauria de fer és un equip petit amb capacitat de producte i de vendes B2B, disposat a validar abans d'invertir i a acceptar que les xifres d'aquest informe són estimacions, no fets.

InfoJobs, segons la font disponible [Wikipedia], és un portal de feina espanyol amb seu a Madrid que opera com a mercat bilateral: les empreses publiquen ofertes i els candidats hi envien candidatures. El model funciona per volum, però no resol el problema de fons: ni l'empresa ni el candidat saben per què una candidatura encaixa o no. Les ofertes són text lliure, els perfils són CVs en formats heterogenis, i la decisió de filtrar queda en mans d'un reclutador que llegeix desenes de candidatures.

El producte que especifiquem no és un clon del portal: és el motor de correspondència que el portal hauria necessitat. Resol tres problemes concrets:

1. Requisits no estructurats. Una oferta diu "anglès fluid" i "experiència en entorns àgils"; això no és computable ni comparable entre ofertes.
2. Matching opac. Si hi ha un rànquing, no s'explica. El candidat no sap per què el descarten i l'empresa no pot auditar el filtre.
3. Evidència absent. Un perfil afirma "Python avançat" sense cap prova verificable; el sistema no distingeix una afirmació d'una evidència.

La decisió de disseny central: el matching no puntua persones, puntua correspondències entre requisits i evidències, i cada correspondència ha de ser reconstruïble a partir de dades emmagatzemades.

Arquitectura de tres serveis desacoblats perquè el motor de matching pugui evolucionar sense tocar el portal, i perquè l'auditoria sigui possible sense reprocessar tot el sistema.

``` [Portal web / API clients] | v [API Gateway] --(auth, rate limit)--> | +--> [Servei de Catàleg] (ofertes, perfils, requisits, evidències) | | | v | [PostgreSQL] (font de veritat, esquema relacional) | +--> [Servei de Matching] (determinista, sense estat) | | | v | [Redis] (cau de resultats per hash d'entrada) | +--> [Servei d'Ingesta] (normalitzadors, cues) | v [Cua de missatges] --> workers de normalització ```

Motius de les decisions:

• PostgreSQL com a font de veritat única. El matching necessita joins deterministes entre requisits, evidències i candidatures. Un magatzem documental faria difícil garantir que la mateixa entrada produeix la mateixa sortida. PostgreSQL amb restriccions i transaccions permet demostrar-ho.
• Servei de Matching sense estat i determinista. Rep un `match_request` (ids d'oferta i perfil + versió de regles) i retorna un resultat. No llegeix dades mutables pel seu compte; les rep del Catàleg. Això fa que el resultat sigui reproduïble i auditable: es pot reexecutar amb la mateixa versió de regles.
• Cua de missatges per a la ingesta. Normalitzar CVs i ofertes és costós i irregular; fer-ho síncronament bloquejaria l'API. Els workers poden reintentar i aïllar errors per document.
• Redis només com a cau. La clau és el hash del `match_request`; si la cau falla, el sistema degrada a càlcul directe, no a error.
• Versió de regles explícita. Cada resultat de matching porta `rules_version`. Sense això, un canvi d'algorisme invalidaria auditories passades.

Esquema relacional mínim. Les taules centrals són `requirement` i `evidence`; la taula `match_result` és derivada i es pot reconstruir.

```sql -- Ofertes i perfils CREATE TABLE job_offer ( id UUID PRIMARY KEY, company_id UUID NOT NULL, title TEXT NOT NULL, raw_text TEXT NOT NULL, status TEXT NOT NULL CHECK (status IN ('draft','published','closed')), created_at TIMESTAMPTZ NOT NULL DEFAULT now() );

CREATE TABLE candidate_profile ( id UUID PRIMARY KEY, user_id UUID NOT NULL, raw_cv JSONB NOT NULL, -- CV original tal com s'ha rebut normalized_at TIMESTAMPTZ );

-- Requisits estructurats d'una oferta CREATE TABLE requirement ( id UUID PRIMARY KEY, offer_id UUID NOT NULL REFERENCES job_offer(id), kind TEXT NOT NULL CHECK (kind IN ('skill','language','experience','education','location')), label TEXT NOT NULL, -- p.ex. 'python', 'angles' level SMALLINT, -- 0..5, nul si no aplica weight NUMERIC(4,2) NOT NULL CHECK (weight > 0), mandatory BOOLEAN NOT NULL DEFAULT false );

-- Evidències d'un perfil (afirmacions normalitzades + procedència) CREATE TABLE evidence ( id UUID PRIMARY KEY, profile_id UUID NOT NULL REFERENCES candidate_profile(id), kind TEXT NOT NULL, -- mateix domini que requirement.kind label TEXT NOT NULL, level SMALLINT, source TEXT NOT NULL CHECK (source IN ('self_declared','certification','work_history','assessment')), confidence NUMERIC(3,2) NOT NULL CHECK (confidence BETWEEN 0 AND 1), valid_from DATE, valid_until DATE );

-- Resultat derivat i auditable CREATE TABLE match_result ( id UUID PRIMARY KEY, offer_id UUID NOT NULL REFERENCES job_offer(id), profile_id UUID NOT NULL REFERENCES candidate_profile(id), rules_version TEXT NOT NULL, input_hash TEXT NOT NULL, -- hash canònic de requisits+evidències+regles score NUMERIC(5,2) NOT NULL, breakdown JSONB NOT NULL, -- per requisit: match, motiu, evidència usada computed_at TIMESTAMPTZ NOT NULL DEFAULT now(), UNIQUE (offer_id, profile_id, rules_version, input_hash) ); ```

Motius:

• `requirement` i `evidence` comparteixen el domini de `kind` i `label` perquè la correspondència sigui un join directe, no una inferència semàntica opaca.
• `evidence.source` i `confidence` existeixen perquè una certificació no val el mateix que una autodeclaració; el pes ho ha de reflectir i l'auditoria ho ha de veure.
• `match_result.breakdown` desa el motiu per requisit. És el que permet respondre "per què no encaixo" sense recalcular.
• `input_hash` garanteix idempotència: reenviar la mateixa entrada no genera un resultat nou.

API REST amb JSON, versionada per prefix (`/v1`). Autenticació per token d'empresa o de candidat; el matching només s'exposa a l'empresa i al propi candidat.

Endpoints principals:

``` POST /v1/offers/{offer_id}/requirements Body: [{kind, label, level, weight, mandatory}] Efecte: substitueix els requisits de l'oferta (transaccional).

POST /v1/profiles/{profile_id}/evidence Body: [{kind, label, level, source, confidence, valid_from, valid_until}]

POST /v1/matches Body: {offer_id, profile_id} Resposta: {score, rules_version, breakdown:[{requirement_id, matched, reason, evidence_id}]} Nota: si existeix match_result amb el mateix input_hash, es retorna el desat.

GET /v1/offers/{offer_id}/candidates?min_score=60&limit=50 Resposta: llista ordenada per score amb breakdown resumit. ```

Integracions:

• Ingesta de CV: el Servei d'Ingesta rep el document original, l'emmagatzema a `raw_cv` i encua la normalització. La normalització produeix files d'`evidence` amb `source='self_declared'`; les certificacions entren per un endpoint separat amb `source='certification'`.
• Webhooks d'estat: quan una normalització acaba o falla, s'emet un esdeveniment perquè el portal actualitzi l'estat del perfil. Motiu: el portal no ha de fer polling.
• Exportació d'auditoria: `GET /v1/matches/{id}/audit` retorna el `breakdown` complet i la versió de regles. És la integració que fa el producte defensable davant d'un candidat o d'un regulador.

Ordre estricte, perquè cada fita desbloqueja la següent:

1. Esquema de dades i migracions. Sense `requirement`, `evidence` i `match_result` no hi ha res a construir. Inclou les restriccions i el `input_hash`.
2. Servei de Catàleg amb CRUD d'ofertes, requisits i evidències. És la interfície mínima per introduir dades reals; sense dades no es pot validar res.
3. Normalitzador d'ofertes a requisits. Un pipeline que converteix text lliure en files de `requirement` amb revisió humana obligatòria abans de publicar. Motiu: la normalització automàtica sense revisió introdueix errors que contaminen tot el matching.
4. Motor de Matching determinista amb `rules_version='v1'`. Regla inicial simple i explicable: correspondència exacta de `label`, comparació de `level`, pes per `mandatory` i `confidence`. Res de models estadístics en aquesta fase.
5. Endpoint de matching i breakdown. És el producte; fins aquí no hi ha res demostrable.
6. Cua d'ingesta i normalització de CVs. Es pot endarrerir perquè el matching funciona amb evidències introduïdes manualment.

Mides:

• Volum inicial assumible: desenes de milers d'ofertes i centenars de milers de perfils. PostgreSQL amb índexs sobre `(offer_id)`, `(profile_id)` i `(kind, label)` suporta aquest ordre de magnitud sense particionar.
• El cost del matching és proporcional al nombre de requisits per oferta (típicament 5–15), no al nombre de perfils, perquè es calcula per parella sol·licitada. El coll d'ampolla és el rànquing massiu (`GET /candidates`), que requereix precalcular o limitar.

Riscos tècnics:

• Normalització sorollosa. Convertir text lliure a `requirement` pot generar duplicats o sinònims no units ("Python" vs "python3"). Mitigació: catàleg tancat de `label` amb àlies, i revisió humana abans de publicar.
• Confiança mal calibrada. `confidence` és un paràmetre subjectiu; si s'infla, el matching s'enganya. Mitigació: valors fixats per `source` a `v1` (p.ex. `self_declared=0.4`, `certification=0.9`) i no editables per l'usuari.
• Expectativa d'IA. Els usuaris esperaran matching semàntic; el `v1` és determinista i pot decebre. Mitigació: el `breakdown` explica el perquè, i la versió de regles fa visible que el motor evoluciona.
• Privadesa. `raw_cv` conté dades personals; cal x