Drinks&Co

Drinks&Co era un marketplace del sector de les begudes, segons la informació disponible. La font periodística que en recull el tancament, Ecommerce News (8 de maig de 2023), la identifica com "la antigua Uvinum", és a dir, com la continuació de la plataforma Uvinum.

Les dades disponibles no permeten precisar la ubicació de l'empresa ni la seva forma jurídica concreta més enllà de la denominació Drinks&Co.

La informació disponible no permet reconstruir la història de la fundació de Drinks&Co. L'única dada rellevant és que Ecommerce News la descriu com l'antiga Uvinum, cosa que indica una continuïtat entre totes dues plataformes, però les dades no detallen com es va produir aquesta transició ni en quina data.

Segons la classificació sectorial disponible, Drinks&Co operava com a marketplace, és a dir, com a plataforma intermediària de compravenda en línia. El sector assignat és el de les begudes, en coherència amb l'herència d'Uvinum, plataforma de venda de vi.

Les dades no permeten detallar el catàleg, els clients ni el model de negoci concret més enllà d'aquesta caracterització general.

No consta informació sobre l'evolució del negoci, la facturació, el creixement o les fites de Drinks&Co en cap moment de la seva trajectòria. Les dades disponibles no permeten afirmar res sobre aquest període.

El tancament consta documentat el 8 de maig de 2023, data en què Ecommerce News publica la notícia "Cierra Drinks&Co, la antigua Uvinum". La causa del tancament no consta a les dades verificades disponibles, i per tant no es pot atribuir a cap factor concret.

La dada més rellevant és la continuïtat respecte d'Uvinum: segons Ecommerce News, Drinks&Co era l'antiga Uvinum, de manera que el tancament del 2023 afecta la plataforma que havia succeït aquella marca. Les dades disponibles no permeten valorar què se n'ha conservat, si hi va haver adquisició de actius o si la marca o la tecnologia van tenir continuïtat per una altra via.

Les dades disponibles no identifiquen els fundadors de Drinks&Co ni el seu parador actual. No consta cap traça sobre les persones que van impulsar el projecte. Per completar aquesta informació caldria consultar el registre mercantil corresponent, les notes de premsa de la transició des d'Uvinum i les fonts sectorials especialitzades en comerç electrònic.

• En un marketplace de begudes, la marca i la base de clients heretades d'una plataforma anterior (aquí, Uvinum) són l'actiu principal, però també un llast: si el projecte successor no aconsegueix diferenciar-se'n, el tancament arrossega la percepció de continuïtat fallida.
• La data del tancament (maig de 2023) se situa en un context de consolidació del comerç electrònic després del pic de la pandèmia; per a un marketplace vertical de begudes, això implica competir amb operadors generalistes i amb marges de logística molt ajustats.
• La manca de dades públiques sobre la causa del tancament recorda la importància, per a qui analitza el sector, de documentar les operacions societàries (canvis de marca, transmissions d'actius) en el moment en què es produeixen, perquè després no sempre queden traçades.

Reconstruir l'essència de Drinks&Co —un marketplace especialitzat en vi i begudes amb catàleg ampli i accés a cellers i distribuïdors— però adaptat al context actual: menys "marketplace pur" i més "plataforma de descoberta i compra recorrent". La font verificada [Ecommerce News, 2023-05-08] confirma el tancament i l'herència d'Uvinum, però no la causa; per tant, la proposta no pot basar-se a corregir un error concret, sinó a dissenyar un model més resilient.

La proposta (a validar): un marketplace vertical de vi, cervesa artesana i destil·lats, amb tres capes: (1) catàleg agregat de cellers petits i mitjans, (2) subscripció de descoberta mensual, i (3) logística agregada per evitar que cada celler gestioni enviaments. L'essència es manté: ser el punt de trobada entre productors de begudes i consumidor final.

El mercat del vi i les begudes especialitzades en línia existeix i és competitiu: grans operadors, cellers amb botiga pròpia i marketplaces generalistes. La dada verificada és que Drinks&Co va operar-hi fins al 2023 [Ecommerce News, 2023-05-08], cosa que indica que hi havia mercat suficient per sostenir una operació durant anys, però no que el model fos rendible.

El nínxol on una reconstrucció té més sentit (proposta, a validar): cellers petits i mitjans que no poden assumir logística ni màrqueting digital propi, i consumidors que volen descobrir productes que no troben al supermercat. Aquest segment és on un marketplace afegeix valor real enfront d'una botiga pròpia.

Proposta de model, amb estimacions a validar:

• Comissió per transacció sobre vendes de cellers: rang estimat del 12–20% (a validar segons marge del producte).
• Subscripció de descoberta (caixa mensual de vi/begudes): preu estimat de 25–45 €/mes, amb marge estimat del 20–30% (a validar).
• Serveis a cellers: fitxes de producte, fotografia, contingut i gestió de campanyes, com a ingressos addicionals (preu a definir).
• Logística: o bé agregada amb operador extern, o bé cobrada al client; no s'hauria d'assumir com a cost fix des del dia u.

La lliçó implícita (no verificada): un marketplace de begudes tendeix a patir per marges baixos i cost logístic alt; per això la proposta prioritza subscripció i serveis, que tenen marge més estable que la comissió pura.

Fase 0 (mesos 0–2): validació. Entrevistes amb 20–30 cellers i 100–200 consumidors objectiu; definir 3–5 categories inicials i un catàleg pilot de 100–200 referències (estimació). Cost estimat: 3.000–8.000 € (a validar).

Fase 1 (mesos 2–6): llançament en una sola regió o ciutat, amb 10–20 cellers socis i subscripció en beta tancada. Objectiu estimat: 200–500 subscriptors i 50–100 comandes/mes (a validar).

Fase 2 (mesos 6–12): ampliació de catàleg, automatització de logística i obertura de la subscripció al públic. Mètrica clau: repetició de compra i marge per comanda, no volum.

Fase 3 (mes 12+): expansió geogràfica només si la unitat econòmica per comanda és positiva.

Totes les xifres són estimacions a validar, no dades de Drinks&Co:

• Desenvolupament de plataforma (MVP): 15.000–40.000 € segons si es fa a mida o amb solucions existents.
• Màrqueting i adquisició inicial: 10.000–25.000 € per als primers 6–12 mesos.
• Operacions i equip mínim (2–4 persones): 60.000–120.000 € anuals, estimació.
• Logística i emmagatzematge inicial: 5.000–15.000 € (si s'externalitza, variable).
• Total orientatiu per al primer any: rang estimat de 90.000–200.000 €, a validar segons abast i regió.

• Marge baix i cost logístic alt: risc estructural dels marketplaces de begudes; la subscripció i els serveis han de compensar-lo.
• Competència de cellers directes i grans operadors: cal un nínxol clar (producte petit i de descoberta).
• Manca d'informació verificada sobre la causa del tancament de Drinks&Co: no es pot descartar que fos per pressió de marge, competència o finançament; caldrà validar-ho amb fonts addicionals abans d'invertir.
• Risc regulatori en venda d'alcohol en línia: normativa variable per territori (a validar per mercat).
• Risc de dependència de pocs cellers o de pocs subscriptors en la fase inicial.

Lliçons que es poden extreure de l'original (amb la cautela que la causa del tancament no consta): un marketplace de begudes necessita un nínxol clar, un model d'ingressos amb marge estable i una logística que no ofegui la unitat econòmica. Per tant, ho hauria de liderar un equip amb experiència en comerç electrònic de producte especialitzat, capacitat de negociació amb cellers i disciplina financera per mesurar marge per comanda des del primer dia —no un equip centrat només en créixer en volum. La reconstrucció hauria de començar petita, validar la repetició de compra i ampliar només quan la unitat econòmica sigui positiva.

Un marketplace de vins i destil·lats té tres friccions estructurals: catàlegs de proveïdor heterogenis (CSV, API, ERP propi), estocs que canvien més ràpid del que es pot sincronitzar, i comandes que han de consolidar-se en un o pocs enviaments per no destruir el marge amb logística fragmentada. Drinks&Co va operar com a marketplace de begudes fins al tancament el 2023 [Ecommerce News, 2023-05-08]; la causa del tancament no consta al registre, de manera que aquesta especificació no l'atribueix a cap factor concret i tracta els tres problemes com a requisits de disseny, no com a diagnòstic del fracàs.

El problema concret que es resol: donar al comprador una disponibilitat i un preu que siguin certs en el moment de pagar, i donar al proveïdor una via d'integració de baix cost (un fitxer o un webhook) sense obligar-lo a canviar d'ERP.

Quatre serveis, cadascun amb una responsabilitat i un motiu:

1. Catalog Ingestor — rep catàlegs de proveïdor en CSV/JSON o via API pull, els normalitza a un model comú (producte, anyada, format, ampolla/caixa, IVA) i publica `catalog.product.upserted`. Motiu: els proveïdors no canviaran el seu format; la normalització ha de ser un servei aïllat i versionat per proveïdor, no lògica dins del web.
2. Availability Service — manté estoc i preu per `(proveïdor, SKU)` amb TTL, i respon consultes de disponibilitat en menys de 150 ms. Motiu: és el punt de lectura calent; separar-lo del catàleg permet escalar-lo i cachejar-lo sense tocar la ingesta.
3. Order Orchestrator — màquina d'estats de comanda, reserva d'estoc, split per proveïdor i consolidació d'enviament. Motiu: la comanda és l'única cosa que ha de ser exacta; ha de ser un servei transaccional amb outbox, no un flux d'esdeveniments sense garanties.
4. Settlement & Payouts — càlcul de comissions, liquidacions i factures per proveïdor. Motiu: sense liquidació automàtica el marketplace no escala més enllà de la confiança manual.

Flux d'una comanda, descrit en text:

``` Comprador → API Gateway → Order Orchestrator Order Orchestrator → Availability Service (reserva TTL 15 min) Order Orchestrator → outbox: order.created Worker → proveïdor (comanda) → outbox: order.confirmed | order.rejected Order Orchestrator → Settlement (comissió) → Payouts (setmanal) ```

Comunicació: HTTP síncrona per a reserves i consultes; esdeveniments (Kafka o SQS+SNS) per a canvis de catàleg i estats de comanda. Motiu: la reserva necessita resposta immediata; el catàleg no.

Entitats principals (PostgreSQL, esquema per domini):

• `supplier(id, name, integration_type, api_credentials_ref, active)`
• `product(id, canonical_name, category, vintage, volume_ml, abv, gtin, attributes jsonb)` — el producte canònic, compartit entre proveïdors.
• `supplier_offer(id, supplier_id, product_id, supplier_sku, price_cents, currency, stock_qty, stock_updated_at, ttl_seconds)` — l'oferta concreta; clau única `(supplier_id, supplier_sku)`.
• `order(id, buyer_id, status, total_cents, currency, created_at)` amb `status ∈ {draft, reserved, confirmed, partially_confirmed, shipped, cancelled}`.
• `order_line(id, order_id, supplier_offer_id, qty, unit_price_cents, status)` — el split per proveïdor viu aquí.
• `reservation(id, order_line_id, qty, expires_at)` — la reserva temporal que evita sobrevenda.
• `shipment(id, order_id, supplier_id, carrier, tracking_ref, status)`.
• `payout(id, supplier_id, period_start, period_end, gross_cents, commission_cents, net_cents, status)`.

Decisions: preus en cèntims enters (evita errors d'arrodoniment); `attributes jsonb` per a trets variables del vi (DO, varietat, criança) sense migracions per cada camp; `stock_updated_at` + `ttl_seconds` perquè la disponibilitat caduqui explícitament en lloc de mentir.

API pública (REST, versionada `/v1`):

• `GET /products?q=&category=&vintage=` — cerca sobre catàleg canònic.
• `GET /products/{id}/offers` — ofertes amb disponibilitat i preu; retorna `stale: true` si l'estoc ha superat el TTL.
• `POST /orders` — cos amb línies `{supplier_offer_id, qty}`; retorna `order_id` i `reservations[].expires_at`.
• `POST /orders/{id}/confirm` — confirma i dispara el split.
• `GET /orders/{id}` — estat i enviaments.

API de proveïdor:

• `POST /supplier/catalog` — pujada CSV (multipart) o JSON; resposta amb `accepted`, `rejected[]` i motiu per línia.
• `POST /supplier/stock` — actualització incremental d'estoc/preu; idempotent per `Idempotency-Key`.
• Webhook de sortida `order.created` cap al proveïdor, amb reintents exponencials i dead-letter queue.

Integracions: passarel·la de pagament (Stripe o Adyen) amb captura diferida fins a `confirmed`; transportistes via API d'etiquetes; facturació electrònica per proveïdor. Motiu de la captura diferida: si un proveïdor rebutja la línia, no s'ha de cobrar ni retornar.

1. Catalog Ingestor + model canònic amb dos proveïdors reals i un CSV de referència. És el primer perquè sense catàleg fiable no hi ha marketplace, i perquè valida el cost real d'integració per proveïdor.
2. Availability Service amb TTL i reserves. És el segon perquè és la promesa central al comprador: preu i estoc certs.
3. Order Orchestrator amb split i outbox, encara que el pagament sigui manual en aquesta fase.
4. La resta (settlement, webhooks de proveïdor, cerca) després de validar el cicle complet amb un proveïdor.

• Volum inicial: 50 proveïdors, 200k ofertes, 5k comandes/mes. Amb aquest ordre de magnitud, PostgreSQL + Redis per a disponibilitat és suficient; no cal cercador dedicat fins a ~1M de productes.
• Risc: estoc mentider. Mitigació: TTL explícit, camp `stale`, i reserva amb expiració; el comprador veu disponibilitat marcada com a verificada o estimada.
• Risc: latència d'integració de proveïdor. Mitigació: CSV com a via de primera classe, no com a pedaç; validació per línia amb errors accionables.
• Risc: sobrevenda en pics. Mitigació: reserva atòmica a la base de dades (`UPDATE ... WHERE stock_qty >= qty`), no a la cache.
• Risc: complexitat de settlement. Mitigació: comissió única per proveïdor en la v1; escales i promocions més endavant.

• Test de contracte d'ingestió: cada format de proveïdor té un fixture CSV i un resultat esperat; el CI falla si canvia el nombre d'acceptats/rebutjats.
• Test de sobrevenda: 100 reserves concurrents sobre estoc 10; el test exigeix exactament 10 èxits i 90 errors `out_of_stock`.
• Test de TTL: una oferta sense actualització durant el TTL es marca `stale` i no es pot reservar sense confirmació del proveïdor.
• Test de split: una comanda amb 3 proveïdors genera 3 línies de proveïdor, 1..3 enviaments i cap càrrec fins a `confirmed`.
• Criteri d'acceptació del primer lliurable: dos proveïdors reals ingestats, disponibilitat consultable en <150 ms p95, i una comanda de prova completada de punta a punta amb pagament en mode test.