Privalia

PRIVALIA VENTA DIRECTA SA és una societat mercantil constituïda l'any 2012 amb domicili a Barcelona, segons la fitxa registral disponible a OpenMercantil (BORME). Al corpus de dades consta amb estat registral actiu.

Cal advertir d'una limitació important: les dades facilitades no descriuen l'objecte social ni l'activitat efectiva de la societat. La classificació com a "software i SaaS" i com a "startup" prové de la fitxa de dades, però el corpus registral no la confirma explícitament. Per tant, no es pot afirmar què feia la societat més enllà del que es desprèn del seu nom social i de les dades disponibles.

La societat es va constituir l'any 2012. El corpus no aporta informació sobre els socis fundadors ni sobre el capital inicial. El primer acte registral documentat és del 20 de maig de 2013 i correspon a nomenaments d'apoderats (Samper Cabrera, Galian Ruano i Giribert Giral), d'acord amb el BORME.

El 18 de juny de 2013 consta una ampliació de capital de 10.210,94 euros, que va situar el capital subscrit i desemborsat en 1.215.409,22 euros, segons el registre.

El corpus no conté informació sobre l'activitat comercial, els productes o els clients de la societat. No consta a les dades facilitades cap descripció de l'objecte social ni dels serveis prestats.

L'únic element que aporta context és l'operació de fusió per absorció documentada el 7 de febrer de 2018, en què la societat va absorbir altres societats; el text registral esmenta "VENTA..." com a societat absorbida, però el corpus no permet completar la denominació ni conèixer l'abast de l'operació.

El corpus no inclou dades financeres (facturació, resultats, plantilla) que permetin identificar períodes d'expansió o de bonança. No consta cap informació d'aquest tipus a les fonts disponibles.

El que sí que consta és una activitat registral sostinguda entre 2013 i 2026, amb nomenaments successius d'apoderats i, el 2018, una ampliació de capital de 238.052,48 euros lligada a la fusió per absorció, que va elevar el capital subscrit a 1.567.616,94 euros, d'acord amb el BORME.

No consta que la societat hagi tancat. Segons la fitxa registral d'OpenMercantil (BORME), l'estat registral és actiu i el darrer acte documentat és del 21 d'abril de 2026 (nomenament d'un apoderat solidari).

Per tant, no es pot atribuir cap causa de tancament a aquesta societat amb les dades disponibles.

Atès que no consta cap tancament, no es pot parlar pròpiament d'herència empresarial en el sentit de continuïtat o llegat d'una activitat cessada. El corpus no aporta informació sobre marques, actius transferits o projectes derivats.

El corpus no identifica els fundadors de la societat. Els noms que consten són els dels membres del consell d'administració i els apoderats:

• Xavier Jean Gabriel Court, conseller.
• Lucas Carne Carcas, conseller.
• Fabio Angello Bonfa, conseller.

Aquestes persones consten com a administradors o apoderats segons el registre, però el corpus no indica si són fundadors ni quina és la seva situació actual més enllà dels càrrecs registrats. Per a més informació es podria consultar el Registre Mercantil de Barcelona (tom 322965) i les fonts públiques de composició d'òrgans socials.

• La informació registral permet traçar la vida formal d'una societat (nomenaments, ampliacions de capital, fusions), però no substitueix les dades financeres ni comercials: per avaluar una empresa cal creuar el BORME amb comptes dipositats i fonts sectorials.
• Una ampliació de capital vinculada a una fusió per absorció (com la del 2018) és un senyal d'operació corporativa rellevant, però cal llegir l'acte complet per conèixer les societats absorbides i l'abast real de l'operació.
• No s'ha de confondre "estat registral actiu" amb "empresa operativa": el registre no informa de l'activitat efectiva, i cal contrastar-ho amb altres fonts abans de concloure res sobre la marxa del negoci.

La font disponible (Wikipedia) descriu Privalia com una plataforma de vendes privades en línia de moda i accessoris, amb un model de flash sales per a socis registrats. La seva essència verificable és, doncs, la intermediació entre marques que volen liquidar estoc sense degradar la marca i consumidors que busquen descompte en un entorn exclusiu.

Avui aquesta essència es podria reconstruir com una plataforma de liquidació premium per a marques, amb tres diferències respecte del model original (aquestes són propostes, no fets de Privalia):

• Accés per invitació però amb capa de personalització per algorisme (recomanació per talla, marca i historial).
• Eines per a la marca: panell d'autoservei per publicar estoc, control de preus mínims i reporting de rotació.
• Model híbrid: flash sales tancades + outlet permanent per a marques que ho prefereixin.

No es disposa, a la font citada, de dades financeres, nombre d'usuaris ni detalls tècnics de Privalia; qualsevol afirmació d'aquest tipus quedaria fora d'aquest informe.

El mercat rellevant és el de liquidació d'estoc de moda i accessoris a Europa del Sud, on existeix un excés estructural d'estoc de temporada i una pressió creixent de les marques per no vendre a preu ple trencat als canals generalistes.

Punts a validar abans de llançar (estimacions, no dades verificades):

• Mida del mercat d'estoc excedentari de moda a Espanya i sud d'Europa: rang estimat de 2.000-4.000 M€ anuals, a validar amb dades sectorials.
• Competència: grans marketplaces generalistes, outlets en línia especialitzats i cadenes físiques de descompte. Cal mapar-los abans de decidir el posicionament.
• Diferenciació possible: servei "marca blanca" per a marques mitjanes que no tenen accés fàcil als grans canals de liquidació.

Proposta (a validar):

• Comissió per venda sobre el preu de liquidació: rang estimat del 15-25%, depenent de la categoria i del volum.
• Quota fixa mensual per a marques amb panell d'autoservei: rang estimat de 200-800 €/mes.
• Serveis addicionals: logística inversa, fotografia de producte i gestió de devolucions, facturats a part.
• Ingrés accessori per publicitat interna de marques dins la plataforma.

El marge dependrà críticament de la logística: si es gestiona estoc propi, el capital circulant puja molt; si es treballa en model dropship o consigna, el risc baixa però el marge també.

Proposta en fases (estimacions de temps, a validar):

1. Fase 0 (mesos 0-3): validació amb 10-15 marques mitjanes de moda de Barcelona i rodalia; acord de consigna i proves de venda en un entorn tancat.
2. Fase 1 (mesos 3-9): llançament de la plataforma amb accés per invitació, catàleg limitat i una comunitat inicial de compradors captada per canals propis.
3. Fase 2 (mesos 9-18): obertura del panell d'autoservei per a marques i primeres campanyes de flash sales recurrents.
4. Fase 3 (mesos 18-30): expansió a Portugal i sud de França, si les mètriques de retenció i rotació ho justifiquen.

Mètriques de decisió a fixar abans de començar: cost d'adquisició de comprador, taxa de recompra, rotació d'estoc per marca i marge net per comanda.

Totes les xifres són estimacions a validar, no dades de Privalia:

• Desenvolupament de plataforma (web + panell de marca + pagaments): rang estimat de 60.000-150.000 €, segons si es construeix a mida o sobre SaaS existent.
• Equip inicial (2-3 persones: producte, comercial i operacions) durant 12 mesos: rang estimat de 90.000-180.000 €.
• Màrqueting i captació inicial: rang estimat de 20.000-60.000 €.
• Legal, fiscal i constitució: rang estimat de 5.000-15.000 €.
• Costos operatius i logística inicial: rang estimat de 15.000-40.000 €.

Total orientatiu d'arrencada: rang estimat de 150.000-400.000 € per als primers 12 mesos, amb un coixí de tresoreria recomanat del 20-30% addicional.

• Risc de marca: les marques poden percebre la plataforma com un canal que degrada el preu; caldrà controls estrictes de preu mínim i confidencialitat.
• Risc de competència: els grans marketplaces poden replicar la proposta amb més volum i millors condicions.
• Risc logístic: devolucions i gestió d'estoc poden erosionar el marge si no es dissenya bé des del primer dia.
• Risc de captació: el cost d'adquirir compradors recurrents en moda és alt i la retenció és la clau del model.
• Risc de dependència de poques marques: si el catàleg depèn de dos o tres proveïdors, la plataforma és fràgil.

Lliçons que es poden extreure de la trajectòria de Privalia segons la font disponible (Wikipedia), aplicables a qualsevol reconstrucció:

• L'essència és la relació amb la marca, no la tecnologia: el valor rau a aconseguir que marques respectables confiïn el seu estoc a un canal controlat.
• L'escala internacional és una decisió de capital, no de producte: créixer fora requereix inversió i equip, i cal decidir-ho amb mètriques, no amb ambició.
• El model de vendes privades depèn de la recurrència del comprador: sense comunitat fidel, cada campanya comença de zero.
• La logística és el coll d'ampolla real: qui controla devolucions i estoc controla el marge.
• Convé construir amb capital aliè al creixement: el model requereix coixí financer per absorbir estocs i campanyes.

Aquestes lliçons són una lectura aplicada de la informació pública disponible; no substitueixen una anàlisi financera detallada ni cap dada interna de l'empresa original.

Privalia operava com a outlet de moda en línia amb un model de vendes flash: cada campanya obria un lot de producte amb estoc limitat i una finestra temporal curta, cosa que concentra el tràfic en finestres molt estretes ([Wikipedia] Privalia). Aquest patró té dos problemes tècnics concrets:

1. Sobrevenda per condicions de carrera. Quan milers d'usuaris afegeixen el mateix article al carretó alhora, un descompte de stock basat en `SELECT` + `UPDATE` no és suficient si no es fa amb atomicitat i control de concurrencia; el resultat és vendre més unitats de les disponibles i haver de cancel·lar comandes.
2. Lectura del catàleg acoblada a l'escriptura. Si la pàgina de campanya llegeix directament de la base de dades transaccional mentre hi ha pics d'addició al carretó, les lectures competeixen amb les escriptures i el temps de resposta es degrada just quan més tràfic hi ha.

La solució que descric no és un redisseny genèric d'e-commerce: és un servei de reserves de stock amb expiració i un catàleg de campanyes versionat i cachejable, que és exactament el punt on el model de vendes flash falla.

Arquitectura de microserveis amb un servei de catàleg (read-heavy, cachejat) i un servei d'estoc i reserves (write-heavy, consistent), units per esdeveniments.

``` [App mòbil / Web] | v [API Gateway] --(lectura)--> [Catàleg: cache Redis + rèplica Postgres] | +--(escriptura)--> [Estoc & Reserves: Postgres primari + Redis Lua] | v [Bus d'esdeveniments: Kafka] | +---------+----------+ v v [Comandes] [Analítica / preus] ```

Decisions i motius:

• Reserva de stock amb script Lua a Redis com a primera línia i Postgres com a font de veritat. El descompte de stock ha de ser atòmic i ràpid; Redis amb un script Lua fa el `DECRBY` condicional (només si hi ha prou estoc) en una sola operació atòmica, i Postgres registra la reserva de forma duradora. Motiu: el pic de tràfic és el coll d'ampolla, i Redis absorbeix la concurrencia sense bloquejos de fila.
• Reserves amb TTL (expiració). Cada reserva té una caducitat (p. ex. 15 minuts) gestionada per Redis; si l'usuari no completa la comanda, l'estoc es retorna automàticament. Motiu: evita que carretons abandonats esgotin l'estoc d'un lot limitat.
• Catàleg versionat per campanya i cachejat. Cada campanya té una versió; el catàleg es publica com a document immutable a Redis/CDN i es llegeix sense tocar la base de dades transaccional. Motiu: desacobla les lectures massives de les escriptures de reserves.
• Kafka per a la propagació d'esdeveniments (`reserva.creada`, `reserva.expira`, `comanda.confirmada`). Motiu: el servei d'estoc no ha de conèixer el de comandes ni el d'analítica; els esdeveniments permeten reconstruir l'estat i auditar.

Entitats principals (Postgres, esquema `commerce`):

```sql campaign(id UUID PK, nom TEXT, inici TIMESTAMPTZ, fi TIMESTAMPTZ, versio INT, estat TEXT) lot(id UUID PK, campaign_id UUID FK, producte_id UUID, preu_original NUMERIC, preu_oferta NUMERIC) stock(lot_id UUID PK, unitats_totals INT, unitats_reservades INT, unitats_venudes INT, CHECK (unitats_reservades + unitats_venudes <= unitats_totals)) reserva(id UUID PK, lot_id UUID FK, usuari_id UUID, quantitat INT, expira_a TIMESTAMPTZ, estat TEXT) comanda(id UUID PK, usuari_id UUID, estat TEXT, total NUMERIC, creada_a TIMESTAMPTZ) comanda_linia(id UUID PK, comanda_id UUID FK, lot_id UUID FK, quantitat INT, preu_unitari NUMERIC) ```

Decisions i motius:

• La restricció `CHECK` a `stock` és la salvaguarda final contra la sobrevenda a nivell de base de dades, independentment de la lògica d'aplicació. Motiu: defensa en profunditat; si Redis i Postgres divergeixen, la BD no accepta un estat invàlid.
• `reserva` separada de `comanda`. Una reserva és temporal i pot expirar; una comanda és duradora. Motiu: models de cicle de vida diferents i evita barrejar estoc compromès amb estoc venut.
• `campaign.versio` permet invalidar la caché del catàleg de forma determinista quan es publica un canvi. Motiu: invalidació de caché sense escombrar claus.

APIs REST (JSON) al gateway:

• `GET /v1/campanyes/{id}` — retorna el document de catàleg versionat (servit des de caché).
• `POST /v1/reserves` — cos `{lot_id, quantitat}`; retorna `201` amb `reserva_id` i `expira_a`, o `409` si no hi ha estoc.
• `DELETE /v1/reserves/{id}` — allibera la reserva anticipadament.
• `POST /v1/comandes` — converteix reserves vàlides en comanda; idempotent per `Idempotency-Key`.
• `GET /v1/estoc/{lot_id}` — lectura d'estoc (eventualment consistent, per a UI).

Decisions i motius:

• Idempotència a `POST /v1/comandes` via capçalera `Idempotency-Key`. Motiu: en pics de tràfic els clients reintenten; sense idempotència es dupliquen comandes.
• `409 Conflict` per a estoc esgotat en lloc de `400`. Motiu: és un conflicte d'estat, no una petició mal formada, i el client mòbil pot reaccionar-hi de forma específica.
• Integracions: passarel·la de pagament (Stripe o similar) per confirmar comandes, i un exportador cap a analítica via Kafka. No s'integra cap sistema de tercers per a l'estoc: és intern i ha de ser la font de veritat.

Ordre d'implementació, per risc decreixent:

1. Servei d'estoc i reserves amb l'script Lua de descompte atòmic i la restricció `CHECK` a Postgres. És el nucli que evita la sobrevenda; sense això la resta no té sentit.
2. Model de campanyes i lots amb publicació versionada i caché de catàleg.
3. API de reserves i comandes amb idempotència.
4. Job d'expiració de reserves (Redis TTL + reconciliació periòdica contra Postgres).
5. Integració de pagament i esdeveniments Kafka per a comandes confirmades.

Motiu de l'ordre: els punts 1 i 2 cobreixen el risc tècnic principal (consistència d'estoc i pics de lectura); la resta és funcionalitat que es pot afegir sobre una base correcta.

• Pic de tràfic: cal dimensionar per a desenes de milers de sessions simultànies sobre un sol lot. El coll d'ampolla és l'script Lua a Redis (una operació per intent de reserva); cal mesurar-ne el throughput abans de fixar el nombre d'instàncies.
• Risc: divergència Redis/Postgres. Si Redis cau o es reinicia, les reserves en memòria es perden. Mitigació: reconciliació periòdica que recalcula `unitats_reservades` des de la taula `reserva` i la restricció `CHECK` com a xarxa de seguretat.
• Risc: reserves òrfenes. Si el job d'expiració falla, l'estoc queda bloquejat. Mitigació: TTL a Redis com a primera línia i un job de reconciliació que allibera reserves amb `expira_a` passat.
• Risc: hot key. Un lot molt popular concentra totes les escriptures en una clau de Redis. Mitigació: partició del comptador d'estoc per lot en subclaus si cal, o acceptar la serialització perquè el volum per lot és limitat per disseny.
• Cost: Redis en memòria per a comptadors i catàleg; Postgres amb rèplica de lectura per al catàleg.

• Prova de càrrega de pic: simular N usuaris concurrents reservant el mateix lot i verificar que `unitats_reservades + unitats_venudes <= unitats_totals` sempre, i que el nombre de `409` coincideix amb l'estoc esgotat.
• Prova de consistència: injectar fallades (reinici de Redis, caiguda del job d'expiració) i comprovar que la reconciliació restaura l'estat correcte.
• Prova d'idempotència: enviar la mateixa `Idempotency-Key` diverses vegades i verificar que es crea una sola comanda.
• Prova d'expiració: crear reserves, no confirmar-les i verificar que l'estoc es retorna dins del TTL més un marge.
• Criteri d'acceptació: zero sobrevendres en 10 execucions de la prova de càrrega, i temps de resposta del catàleg per sota del llindar fixat durant el pic.

Nota de fonts: les dades d'empresa i el model de vendes flash provenen de [Wikipedia] Privalia (https://es.wikipedia.org/wiki/Privalia); la resta són decisions de disseny tècnic proposades, no fets verificats sobre l'empresa.