MEDIR FERRER Y CIA SA

MEDIR FERRER Y CIA SA era una societat anònima amb domicili a Barcelona, constituïda l'any 2009. El corpus la classifica dins del sector del programari i SaaS. La seva situació registral és la de societat tancada, amb estat documental de "disuelta" i extinció inscrita al BORME, d'acord amb la fitxa registral consultada (OpenMercantil, a partir del BORME).

La societat es va constituir el 2009. Entre els càrrecs que consten al corpus figuren Alejandro Jaumandreu Patxot i Ernest Domènech Rambla com a consellers, i Deloitte Auditors SL com a auditor. El corpus no aporta informació sobre el capital fundacional, els socis inicials ni les circumstàncies concretes de la constitució.

Segons la classificació sectorial del corpus, l'empresa operava en l'àmbit del programari i SaaS. El corpus no conté informació sobre els productes concrets, els clients ni el model de negoci. Aquesta manca de dades impedeix detallar a qui s'adreçava ni com es monetitzava l'activitat.

El corpus no conté dades financeres, comercials ni de creixement que permetin identificar un període d'esplendor o quantificar l'activitat de l'empresa en cap moment de la seva vida. No consta informació sobre facturació, plantilla o clients.

La causa verificada del tancament és l'extinció de la societat inscrita al BORME, amb estat documental de "disuelta". El corpus no indica els motius econòmics, judicials o voluntaris que van portar a la dissolució, ni la data exacta de l'acord de dissolució. Qualsevol afirmació sobre les causes materials del tancament no estaria suportada per les dades disponibles.

El corpus no recull informació sobre la continuïtat de l'activitat, la transferència de productes o tecnologia, ni cap successió empresarial vinculada a MEDIR FERRER Y CIA SA. No consta cap traça documental de l'herència de l'empresa.

Del corpus consten Alejandro Jaumandreu Patxot i Ernest Domènech Rambla com a consellers de la societat. També hi apareix Deloitte Auditors SL com a auditor. El corpus esmenta altres empreses amb fundadors coincidents: FERRER ALIMENTACION SA (Barcelona, 2021) i INNOVACION GLOBAL DE SEGURIDAD SA (Madrid, activa). No consta informació sobre la trajectòria posterior de Jaumandreu Patxot ni de Domènech Rambla més enllà d'aquestes coincidències. Per completar-ho caldria consultar el Registre Mercantil de Barcelona i les fitxes registrals de les societats esmentades.

• En el sector del programari i SaaS, la desaparició d'una societat sovint no equival a la desaparició del producte: caldria verificar si hi va haver transferència d'actius o de codi, cosa que el corpus no permet confirmar.
• La presència d'un auditor de primera línia (Deloitte) indica que la societat va estar sotmesa a obligacions d'auditoria, habituals en societats de certa dimensió; això no implica per si sol ni èxit ni fracàs.
• Per a qualsevol anàlisi de continuïtat en SaaS, la dada crítica és la titularitat de la propietat intel·lectual i dels contractes de clients en el moment de la dissolució; el corpus no la recull, i és el primer punt a consultar al Registre.
• La coincidència de noms de consellers amb societats d'altres sectors recorda que, en grups familiars o patrimonials, la sortida d'una línia de negoci pot ser una decisió de reordenació i no un fracàs aïllat; caldria contrastar-ho amb les altres societats del corpus abans de concloure res.

El que les dades permeten afirmar és limitat: MEDIR FERRER Y CIA SA era una societat mercantil catalana, constituïda el 2009, classificada al sector de software i SaaS, amb seu a Barcelona, i tancada. Tenia consell d'administració, auditoria externa (Deloitte, de manera intermitent des del 2019) i va rebre l'entrada d'un vehicle d'inversió (Tesar Capital Investments SL) com a conseller i president el 2022-2023 [BORME via OpenMercantil, 2026-06-23].

Més enllà d'això, no tenim dades verificades sobre quin producte venia, a qui, amb quins ingressos ni per què va tancar. Qualsevol reconstrucció ha de partir d'aquesta honestedat.

La proposta que es pot fer avui —marcada com a proposta, no com a fet— és una empresa de programari de gestió (ERP/CRM lleuger) per a PIME catalanes, un nínxol on el teixit empresarial és dens i on les eines genèriques globals deixen buits de localització (facturació electrònica, models fiscals, convenis, català). L'essència que es preserva és: societat barcelonina, sector SaaS, vocació de creixement amb inversió externa.

El mercat de programari de gestió per a PIME a Catalunya és real i competitiu. Conviuen eines globals (Sage, Odoo, Holded, Microsoft Dynamics) amb proveïdors locals i integradors. La diferència competitiva sostenible per a un nou entrant no és el producte genèric, sinó:

• Localització profunda: facturació electrònica (TicketBAI, Verifactu), models 303/390/111, SEPA, convenis col·lectius catalans.
• Suport en català i presencial a l'àrea metropolitana de Barcelona.
• Verticalització per sectors concrets (serveis professionals, distribució, tallers, clíniques).

Nota: aquesta anàlisi de mercat és una estimació qualitativa basada en el coneixement general del sector; no prové de cap font verificada sobre MEDIR FERRER ni sobre mides de mercat concretes. Qualsevol xifra de mercat s'hauria de validar amb dades d'Idescat, INE o estudis sectorials abans de construir-hi un pla financer.

Proposta de model, no reconstrucció del model original (que desconeixem):

• Subscripció SaaS per usuari/mes, amb plans per mida d'empresa. Preu orientatiu de mercat: 15-40 €/usuari/mes per a PIME (rang estimat, a validar amb el mercat local).
• Implantació i migració com a ingrés inicial (servei professional, 500-3.000 € per client, estimació).
• Suport i formació com a ingrés recurrent addicional.
• Canal: venda directa a Barcelona + xarxa de gestories i assessors com a prescriptors (comissió recurrent).

El model SaaS té l'avantatge de l'ingrés recurrent i el desavantatge del cicle de venda llarg i el cost d'adquisició de client (CAC) elevat en PIME. Caldrà validar el CAC real abans de comprometre inversió.

Proposta en fases, amb horitzons estimats:

1. Fase 0 — Validació (mesos 0-3): 20-30 entrevistes amb PIME i gestories de Barcelona per confirmar el nínxol i el preu disposat a pagar. Cost estimat: 3.000-8.000 € (temps propi + alguna eina).
2. Fase 1 — MVP (mesos 3-9): producte mínim per a un sol vertical (p. ex. serveis professionals), amb facturació, despeses i informes bàsics. Cost estimat de desenvolupament: 40.000-90.000 € (equip de 2-3 persones, estimació a validar).
3. Fase 2 — Primers clients (mesos 9-15): 10-20 clients de pagament, suport intensiu, iteració. Objectiu: validar retenció i disposició a pagar.
4. Fase 3 — Escalat (mesos 15-30): canal de gestories, màrqueting, possible ronda de finançament.

La lliçó de la cronologia registral original: l'empresa va passar de societat familiar/consell a entrada d'inversió (2022-2023) i després a administrador únic i tancament (2025). Això suggereix que caldrà un pla de sortida o de continuïtat clar abans d'acceptar capital extern, perquè la inversió no garanteix la viabilitat.

Estimació de capital inicial per als primers 12-15 mesos (a validar amb pressupostos reals):

| Concepte | Rang estimat | |---|---| | Desenvolupament MVP (equip) | 40.000-90.000 € | | Constitució, legal, fiscal | 2.000-5.000 € | | Màrqueting i vendes inicials | 8.000-20.000 € | | Infraestructura i eines | 3.000-8.000 € | | Costos de personal no-dev (suport, vendes) | 15.000-40.000 € | | Total | 68.000-163.000 € |

Aquests imports són estimacions de mercat, no dades de MEDIR FERRER. La forquilla depèn de si el fundador programa ell mateix (cost baix) o contracta equip (cost alt). Una versió "bootstrap" podria arrencar amb 30.000-50.000 € si el fundador és tècnic i ven directament.

• Risc de producte: construir quelcom que el mercat no vol. Mitigació: validar abans de desenvolupar.
• Risc competitiu: els grans (Holded, Odoo, Sage) tenen escala; cal nínxol i localització.
• Risc de finançament: la cronologia original mostra entrada de capital i després tancament; cal no dependre d'inversió externa per sobreviure.
• Risc de CAC: en PIME, vendre SaaS és car; cal validar el cost d'adquisició.
• Risc de concentració: si el negoci depèn de pocs clients grans, és fràgil.
• Risc de govern: la complexitat de consell i auditoria (visible al registre) afegeix cost i lentitud; una estructura simple és més àgil en fase inicial.

Aquesta secció recull les lliçons de l'informe original (la cronologia registral), no un perfil de candidat:

1. La inversió no és la solució: l'entrada de Tesar Capital el 2022-2023 i el tancament el 2025 mostren que el capital extern no garanteix continuïtat; cal un model de negoci sòlid abans que diners.
2. La governança pesada costa: consell, auditoria i apoderats múltiples (desenes de nomenaments i revocacions) suggereixen una estructura complexa que pot alentir la presa de decisions; en fase inicial, estructura simple.
3. El cicle de vida és llarg: 16 anys d'història mostren que el sector permet longevitat, però també que cal reinvenció constant.
4. La localització és un actiu: una empresa barcelonina de software té sentit si aprofita el mercat local; no competir de front amb globals en producte genèric.
5. Cal pla de successió/sortida: el pas a administrador únic el 2025 és un senyal de reestructuració; qualsevol reconstrucció ha de preveure des del dia u com s'escala, es ven o es tanca.

Nota final: totes les xifres d'aquest informe són estimacions de mercat o propostes, no dades verificades de MEDIR FERRER Y CIA SA. Les úniques dades verificades són les de la fitxa registral citada (constitució 2009, sector, seu, tancament, nomenaments i auditoria).

MEDIR FERRER Y CIA SA va operar del 2009 al 2019 al sector del software i SaaS des de Barcelona, i la seva extinció consta inscrita al BORME en estat de dissolució [BORME / BOE via OpenMercantil, 2026-06-23]. El producte que proposo no pretén reconstruir la seva cartera comercial, sinó cobrir el nínxol que un proveïdor d'aquest perfil sol deixar desatès quan desapareix: la custòdia a llarg termini d'expedients sensibles (mèdics, de sinistre, de reclamació) que sobreviuen a l'empresa que els va gestionar.

El problema concret és que les asseguradores, mútues i clíniques hereten expedients en formats propietaris, amb metadades incompletes i sense garanties d'integritat verificables. Quan cal auditar un cas, defensar una reclamació o respondre a una inspecció, no hi ha manera de demostrar que un document no s'ha alterat des de la seva incorporació. Això genera risc legal i cost operatiu de reconstrucció manual.

La solució és un servei de custòdia documental amb traçabilitat criptogràfica: cada document s'ingereix amb un hash, cada accés i cada canvi d'estat queda en un registre encadenat, i el client pot verificar la integritat de qualsevol expedient en qualsevol moment sense dependre de la paraula del proveïdor.

Arquitectura en dos plans clarament separats, amb un motiu: el pla de dades ha de poder tenir un cicle de vida, un règim d'accés i una auditoria diferents del pla de control, perquè és on viu la informació sensible i on les exigències de compliment són més dures.

``` ┌─────────────────────────────┐ Clients ───────► │ API Gateway (TLS, OAuth2) │ └──────────────┬──────────────┘ │ ┌────────────────────┼────────────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌────────────────┐ ┌────────────────┐ │ Pla control │ │ Pla dades │ │ Pla auditoria │ │ - identitat │ │ - ingesta │ │ - event log │ │ - tenants │ │ - emmagatzematge│ │ - verificació │ │ - facturació │ │ WORM (S3+lock)│ │ per hash │ │ - catàleg │ │ - index cerca │ │ - export proves│ └───────┬───────┘ └───────┬────────┘ └───────┬────────┘ │ │ │ ▼ ▼ ▼ ┌───────────────┐ ┌────────────────┐ ┌────────────────┐ │ Postgres │ │ Object storage │ │ Append-only │ │ (control) │ │ + OpenSearch │ │ ledger (Kafka │ │ │ │ │ │ + Postgres WAL)│ └───────────────┘ └────────────────┘ └────────────────┘ ```

Decisions i motius:

• Separació control/dades: el pla de control pot reiniciar-se o migrar-se sense tocar els béns custodiats; el pla de dades s'ha de poder segellar (WORM) i auditar de manera independent.
• Emmagatzematge WORM amb object lock: els documents custodiats no s'han de poder esborrar ni sobreescriure dins del període de retenció contractual; un bucket amb object lock en mode compliance ho garanteix a nivell d'infraestructura, no només d'aplicació.
• Registre encadenat per hash: cada esdeveniment inclou el hash de l'anterior, de manera que qualsevol manipulació del registre és detectable. És el mecanisme que permet al client verificar la integritat sense confiar en l'operador.
• OpenSearch per a cerca: la cerca per metadades i text sobre expedients és el cas d'ús més freqüent; separar-la de Postgres evita que les consultes de cerca degradin les transaccions de control.
• Kafka com a bus d'esdeveniments: permet que la ingesta, la indexació i l'auditoria evolucionin de manera independent i que el ledger es pugui reconstruir des del log.

Entitats principals, amb el motiu de cada decisió:

• tenant: organització client (asseguradora, mútua, clínica). Aïllament lògic per `tenant_id` a totes les taules; motiu: un sol desplegament multi-tenant redueix cost, i l'aïllament per fila és suficient si s'aplica a nivell de repositori i de base de dades.
• expedient: unitat de custòdia (un cas mèdic, un sinistre, una reclamació). Camps: `id`, `tenant_id`, `tipus`, `referencia_externa`, `estat`, `creat_el`, `retention_until`.
• document: fitxer custodiat. Camps: `id`, `expedient_id`, `hash_sha256`, `mida`, `content_type`, `object_key`, `ingest_el`, `ingest_per`.
• versio_document: cada document pot tenir versions successives; la versió original mai no se sobreescriu. Camps: `document_id`, `versio`, `hash_sha256`, `object_key`, `motiu`.
• esdeveniment: registre append-only. Camps: `id`, `tenant_id`, `expedient_id`, `tipus` (ingesta, consulta, canvi_estat, export, esborrat_lògic), `actor`, `timestamp`, `payload_hash`, `hash_anterior`, `hash_propi`.
• acces: registre de consultes per a compliment i auditoria. Camps: `id`, `tenant_id`, `expedient_id`, `actor`, `ip`, `timestamp`, `resultat`.
• contracte_retencio: política de retenció per tipus d'expedient i per tenant. Camps: `tenant_id`, `tipus`, `anys`, `base_legal`.

Motiu del doble registre `esdeveniment` + `acces`: el primer és la cadena d'integritat (què ha passat amb el bé custodiat), el segon és la traçabilitat d'ús (qui ha mirat què), que sovint té bases legals i terminis de conservació diferents.

API REST versionada (`/v1`), autenticació OAuth2 client credentials per a integracions màquina-màquina i OIDC per a usuaris.

• `POST /v1/expedients` — crea un expedient.
• `POST /v1/expedients/{id}/documents` — ingesta multipart; retorna `hash_sha256` calculat pel servidor i `object_key`. El client pot enviar el seu propi hash i el servei el compara; motiu: permet detectar corrupció en trànsit.
• `GET /v1/expedients/{id}/documents/{docId}/verificacio` — retorna el hash actual i la cadena d'esdeveniments associats; el client pot recalcular el hash del fitxer descarregat i comparar-lo.
• `GET /v1/expedients/{id}/esdeveniments` — llista paginada del registre encadenat.
• `POST /v1/exports` — sol·licita un export de proves (PDF + JSON signat) per a un expedient o un rang; és asíncron i retorna un `job_id`.
• `GET /v1/jobs/{jobId}` — estat de l'export.

Integracions previstes:

• Webhooks per a esdeveniments d'ingesta i canvi d'estat, amb signatura HMAC.
• Connector SFTP per a clients que encara lliuren lots nocturns; motiu: el sector assegurador manté fluxos batch i forçar-los a canviar a API alenteix l'adopció.
• Export a format estàndard (JSON + PDF/A) per a inspeccions i trasllats a un altre custodi; motiu: evitar el bloqueig del client (vendor lock-in) és un argument comercial i una exigència de compliment.

Ordre de construcció, amb el criteri de màxim valor contractual primer:

1. Nucli d'expedient i ingesta (`expedient`, `document`, `versio_document`, bucket WORM). Sense això no hi ha producte.
2. Registre encadenat d'esdeveniments i endpoint de verificació. És el diferenciador i el que justifica el preu; s'ha de construir alhora que la ingesta perquè retroactivament no es pot encadenar bé.
3. Autenticació, tenants i aïllament. Imprescindible abans de qualsevol client real.
4. API de consulta i export de proves. És el que es demostra en una venda.
5. Connector SFTP i webhooks. Amplia el mercat sense tocar el nucli.
6. Cerca (OpenSearch) i firma electrònica. La firma és la peça més complexa (integracions amb prestadors de confiança) i no ha de bloquejar el llançament.

• Volum: un tenant mitjà pot generar 50.000–200.000 documents/any; amb 20 tenants, 1–4 M documents/any. A ~500 KB de mitjana, 0,5–2 TB/any. El bucket WORM i OpenSearch han de dimensionar-se per a un creixement de 5 anys.
• Risc: cost d'emmagatzematge WORM. L'object lock impedeix esborrar; cal calcular el cost de retenció a 10 anys abans de fixar preus. Mitigació: compressió i política de retenció per tipus.
• Risc: rendiment de la cadena de hash. L'encadenat serialitza escriptures per expedient; amb molta concurrència sobre el mateix expedient pot ser coll d'ampolla. Mitigació: encadenar per expedient (no globalment) i permetre particions.
• Risc: compliment i residència de dades. Expedients mèdics exigeixen residència a la UE i acords de tractament; cal desplegament a la UE des del dia u.
• Risc: verificació pel client. Si el client no pot recalcular el hash fàcilment, la promesa d'integritat no es percep. Mitigació: eina CLI i documentació clara.
• Risc: dependència d'un sol proveïdor de núvol. Mitigació: abstracció d'emmagatzematge i export estàndard.

• Prova d'integritat extrem a extrem: ingerir un document, alterar-lo al bucket (simulat en entorn de proves), i comprovar que la verificació detecta la discrepància de hash i que la cadena d'esdeveniments assenyala el punt de manipulació.
• **Prova de càr