Drinks&Co

Drinks&Co era un marketplace del sector de las bebidas, según la información disponible. La fuente periodística que recoge su cierre, Ecommerce News (8 de mayo de 2023), la identifica como "la antigua Uvinum", es decir, como la continuación de la plataforma Uvinum.

Los datos disponibles no permiten precisar la ubicación de la empresa ni su forma jurídica concreta más allá de la denominación Drinks&Co.

La información disponible no permite reconstruir la historia de la fundación de Drinks&Co. El único dato relevante es que Ecommerce News la describe como la antigua Uvinum, lo que indica una continuidad entre ambas plataformas, pero los datos no detallan cómo se produjo esa transición ni en qué fecha.

Según la clasificación sectorial disponible, Drinks&Co operaba como marketplace, es decir, como plataforma intermediaria de compraventa en línea. El sector asignado es el de las bebidas, en coherencia con la herencia de Uvinum, plataforma de venta de vino.

Los datos no permiten detallar el catálogo, los clientes ni el modelo de negocio concreto más allá de esta caracterización general.

No consta información sobre la evolución del negocio, la facturación, el crecimiento o los hitos de Drinks&Co en ningún momento de su trayectoria. Los datos disponibles no permiten afirmar nada sobre este periodo.

El cierre consta documentado el 8 de mayo de 2023, fecha en que Ecommerce News publica la noticia "Cierra Drinks&Co, la antigua Uvinum". La causa del cierre no consta en los datos verificados disponibles y, por tanto, no se puede atribuir a ningún factor concreto.

El dato más relevante es la continuidad respecto a Uvinum: según Ecommerce News, Drinks&Co era la antigua Uvinum, de modo que el cierre de 2023 afecta a la plataforma que había sucedido a aquella marca. Los datos disponibles no permiten valorar qué se ha conservado, si hubo adquisición de activos o si la marca o la tecnología tuvieron continuidad por otra vía.

Los datos disponibles no identifican a los fundadores de Drinks&Co ni su paradero actual. No consta ningún rastro sobre las personas que impulsaron el proyecto. Para completar esta información habría que consultar el registro mercantil correspondiente, las notas de prensa de la transición desde Uvinum y las fuentes sectoriales especializadas en comercio electrónico.

• En un marketplace de bebidas, la marca y la base de clientes heredadas de una plataforma anterior (aquí, Uvinum) son el activo principal, pero también un lastre: si el proyecto sucesor no consigue diferenciarse, el cierre arrastra la percepción de continuidad fallida.
• La fecha del cierre (mayo de 2023) se sitúa en un contexto de consolidación del comercio electrónico tras el pico de la pandemia; para un marketplace vertical de bebidas, esto implica competir con operadores generalistas y con márgenes de logística muy ajustados.
• La falta de datos públicos sobre la causa del cierre recuerda la importancia, para quien analiza el sector, de documentar las operaciones societarias (cambios de marca, transmisiones de activos) en el momento en que se producen, porque después no siempre quedan trazadas.

La font verificada [Ecommerce News, 2023-05-08] només permet afirmar que Drinks&Co —hereva d'Uvinum— va tancar el 2023. No hi ha dada verificada sobre causa, mida, catàleg, clients ni tecnologia. Així que la "idea, avui" és una proposta nova inspirada en l'essència d'un marketplace de vi i begudes:

• Un marketplace especialitzat en vi, cervesa artesana i destil·lats, on cellers i distribuïdors independentment petits venen directament al consumidor.
• Diferenciació per curadoria i descobriment (seleccions, guies, maridatges), no per preu pur.
• Model sense estoc propi: la plataforma connecta oferta i demanda i cobra comissió o subscripció.

Això és una proposta, no una reconstrucció fidel: no tenim dades per saber com operava Drinks&Co.

No disposem de dades verificades sobre el mercat que atenia Drinks&Co. El que sí que és raonable afirmar com a context general (a validar amb dades pròpies):

• El comerç electrònic de vi i begudes existeix i és competitiu, amb grans operadors i marketplaces generalistes.
• Hi ha espai per a nínxols: vins de petites denominacions, cervesa artesana, producte local.
• La venda d'alcohol en línia té restriccions legals per país (edat, llicències, enviaments), cosa que condiciona el mercat adreçable.

Qualsevol xifra de mercat caldria validar-la amb fonts sectorials abans de decidir; aquí no n'inventem cap.

Proposta (a validar):

• Comissió per transacció sobre les vendes dels cellers (rang orientatiu a estudiar: 8–15%, estimació).
• Subscripció per a cellers per tenir botiga i visibilitat (rang orientatiu: 30–100 €/mes, estimació).
• Ingressos de màrqueting i curadoria (seleccions patrocinades, contingut, caixes temàtiques).
• Logística: inicialment a càrrec del celler; la plataforma només facilita etiquetes i seguiment.

El model lleuger (sense estoc) redueix capital i risc, però trasllada complexitat a la logística i a la confiança del comprador.

Proposta per fases:

1. Fase 0 – Validació (1–2 mesos): entrevistes amb 20–30 cellers i compradors, verificació legal per país, definició de nínxol.
2. Fase 1 – MVP (2–3 mesos): marketplace amb 20–50 cellers, pagaments, enviaments, atenció bàsica.
3. Fase 2 – Tracció (3–6 mesos): contingut i curadoria, primeres campanyes, mètriques de repetició.
4. Fase 3 – Escala: ampliació de categories i geografies, si les unit economics ho permeten.

Cada fase hauria de tenir criteris de continuïtat clars (per exemple, taxa de recompra i marge per comanda, llindars a definir).

Estimació orientativa, a validar (no són dades de Drinks&Co):

• Tecnologia (marketplace, pagaments, integracions): 15.000–40.000 € (rang de, segons build vs. plataforma existent).
• Legal i compliance (llicències, termes, protecció de dades, normativa d'alcohol): 5.000–15.000 €.
• Màrqueting de llançament: 5.000–15.000 €.
• Operacions i equip mínim (6 mesos): 30.000–60.000 €.
• Total d'arrencada estimat: 55.000–130.000 € (rang de, a validar).

Són xifres de planificació, no costos reals de cap empresa.

• Regulació de l'alcohol: llicències, edat, enviaments transfronterers; pot limitar mercats sencers.
• Confiança i logística: el vi és fràgil i sensible a la temperatura; devolucions i incidències encareixen.
• Competència: grans operadors i marketplaces generalistes amb més tràfic.
• Dependència dels cellers: si els proveïdors clau marxen, el catàleg s'ensorra.
• Manca de dades històriques: no sabem per què va tancar Drinks&Co; replicar l'essència sense entendre el fracàs és arriscat.

Lliçons que es desprenen de l'evidència disponible (i del que no en sabem):

• Cal entendre primer per què va tancar Drinks&Co. La font només confirma el tancament; sense causa verificada, qualsevol reconstrucció és especulativa i ha de començar per una due diligence del cas.
• No replicar a cegues. L'essència (marketplace especialitzat de begudes) es pot repensar, però el model concret ha de néixer de validació real, no d'imitació.
• Prioritzar el model lleuger i el nínxol abans d'escalar, per reduir capital exposat.
• Tractar la regulació com a requisit de disseny, no com a tràmit posterior.
• Ho hauria de liderar un equip amb experiència en marketplace/ecommerce i en el sector de begudes, capaç de validar legal, logística i unit economics abans de comprometre inversió.

Nota: aquest informe no conté dades verificades sobre l'operació de Drinks&Co més enllà del seu tancament el 2023 [Ecommerce News, 2023-05-08]; totes les xifres i el model són propostes i estimacions a validar.

Drinks&Co va operar com a marketplace de vins i begudes (hereva d'Uvinum) fins al tancament el 8 de maig de 2023 [Ecommerce News, 2023-05-08]. La font disponible no documenta la causa del tancament, de manera que aquesta especificació no l'atribueix a cap motiu concret: parteix del problema estructural típic d'un marketplace de begudes, que és la combinació de marge baix per ampolla, logística fràgil (vidre, pes, temperatura) i catàleg atomitzat entre molts productors petits.

El producte que es descriu resol tres coses concretes: (1) publicar catàleg de molts venedors sense que l'equip central hagi de tocar cada fitxa, (2) permetre una cistella amb productes de diversos venedors amb un sol pagament, i (3) liquidar els diners a cada venedor de forma automàtica i auditable. La premissa de disseny és que l'operador no ha de gestionar estoc propi ni magatzem central: només federació de catàleg, comanda i pagament.

Arquitectura de microserveis petits al voltant d'un nucli de comandes, amb esdeveniments com a contracte entre serveis. El motiu és que el catàleg i la liquidació tenen cicles de vida molt diferents (el catàleg canvia cada dia, la liquidació és setmanal) i no convé acoblar-los en una sola base de dades.

``` [Venedor] --API--> catalog-service --(events)--> search-index | [Comprador] --API--> cart-service --> order-service --(events)--> payment-service | | +--(events)--> fulfillment-service | | +--(events)--> ledger-service <--+ | payout-service (batch setmanal) ```

• catalog-service: rep productes per API o feed CSV/XML del venedor. Valida, normalitza i publica esdeveniments `product.upserted`.
• search-index: índex de cerca (OpenSearch) alimentat per esdeveniments. Motiu: les consultes de catàleg són de lectura massiva i no han de tocar la base transaccional.
• cart-service: cistella sense estat persistent fort; es guarda en Redis amb TTL de 30 dies. Motiu: una cistella no és una transacció i no ha de competir per connexions amb la base de comandes.
• order-service: desa la comanda com a agregat immutable amb línies per venedor. Motiu: una comanda multi-vendedor s'ha de poder dividir en subcomandes sense duplicar dades.
• payment-service: cobrament amb Stripe Connect (o equivalent amb suport de destination charges). Motiu: el repartiment a venedors és el punt on un marketplace casolà falla; delegar-lo a un PSP amb compte connectat elimina conciliació manual.
• ledger-service: llibre de doble entrada de cada moviment (càrrec al comprador, comissió, deute al venedor). Motiu: la liquidació ha de ser auditable i reproduïble; un simple camp `amount_owed` no ho és.
• payout-service: procés batch setmanal que llegeix el ledger i executa transferències. Motiu: separar el càlcul (ledger) de l'execució (payout) permet reintents sense duplicar pagaments.

Entitats principals (PostgreSQL, una base per servei; les claus foranes entre serveis no existeixen, es referencia per ID i esdeveniment):

``` vendor(id, legal_name, tax_id, status, stripe_account_id, created_at) product(id, vendor_id, sku, title, vintage, volume_ml, abv, price_cents, currency, stock_qty, status, updated_at) product_feed_run(id, vendor_id, started_at, finished_at, rows_ok, rows_error) order(id, buyer_id, status, total_cents, currency, created_at) order_line(id, order_id, vendor_id, product_id, qty, unit_price_cents, subtotal_cents) suborder(id, order_id, vendor_id, status, shipping_cents, commission_cents) payment(id, order_id, psp_ref, status, captured_cents, created_at) ledger_entry(id, account, debit_cents, credit_cents, ref_type, ref_id, created_at) payout(id, vendor_id, period_start, period_end, amount_cents, status, executed_at) ```

Decisions i motius:

• Preus en cèntims i moneda explícita: evita arrodoniments binaris i permet afegir mercats.
• `suborder` com a unitat de treball: cada venedor envia i factura per separat; l'estat de la comanda del comprador és una funció dels estats de les subcomandes.
• `ledger_entry` immutable: només s'insereixen files, mai s'actualitzen; les correccions són entrades compensatòries. Motiu: auditoria i reproducció de liquidacions.
• `product_feed_run`: registra cada importació de catàleg per venedor, de manera que un feed trencat es detecta i s'atura sense esborrar el catàleg anterior.

API REST versionada (`/v1`) amb autenticació per token per a venedors i OAuth per a compradors.

• `POST /v1/vendors/{id}/feed` — puja un feed CSV/XML; retorna `feed_run_id`.
• `GET /v1/vendors/{id}/feed/{run_id}` — estat i errors per fila.
• `GET /v1/products?q=&vintage=&region=&page=` — cerca al índex.
• `POST /v1/cart/items` / `DELETE /v1/cart/items/{line}` — cistella.
• `POST /v1/orders` — crea comanda a partir de la cistella; retorna `order_id` i `client_secret` de pagament.
• `POST /v1/webhooks/psp` — webhook del PSP per confirmar captura i transferència.
• `GET /v1/vendors/{id}/payouts` — historial de liquidacions.

Integracions:

• PSP amb comptes connectats (Stripe Connect o Adyen for Platforms): el càrrec es fa al comprador i la part del venedor es transfereix al seu compte connectat. Motiu: elimina la necessitat de custòdia de fons i de conciliació manual.
• Transportistes: integració per API de tarifes i etiquetes (per exemple, Sendcloud o similar) a nivell de `suborder`. Motiu: cada venedor pot tenir el seu transportista; l'operador no ha de negociar volum central.
• Facturació: generació de factura per `suborder` amb les dades fiscals del venedor.

1. catalog-service + feed de venedor: sense catàleg federat no hi ha marketplace. És el mínim per incorporar els primers 10 venedors.
2. order-service + payment-service amb destination charges: el flux de compra amb un sol pagament i repartiment automàtic és el nucli del valor.
3. ledger-service: encara que sigui amb una taula i un job, ha d'existir des del primer euro cobrat; retroactivament és impossible de reconstruir.
4. search-index: es pot començar amb consultes SQL i migrar a OpenSearch quan el catàleg superi unes desenes de milers de productes.

El que no s'ha de construir primer: panell d'analítica avançat, ressenyes, recomanacions, app mòbil nativa. Cap d'aquests elements resol el problema de catàleg ni de liquidació.

• Volum inicial assumit: 50 venedors, 20.000 productes, 500 comandes/dia. Aquesta escala no justifica microserveis per si sola; el motiu de separar serveis és organitzatiu (equips i cicles de desplegament), no de càrrega.
• Risc: feeds de venedor trencats. Mitigació: validació per fila, `feed_run` amb errors, i no esborrar mai el catàleg anterior fins que el nou feed superi la validació.
• Risc: doble pagament en reintents de payout. Mitigació: clau d'idempotència per `(vendor_id, period_start, period_end)` i estat `executed` al ledger.
• Risc: comandes multi-vendedor amb un venedor que no envia. Mitigació: `suborder` amb estat independent i política de reemborsament parcial per subcomanda.
• Risc: logística de vidre i temperatura. No es resol amb programari; la decisió és no gestionar estoc propi i deixar l'enviament al venedor, amb el cost que això té en experiència de compra.
• Risc: compliment fiscal multi-jurisdicció. Mitigació: facturació per venedor i no per operador; l'operador només factura la comissió.

• Test d'integració del flux complet: feed → catàleg → cistella → comanda multi-vendedor → pagament → ledger → payout, amb un PSP en mode test. Criteri d'èxit: el ledger quadra a zero (suma de dèbits = suma de crèdits) després de cada comanda.
• Test d'idempotència: repetir el webhook del PSP i el job de payout; el resultat ha de ser idèntic i no ha de generar transferències duplicades.
• Test de feed trencat: pujar un feed amb files invàlides; el catàleg anterior ha de romandre intacte i `feed_run` ha de reportar els errors per fila.
• Mètrica operativa: nombre de comandes que requereixen intervenció manual per cada 1.000. Objectiu inicial: menys de 5.
• Mètrica de cost: cost de PSP i de desplegament per comanda; ha de ser conegut i traçable abans d'escalar el nombre de venedors.