MEDIR FERRER Y CIA SA

MEDIR FERRER Y CIA SA era una sociedad anónima con domicilio en Barcelona, constituida en el año 2009. El corpus la clasifica dentro del sector del software y SaaS. Su situación registral es la de sociedad cerrada, con estado documental de "disuelta" y extinción inscrita en el BORME, de acuerdo con la ficha registral consultada (OpenMercantil, a partir del BORME).

La sociedad se constituyó en 2009. Entre los cargos que constan en el corpus figuran Alejandro Jaumandreu Patxot y Ernest Domènech Rambla como consejeros, y Deloitte Auditors SL como auditor. El corpus no aporta información sobre el capital fundacional, los socios iniciales ni las circunstancias concretas de la constitución.

Según la clasificación sectorial del corpus, la empresa operaba en el ámbito del software y SaaS. El corpus no contiene información sobre los productos concretos, los clientes ni el modelo de negocio. Esta falta de datos impide detallar a quién se dirigía ni cómo se monetizaba la actividad.

El corpus no contiene datos financieros, comerciales ni de crecimiento que permitan identificar un periodo de esplendor o cuantificar la actividad de la empresa en ningún momento de su vida. No consta información sobre facturación, plantilla o clientes.

La causa verificada del cierre es la extinción de la sociedad inscrita en el BORME, con estado documental de "disuelta". El corpus no indica los motivos económicos, judiciales o voluntarios que llevaron a la disolución, ni la fecha exacta del acuerdo de disolución. Cualquier afirmación sobre las causas materiales del cierre no estaría respaldada por los datos disponibles.

El corpus no recoge información sobre la continuidad de la actividad, la transferencia de productos o tecnología, ni ninguna sucesión empresarial vinculada a MEDIR FERRER Y CIA SA. No consta ningún rastro documental de la herencia de la empresa.

Del corpus constan Alejandro Jaumandreu Patxot y Ernest Domènech Rambla como consejeros de la sociedad. También aparece Deloitte Auditors SL como auditor. El corpus menciona otras empresas con fundadores coincidentes: FERRER ALIMENTACION SA (Barcelona, 2021) e INNOVACION GLOBAL DE SEGURIDAD SA (Madrid, activa). No consta información sobre la trayectoria posterior de Jaumandreu Patxot ni de Domènech Rambla más allá de estas coincidencias. Para completarlo habría que consultar el Registro Mercantil de Barcelona y las fichas registrales de las sociedades mencionadas.

• En el sector del software y SaaS, la desaparición de una sociedad a menudo no equivale a la desaparición del producto: habría que verificar si hubo transferencia de activos o de código, cosa que el corpus no permite confirmar.
• La presencia de un auditor de primera línea (Deloitte) indica que la sociedad estuvo sometida a obligaciones de auditoría, habituales en sociedades de cierta dimensión; esto no implica por sí solo ni éxito ni fracaso.
• Para cualquier análisis de continuidad en SaaS, el dato crítico es la titularidad de la propiedad intelectual y de los contratos de clientes en el momento de la disolución; el corpus no la recoge, y es el primer punto a consultar en el Registro.
• La coincidencia de nombres de consejeros con sociedades de otros sectores recuerda que, en grupos familiares o patrimoniales, la salida de una línea de negocio puede ser una decisión de reordenación y no un fracaso aislado; habría que contrastarlo con las otras sociedades del corpus antes de concluir nada.

La informació verificada només ens diu que MEDIR FERRER Y CIA SA era una societat de software i SaaS a Barcelona, constituïda el 2009 i extinta segons el BORME [BORME / BOE via OpenMercantil, 2026-06-23]. No tenim dades públiques verificades sobre quin producte venia, a qui, ni amb quins ingressos. Per tant, la reconstrucció no pot ser "fer el mateix producte": ha de ser construir una empresa de programari nova amb la mateixa essència sectorial i geogràfica.

La proposta que plantejo (marcada com a proposta, no com a fet) és un SaaS vertical de nínxol: programari per a un sector concret (per exemple, indústria, salut privada, logística o serveis professionals), venut per subscripció a empreses mitjanes de Catalunya i Espanya. L'avantatge d'un vertical és que es pot començar amb poc equip, té cicle de venda identificable i no competeix frontalment amb grans plataformes horitzontals.

El que no recomano és intentar reconstruir una estructura societària complexa com la que mostra el registre (consellers, auditor, apoderats successius). Aquesta complexitat responia a una realitat de governança d'una altra etapa; una empresa nova no la necessita per validar producte.

No disposem de dades verificades sobre el mercat que atenia MEDIR FERRER Y CIA SA, així que no puc afirmar res sobre la seva quota, clients o competidors. El que sí que és verificable és el context: Barcelona té un ecosistema consolidat de software, amb talent tècnic, universitats, acceleradores i compradors corporatius a prop.

La meva lectura (a validar) és que el mercat rellevant avui és el de digitalització de pimes i mitjanes empreses, on encara hi ha buits en sectors poc digitalitzats. Un SaaS vertical ben enfocat pot capturar un nínxol sense necessitat de capital massiu. Aquesta és una hipòtesi de treball, no una dada.

Proposta de model (a validar):

• Subscripció mensual o anual per empresa, amb preus segons nombre d'usuaris o volum.
• Implantació inicial cobrada a part (setup), que ajuda a finançar el primer any.
• Suport i formació com a servei addicional.
• Creixement basat en retenció (churn baix) més que en adquisició massiva.

Rangs orientatius d'estimació, a validar amb el mercat:

• Preu objectiu: entre 100 i 600 €/mes per client segons mida (estimació).
• Objectiu de 30-50 clients recurrents en 18-24 mesos per arribar a un punt d'equilibri amb equip petit (estimació, a validar).

Fases proposades:

1. Mesos 0-2 — Validació: 15-25 entrevistes amb empreses del nínxol triat per confirmar el problema i el dispositiu de pagament. Cost baix, sense producte.
2. Mesos 2-5 — Prototip: MVP funcional amb un sol cas d'ús. 1-2 persones tècniques.
3. Mesos 5-9 — Primers clients: 3-5 clients pilots, preferiblement de pagament o amb compromís de compra.
4. Mesos 9-18 — Iteració i vendes: ajustar producte, contractar primer comercial, mesurar churn.
5. Mes 18+ — Escalat: decidir si cal capital extern o creixement orgànic.

Tots els imports són estimacions a validar, no dades de l'empresa original:

• Equip fundador (2-3 persones, 12 mesos): 120.000-200.000 € en sous o estalvi personal (rang estimat).
• Desenvolupament i infraestructura (núvol, eines, llicències): 10.000-25.000 € el primer any (estimació).
• Legal, constitució i comptabilitat: 3.000-8.000 € (estimació).
• Màrqueting i vendes inicials: 15.000-40.000 € el primer any (estimació).
• Total orientatiu d'arrencada per 12 mesos: 150.000-270.000 € (rang estimat, a validar segons equip i ambició).

Es pot començar per la banda baixa si els fundadors treballen sense sou inicial i es finança amb clients pilots.

• Risc de producte: construir quelcom que el mercat no pagui. Mitigació: validar abans de codi.
• Risc de mercat: el nínxol triat pot ser massa petit o massa competitiu. Mitigació: triar un segment amb dolor clar i disposició a pagar.
• Risc financer: 12 mesos de runway és poc si les vendes triguen. Mitigació: clients de pagament des del mes 5-6.
• Risc de governança: replicar una estructura societària complexa massa aviat encareix i alenteix. Mitigació: estructura simple fins a tracció.
• Risc de talent: competir per desenvolupadors a Barcelona té cost alt. Mitigació: equip petit i enfocat.

Les lliçons que es poden extreure de l'expedient original, sense especular sobre el perquè del tancament:

• Una empresa de software no es sosté per la seva estructura societària, sinó pel producte i els clients. El registre mostra molts nomenaments i revocacions de consellers, apoderats i auditors al llarg dels anys; això indica una governança activa, però no substitueix la tracció comercial.
• L'auditoria i la governança formal arriben quan l'empresa ja té una mida determinada. Una reconstrucció no hauria de començar per aquí.
• La continuïtat depèn de la capacitat de renovar-se. Una empresa de 17 anys que acaba extinta recorda que el sector del software exigeix reinvenció constant.
• Qui ho hauria de fer: un equip fundador petit (2-3 persones) amb un tècnic de producte i algú amb accés al nínxol comercial, a Barcelona, amb estructura simple i enfocament en clients de pagament des del primer dia. No cal replicar l'organigrama antic; cal replicar l'ofici: fer programari que algú pagui.

Les dades registrals públiques existeixen, però arriben com a actes discrets i textuals (nomenaments, revocacions, canvis d'auditor) sense una estructura que permeti respondre preguntes simples: qui era conseller el 2024-10-18? Quan es va revocar exactament un apoderat? Hi ha incoherències entre el nomenament i la revocació?

En el cas de referència, la cronologia mostra desenes d'actes entre 2019 i 2026 amb càrrecs que entren i surten (consellers, presidents, secretaris, apoderats solidaris i mancomunats, auditors), i una revocació que sovint apareix dins del mateix acte que el nomenament. Reconstruir manualment aquest estat és lent i propens a errors.

El producte resol la reconstrucció automàtica de l'estat d'un òrgan d'administració en qualsevol instant, amb traçabilitat a l'acte font. No pretén substituir l'assessorament legal, sinó donar una base de dades auditable i citada.

Arquitectura en tres capes, amb un principi: els esdeveniments font són immutables i tot el derivat és recalculable.

``` [Font: BORME/BOE PDF + OpenMercantil] | v (1) Ingesta --> raw_act (emmagatzematge cru, hash SHA-256, URL font) | v (2) Normalitzador (parser + regles) --> event (nomenament/revocació) | v (3) Projector d'estat --> mandate (mandats amb inici/fi) + snapshot per data | v (4) API de consulta temporal + alertes ```

Decisions i motius:

• Emmagatzematge cru abans de normalitzar: si el parser millora, es reprocessa sense tornar a descarregar ni perdre traçabilitat. Cada registre cru guarda la URL i un hash per verificar integritat.
• Model d'esdeveniments (event sourcing) en lloc d'actualitzar taules d'estat directament: les revocacions arriben dins del mateix acte que els nomenaments i en ordre no trivial; un log d'esdeveniments permet reconstruir i auditar. L'estat (`mandate`) és una projecció recalculable.
• Idempotència per clau natural (empresa + data acte + tipus + persona + càrrec): les mateixes dades apareixen en fonts duplicades (OpenMercantil i PDF BORME); la clau evita duplicats.
• PostgreSQL com a magatzem únic: suporta consultes temporals (`tstzrange`, `EXCLUDE` per evitar solapaments de mandats del mateix càrrec) i JSONB per al payload cru. Motiu: menys peces mòbils que un motor de cerca separat en la primera fase.
• Parser amb revisió humana (human-in-the-loop): el text registral és ambigu; els casos de baixa confiança es marquen per revisió abans de projectar-se.

Entitats principals (PostgreSQL):

```sql -- Acte cru, immutable raw_act ( id uuid PK, source text, -- 'borme_pdf' | 'openmercantil' source_url text, content_hash text UNIQUE, -- SHA-256 del document fetched_at timestamptz, payload jsonb );

-- Esdeveniment normalitzat event ( id uuid PK, raw_act_id uuid FK, company_id uuid FK, event_date date, kind text, -- 'appointment' | 'revocation' role text, -- 'consejero','presidente','secretario', -- 'apoderado_solidario','apoderado_mancomunado','auditor' person_or_entity_id uuid FK, confidence numeric, -- 0..1, del parser needs_review boolean, UNIQUE (company_id, event_date, kind, role, person_or_entity_id) );

-- Mandat projectat (rang temporal) mandate ( id uuid PK, company_id uuid FK, role text, holder_id uuid FK, valid tstzrange, -- [inici, fi) start_event_id uuid FK, end_event_id uuid FK NULL, EXCLUDE USING gist (company_id WITH =, role WITH =, holder_id WITH =, valid WITH &&) );

-- Persona o entitat (una SL pot ser conseller, com TESAR CAPITAL INVESTMENTS SL) party ( id uuid PK, display_name text, kind text, -- 'person' | 'legal_entity' normalized_name text ); ```

Notes de disseny:

• `party` unifica persones físiques i societats perquè el registre barreja ambdues (per exemple, un conseller pot ser una SL). Motiu: el model de càrrecs no ha de distingir el tipus de titular.
• La restricció `EXCLUDE` impedeix dos mandats simultanis del mateix càrrec per al mateix titular, cosa que ajuda a detectar errors de parsing.
• `valid` com a `tstzrange` permet consultes "qui ocupava el càrrec X el dia D" amb una sola condició de contenció.

API REST (versionada, `/v1`):

• `GET /v1/companies/{id}/timeline?from=&to=` → llista d'esdeveniments ordenats amb enllaç a la font.
• `GET /v1/companies/{id}/state?as_of=YYYY-MM-DD` → estat dels càrrecs en una data (projecció de `mandate`).
• `GET /v1/companies/{id}/inconsistencies` → revocacions sense nomenament previ, solapaments, etc.
• `POST /v1/ingest` (intern) → encua un document per processar.
• `GET /v1/events/{id}/source` → retorna URL i hash del document font.

Integracions:

• Ingesta BORME/BOE: descàrrega periòdica de PDFs per data i secció; el parser extreu actes. Motiu: és la font primària i verificable.
• OpenMercantil: font secundària per contrastar i completar; s'usa per validació creuada, no com a única font.
• Webhooks d'alerta: quan es projecta un esdeveniment nou per a una empresa subscrita, s'envia un esdeveniment signat (HMAC) amb tipus, càrrec i data.

Cada resposta d'API inclou sempre la referència a la font (`source_url` + `content_hash`) perquè l'afirmació sigui auditable.

1. Esquema de dades i ingesta crua (`raw_act`): descàrrega i emmagatzematge amb hash i URL. És la base de tota la traçabilitat.
2. Parser de nomenaments/revocacions amb extracció de càrrec, persona i data, i marcatge `needs_review` per sota d'un llindar de confiança.
3. Projector d'estat que genera `mandate` a partir dels esdeveniments, amb la restricció d'exclusió activa.
4. Endpoint `state?as_of=` i `timeline`: són les dues consultes que donen valor immediat.
5. Detecció d'inconsistències bàsica (revocació sense nomenament, solapament).

No es construeix primer la UI ni les alertes: primer cal que la reconstrucció temporal sigui correcta i verificable.

• Volum: el BORME publica diàriament; per a una sola empresa de referència hi ha ~25 actes en 7 anys. El repte no és el volum sinó la qualitat del text.
• Risc: parsing ambigu. Els actes barregen nomenaments i revocacions en el mateix registre i abreugen noms. Mitigació: `confidence` + revisió humana + validació creuada entre fonts.
• Risc: entitats vs persones. Un conseller pot ser una SL (per exemple, TESAR CAPITAL INVESTMENTS SL). Mitigació: model `party` amb `kind`.
• Risc: dates i ordre. La data de l'acte registral no sempre és la data efectiva del nomenament. Mitigació: guardar ambdues dates quan es puguin extreure i exposar-les per separat.
• Risc: dependència de fonts. Si una font canvia de format, la ingesta es trenca. Mitigació: emmagatzematge cru + reparseig; alertes de taxa d'error del parser.
• Risc legal: el producte no ha de presentar-se com a assessorament legal. Mitigació: cada dada porta la font i una nota de "verificar amb el registre".

• Test de reconstrucció: amb les dades de referència, `state?as_of=2024-10-18` ha de retornar el consell amb els càrrecs que l'acte d'aquella data descriu, i `state?as_of=2025-08-12` ha de reflectir l'administrador únic i les revocacions.
• Test d'idempotència: ingerir el mateix document dues vegades no genera esdeveniments duplicats (clau natural + `content_hash`).
• Test d'integritat: cada `event` ha de resoldre a un `raw_act` amb hash vàlid i URL accessible.
• Test d'inconsistència: introduir una revocació sense nomenament previ i comprovar que `inconsistencies` la detecta.
• Validació creuada: comparar la projecció amb la font secundària (OpenMercantil) i marcar discrepàncies per a revisió.
• Mètrica de qualitat del parser: percentatge d'esdeveniments amb `needs_review=false` sobre el total, amb objectiu de millora contínua.

Fonts citades: ficha registral i actes BORME de MEDIR FERRER Y CIA SA a OpenMercantil i BOE/BORME (2026-06-23).