Privalia

PRIVALIA VENTA DIRECTA SA es una sociedad mercantil constituida en el año 2012 con domicilio en Barcelona, según la ficha registral disponible en OpenMercantil (BORME). En el corpus de datos consta con estado registral activo.

Conviene advertir de una limitación importante: los datos facilitados no describen el objeto social ni la actividad efectiva de la sociedad. La clasificación como "software y SaaS" y como "startup" proviene de la ficha de datos, pero el corpus registral no la confirma explícitamente. Por tanto, no se puede afirmar qué hacía la sociedad más allá de lo que se desprende de su nombre social y de los datos disponibles.

La sociedad se constituyó en el año 2012. El corpus no aporta información sobre los socios fundadores ni sobre el capital inicial. El primer acto registral documentado es del 20 de mayo de 2013 y corresponde a nombramientos de apoderados (Samper Cabrera, Galian Ruano y Giribert Giral), de acuerdo con el BORME.

El 18 de junio de 2013 consta una ampliación de capital de 10.210,94 euros, que situó el capital suscrito y desembolsado en 1.215.409,22 euros, según el registro.

El corpus no contiene información sobre la actividad comercial, los productos o los clientes de la sociedad. No consta en los datos facilitados ninguna descripción del objeto social ni de los servicios prestados.

El único elemento que aporta contexto es la operación de fusión por absorción documentada el 7 de febrero de 2018, en la que la sociedad absorbió otras sociedades; el texto registral menciona "VENTA..." como sociedad absorbida, pero el corpus no permite completar la denominación ni conocer el alcance de la operación.

El corpus no incluye datos financieros (facturación, resultados, plantilla) que permitan identificar periodos de expansión o de bonanza. No consta ninguna información de este tipo en las fuentes disponibles.

Lo que sí consta es una actividad registral sostenida entre 2013 y 2026, con nombramientos sucesivos de apoderados y, en 2018, una ampliación de capital de 238.052,48 euros ligada a la fusión por absorción, que elevó el capital suscrito a 1.567.616,94 euros, de acuerdo con el BORME.

No consta que la sociedad haya cerrado. Según la ficha registral de OpenMercantil (BORME), el estado registral es activo y el último acto documentado es del 21 de abril de 2026 (nombramiento de un apoderado solidario).

Por tanto, no se puede atribuir ninguna causa de cierre a esta sociedad con los datos disponibles.

Dado que no consta ningún cierre, no se puede hablar propiamente de herencia empresarial en el sentido de continuidad o legado de una actividad cesada. El corpus no aporta información sobre marcas, activos transferidos o proyectos derivados.

El corpus no identifica a los fundadores de la sociedad. Los nombres que constan son los de los miembros del consejo de administración y los apoderados:

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

Estas personas constan como administradores o apoderados según el registro, pero el corpus no indica si son fundadores ni cuál es su situación actual más allá de los cargos registrados. Para más información se podría consultar el Registro Mercantil de Barcelona (tomo 322965) y las fuentes públicas de composición de órganos sociales.

• La información registral permite trazar la vida formal de una sociedad (nombramientos, ampliaciones de capital, fusiones), pero no sustituye los datos financieros ni comerciales: para evaluar una empresa hay que cruzar el BORME con cuentas depositadas y fuentes sectoriales.
• Una ampliación de capital vinculada a una fusión por absorción (como la de 2018) es una señal de operación corporativa relevante, pero hay que leer el acto completo para conocer las sociedades absorbidas y el alcance real de la operación.
• No se debe confundir "estado registral activo" con "empresa operativa": el registro no informa de la actividad efectiva, y hay que contrastarlo con otras fuentes antes de concluir nada sobre la marcha del negocio.

La essència de Privalia era simple: oferir a marques de moda un canal per liquidar estoc sobrant amb descompte, i oferir al consumidor accés a marques a preus baixos en vendes flash de durada limitada. Segons Wikipedia, Privalia es va fundar a Barcelona el 2006 com a club de compres privat de moda online i va créixer fins a operar en diversos països.

Avui aquesta essència es podria reconstruir de tres maneres, totes com a proposta:

1. Outlet digital de marca amb flash sales (el model original actualitzat): vendes de durada curta, accés obert o amb registre, app mòbil com a canal principal.
2. Marketplace B2B2C de liquidació d'estoc: connectar marques i retailers amb consumidor final, cobrant comissió en lloc de comprar estoc propi (model més lleuger en capital).
3. Outlet de nínxol (moda infantil, esport, llar): començar en una vertical on el marge i la recurrència siguin més fàcils de defensar.

La diferència clau respecte al 2006 és que avui el cost de muntar una botiga online és molt baix, però el cost d'adquirir tràfic és molt alt i la competència (marketplaces globals, outlets de les mateixes marques) és molt més forta.

El mercat de l'outlet i la liquidació d'estoc de moda existeix i és gran, però les dades concretes de mida i creixement no estan a la font verificada disponible i, per tant, no s'afirmen aquí. El que sí que és verificable és que Privalia va operar en aquest nínxol i va créixer fins a escala internacional, cosa que indica que el mercat era prou gran per sostenir un operador des de Barcelona.

Com a estimació a validar, el mercat rellevant per a un nou entrant seria: (a) marques mitjanes i petites que necessiten liquidar estoc sense degradar el preu a la seva botiga principal; (b) consumidors sensibles al preu disposats a comprar per impuls en finestres curtes. La validació d'aquestes dues hipòtesis amb 20-30 entrevistes seria el primer pas abans de comprometre capital.

Dues opcions, presentades com a proposta:

• Model de compra d'estoc (com l'original, presumiblement): compres estoc a la marca amb descompte i el revens. Marge brut més alt, però requereix capital de treball i gestió logística pròpia. Risc d'inventari.
• Model de marketplace amb comissió: la marca posa l'estoc, tu aportes tràfic i plataforma, i cobres comissió (rang habitual al sector, estimació a validar: 15-30% del valor de venda). Molt menys capital, però marge per operació més baix i més dependència de la qualitat de les marques.

Una via intermèdia habitual és començar amb compra d'estoc en una vertical petita per demostrar tracció i després obrir marketplace.

Pla proposat en fases (proposta, terminis orientatius):

1. Fase 0 — Validació (4-8 setmanes): entrevistes amb marques i consumidors, definició de la vertical, prova de concepte amb una llista de correu i 1-2 vendes pilot.
2. Fase 1 — MVP (2-3 mesos): botiga sobre plataforma existent (Shopify o similar), pagaments, logística externalitzada, primeres 5-10 marques.
3. Fase 2 — Tracció (3-6 mesos): campanyes de captació, primeres mètriques de recurrència i marge, decisió sobre compra d'estoc vs. marketplace.
4. Fase 3 — Escalat (a partir del mes 9-12): ampliació de verticals o categories, possible expansió geogràfica.

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

• Equip mínim (2-3 persones: producte/comercial i operacions): cost laboral anual rang estimat 90.000-180.000 €.
• Plataforma i tecnologia (e-commerce, pagaments, eines de màrqueting): rang estimat 500-2.000 €/mes.
• Màrqueting inicial (captació i primeres campanyes): rang estimat 20.000-60.000 € per als primers 6 mesos.
• Capital de treball per a estoc (si es tria el model de compra): rang estimat 30.000-100.000 € per a les primeres comandes.
• Legal, constitució i contingències: rang estimat 5.000-15.000 €.

Cost total orientatiu del primer any: rang estimat 150.000-350.000 €, molt dependent del model triat (marketplace al tram baix, compra d'estoc al tram alt).

• Adquisició de tràfic cara: el cost per client ha pujat molt des del 2006; un model basat en vendes flash necessita recurrència alta per compensar.
• Competència de marketplaces globals i dels propis outlets de les marques, que poden vendre directe.
• Risc d'inventari si es compra estoc i no es ven dins la finestra prevista.
• Dependència de poques marques subministradores en la fase inicial.
• Marge pressionat per descomptes i devolucions.
• Risc de replicar un model del passat sense adaptar-lo al context actual (mòbil, algorismes de descoberta, expectatives de lliurament ràpid).

Aquesta secció recull les lliçons de l'informe original, no un perfil de candidat:

• Privalia mostra que des de Barcelona es pot construir un negoci de moda online d'escala internacional; la ubicació no és una limitació.
• El creixement va requerir capital, equip i execució sostinguda; no és un negoci de cap de setmana.
• La essència del model (descompte + exclusivitat temporal + marca) és replicable; el que no és replicable és el context de mercat del 2006.
• La lliçó principal per a un reconstrucció avui: validar el canal d'adquisició i la recurrència abans d'escalar, i triar conscientment entre capital-intensiu (compra d'estoc) i lleuger (marketplace).

Nota: les úniques dades verificades sobre Privalia en aquest informe provenen de Wikipedia; la resta són propostes o estimacions marcades com a tals i pendents de validació.

Privalia, segons la font disponible ([Wikipedia] Privalia — Wikipédia), va operar com a club de venda privada de moda: accés per invitació, campanyes de durada limitada i descomptes agressius sobre estoc de marca. El model va funcionar comercialment, però la font no documenta cap capa de programari llicenciable: el valor quedava captiu d'un operador únic que comprava l'estoc, el movia pels seus magatzems i gestionava la relació amb la marca de forma manual.

El problema concret que aquest producte resol és el de la marca mitjana europea de moda que acumula entre 2.000 i 50.000 unitats d'estoc sobrant per temporada i no té ni el canal ni l'equip per liquidar-les sense destruir el preu de marca. Avui ho fa amb outlets propis (cars de muntar), liquidadors a l'engròs (preu de misèria) o acumulant estoc al magatzem (cost logístic). Cap de les tres opcions dona visibilitat de quin lot s'ha venut, a quin preu efectiu i quan es cobra.

La solució és un SaaS multi-tenant on la marca conserva la propietat de l'estoc fins a la venda, la plataforma allotja la flash-sale privada, i la liquidació es calcula per lot venut amb comissió transparent. El motiu de fer-ho SaaS i no marketplace és que el client vol control de preu i marca, i el motiu de fer-ho amb liquidació per lot és que sense traçabilitat financera la marca no hi entra.

Arquitectura de microserveis moderada, no per moda sinó perquè els pics de trànsit de flash-sale (obertura de campanya) i el procés de liquidació tenen perfils de càrrega oposats: el primer és lectura massiva i escriptura de comandes en segons, el segon és càlcul batch nocturn. Separar-los permet escalar el catàleg sense arrossegar el motor financer.

``` [Client web marca] [App comprador] | | v v [API Gateway / BFF] (auth JWT, rate limit per tenant) | +----+---------------------+------------------+ | | | [Catàleg i lots] [Motor de campanyes] [Comandes] | | | +----------> [Event bus: Kafka] <------------+ | +------------+-------------+ | | [Liquidació batch] [Notificacions] | [Ledger financer append-only] ```

Decisions i motius:

• Event bus (Kafka) entre comandes i liquidació: la liquidació no ha de dependre de la disponibilitat del servei de comandes ni bloquejar-lo. Els esdeveniments `order.placed` i `order.refunded` són la font de veritat per al càlcul.
• Ledger append-only per a liquidacions: cada moviment financer és un registre immutable amb `lot_id`, `order_id`, `import_brut`, `comissio`, `import_net`. Motiu: auditabilitat i conciliació; un `UPDATE` sobre imports és un risc comptable inacceptable.
• PostgreSQL per a catàleg i comandes, amb particionat per `tenant_id`: aïllament de dades per client i consultes ràpides per marca.
• Redis per a comptador d'estoc de campanya: durant una flash-sale, el decrement d'estoc ha de ser atòmic i ràpid; es fa amb operacions `DECR` i reconciliació posterior contra PostgreSQL.
• Object storage (S3-compatible) per a imatges i CSV de lots: els fitxers d'estoc poden ser grans i no han de passar pel servei de catàleg.

Entitats principals (PostgreSQL, esquema per tenant lògic amb `tenant_id` a totes les taules):

```sql tenant(id, nom, cif, comissio_pct, estat, creat_el)

marca(id, tenant_id, nom, contacte_email, condicions_liquidacio)

lot(id, tenant_id, marca_id, codi_intern, descripcio, unitats_totals, unitats_disponibles, cost_unitari, pvp_referencia, estat, data_entrada)

campanya(id, tenant_id, lot_id, nom, slug_privat, inici, fi, preu_especial, aforament_max, estat) -- esborrany | programada | activa | tancada

comanda(id, tenant_id, campanya_id, comprador_id, import_total, estat, creat_el)

linia_comanda(id, comanda_id, lot_id, unitats, preu_unitari)

liquidacio(id, tenant_id, lot_id, periode_inici, periode_fin, unitats_venudes, import_brut, comissio, import_net, estat) -- calculada | aprovada | pagada

moviment_ledger(id, liquidacio_id, tipus, import, creat_el) ```

Decisions i motius:

• `lot` com a unitat de traçabilitat, no el producte: la marca pensa en lots ("200 caixes de la col·lecció tardor"), no en SKUs individuals. El lot és la clau de la liquidació.
• `campanya` separada de `lot`: un mateix lot pot tenir diverses campanyes (per exemple, rebaixa progressiva). Separar-ho permet reutilitzar estoc sense duplicar dades.
• `preu_especial` a la campanya i `pvp_referencia` al lot: el preu de venda és decisió de la campanya; la referència de PVP serveix per calcular el descompte mostrat i per a informes de marca.
• `liquidacio` amb període: la liquidació és periòdica (setmanal o mensual per contracte), no per comanda. Motiu: reduir cost de transferències i facilitar la conciliació bancària de la marca.

API REST versionada (`/v1`), autenticació JWT amb claims `tenant_id` i `rol` (`marca_admin`, `operador`, `comprador`). Totes les respostes inclouen `X-Tenant-Id` per a traçabilitat.

Endpoints clau:

• `POST /v1/lots` — alta de lot amb CSV d'unitats; retorna `lot_id` i estat `validant`. Validació asíncrona de format i duplicats.
• `POST /v1/campanyes` — crea campanya sobre un lot; requereix `inici`, `fi`, `preu_especial`, `aforament_max`.
• `POST /v1/campanyes/{id}/publicar` — passa a `programada` i publica l'esdeveniment `campaign.scheduled`.
• `GET /v1/campanyes/{id}/estoc` — consulta en temps real (Redis + reconciliació).
• `POST /v1/comandes` — crea comanda; idempotència via `Idempotency-Key`.
• `GET /v1/liquidacions?lot_id=&periode=` — consulta liquidacions calculades.
• `POST /v1/liquidacions/{id}/aprovar` — la marca aprova; dispara el pagament.

Integracions:

• Passarel·la de pagament (Stripe o Adyen) per cobrar al comprador; webhook `payment.succeeded` confirma la comanda.
• Exportació CSV/Excel de liquidacions per a l'ERP de la marca (Sage, Odoo). Motiu: cap marca mitjana canvia d'ERP per un canal de liquidació.
• Correu transaccional (SendGrid) per invitacions a la flash-sale i notificacions de liquidació.
• Webhook de sortida `liquidacio.pagada` perquè la marca actualitzi el seu sistema comptable.

Ordre per valor demostrable i risc:

1. Catàleg de lots + pujada CSV + validació. Sense lots no hi ha producte. És la peça que la marca toca primer i on es guanya o es perd la confiança.
2. Motor de campanyes amb control d'estoc a Redis i reconciliació. És el nucli tècnic i el punt de fallada més probable; s'ha de provar amb càrrega real abans de vendre'l.
3. Comandes + pagament + webhook de confirmació. Sense cobrament no hi ha liquidació.
4. Ledger i càlcul de liquidació batch. Es pot llançar en mode "calculada, pendent d'aprovació manual" mentre es valida amb les primeres marques.
5. Portal de marca amb informes de lot venut i exportació CSV. És el que justifica la subscripció recurrent.

No construir primer: app de comprador nativa (web responsive primer), ni integracions ERP profundes, ni multi-idioma complet.

• Pic d'obertura de campanya: una flash-sale pot rebre 10.000 peticions en 60 segons. Risc: sobrevenda d'estoc. Mitigació: `DECR` atòmic a Redis amb reserva temporal (TTL 10 min) i alliberament si no es completa el pagament; reconciliació cada 5 min contra PostgreSQL.
• Consistència del ledger: un esdeveniment duplicat de Kafka pot duplicar una liquidació. Mitigació: clau d'idempotència `(order_id, tipus_moviment)` única al ledger.
• Volum de dades: 50.000 unitats per lot i 200 lots per tenant genera milions de línies de comanda. Mitigació: particionat per `tenant_id` i `creat_el` mensual; retenció de 24 mesos en línia.
• Compliment fiscal: la liquidació implica facturació entre plataforma i marca; cal validar IVA per país de la marca. Risc: error de càlcul amb impacte legal. Mitigació: càlcul d'impostos delegat a un servei especialitzat (per exemple, Stripe Tax) i revisió per país abans de llançar fora d'Espanya.
• Dependència de la font: la descripció del model Privalia es basa en la font disponible ([Wikipedia] Privalia — Wikipédia), que no detalla l'operativa interna; les decisions d'aquesta especificació són pròpies i no una reconstrucció del seu sistema.

• Test de càrrega d'obertura de campanya: simular 10.000 usuaris concurrents sobre una campanya de 5.000 unitats; criteri d'èxit: zero sobrevendes i p95 de `POST /v1/comandes` < 800 ms.
• Test d'idempotència del ledger: reenviar 1.000 esdeveniments `order.placed` duplicats; criteri: cap moviment duplicat i suma de liquidació igual a la calculada manualment.
• Conciliació pilot amb 3 marques: durant 8 setmanes, comparar la liquidació calculada per la plataforma amb el recompte manual de la marca; criteri: desviació < 0,5% en unitats i < 0,1% en imports.
• Test de reconciliació Redis/PostgreSQL: aturar Redis durant una campanya activa i verificar que la reconciliació recupera l'estoc correcte sense sobrevenda