Wallapop

Wallapop es una startup del sector de los marketplaces, constituida como sociedad limitada (WALLAPOP, S.L.) con domicilio en Barcelona. De acuerdo con el registro, el estado de la sociedad es activo. Su actividad se sitúa en el segmento de la compraventa de productos de segunda mano entre particulares.

La sociedad se constituyó en el año 2013 en Barcelona, según consta en la cronología registral disponible. Entre los fundadores figuran Albertotics, como cofundador, y Enrique Quemada, como cofundador, de acuerdo con los datos registrales facilitados.

Wallapop operaba como marketplace, es decir, como plataforma que pone en contacto compradores y vendedores de productos de segunda mano. Los datos disponibles no permiten detallar el modelo de monetización, el alcance geográfico ni la evolución del producto más allá de esta definición sectorial.

No consta información verificada sobre la evolución de la actividad, el crecimiento, la financiación o los resultados de la empresa en ningún periodo. Las fuentes disponibles no permiten afirmar nada sobre este punto.

Wallapop no consta como empresa cerrada: de acuerdo con el registro, la sociedad es activa. Por tanto, no hay ninguna causa de cierre que documentar con los datos disponibles.

No consta información verificada sobre el impacto, la continuidad o la herencia de la empresa más allá de su condición de sociedad activa según el registro.

Los datos disponibles solo identifican a Albertotics y Enrique Quemada como cofundadores. No consta información sobre su situación actual, sus cargos o sus actividades posteriores. Para completar este punto habría que consultar el Registro Mercantil (titularidad y administradores vigentes), el BORME para los nombramientos y ceses, y fuentes públicas de la empresa.

Con la información verificada disponible no se pueden extraer lecciones operativas específicas sobre la estrategia, la financiación o la gestión del marketplace. Cualquier conclusión sobre aciertos o errores de Wallapop requeriría datos que el corpus facilitado no contiene, y por tanto no se formulan.

La dada verificada és clara: Wallapop es va constituir el 2013 a Barcelona com a marketplace de segona mà i avui consta com a activa [Wikipedia]. No hi ha, per tant, un tancament a reconstruir: el que es pot plantejar és com es construiria avui, des de zero, un marketplace de proximitat per a productes de segona mà amb la mateixa essència (particulars venent a particulars, geolocalització, mòbil primer).

Proposta (no dada de l'empresa): un marketplace C2C de segona mà amb tres decisions de disseny clares:

• Confiança com a producte: verificació d'identitat i historial de transaccions visible, perquè el principal fre del C2C és la por a l'estafa.
• Proximitat real: transacció en mà i en persona com a opció per defecte a les ciutats, amb enviament com a complement.
• Monetització tardana i selectiva: no cobrar per publicar; cobrar per visibilitat i per serveis de confiança.

L'essència que es preserva és la del 2013: aprofitar béns que ja existeixen en lloc de fabricar-ne de nous, amb una experiència mòbil simple.

El mercat rellevant és el de la segona mà C2C en línia a Espanya i el sud d'Europa. Estimació (a validar amb dades d'INE, informes sectorials i tràfic web): es tracta d'un mercat madur en demanda però concentrat en pocs actors, on la diferenciació per confiança i proximitat continua sent una escletxa plausible.

Punts a verificar abans de decidir res:

• Mida i creixement del mercat de segona mà a Espanya (fonts públiques i informes sectorials).
• Grau de concentració: quants actors capten la major part del tràfic.
• Sensibilitat al preu dels usuaris i disposició a pagar per confiança/visibilitat.

Advertiment: no disposo de xifres verificades de quota, usuaris ni facturació de Wallapop a les fonts facilitades; qualsevol número d'aquesta secció seria inventat i per tant no s'inclou.

Proposta de model (a validar):

• Publicar gratis per maximitzar oferta i liquiditat del mercat.
• Ingressos per visibilitat: destacats i promocions de llistats.
• Ingressos per confiança: verificació d'identitat, protecció de compra i resolució de disputes.
• Comissió només en transaccions amb enviament o pagament protegit, no en les presencials.

La lògica és la clàssica de marketplace: créixer en oferta i demanda abans de monetitzar, i monetitzar allà on afegeixes valor (confiança i logística), no on l'usuari ja té alternatives gratuïtes.

Proposta de full de ruta (estimació de terminis, a validar):

1. Mesos 0-3 — Nucli: producte mínim viable amb publicació, cerca geolocalitzada i missatgeria. Una sola ciutat (Barcelona, per coherència amb l'origen).
2. Mesos 3-6 — Confiança: verificació d'identitat bàsica i valoracions. Mètrica clau: percentatge de transaccions completades sense disputa.
3. Mesos 6-12 — Liquiditat local: concentrar esforç en una ciutat fins a densitat suficient abans d'obrir la segona. Evitar l'error clàssic d'expandir-se sense liquiditat.
4. Mesos 12-18 — Monetització selectiva: activar destacats i protecció de compra; mesurar disposició a pagar.

Totes les xifres són estimacions de rang, a validar amb pressupostos reals:

• Equip fundacional (2-4 persones, 12 mesos): rang estimat de 250.000–500.000 € en costos de personal.
• Producte i tecnologia (MVP + iteracions): rang estimat de 80.000–200.000 €.
• Màrqueting de llançament en una ciutat: rang estimat de 50.000–150.000 €.
• Legal, fiscal i compliment (RGPD, pagaments): rang estimat de 20.000–50.000 €.
• Total orientatiu any 1: rang estimat de 400.000–900.000 €, sense comptar capital de creixement posterior.

Aquestes xifres no provenen de cap font verificada sobre Wallapop; són una estimació de consultoria per dimensionar l'esforç.

• Liquiditat: un marketplace sense prou oferta no atrau demanda i viceversa; és el risc número u.
• Competència consolidada: els actors existents tenen xarxa, marca i dades; cal una escletxa real (confiança, nínxol, geografia).
• Frau i estafes: sense confiança, la reputació es trenca ràpid.
• Monetització difícil: usuaris acostumats a publicar gratis.
• Risc regulatori: protecció de dades, consum i pagaments.
• Risc de dada: les fonts verificades disponibles sobre l'empresa de referència són mínimes; qualsevol comparació directa s'ha de tractar amb cautela.

Lliçons a extreure de l'informe original (no un currículum):

• L'essència mana, no la còpia: el valor era resoldre la segona mà de proximitat, no replicar funcionalitats.
• La confiança és el producte: qui construeixi avui un marketplace C2C ha de tractar la confiança com a nucli, no com a afegit.
• Concentració abans d'expansió: guanyar una ciutat abans d'obrir-ne una altra.
• Monetitzar tard i on afegeixes valor: visibilitat i confiança, no publicació.
• Validar les dades abans de decidir: les fonts verificades disponibles són escasses; qualsevol pla s'ha de contrastar amb dades públiques i de mercat abans d'invertir.

Wallapop era un marketplace de compravenda de productes de segona mà entre particulars, amb seu a Barcelona [Wikipedia]. El model de negoci depenia de la confiança entre usuaris que no es coneixien: algú ven un mòbil i algú altre paga abans de rebre'l. Els riscos clàssics són el frau (producte que no arriba, producte que no és el descrit), la suplantació d'identitat, i la manca de mecanismes àgils de resolució quan alguna cosa falla.

El producte que es proposa no és un marketplace nou, sinó una capa de confiança reutilitzable (Trust-as-a-Service) que qualsevol plataforma de segona mà pugui integrar. Resol tres coses concretes: (1) saber qui és realment l'altra part, (2) tenir un historial de comportament fiable i portable, i (3) disposar d'un mecanisme de resolució de disputes amb retenció de fons opcional.

El motiu de fer-ho com a servei independent i no com a funcionalitat interna d'un sol marketplace és que el valor de la reputació augmenta amb la xarxa: com més plataformes hi participen, més útil és l'historial d'un usuari. Això també redueix el risc de dependre d'un sol operador, que és precisament el que va passar quan Wallapop va tancar.

Arquitectura de microserveis orientada a esdeveniments, desplegada en un sol cloud (per exemple AWS) amb Kubernetes. Els motius de cada decisió:

• Microserveis separats per domini (Identitat, Reputació, Transaccions, Disputes, Notificacions): cada domini té el seu cicle de canvi i els seus requisits de compliment; separar-los permet escalar la verificació d'identitat (intensiva en CPU i en crides a proveïdors externs) independentment de la reputació (intensiva en lectura).
• Event bus (Kafka o SNS/SQS): la reputació s'ha de recalcular de manera asíncrona a partir d'esdeveniments de transacció i disputa. Fer-ho síncron acoblaria la latència del marketplace a la del càlcul de puntuacions.
• Base de dades per servei (PostgreSQL per domini): evita l'acoblament per esquema compartit i permet decisions de consistència diferents (forta per a transaccions i escrow, eventual per a reputació).
• API Gateway amb autenticació per API key + OAuth2 client credentials: els clients són plataformes, no usuaris finals; cal identificar el tenant i limitar quota per tenant.
• Escrow opcional com a servei separat amb ledger d'entrades dobles: els diners no es poden tractar com un camp més; un ledger immutable amb partides dobles és l'única manera raonable d'auditar moviments i quadrar saldos.

Flux principal (descrit en text):

``` [Marketplace client] --API--> [API Gateway] --> [Identity] --> [KYC provider] |--> [Transactions] --> [Ledger/Escrow] |--> [Disputes] '--> [Reputation] <-- event bus <-- (Transactions, Disputes) ```

Un esdeveniment `transaction.completed` o `dispute.opened` es publica al bus; el servei de Reputació consumeix i actualitza la puntuació de l'usuari de manera idempotent (clau d'idempotència per esdeveniment).

Entitats principals (PostgreSQL, un esquema per servei):

• `tenant` — plataforma client. Camps: `id`, `name`, `api_key_hash`, `webhook_url`, `created_at`.
• `identity` — persona verificada. Camps: `id`, `tenant_id`, `external_user_ref`, `verification_level` (none/email/phone/document), `verified_at`, `status`.
• `identity_document` — resultat de KYC. Camps: `id`, `identity_id`, `provider`, `provider_ref`, `result`, `checked_at`. No s'hi guarden imatges de documents; només la referència al proveïdor i el resultat, per minimitzar el risc de dades sensibles.
• `transaction` — operació entre dues identitats. Camps: `id`, `tenant_id`, `buyer_identity_id`, `seller_identity_id`, `amount_cents`, `currency`, `status` (created/shipped/received/completed/disputed/cancelled), `created_at`, `completed_at`.
• `ledger_entry` — partides dobles de l'escrow. Camps: `id`, `transaction_id`, `account` (buyer_hold/seller_pending/fees), `debit_cents`, `credit_cents`, `created_at`. Immutable; només s'insereix.
• `dispute` — Camps: `id`, `transaction_id`, `opened_by_identity_id`, `reason_code`, `status` (open/under_review/resolved_buyer/resolved_seller/closed), `resolution_notes`, `opened_at`, `resolved_at`.
• `reputation_score` — projecció derivada. Camps: `identity_id`, `score` (0–100), `completed_transactions`, `disputes_lost`, `computed_at`, `model_version`. Es pot reconstruir des dels esdeveniments; no és la font de veritat.

Motiu de separar `reputation_score` com a projecció: permet canviar l'algorisme de puntuació i recalcular sense migrar dades primàries.

API REST versionada (`/v1`), JSON, autenticada per tenant.

• `POST /v1/identities` — crea o recupera una identitat per `external_user_ref`. Retorna `verification_level`.
• `POST /v1/identities/{id}/verify` — inicia verificació; retorna un `verification_url` del proveïdor KYC (redirecció hospedada, per no tocar dades de document al nostre sistema).
• `POST /v1/transactions` — registra una transacció; retorna `id` i estat.
• `POST /v1/transactions/{id}/events` — afegeix esdeveniments (`shipped`, `received`, `completed`).
• `POST /v1/disputes` — obre una disputa amb `reason_code` i evidències (URLs signades a object storage, no binaris a l'API).
• `GET /v1/identities/{id}/reputation` — retorna `score`, `model_version` i desglossament.
• Webhooks cap al tenant: `identity.verified`, `transaction.completed`, `dispute.resolved`, signats amb HMAC.

Integracions externes:

• Proveïdor KYC (p. ex. Onfido o equivalent): verificació de document i prova de vida. Motiu: no construir verificació d'identitat pròpia, és regulada i costosa.
• Passarel·la de pagament per a escrow (p. ex. Stripe Connect o Adyen Marketpay): el ledger propi registra els moviments, però la custòdia real dels fons la fa la passarel·la. Motiu: evitar ser entitat de pagament regulada en la primera fase.
• Object storage amb URLs signades per a evidències de disputa.

Ordre de construcció amb justificació:

1. API Gateway + tenants + API keys. Sense això no hi ha producte multi-client; és la base de tot.
2. Servei d'Identitat amb verificació via proveïdor KYC. És el valor més immediat i el que més redueix el frau; a més, és el que menys depèn d'altres serveis.
3. Registre de transaccions i esdeveniments. Permet començar a acumular historial, que és l'actiu que fa útil la reputació.
4. Reputació v1 (regla simple i explicable). P. ex. `score = f(transaccions completades, disputes perdudes, antiguitat)`. Motiu: una fórmula simple i auditable és millor que un model opac en la fase inicial, i es pot versionar.
5. Disputes amb flux manual assistit. Primer un panell intern per a revisors humans; l'automatització ve després d'acumular casos.
6. Escrow. És l'últim perquè afegeix complexitat reguladora i financera; el producte ja té valor sense ell.

• Volum inicial estimat: 10–50 tenants, 100k–1M identitats, 1–5M transaccions/any. Aquesta escala cap en un PostgreSQL ben indexat per domini; no cal NoSQL. El coll d'ampolla real és la latència del proveïdor KYC, no la base de dades.
• Risc: compliment i dades personals. Verificació d'identitat implica dades sensibles (RGPD). Mitigació: no emmagatzemar documents, minimitzar dades, xifratge en repòs, retenció definida.
• Risc: frau coordinat entre tenants. Un usuari banejat en un tenant pot reaparèixer en un altre. Mitigació: senyals de frau compartits entre tenants amb consentiment i pseudonimització.
• Risc: reputació manipulable. Col·lusió entre comprador i venedor per inflar puntuacions. Mitigació: ponderar per diversitat de contraparts i detectar patrons (mateixes parelles repetides).
• Risc: escrow i regulació financera. Si es custodia fons, apareix la figura d'entitat de pagament. Mitigació: delegar la custòdia a una passarel·la regulada i limitar-se a orquestrar.
• Risc: dependència d'un sol proveïdor KYC. Mitigació: capa d'abstracció `KycProvider` amb dos proveïdors intercanviables.

• Tests unitaris i de contracte per a cada API (schema OpenAPI com a font de veritat), amb proves de compatibilitat enrere entre versions.
• Tests d'idempotència dels consumidors d'esdeveniments: reenviar el mateix esdeveniment no ha de duplicar moviments del ledger ni canviar la puntuació.
• Proves de quadre del ledger: invariant que la suma de débits iguala la suma de crèdits per transacció, verificada en CI i en un job diari.
• Validació de producte amb mètriques concretes: taxa de frau reportada pels tenants abans/després, percentatge de transaccions amb identitat verificada, temps mitjà de resolució de disputes, i correlació entre `score` i incidències reals (calibratge del model).
• Pilot amb 2–3 tenants abans de generalitzar, amb un conjunt de casos de disputa etiquetats per mesurar la qualitat de la puntuació i del flux de resolució.
• Auditoria de seguretat (pentest) i revisió de compliment RGPD abans del llançament de l'escrow.