SINERQUIA HR TOOL SA

SINERQUIA HR TOOL SA era una sociedad anónima con domicilio en Barcelona, activa en el sector del software y SaaS, con un capital social de 56.845 euros. Según el registro, operó durante catorce años, entre su constitución en 2012 y la transformación inscrita en 2026.

La sociedad se constituyó en el año 2012. Los datos disponibles no incluyen el detalle de los socios fundadores ni el objeto social literal; esta información no consta en el corpus suministrado.

El sector asignado es el de software y SaaS. El corpus no detalla el producto concreto, los clientes ni el modelo de negocio más allá de esta clasificación sectorial, por lo que no se puede precisar qué herramientas ofrecía ni a qué segmento de mercado se dirigía.

No consta en el corpus ningún dato de facturación, plantilla, rondas de financiación o clientes que permita describir la evolución económica de la empresa. El único elemento cronológico relevante es que en 2022 se inscribieron nombramientos de apoderados solidarios (Pere Barceló Bigas y Jordi Arias Flores), según el BORME.

No se trata de un cierre por disolución. De acuerdo con el acta inscrita en el BORME el 20 de agosto de 2026, la sociedad se transformó: adoptó la denominación y forma de SINERQUIA HR TOOL SL. En el mismo acto constan revocaciones y nombramientos: se revoca al administrador único, Ivan Ignacio Martínez Yemail, y se nombra administradora solidaria a Vineyards Fields SL. Previamente, el 6 de julio de 2026, se había inscrito una reducción de capital acordada por la Junta General Ordinaria de Accionistas del 18 de junio de 2026, en cumplimiento del artículo 319 de la Ley de Sociedades de Capital.

La sociedad continúa existiendo bajo la forma de SINERQUIA HR TOOL SL. El corpus no permite valorar ningún legado de producto, tecnología o equipo más allá de la continuidad jurídica de la empresa.

El corpus no identifica a los fundadores. Las personas que constan son cargos y apoderados: Ivan Ignacio Martínez Yemail (administrador único nombrado en 2021 y revocado en 2026), Pere Barceló Bigas y Jordi Arias Flores (apoderados solidarios nombrados en 2022) y Vineyards Fields SL (administradora solidaria nombrada en 2026). No consta su situación actual más allá de estos nombramientos y revocaciones. Para ampliarlo se podría consultar el Registro Mercantil de Barcelona y las cuentas anuales depositadas.

• En el sector SaaS, la transformación de SA a SL es una operación habitual para reducir costes de gobierno corporativo y flexibilizar la estructura societaria; conviene distinguirla siempre de un cierre.
• La reducción de capital previa a la transformación (junio-julio de 2026) indica un ajuste de la estructura financiera antes del cambio de forma; en SaaS con capital modesto, estas operaciones suelen acompañar reestructuraciones de socios o de gobierno.
• La entrada de una persona jurídica como administradora solidaria (Vineyards Fields SL) sustituye la gestión unipersonal por una estructura de control diferente; en empresas de software, este cambio suele preceder movimientos de propiedad o de gobierno que conviene verificar en el registro.

La dada registral és clara i cal llegir-la bé: el que consta al BORME el 2026-08-20 és una transformació de societat —la denominació i forma adoptada passa a ser SINERQUIA HR TOOL SL—, acompanyada de revocacions i nous nomenaments d'administració [BORME / BOE, 2026-08-20]. Abans, el 2026-07-06, hi havia hagut una reducció de capital [BORME / BOE, 2026-08-20]. És a dir: el que tenim verificat no és un tancament, sinó una reordenació societària i financera.

Per tant, la "reconstrucció" que proposo no és la d'un negoci desaparegut, sinó la d'una essència de producte: programari de gestió de persones (HR tool) venut com a SaaS a empreses petites i mitjanes, des de Barcelona, amb 14 anys d'història de mercat al darrere.

La proposta, avui, seria un SaaS de RRHH per a pimes de 10 a 250 empleats centrat en el que és dolorós i recurrent: nòmines i convenis catalans, control horari i registre de jornada, vacances i absències, i un mòdul lleuger d'onboarding i expedient del treballador. No un ERP de RRHH complet: un producte estret, ben integrat amb les gestories i amb els sistemes de nòmina existents.

Això és una proposta nova, no una descripció del que feia l'empresa original (d'això no en tenim detall verificat).

El mercat és real i està poblat: a Espanya hi ha desenes d'eines de control horari, gestió de vacances i nòmina per a pimes, i el segment català té particularitats (convenis provincials, llengua, relació estreta amb gestories). La dada verificada que tenim és que una empresa d'aquest sector va operar 14 anys a Barcelona [BORME / BOE, 2026-08-20] —senyal que hi ha hagut mercat suficient per sostenir una empresa, no que el nínxol estigui lliure.

El que no puc afirmar: quants clients tenia, quina quota, quin ARPU. Això no consta a les fonts disponibles.

Com a estimació a validar: el segment objectiu raonable seria pimes catalanes de 10–250 treballadors, un mercat de diversos milers d'empreses a l'àrea metropolitana de Barcelona. La validació hauria de venir de: (a) quantes gestories de nòmina hi ha a Catalunya i quines eines fan servir, (b) quin preu paguen avui per eines similars, (c) quins punts de dolor apareixen en una mostra de 30–50 pimes.

Model SaaS per subscripció per empleat i mes, amb tres components:

1. Subscripció base per empresa (mòdul de control horari + vacances + expedient). Estimació de rang: 2–5 €/empleat/mes, a validar amb preus de mercat.
2. Mòdul de nòmina/conveni com a complement de pagament, venut sovint a través de la gestoria.
3. Canal de gestories: la gestoria prescriu l'eina al client i rep comissió o descompte. Aquest és el canal que històricament ha funcionat en aquest segment (a validar).

El cànon d'entrada i la implantació (setup) poden aportar caixa inicial, però el valor del negoci és el MRR i la retenció. Un objectiu raonable a 24 mesos, com a estimació: 150–300 empreses clients i un MRR de 15.000–40.000 €, a validar segons preu i mida mitjana de client.

Fase 0 (mesos 0–2): validació. 30–50 entrevistes a pimes i 10–15 gestories de Barcelona. Objectiu: confirmar el nínxol i el preu. Cost estimat: 5.000–10.000 €.

Fase 1 (mesos 2–6): MVP. Control horari, vacances i expedient, amb compliment del registre de jornada i convenis catalans bàsics. Equip mínim de 2 desenvolupadors + 1 producte. Cost estimat: 40.000–70.000 €.

Fase 2 (mesos 6–12): primers 20–40 clients via gestories. Cost estimat: 20.000–40.000 € (màrqueting i suport).

Fase 3 (mesos 12–24): mòdul de nòmina, integracions i escalat comercial. Cost estimat: 30.000–60.000 €.

Totes les xifres són estimacions a validar; no provenen de cap dada verificada de l'empresa original.

Rang estimat d'inversió inicial per als primers 12 mesos: 60.000–120.000 €, a validar. Desglossament orientatiu:

• Producte i enginyeria (MVP + iteració): 40.000–70.000 €
• Validació de mercat i primers clients: 10.000–20.000 €
• Legal, compliment (RGPD, registre de jornada) i constitució: 5.000–10.000 €
• Màrqueting i canal de gestories: 5.000–20.000 €

No incloc sous de fundadors ni cost d'adquisició d'una cartera existent (no verificable). Si es volgués adquirir una base de clients o una marca, caldria una valoració a part, que no es pot fer amb les dades disponibles.

1. Risc de lectura de la dada: el 2026-08-20 consta una transformació, no una dissolució [BORME / BOE, 2026-08-20]. Si algú llegeix "tancament" i assumeix que el mercat ha fallat, pot abandonar un nínxol que potser és viu. Cal verificar l'estat actual de la SL successora abans de decidir res.
2. Risc de competència: el segment HR SaaS per a pimes és concorregut; cal un angle (convenis catalans, canal gestoria, llengua) o no hi ha espai.
3. Risc de canal: dependre de gestories pot limitar el creixement i la propietat del client.
4. Risc regulatori: canvis en registre de jornada, RGPD i convenis obliguen a manteniment continu.
5. Risc financer: el rang de 60.000–120.000 € és una estimació; si el MVP s'allarga, el cost pot duplicar-se.

Les lliçons de l'informe original, en clau de reconstrucció:

• La dada mana: el que consta és una transformació societària i una reducció de capital prèvia [BORME / BOE, 2026-08-20]; qualsevol pla ha de partir d'aquí i no de suposicions de tancament.
• L'essència és el producte, no la forma jurídica: SA o SL és irrellevant per al client; el que compta és l'eina de RRHH i el canal.
• El canal de gestories és el actiu a reconstruir primer, abans que el codi.
• Cal validar preu i nínxol amb dades pròpies, perquè les dades verificades de l'empresa original no inclouen clients, ingressos ni producte.
• Qui ho hauria de fer: un equip petit (2–3 persones) amb experiència en SaaS de RRHH o en gestoria de nòmina, amb capital propi o d'un soci financer per cobrir el rang estimat de 60.000–120.000 €, i amb disciplina per validar abans d'escriure codi.

Les PIMEs espanyoles gestionen persones amb fulls de càlcul i correu: l'expedient del treballador, els permisos, les vacances i els càlculs de nòmina acaben en mans d'una sola persona que no té temps de mantenir-los al dia. El resultat és informació duplicada, permisos que ningú no pot justificar davant d'una inspecció i regles de conveni aplicades de memòria.

SINERQUIA HR TOOL SA operava en aquest nínxol (software i SaaS, Barcelona, 2012–2026) i la seva transformació en SL el 2026-08-20 [BORME / BOE, 2026-08-20] deixa un buit de producte. La solució que proposo no és un ERP de RRHH complet: és el nucli que una PIME de 20 a 250 treballadors necessita per tenir l'expedient i les absències sota control, amb cada decisió traçable a una regla concreta i a una versió concreta del conveni.

El motiu de centrar-nos-hi: és la part on la llei espanyola imposa traçabilitat (registre de jornada, permisos, igualtat) i, per tant, on un producte ben fet val més que un full de càlcul.

Monolític modular en un sol desplegable, amb mòduls separats per fronteres de codi i d'esquema. El motiu és la mida de l'equip: un microserveis exigiria infraestructura i operació que un producte d'aquest abast no pot sostenir; un monolític modular permet extreure mòduls més endavant sense pagar el cost ara.

Components:

``` [Client web SPA] --HTTPS--> [API Gateway / BFF] | +------------+-------------+ | | [Mòdul Expedient] [Mòdul Absències] | | +-----------+--------------+ | [Motor de Regles Laborals] | +-----------+-----------+ | | [PostgreSQL 16] [Cua de feines] (esquema per mòdul) (Redis + worker) | [Exportador nòmina] [Generador documents] ```

Decisions i motius:

• PostgreSQL 16 amb un esquema per mòdul (`expedient`, `absencies`, `regles`, `auditoria`). Motiu: aïllament lògic sense cost operatiu; les migracions es poden versionar per mòdul.
• Motor de regles com a servei intern, no com a llibreria dins de cada mòdul. Motiu: les regles de conveni canvien sovint i han de poder-se provar i versionar independentment del codi de negoci.
• Cua de feines per a tot el que és lent o extern (exportacions, generació de PDF, enviaments). Motiu: l'API ha de respondre en menys de 300 ms i no ha de dependre de serveis de tercers.
• Auditoria append-only en taula separada, no en logs. Motiu: la traçabilitat és un requisit legal, no un requisit de depuració; ha de ser consultable per l'usuari final.
• Desplegament en un sol proveïdor cloud europeu (regió UE) amb contenidors. Motiu: residència de dades i compliment RGPD sense arquitectura multi-regió prematura.

Entitats principals, amb els camps que justifiquen la decisió:

``` empresa(id, nom, cif, conveni_id, created_at) conveni(id, codi, nom, ambit, vigent_des_de, vigent_fins_a) conveni_versio(id, conveni_id, versio, data_publicacio, font_url, hash) regla(id, conveni_versio_id, tipus, condicio_json, efecte_json, prioritat) treballador(id, empresa_id, nom, cognoms, dni, data_alta, data_baixa, tipus_contracte) contracte(id, treballador_id, tipus, jornada_hores, data_inici, data_fi) absencia(id, treballador_id, tipus, data_inici, data_fi, estat, regla_aplicada_id) saldo(id, treballador_id, tipus, any, minuts_disponibles, minuts_gaudits) auditoria(id, actor_id, entitat, entitat_id, accio, abans_json, despres_json, created_at) ```

Decisions i motius:

• `conveni_versio` amb `hash` i `font_url`. Motiu: cada càlcul ha de poder-se reproduir mesos després; si el conveni canvia, la versió antiga es conserva i no s'esborra mai.
• `regla` amb `condicio_json` i `efecte_json`. Motiu: les regles de conveni són condicionals i variades; un esquema rígid obligaria a migracions per cada conveni nou. El motor les interpreta amb un vocabulari tancat de camps i operadors, validat en escriure.
• `absencia.regla_aplicada_id`. Motiu: és el vincle que permet respondre "per què aquest permís és de 5 dies i no de 3" sense consultar logs.
• `saldo` en minuts, no en dies. Motiu: els permisos per hores existeixen i la conversió a dies perd informació.
• `auditoria` append-only amb `abans_json`/`despres_json`. Motiu: permet reconstruir l'estat en qualsevol moment i demostrar qui va canviar què.

API REST versionada (`/v1`), autenticació per OAuth 2.0 amb tokens de curta durada i refresh, i claus d'API per a integracions d'empresa.

Endpoints principals:

``` GET /v1/treballadors?estat=actiu&page=1 POST /v1/treballadors GET /v1/treballadors/{id}/expedient POST /v1/absencies # retorna regla_aplicada i justificació GET /v1/absencies/{id}/justificacio GET /v1/saldos?treballador_id=&any= POST /v1/exportacions/nomina # asíncrona, retorna job_id GET /v1/jobs/{job_id} GET /v1/auditoria?entitat=&entitat_id= ```

Decisions i motius:

• `POST /v1/absencies` retorna la justificació de la regla aplicada en la mateixa resposta. Motiu: l'usuari ha de veure per què el sistema ha decidit allò, no descobrir-ho en un informe posterior.
• Exportacions sempre asíncrones amb `job_id`. Motiu: els fitxers de nòmina poden trigar i no han de bloquejar l'API.
• Webhooks sortints per a canvis d'absència i alta/baixa de treballador. Motiu: les PIMEs tenen gestories i sistemes de nòmina externs que necessiten sincronitzar-se.
• Integracions de primera fase: importació CSV de treballadors, exportació a format de nòmina estàndard (fitxer de longitud fixa definit per la gestoria), i SSO via SAML per a empreses grans.
• No integrem cap API de tercers en la primera fase. Motiu: cada integració externa afegeix superfície de fallada i suport; primer cal validar el nucli.

Ordre de construcció, amb el motiu de cada pas:

1. Esquema `auditoria` i middleware de traçabilitat. Motiu: si s'afegeix després, cal reescriure tots els escriptors; si hi és des del primer dia, cada funcionalitat neix auditable.
2. Mòdul Expedient (treballador, contracte, alta/baixa) amb importació CSV. Motiu: és la dada base de tot la resta i permet provar el producte amb dades reals d'una empresa pilot.
3. Motor de Regles Laborals amb una versió de conveni de prova i l'endpoint de justificació. Motiu: és el diferenciador i el risc tècnic principal; s'ha de validar aviat amb un conveni real.
4. Mòdul Absències i Saldos recolzat en el motor. Motiu: és el cas d'ús que genera valor diari i el que més es consulta.
5. Exportació de nòmina asíncrona. Motiu: tanca el cicle amb la gestoria, però depèn de l'estabilitat dels punts 2 i 4.

No es construeix en la primera fase: acompliment, formació, portal del treballador, ni integracions de nòmina natives. Motiu: amplien l'abast sense validar el nucli.

Mides objectiu per a la primera versió: 50 empreses, 5.000 treballadors actius, 200.000 registres d'absència anuals. Amb aquest volum, un Postgres únic amb rèpliques de lectura i un worker n'hi ha prou; el motiu és que el coll d'ampolla serà el motor de regles, no la base de dades.

Riscos tècnics i mitigació:

• Complexitat del motor de regles. Un vocabulari massa ric esdevé un llenguatge de programació que ningú no sap mantenir. Mitigació: vocabulari tancat (camps, operadors, efectes) i proves de regressió per cada conveni versionat.
• Canvis de conveni sense preavís. Mitigació: `conveni_versio` immutable i un procés de publicació que obliga a indicar data d'efecte i font.
• Residència i RGPD. Mitigació: regió UE única, xifrat en repòs, i política de retenció explícita per a l'auditoria (mínim legal, no perpetuïtat).
• Dependència d'una sola persona per als convenis. Mitigació: el coneixement viu a les regles versionades, no al cap de ningú; cada regla té una prova associada.
• Migració de dades de clients existents. Mitigació: importador CSV amb informe d'errors per fila i mode de simulació abans d'escriure.

La validació té tres nivells i cada un respon a una pregunta diferent.

Nivell 1 — Correcció de les regles. Per a cada conveni versionat, un joc de casos (entrada: treballador, dates, tipus d'absència; sortida esperada: dies o minuts i regla aplicada). El motor ha de passar-los tots abans de publicar la versió. Motiu: és l'única manera de demostrar que el càlcul és correcte sense dependre de proves manuals.

Nivell 2 — Traçabilitat. Prova d'integració que, per a qualsevol absència creada, l'endpoint de justificació retorna la regla i la versió de conveni, i que l'auditoria conté l'estat anterior i posterior. Motiu: valida el requisit legal, no només el funcional.

Nivell 3 — Producte amb empreses pilot. Tres PIMEs de 30 a 120 tre