Chicfy

Chicfy era una startup española del sector de los marketplaces, según consta en los datos de la empresa. Se trataba de una aplicación de compraventa de moda de segunda mano entre particulares, conocida por el lema «claro que sí, guapi», según El Mundo.

La ubicación de la empresa no consta en los datos disponibles.

Los datos disponibles no incluyen información sobre la fundación de Chicfy: no constan ni la fecha, ni los fundadores, ni el lugar de constitución. Esta información no se puede afirmar con las fuentes facilitadas.

Chicfy operaba como marketplace, es decir, una plataforma que pone en contacto compradores y vendedores. Según El Mundo, se trataba de una aplicación de moda de segunda mano, lo que sitúa su actividad en la compraventa de ropa y complementos usados entre usuarios particulares.

El detalle del modelo de negocio, las comisiones o el perfil concreto de usuarios no consta en los datos disponibles.

Los datos disponibles no incluyen cifras de facturación, número de usuarios, rondas de financiación ni ningún otro indicador de actividad de Chicfy. Por tanto, no se puede describir con precisión cuáles fueron los años buenos ni la magnitud de la actividad. El único elemento que consta es el reconocimiento del lema «claro que sí, guapi» asociado a la marca, según El Mundo.

Según El Mundo (15 de octubre de 2019), Chicfy cerró y pasó a manos de su rival Vinted. La noticia registra el cierre y el traspaso, pero los datos disponibles no detallan la causa del cierre, que consta explícitamente como no verificada.

El cierre de Chicfy se produjo con el paso de la actividad a Vinted, su rival, según El Mundo. Los datos disponibles no permiten afirmar nada más sobre qué se conservó: no consta si la marca, la base de usuarios o la tecnología se integraron en Vinted, ni en qué términos se hizo el traspaso.

Los datos disponibles no identifican a los fundadores de Chicfy, de modo que no consta quiénes son ni qué trayectoria han seguido tras el cierre. Para obtener esta información habría que consultar el registro mercantil (BORME) para identificar a los administradores de la sociedad, y fuentes periodísticas especializadas en startups para trazar su actividad posterior.

• En un marketplace de moda de segunda mano, la masa crítica de usuarios es el activo principal; cuando aparece un competidor con más escala, como Vinted, la presión sobre el modelo se concentra en la capacidad de retener oferta y demanda a la vez.
• El cierre de Chicfy se resolvió con un traspaso a la rival, un patrón habitual en sectores donde el ganador se lo lleva casi todo: la salida a menudo pasa por la integración en el competidor más grande más que por una liquidación pura.
• La marca y el tono de comunicación (el lema «claro que sí, guapi») pueden generar notoriedad, pero los datos disponibles no permiten afirmar que esta notoriedad se tradujera en retención o monetización; para un marketplace, la notoriedad sin escala de usuarios no sostiene el negocio.
• La falta de datos públicos sobre fundación, financiación y cifras de actividad en el momento del cierre es, en sí misma, una señal: conviene documentar y hacer públicas las métricas clave a lo largo de la vida de la startup para que el mercado y los inversores puedan evaluar su viabilidad.

Reconstruir l'essència de Chicfy —un marketplace on particulars venen roba de segona mà, amb un to proper i comunitari— és possible avui, però no es pot plantejar com una repetició del model de 2019. La dada verificada és que l'empresa va tancar el 15 d'octubre de 2019 i va passar a mans de Vinted (El Mundo, 15/10/2019). La causa del tancament no consta a les fonts disponibles, de manera que no podem atribuir-lo a un factor concret; qualsevol explicació seria especulació.

La proposta, doncs, és marcada com a proposta: un marketplace C2C de moda de segona mà amb èmfasi en la confiança entre usuaris, la cura de la presentació del producte i una comunitat local o de nínxol. No es tracta de competir amb un catàleg generalista, sinó d'ocupar un espai on la confiança i el tracte humà siguin el diferencial.

El mercat de la moda de segona mà existeix i és gran, però també està concentrat. Vinted, que va absorbir Chicfy segons la font citada, és un actor dominant; Wallapop i plataformes especialitzades també hi són presents. Això vol dir que el mercat no s'ha de crear, però sí que s'ha de conquerir en un nínxol.

La lectura estratègica és clara: no hi ha espai per a un "Chicfy 2.0" genèric, però sí per a una proposta amb un angle definit —per exemple, moda local, marques concretes, o un segment d'usuaris que valoren la confiança i el tracte per sobre del preu més baix. Aquesta és una hipòtesi de treball, a validar amb recerca de mercat abans d'invertir.

El model bàsic d'un marketplace C2C és la comissió per transacció, eventualment complementada amb serveis de valor afegit (enviaments, destacats, verificació). Aquesta és una proposta de model, no una dada de Chicfy.

El punt crític és el cost d'adquisició d'usuaris i la massa crítica: un marketplace sense oferta no atrau demanda i viceversa. Per això el model hauria de preveure un llançament en un nínxol tancat (una ciutat, una categoria, una comunitat) abans d'escalar. Els ingressos per comissió són una estimació a validar; no hi ha dades públiques verificades sobre els marges de Chicfy.

Un pla raonable, marcat com a proposta, seria per fases:

1. Fase 0 — validació (1-2 mesos): entrevistes amb usuaris potencials, anàlisi de la competència i definició del nínxol. Cost estimat: baix, a validar.
2. Fase 1 — pilot tancat (3-6 mesos): una sola ciutat o comunitat, oferta curada, acompanyament manual de les primeres transaccions. L'objectiu és demostrar que hi ha intercanvi real i confiança.
3. Fase 2 — obertura gradual: ampliació de categories o geografia només si les mètriques del pilot ho justifiquen.

No hi ha informació verificada sobre com va llançar Chicfy ni sobre els seus terminis; aquest pla és una proposta metodològica, no una reconstrucció documentada.

No hi ha dades verificades sobre el capital que va necessitar Chicfy. El que segueix és una estimació de rang, a validar, per a un llançament lleuger:

• Desenvolupament tècnic: es pot començar amb solucions existents o un desenvolupament mínim. Rang estimat: 15.000–60.000 €, segons si es fa a mida o amb eines de tercers.
• Màrqueting i adquisició inicial: 5.000–20.000 € per al pilot, estimació.
• Operació i equip mínim: 2-4 persones durant els primers mesos; cost estimat de 30.000–80.000 € anuals, a validar segons l'equip.
• Total orientatiu per al primer any: rang estimat de 50.000–150.000 €, a validar amb un pla financer detallat.

Aquestes xifres són orientatives i no provenen de cap font verificada sobre Chicfy.

• Competència d'un incumbent consolidat: Vinted ja va absorbir Chicfy (El Mundo, 15/10/2019); competir-hi de front és el risc principal.
• Massa crítica: un marketplace sense prou oferta o demanda no arrenca; és el risc estructural del model.
• Causa de tancament desconeguda: com que no consta per què va tancar Chicfy, no es pot descartar que fos per factors que també afectarien una reconstrucció (finançament, unit economics, competència). Caldrà investigar-ho abans de decidir.
• Cost d'adquisició d'usuaris: pot menjar-se els marges si no es treballa amb un nínxol i una comunitat.

Aquest apartat recull les lliçons de l'informe original, no un currículum:

• Cal partir de fets, no de mites: l'única dada verificada és el tancament i el traspàs a Vinted el 2019; la causa no consta. Qualsevol relat que atribueixi el fracàs a una causa concreta sense font és especulació.
• El mercat existeix, però està ocupat: la reconstrucció ha de ser un nínxol, no una còpia.
• Els números s'han de marcar com a estimació: no hi ha dades públiques verificades sobre costos o marges de Chicfy; qualsevol xifra és orientativa i a validar.
• La confiança i la comunitat són el diferencial, no el catàleg: és l'essència que es pot reconstruir avui, amb un model de costos i un pla de llançament prudents.

Chicfy era un marketplace C2C de moda on la confiança entre desconeguts es resolia amb moderació i atenció manual, i on el pagament i l'enviament no estaven integrats de manera que l'usuari no hagués de sortir de la plataforma. Quan Vinted va arribar amb enviaments integrats, pagament retingut fins a recepció i un catàleg molt més gran, l'avantatge competitiu de Chicfy es va evaporar; el tancament i el traspàs a Vinted el 2019 [El Mundo, 2019-10-15] és el fet verificat, però la causa exacta no consta al registre.

El problema tècnic concret que cal resoldre és aquest: fer que una transacció entre dos desconeguts sigui segura i barata sense que cap persona l'hagi de revisar. Això vol dir tres coses alhora: (1) diners retinguts en escrow fins que el comprador confirma la recepció, (2) etiqueta d'enviament generada automàticament amb seguiment, i (3) un senyal de confiança calculat a partir de dades objectives (historial, disputes, temps de resposta) en lloc de la moderació manual. Si qualsevol de les tres falla, el cost per transacció puja i el model no escala.

Arquitectura de monolític modular amb cues, deliberadament simple: un sol desplegable de l'aplicació (API + workers) i serveis externs per a allò que no és diferencial.

``` [App mòbil / Web] --HTTPS--> [API Gateway] | [Servei d'aplicació] (monòlit modular, 4 mòduls) - Catàleg i cerca - Comandes i escrow - Confiança i disputes - Notificacions | +--------------------+--------------------+ | | | [PostgreSQL] [Cua de feines] [Object storage] (font de veritat) (Redis/SQS) (imatges) | +--------------+--------------+ | | | [PSP: Stripe] [Transportistes] [Cerca: Meilisearch] (escrow) (Correus/SEUR) (índex derivat) ```

Per què monolític modular i no microserveis: el volum inicial no justifica la complexitat operativa; els límits entre mòduls es fan respectar amb esquemes de BD separats per mòdul i comunicació per esdeveniments interns, de manera que extreure'n un servei més endavant sigui una feina de setmanes i no de mesos.

Per què PostgreSQL com a font de veritat i Meilisearch com a índex derivat: la cerca de moda necessita filtres faceted (talla, marca, color, preu) i tolerància a errors tipogràfics; PostgreSQL no ho fa bé i Elasticsearch és massa pesat per començar. Meilisearch es reconstrueix des de PostgreSQL en qualsevol moment, així que no és una font de veritat i no cal fer-ne backups lògics.

Per què escrow amb un PSP i no saldo propi: gestionar saldos d'usuari converteix l'empresa en entitat de diner electrònic amb obligacions regulatories. Amb Stripe Connect (o equivalent) els diners queden al compte de la plataforma i s'alliberen al venedor amb una transferència; la plataforma no custodia fons de tercers més enllà del període d'escrow definit contractualment.

Esquemes separats per mòdul dins la mateixa instància PostgreSQL.

```sql -- catàleg CREATE TABLE users ( id uuid PRIMARY KEY, email citext UNIQUE NOT NULL, created_at timestamptz NOT NULL DEFAULT now(), trust_score numeric(4,2) NOT NULL DEFAULT 0, -- 0..5, recalculat status text NOT NULL DEFAULT 'active' -- active|suspended|deleted );

CREATE TABLE listings ( id uuid PRIMARY KEY, seller_id uuid NOT NULL REFERENCES users(id), title text NOT NULL, description text NOT NULL, brand text, size text, category text NOT NULL, condition text NOT NULL, -- new|like_new|good|fair price_cents integer NOT NULL CHECK (price_cents > 0), currency char(3) NOT NULL DEFAULT 'EUR', status text NOT NULL DEFAULT 'draft', -- draft|active|reserved|sold|removed created_at timestamptz NOT NULL DEFAULT now() ); CREATE INDEX ON listings (status, category, price_cents);

CREATE TABLE listing_images ( id uuid PRIMARY KEY, listing_id uuid NOT NULL REFERENCES listings(id) ON DELETE CASCADE, object_key text NOT NULL, position smallint NOT NULL );

-- comandes i escrow CREATE TABLE orders ( id uuid PRIMARY KEY, listing_id uuid NOT NULL UNIQUE REFERENCES listings(id), buyer_id uuid NOT NULL REFERENCES users(id), seller_id uuid NOT NULL REFERENCES users(id), amount_cents integer NOT NULL, fee_cents integer NOT NULL, status text NOT NULL, -- pending_payment|paid|shipped|delivered|released|refunded|disputed psp_payment_id text, psp_transfer_id text, ship_deadline timestamptz, -- paid_at + 5 dies auto_release_at timestamptz, -- delivered_at + 48 h created_at timestamptz NOT NULL DEFAULT now() );

CREATE TABLE shipments ( id uuid PRIMARY KEY, order_id uuid NOT NULL REFERENCES orders(id), carrier text NOT NULL, -- correos|seur tracking_code text NOT NULL, label_url text NOT NULL, last_status text, last_event_at timestamptz );

-- confiança i disputes CREATE TABLE disputes ( id uuid PRIMARY KEY, order_id uuid NOT NULL REFERENCES orders(id), opened_by uuid NOT NULL REFERENCES users(id), reason text NOT NULL, -- not_received|not_as_described|damaged status text NOT NULL DEFAULT 'open', -- open|resolved_buyer|resolved_seller opened_at timestamptz NOT NULL DEFAULT now(), resolved_at timestamptz );

CREATE TABLE trust_events ( id bigserial PRIMARY KEY, user_id uuid NOT NULL REFERENCES users(id), kind text NOT NULL, -- sale_completed|dispute_lost|late_shipment|... weight numeric(4,2) NOT NULL, created_at timestamptz NOT NULL DEFAULT now() ); ```

Decisions i motius:

• `orders.listing_id UNIQUE`: un article de segona mà és una unitat d'estoc; impedir dues comandes simultànies sobre el mateix listing elimina la classe d'error més freqüent dels marketplaces C2C. La reserva es fa amb `UPDATE listings SET status='reserved' WHERE id=$1 AND status='active'` dins la transacció de creació de la comanda.
• `auto_release_at` materialitzat a la fila: permet un job que allibera pagaments amb una sola consulta indexada, sense calcular dates en temps d'execució.
• `trust_score` desnormalitzat a `users` i recalculat per esdeveniments: la pàgina de producte necessita el score del venedor en cada render; recalcular-lo a partir de `trust_events` seria una agregació per petició.
• Cents enters i mai `float`: els errors d'arrodoniment en diners són inacceptables i difícils de detectar després.

API REST versionada (`/v1`), autenticació amb JWT emès per la mateixa aplicació, idempotència obligatòria a les escriptures de pagament.

Endpoints principals:

``` POST /v1/listings crear article (draft) PATCH /v1/listings/{id} editar / publicar GET /v1/search?q=&category=&size=&min=&max=&cursor= POST /v1/orders {listing_id} -> reserva + PaymentIntent POST /v1/orders/{id}/ship {carrier} -> genera etiqueta POST /v1/orders/{id}/confirm comprador confirma recepció -> allibera POST /v1/orders/{id}/dispute {reason} POST /v1/webhooks/psp Stripe: payment_intent.succeeded, transfer.failed POST /v1/webhooks/carrier events de seguiment ```

Integracions externes i per què:

| Integració | Ús | Motiu | |---|---|---| | Stripe Connect | PaymentIntent + transferència al venedor | Escrow sense llicència de diner electrònic; webhooks fiables | | Correos / SEUR API | Generació d'etiquetes i seguiment | L'etiqueta generada per la plataforma és el que fa que l'enviament sigui "integrat" i no una instrucció a l'usuari | | Meilisearch | Índex de cerca | Facetes i tolerància a errors amb cost operatiu baix | | Object storage (S3/R2) | Imatges | No servim imatges des de l'app; CDN al davant |

Flux d'escrow, pas a pas:

1. `POST /v1/orders` reserva el listing i crea un PaymentIntent amb `capture_method: manual` i `transfer_data.destination = seller_account`.
2. Quan arriba `payment_intent.amount_capturable_updated`, capturem i posem l'ordre a `paid`, amb `ship_deadline = now() + 5 dies`.
3. El venedor crida `/ship`; generem l'etiqueta via API del transportista i desem `tracking_code`.
4. El webhook del transportista marca `delivered` i fixa `auto_release_at = now() + 48 h`.
5. O bé el comprador confirma, o bé el job d'alliberament automàtic fa la transferència al venedor. En cas de disputa oberta, l'alliberament es bloqueja.

Idempotència: cada crida a `/orders` porta una `Idempotency-Key`; els webhooks es processen amb una taula `processed_events(event_id)` per evitar doble alliberament.

Ordre deliberat perquè cada fita validi una hipòtesi abans de gastar en la següent:

1. Catàleg i publicació d'anuncis (setmanes 1-4): usuaris, listings, imatges, cerca bàsica. Hipòtesi a validar: hi ha prou oferta perquè un comprador trobi alguna cosa.
2. Comanda amb escrow manual-assistit (setmanes 5-8): Stripe Connect, estats d'ordre, alliberament manual des d'un panell intern. Encara sense etiquetes automàtiques. Hipòtesi: la gent paga dins la plataforma si els diners estan protegits.
3. Etiquetes i seguiment automàtics (setmanes 9-12): integració amb un sol transportista primer. Hipòtesi: l'enviament integrat redueix l'abandonament entre "venc" i "envio".
4. Alliberament automàtic i disputes (setmanes 13-16): job d'auto-release, formulari de disputa