Muroexe

Muroexe consta en el corpus como una startup del sector del marketplace, según la ficha de datos disponible. La fuente periodística consultada la describe como una startup de zapatos o zapatillas. La ubicación de la empresa no consta en los datos facilitados.

No consta en los datos disponibles ninguna información sobre la fecha de fundación, los fundadores ni las circunstancias en que se creó la empresa.

Según El Confidencial, Muroexe se dedicaba al calzado, concretamente a zapatos o zapatillas. La ficha de datos la clasifica dentro del sector del marketplace, lo que sugiere un modelo de venta en línea, pero las fuentes disponibles no detallan el modelo de negocio, los canales de distribución ni el perfil de cliente.

El titular de El Confidencial (8 de noviembre de 2021) indica que la startup "llevó hasta Pedro Sánchez", expresión que la fuente utiliza para subrayar su notoriedad pública. Los datos disponibles no incluyen cifras de facturación, crecimiento, rondas de financiación ni hitos concretos de este periodo.

Según El Confidencial, el 8 de noviembre de 2021 la empresa entró en liquidación. La causa del cierre no consta en los datos verificados ni en la fuente disponible.

No consta en los datos disponibles información sobre la herencia empresarial, la continuidad de la marca, la venta de activos o el impacto del cierre en el sector.

No consta en los datos disponibles la identidad de los fundadores ni su situación actual. Para completar esta información habría que consultar el registro mercantil (BORME y Registro Mercantil) para identificar a los administradores y socios, y hacer seguimiento de fuentes periodísticas posteriores a 2021.

• En un modelo de venta en línea de producto propio (calzado), la notoriedad pública y las apariciones institucionales no garantizan por sí solas la viabilidad financiera; hay que contrastarlas con márgenes, coste de adquisición de cliente y estructura de capital.
• La clasificación sectorial (marketplace) y la actividad real (marca de calzado) pueden divergir; conviene verificar el modelo de negocio antes de sacar conclusiones sobre escalabilidad.
• Cuando la causa del cierre no consta documentada, el análisis debe limitarse a los hechos registrales y periodísticos y evitar atribuir el fracaso a factores no verificados.

Reconstruir Muroexe com una marca de calçat urbà de venda directa (D2C), no com un marketplace. L'essència que es pot preservar és la proposta de sabates amb disseny propi i preu contingut, adreçades a un públic urbà jove.

Cal dir-ho clarament: no consta per què va tancar Muroexe (El Confidencial, 2021-11-08, només informa de l'entrada en liquidació). Per tant, aquesta proposta no pretén corregir una causa coneguda, sinó construir un model diferent amb menys punts de fragilitat estructural.

La diferència clau respecte de l'original: un marketplace necessita escala, dos costats de mercat i inversió sostinguda; una marca D2C pot començar petita, amb estoc limitat i marge controlat. (Proposta, no fet verificat.)

El mercat del calçat urbà i de moda accessibles existeix i és gran, però també molt competitiu. Hi conviuen marques consolidades, marques de distribució massiva i desenes de marques digitals nascudes els darrers anys.

No disposam de dades verificades sobre la quota de mercat que va arribar a tenir Muroexe ni sobre la seva evolució de vendes; aquestes xifres no consten a les fonts disponibles. Qualsevol afirmació sobre la mida del nínxol concret que ocupava seria una estimació a validar.

El que sí que es pot afirmar és que el nínxol de "sabata de disseny a preu mitjà, comprada online" continua existint. La validació real d'aquest mercat s'hauria de fer amb proves de venda abans d'invertir en estoc. (Proposta.)

Model proposat: venda directa al consumidor, catàleg reduït, producció en tandes curtes i marge brut objectiu alt per compensar el cost d'adquisició de client.

• Ingressos: venda online principalment; possibles col·laboracions o edicions limitades com a palanca de marca.
• Costos principals: producció (fabricació externa), logística i devolucions, màrqueting digital, plataforma tècnica.
• Diferencial respecte del marketplace: un sol costat de mercat, control directe de marge i de la relació amb el client.

Totes les ràtios concretes (marge objectiu, cost d'adquisició, taxa de devolució) són estimacions a validar amb pilots reals; no es poden extreure de les fonts disponibles sobre Muroexe.

Fases proposades (proposta, calendari estimat):

1. Fase 0 — Validació (1-2 mesos): definir 2-3 models, fer pre-venda o llista d'espera, mesurar interès real abans de produir.
2. Fase 1 — Pilot (2-3 mesos): primera tanda curta de producció, venda online, mesurar marge real, devolucions i cost d'adquisició.
3. Fase 2 — Consolidació (6-12 mesos): ampliar catàleg només si el pilot compleix objectius de marge i repetició de compra.
4. Fase 3 — Creixement: canals addicionals o col·laboracions, sempre amb estoc controlat.

El criteri de decisió hauria de ser numèric: si el pilot no assoleix els objectius de marge i devolucions, no s'escala.

Xifres estimades i a validar, no dades de Muroexe:

• Disseny i mostres: rang orientatiu de 3.000-8.000 € (estimació).
• Primera producció (tanda curta): rang orientatiu de 15.000-40.000 € segons volum i fabricant (estimació).
• Plataforma de venda i web: 2.000-6.000 € inicial (estimació).
• Màrqueting de llançament: 5.000-15.000 € (estimació).
• Logística i operativa inicial: 3.000-8.000 € (estimació).
• Costos legals i administratius: 1.500-4.000 € (estimació).

Ordre de magnitud total per a un pilot: rang aproximat de 30.000-80.000 €, a validar segons fabricant, volum i país d'operació. Aquestes xifres són una proposta de pressupost, no una reconstrucció comptable de Muroexe.

• Causa de tancament desconeguda: com que no consta per què va tancar Muroexe, no es pot descartar que el risc principal (marge, estoc, finançament o demanda) segueixi present en qualsevol reconstrucció.
• Estoc i tresoreria: una marca de producte físic immobilitza capital; un error de previsió de demanda pot ofegar la caixa.
• Cost d'adquisició de client: en moda digital és habitualment alt; cal validar-lo abans d'escalar.
• Devolucions: el calçat té taxes de retorn significatives; impacta directament el marge.
• Competència: mercat saturat; cal un diferencial clar de producte o marca.
• Risc de "reconstruir per nostalgia": replicar l'estructura anterior sense corregir el que fos que va fallar seria el pitjor escenari.

Lliçons que es poden extreure de l'experiència Muroexe, a partir del que és verificable:

1. Un marketplace és estructuralment més fràgil que una marca D2C per a un projecte petit: necessita escala i inversió sostinguda. La reconstrucció hauria d'evitar aquesta complexitat inicial.
2. La notorietat pública no equival a viabilitat econòmica. Muroexe va tenir visibilitat mediàtica (El Confidencial, 2021-11-08) i tot i així va acabar en liquidació; la marca no substitueix el marge.
3. La informació sobre el tancament és incompleta. Qualsevol equip que vulgui reconstruir el projecte hauria de començar per entendre què va passar realment, no per assumir-ho.
4. El perfil adequat és un equip petit amb experiència en producte físic, control de marge i operacions, disposat a validar amb pilots abans d'invertir en escala — no un equip centrat a replicar l'aparador mediàtic.

En resum: la reconstrucció viable avui és una marca de calçat D2C, petita, validada per fases i amb disciplina de caixa; el llegat de Muroexe és la marca i el nínxol, no l'estructura de marketplace que el va portar a liquidació.

Muroexe era una startup de marketplace de calçat que va entrar en liquidació el novembre de 2021 (El Confidencial, 2021-11-08). La font verificada no indica la causa del tancament, així que aquesta especificació no la diagnostica: descriu un producte que elimina una classe de fallada freqüent en marketplaces de marca pròpia —vendre estoc que encara no existeix o que no es pot reposar— mitjançant lots de producció confirmats i bloqueig de venda.

El problema concret que resol és: un client vol comprar una talla concreta d'un model, i el sistema ha de saber, en el moment del checkout, si aquella unitat pertany a un lot real, en quin estat de producció és i quan es pot enviar. Sense aquesta dada, el marketplace ven promeses i acumula devolucions i cancel·lacions.

Quatre serveis i un bus d'esdeveniments. El motiu de separar-los és que el cicle de vida del producte (temporades, lots) canvia molt més lentament que el del pagament, i barrejar-los obliga a desplegar tot el sistema per un canvi de preu.

``` [Client web/app] | [API Gateway] -- auth JWT, rate limit | +--> catalog-svc (models, variants, talles, preus) +--> inventory-svc (lots, reserves, disponibilitat per talla) +--> order-svc (carret, comanda, estats) +--> payment-svc (PSP, webhooks, refusos) | [Event bus: order.created, lot.confirmed, stock.reserved] | [Read model: disponibilitat per SKU] <-- projecció desnormalitzada ```

Decisions i motius:

• Inventari per lot, no per SKU agregat. Cada unitat venible pertany a un `lot_id` amb estat (`planificat`, `en_producció`, `confirmat`, `disponible`). Motiu: permet bloquejar la venda fins que el lot és confirmat i traça quina producció respon a quina comanda.
• Reserva amb TTL al checkout. En crear la comanda es reserva la unitat 15 minuts; si el pagament no es completa, s'allibera per esdeveniment. Motiu: evita sobrevenda sense necessitat de bloquejos de base de dades llargs.
• Read model de disponibilitat. Projecció desnormalitzada actualitzada per events. Motiu: la consulta de catàleg és la ruta calenta i no ha de fer joins contra lots.
• Idempotència a pagament i comanda. Claus d'idempotència a les crides i als consumidors d'events. Motiu: els webhooks del PSP es repeteixen.

Esquema relacional (PostgreSQL) per a l'escriptura; el read model pot ser la mateixa base amb taules de projecció o Redis.

```sql -- Catàleg producte(id, nom, temporada, actiu) variant(id, producte_id, color, referencia) -- p.ex. "Runner Blau" talla(id, variant_id, valor) -- 36..47 preu(variant_id, import_centims, moneda, vigent_des)

-- Producció i estoc lot(id, variant_id, quantitat, estat, data_confirmacio) -- estat: planificat | en_produccio | confirmat | cancel·lat unitat_estoc(id, lot_id, talla_id, estat) -- estat: disponible | reservada | venuda | retornada reserva(id, unitat_estoc_id, comanda_id, expira_a)

-- Comandes comanda(id, client_id, estat, total_centims, creat_a) -- estat: creada | pagada | preparacio | enviada | cancel·lada linia_comanda(id, comanda_id, variant_id, talla_id, unitat_estoc_id, preu_centims) pagament(id, comanda_id, psp_ref, estat, import_centims, idempotency_key UNIQUE) ```

Restricció clau: `UNIQUE(unitat_estoc_id)` a `linia_comanda` perquè una unitat física no es vengui dues vegades. La disponibilitat mostrada al catàleg és `COUNT(unitat_estoc WHERE estat='disponible' AND lot.estat='confirmat')` per talla.

REST per al client, esdeveniments interns per a la coherència.

``` GET /v1/products/{id} -> variants, talles, disponibilitat POST /v1/orders -> crea comanda + reserves (Idempotency-Key) GET /v1/orders/{id} POST /v1/payments/intent -> crea intenció al PSP POST /v1/webhooks/psp -> confirma/refusa pagament (idempotent) POST /internal/lots/{id}/confirm -> admin: lot passa a confirmat ```

Integracions:

• PSP (Stripe o equivalent) per targeta; webhook signat i verificació de signatura. Motiu: no gestionar dades de targeta.
• Transportista per generar etiquetes quan la comanda passa a `preparacio`; integració per API amb reintents.
• ERP/producció (o un simple panell intern) que confirma lots; en la primera versió pot ser una pantalla d'admin, no una integració.

Contracte d'event (exemple): ```json { "type": "stock.reserved", "order_id": "...", "unit_ids": ["..."], "expires_at": "..." } ```

Ordre estricte, cada pas desbloqueja el següent:

1. Catàleg + disponibilitat per lot (catalog-svc, inventory-svc, read model). Sense això no hi ha res a vendre de manera honesta.
2. Comanda amb reserves TTL i alliberament per event. És el nucli que evita la sobrevenda.
3. Pagament amb PSP i webhook idempotent. Tanca el cicle de compra.
4. Panell intern de lots (confirmar/cancel·lar producció). Permet operar sense ERP.
5. Etiquetes de transport. Es pot fer manualment les primeres setmanes.

No construir encara: multi-vendor, ressenyes, programa de punts, app mòbil nativa. Motiu: cap d'aquests elements valida la hipòtesi central (vendre només estoc confirmat).

• Volum inicial: 5.000–20.000 SKU-talla actius, pics de 200 comandes/hora en llançament. Un sol PostgreSQL amb rèpliques de lectura n'hi ha prou; no cal microserveis realment distribuïts, però sí límits clars entre mòduls.
• Risc: reserves òrfenes. Si l'event d'alliberament es perd, unitats queden reservades per sempre. Mitigació: job de reconciliació que expira reserves vençudes cada minut.
• Risc: webhook duplicat o fora d'ordre. Mitigació: clau d'idempotència i màquina d'estats de comanda que ignora transicions invàlides.
• Risc: read model desincronitzat. Mitigació: reconstrucció de la projecció des de l'log d'events i alerta si el lag supera 30 s.
• Risc de producte: si la producció no confirma lots a temps, el catàleg apareix buit i es perd conversió. És un risc operatiu, no tècnic, i s'ha de mesurar amb mètriques de cobertura d'estoc.

• Test de sobrevenda: dues comandes concurrents sobre l'última unitat d'una talla; exactament una ha de reeixir. Test d'integració amb càrrega (k6, 200 usuaris concurrents).
• Test d'idempotència: reenviar el mateix webhook 10 vegades; l'estat de la comanda no canvia després del primer.
• Test de reserva expirada: crear comanda, no pagar, esperar el TTL; la unitat torna a `disponible` i el read model ho reflecteix en menys de 60 s.
• Criteri d'acceptació funcional: cap comanda pot existir amb una línia que referenciï una unitat d'un lot no `confirmat`.
• Mètrica d'èxit inicial: 0 comandes cancel·lades per manca d'estoc en 30 dies de funcionament, i lag de projecció < 30 s el 99% del temps.