Bimba y Lola

Según la ficha registral de OpenMercantil (BORME), BIMBA Y LOLA STUDIO SOCIEDAD LIMITADA es una sociedad limitada constituida en el año 2025 con domicilio en Barcelona. El estado registral que consta es "activa".

El corpus facilitado no describe el objeto social ni la actividad efectiva de la sociedad. La clasificación recibida la identifica como "startup" y sector "Otros", pero esta etiqueta no proviene de ninguna de las fuentes citadas y, por tanto, no se puede confirmar documentalmente.

La fecha de constitución que consta es 2025. El corpus no incluye la escritura de constitución, el capital social inicial ni los socios fundadores originarios.

Lo que sí consta en el BORME es la composición del consejo de administración en los primeros meses de vida de la sociedad y los cambios posteriores:

• El 10 de marzo de 2025 consta el cese como consejero de CASTELLANO RIOS JOSE MARIA, junto con reelecciones de varios consejeros (DOMINGUEZ FERNANDEZ JESUS, MARTINEZ ALBACETE FERNANDO, MARTINEZ GUTIERREZ JOSE MANUEL y TRUJILLO PARRA CR[ISTINA], según el texto truncado del acta).
• El 15 de diciembre de 2025 consta el cese como consejera de TRUJILLO PARRA CRISTINA.
• El 29 de enero de 2026 consta el nombramiento como consejero de SOLER DUFFO CARLOS.
• El 6 de marzo de 2026 consta el nombramiento como consejera de GAMERO DEL CASTILLO CALLEJA NATALIA.

Estos datos provienen de los actos publicados en el BORME y recogidos en la ficha de OpenMercantil.

No consta. El corpus facilitado no contiene ninguna descripción de la actividad, de los productos o servicios, de los clientes ni de los mercados de la sociedad. Tampoco consta ninguna fuente periodística que lo describa.

No consta. La sociedad se constituyó en 2025 y el corpus no incluye datos financieros, comerciales ni de crecimiento de ningún ejercicio. No se puede afirmar nada sobre resultados, facturación o expansión.

No consta ningún cierre. Según el registro, la sociedad consta como activa en la fecha de la ficha consultada (2026-03-06). Los actos recogidos son nombramientos y ceses de consejeros, no una disolución ni un concurso.

No consta. El corpus no documenta ningún cierre, venta, fusión ni transformación de la sociedad, de modo que no se puede describir ningún legado empresarial o industrial.

El corpus no identifica formalmente "fundadores", sino consejeros. Las personas que constan como consejeras en la última información disponible son NATALIA GAMERO DEL CASTILLO CALLEJA (nombrada el 6 de marzo de 2026), CARLOS SOLER DUFFO (nombrado el 29 de enero de 2026) y JESÚS DOMINGUEZ FERNANDEZ (reelegido el 10 de marzo de 2025). De lo que hacen actualmente fuera de este cargo no consta nada en el corpus.

Para completar esta sección habría que consultar el Registro Mercantil de Barcelona (hoja registral completa y cuentas depositadas), el BORME de los ejercicios sucesivos y, si procede, fuentes periodísticas económicas.

• En sociedades de constitución reciente, el BORME es una fuente fiable para trazar la composición y los cambios del consejo de administración, pero no dice nada sobre la actividad real: para evaluar el negocio se necesitan las cuentas depositadas y fuentes comerciales.
• La rotación de consejeros en los primeros meses (ceses en marzo y diciembre de 2025, nombramientos en enero y marzo de 2026) es una señal que hay que contrastar con la estructura de propiedad antes de sacar conclusiones; el registro no explica los motivos de los cambios.
• No se debe confundir una sociedad de nueva creación con una marca comercial existente: el corpus solo acredita la existencia de esta sociedad limitada, no su relación con ninguna marca o grupo, que no consta en las fuentes facilitadas.

Segons la font disponible (Wikipedia), Bimba y Lola és una marca de moda i accessoris fundada el 2005 a Vigo per les germanes Uxía i María Domínguez, amb un posicionament de disseny propi, preu mitjà-alt i vocació internacional. La fitxa de partida (startup SaaS a Barcelona) no encaixa amb aquesta descripció i caldria corregir-la abans de fer cap pla.

La idea reconstruïble avui, com a proposta, no és replicar la marca original sinó construir una marca de moda-accessoris d'origen atlàntic amb tres decisions contemporànies: canal digital-first amb botiga física com a experiència de marca, producció de proximitat (Portugal/Galícia) per escurçar terminis i reduir estoc, i un catàleg més curt i rotatiu que el d'una marca de moda ràpida.

La diferència respecte del 2005 és el context: avui el cost d'adquisició digital és molt alt i la diferenciació per producte és més difícil; per tant, l'essència a preservar és el disseny propi recognoscible i el relat d'origen, no la logística ni l'escala.

El mercat rellevant és el de moda i accessoris de preu mitjà a Espanya i Europa, un segment molt competitiu on conviuen marques consolidades, cadenes de moda ràpida i marques digitals natives. La font consultada no aporta dades de mida de mercat ni de quota, de manera que qualsevol xifra que es doni aquí és estimació a validar amb dades sectorials (ACOTEX, INE, Eurostat).

El que sí que es pot afirmar amb la font: la marca original va néixer a Galícia i va créixer cap a mercats internacionals, cosa que indica que el producte gallec de moda-accessoris té recorregut fora del mercat local. Això és un senyal, no una prova d'escala.

Per a una proposta nova, el nínxol més defensable avui és el de compradora de 25-45 anys que vol disseny diferenciat a preu mitjà i valora origen europeu i producció propera — un nínxol on la competència és menor que en moda ràpida però on la despesa de màrqueting per captar client és alta.

Proposta de model, no descripció del model original:

• Ingressos: venda directa al consumidor via e-commerce propi (majoritari) i botiga física a una ciutat (Barcelona o Vigo com a primera plaça). Marxandatge i accessoris com a categoria d'entrada de preu baix per captar client.
• Marge: el marge brut objectiu en moda-accessoris de preu mitjà se situa habitualment en el rang del 55-65% (estimació sectorial a validar); la producció de proximitat el redueix respecte d'Àsia però millora rotació i redueix estoc mort.
• Costos clau: disseny i mostrari, producció (comandes mínimes), logística i devolucions, màrqueting digital (el més volàtil), i equip petit de marca i operacions.
• Estructura: equip fundador de 2-3 persones (disseny, marca, operacions) amb serveis externs per a producció, logística i màrqueting.

No hi ha dades verificades sobre preus, marges ni estructura de costos de l'empresa original; tot el que segueix és proposta i estimació.

Proposta en quatre fases, amb terminis estimats:

1. Fase 0 — Validació (mesos 0-3): definir posicionament, 15-25 referències de mostrari, test de demanda amb pre-venda o llista d'espera. Cost estimat: 8.000-15.000 € (a validar).
2. Fase 1 — Llançament digital (mesos 3-9): e-commerce propi, primera col·lecció curta, producció de proximitat en lot petit. Objectiu: validar conversió i taxa de retorn, no volum.
3. Fase 2 — Primera botiga (mesos 9-18): una plaça única, format petit, com a espai de marca i prova de producte. Decisió condicionada a les dades de la fase 1.
4. Fase 3 — Escalat selectiu (mesos 18-36): ampliar catàleg i, si les mètriques ho justifiquen, segon mercat o segona botiga.

El criteri de pas entre fases hauria de ser explícit (per exemple, cost d'adquisició i marge per comanda), no el calendari.

Estimació de rang, a validar amb pressupostos reals per a un llançament digital-first amb producció de proximitat:

• Disseny i mostrari: 8.000-15.000 €
• Primera producció (lot petit, 15-25 referències): 25.000-50.000 €
• E-commerce, fotografia i contingut: 8.000-15.000 €
• Màrqueting de llançament (6 mesos): 15.000-30.000 €
• Logística, devolucions i estructura legal/fiscal: 6.000-12.000 €
• Marge de tresoreria per a 12 mesos: 20.000-40.000 €

Total orientatiu: 80.000-160.000 € per arribar a un any d'operació digital. Afegir una botiga física sumaria, segons ciutat i format, un rang estimat de 40.000-90.000 € d'obertura i existències. Són xifres de planificació, no compromisos.

• Risc de marca: el nom i l'essència originals no es poden replicar; cal construir una identitat pròpia i verificar que no col·lideixi amb marques existents.
• Risc de canal: el cost d'adquisició digital en moda és alt i creixent; un model que depengui només de publicitat és fràgil.
• Risc d'estoc: la moda té temporada; produir de proximitat redueix risc però encareix unitat.
• Risc d'escala: passar de marca petita a marca amb botiga exigeix capital i equip que la fase digital no genera sola.
• Risc de dades de partida: la fitxa inicial (SaaS, Barcelona) no coincideix amb la font; qualsevol pla ha de partir de la informació corregida i verificada, no de la fitxa.

Les lliçons de l'informe original, aplicables a qualsevol reconstrucció:

1. L'essència és el disseny i el relat d'origen, no l'escala: el que fa recognoscible una marca de moda és el producte i la seva història, i això es pot començar petit.
2. Canal i producte es validen junts i amb dades: no es decideix obrir botiga ni ampliar catàleg sense mètriques de conversió i marge.
3. Producció de proximitat com a avantatge competitiu, no com a cost: redueix estoc i temps de reacció.
4. Corregir les dades de partida abans de planificar: una fitxa equivocada invalida qualsevol pressupost.
5. Capital de tresoreria és el factor limitant real, més que la idea: cal dimensionar el llançament per sobreviure un any sense vendes òptimes.

Aquestes lliçons les hauria d'aplicar un equip fundador petit amb perfil de disseny i marca, capacitat operativa i disciplina financera — no un perfil tecnològic, atès que el negoci verificat és de moda, no de software.

Bimba y Lola és una marca de moda d'origen gallec fundada el 2005, amb seu operativa a Barcelona i presència internacional, que ven per botiga física i per e-commerce ([Wikipedia] Bimba y Lola). En aquest tipus de marques, el catàleg és molt gran en SKU i molt curt en cicle de vida: cada temporada genera milers de referències amb talles, i la disponibilitat canvia cada hora per vendes a botiga, devolucions i enviaments.

El problema concret que resol el producte és la disponibilitat inconsistent entre canals: la web diu que hi ha talla, la botiga no la troba, i el magatzem no sap què reposar. No és un problema de "falta de dades" sinó de dades correctes en el moment de decidir: el POS i l'ERP tenen l'estoc, però ni la latència ni les regles de reserva estan pensades per respondre "puc vendre això ara i aquí?" en mil·lisegons.

El producte no pretén substituir l'ERP ni el POS: pretén ser la capa de decisió de disponibilitat per sobre, amb una API estable i un model de dades propi.

Arquitectura de serveis amb un nucli síncron de baixa latència i una capa asíncrona d'ingestió i analítica. El motiu és separar el camí crític (consulta de disponibilitat en checkout) del camí no crític (sincronització massiva, reposició, informes): si l'ingestió va lenta, el checkout no ha de patir.

``` [POS botigues] --batch/CDC--> [Ingestor] --event--> [Kafka/Redpanda] [ERP magatzem] --CDC-------> [Ingestor] | [E-commerce] --webhook---> [Ingestor] v [Stock Projector] --> [Postgres (stock per SKU+ubicació)] | ^ v | [Redis (disponibilitat)] [Availability API] ^ [Web / Botiga / Marketplace] ------------------- HTTPS ------------------| ```

Components i motius:

• Ingestor: adaptadors per font (connector JDBC/CDC per a ERP, API REST per a POS, webhook per a e-commerce). Motiu: cada font té un contracte diferent i no volem que el nucli conegui cap d'elles.
• Bus d'esdeveniments (Kafka o Redpanda): desacobla ingesta i projecció, permet reintents i reprocessament. Motiu: els talls de sincronització amb ERP són habituals i cal poder reconstruir estat.
• Stock Projector: consumeix esdeveniments i manté l'estat materialitzat a Postgres. Motiu: consultes de disponibilitat necessiten un estat coherent i auditable, no un càlcul sobre logs.
• Redis: cache de disponibilitat per SKU+ubicació amb TTL curt (segons). Motiu: el checkout necessita p99 baix i el càlcul de regles no ha de fer-se a cada petició.
• Availability API: servei síncron que llegeix de Redis i, en cas de fallada, cau a Postgres amb un circuit breaker. Motiu: degradació controlada en lloc de caiguda.

Model relacional a Postgres amb taules d'estat i taules d'esdeveniments. Motiu: l'estat de disponibilitat ha de ser auditable (qui va canviar què i quan) i reconstruïble.

Entitats principals:

• `product` (id, sku_pare, marca, temporada, actiu)
• `variant` (id, product_id, talla, color, ean)
• `location` (id, tipus [botiga|magatzem|3PL], codi_extern, pais)
• `stock_snapshot` (variant_id, location_id, quantitat_fisica, quantitat_reservada, actualitzat_a) — clau composta, estat materialitzat
• `stock_event` (id, variant_id, location_id, delta, motiu, origen, ocorregut_a) — log immutable, font de veritat per reconstruir
• `reservation` (id, variant_id, location_id, canal, quantitat, expira_a, estat)
• `availability_rule` (id, abast, regla_json) — regles de què es pot exposar per canal (p. ex. no exposar l'última unitat d'una botiga a la web)

Decisions:

• `stock_event` és append-only i `stock_snapshot` és derivat. Motiu: permet reprocessar si una font envia dades errònies.
• Les reserves tenen expiració. Motiu: evita bloquejar estoc per carrets abandonats.
• `availability_rule` és configurable per marca i canal. Motiu: cada marca té polítiques diferents sobre exposar estoc de botiga a la web.

API pública REST/JSON, versionada (`/v1`), amb autenticació per API key per marca i scopes per canal.

Endpoints principals:

• `GET /v1/availability?variant_id=...&location_id=...` → `{disponible, motiu, actualitzat_a}`. Latència objectiu p99 < 80 ms.
• `POST /v1/reservations` → crea reserva amb TTL; retorna `reservation_id`.
• `DELETE /v1/reservations/{id}` → allibera.
• `POST /v1/stock-events` → ingesta d'esdeveniments per a fonts que no permeten CDC.
• `GET /v1/replenishment/suggestions?location_id=...` → suggeriments de reposició.

Integracions:

• ERP: connector CDC (Debezium sobre Postgres/MySQL) o extracte programat si l'ERP no exposa binlog. Motiu: minimitzar latència i no carregar l'ERP amb consultes massives.
• POS: adaptador per API REST amb polling incremental per `updated_at`. Motiu: la majoria de POS no ofereixen streaming.
• E-commerce: webhook d'ordre i devolució; el producte no processa pagaments, només reserva i allibera estoc.
• Marketplaces: sortida via API de disponibilitat; no s'ingesta res d'ells en la primera versió.

Ordre deliberat per validar el risc més gran abans d'invertir en amplada:

1. Connector d'una sola font d'estoc (una botiga pilot o un magatzem) i `stock_event` + `stock_snapshot`. Motiu: valida que podem obtenir dades fiables i amb quina latència real.
2. Availability API en mode lectura amb Redis i Postgres. Motiu: és el contracte que consumeix el client; sense això no hi ha producte.
3. Reserves amb TTL. Motiu: converteix "disponibilitat" en "compromís", que és el que necessita el checkout.
4. Regles de disponibilitat per canal. Motiu: sense regles, el producte és un mirall de l'ERP i no aporta decisió.
5. Suggeriments de reposició (batch diari). Motiu: és el valor per a operacions, però depèn d'haver acumulat historial.

No es construeix en la primera versió: multi-tenant complet, analítica en temps real ni integració de marketplaces.

Mides orientatives per a una marca pilot:

• Catàleg: 50k–200k variants actives per temporada.
• Esdeveniments d'estoc: 1–5 M/dia en pic (temporada alta).
• Consultes de disponibilitat: 50–500 req/s en pic, amb pics de checkout.

Riscos i mitigació:

• Latència de la font: si el POS triga 15 min a reflectir una venda, la disponibilitat no és "en temps real". Mitigació: exposar `actualitzat_a` a l'API i permetre regles de marge de seguretat per canal.
• Qualitat de dades: SKUs duplicats o EAN inconsistents entre ERP i POS. Mitigació: capa de normalització amb àlies de SKU i alertes de discrepància.
• Sobrevenda en pic: reserves concurrents sobre l'última unitat. Mitigació: reserva atòmica a Postgres amb `SELECT ... FOR UPDATE` o operació atòmica a Redis, i TTL curt.
• Cost d'emmagatzematge d'esdeveniments: log append-only creix. Mitigació: particionat per mes i retenció configurable (p. ex. 12 mesos) amb snapshots periòdics.

Validació en tres nivells, cadascun amb criteri d'èxit explícit:

1. Validació de dades (pilot): comparar `stock_snapshot` amb l'ERP/POS durant 2 setmanes. Criteri: >99,5% de coincidència per SKU+ubicació i latència mediana < 5 min.
2. Validació de rendiment: proves de càrrega sobre `GET /v1/availability` a 500 req/s. Criteri: p99 < 80 ms i error rate < 0,1% amb Redis actiu; degradació a Postgres < 300 ms p99.
3. Validació de negoci: A/B al checkout de la marca pilot comparant disponibilitat exposada amb i sense regles. Criteri: reducció mesurable de cancel·lacions per manca d'estoc i de vendes perdudes per fals "esgotat".

La validació es fa amb una sola marca i una sola regió abans d'obrir a més clients; el producte no es considera llest per escalar fins que els tres criteris es compleixin simultàniament.