Glovo

GLOVOAPP23, S.L. es una sociedad mercantil constituida en Barcelona, clasificada como startup del sector de logística y transporte. De acuerdo con el registro mercantil, su razón social es GLOVOAPP23, S.L., tiene un capital social de 352.692 EUR y consta como activa. La información verificada disponible no indica ningún proceso de cierre ni de disolución.

La sociedad se constituyó el 6 de febrero de 2015 en Barcelona, según el acta de constitución que consta en el registro mercantil. Los fundadores y administradores que constan son Oscar Mingueza (cofundador y CEO), Sami Bekhouche (cofundador) y David Rougier (cofundador). No constan en los datos disponibles otros detalles sobre el capital inicial, los socios fundadores ni las circunstancias concretas de la constitución.

La clasificación sectorial disponible sitúa a la empresa en logística y transporte. Los datos verificados no detallan el modelo de negocio, los servicios concretos ni el perfil de clientes. Esta información no consta en el corpus suministrado.

No consta información verificada sobre la evolución de la empresa, los resultados, el crecimiento, la facturación ni hitos relevantes. Los datos disponibles se limitan a la constitución y a los datos registrales básicos.

De acuerdo con el registro mercantil, la empresa consta activa. Los datos verificados no documentan ningún cierre, disolución ni transformación societaria. Por tanto, no se puede afirmar ninguna causa de cierre.

No consta información verificada sobre la herencia, el impacto o la continuidad de la actividad más allá del estado registral actual de empresa activa.

Los fundadores que constan en el corpus son Oscar Mingueza (cofundador y CEO), Sami Bekhouche (cofundador) y David Rougier (cofundador). Los datos disponibles no indican su situación actual más allá de los cargos registrados. Para ampliarlo, se podría consultar el Registro Mercantil para verificar la vigencia de los cargos y las últimas actas depositadas.

• La información registral permite confirmar la constitución y el estado de una sociedad, pero no explica por sí sola el modelo de negocio ni su evolución; hay que contrastarla con fuentes adicionales.
• Cuando una empresa consta activa en el registro, cualquier afirmación sobre cierre o transformación requiere una fuente que lo documente; en ausencia de esa fuente, hay que limitarse al estado registral.
• Para startups del sector logístico, la fecha de constitución y el capital social son datos útiles para situar la empresa, pero no sustituyen la información sobre actividad, clientes o resultados, que hay que verificar por separado.

Reconstruir l'essència de Glovo —el lliurament urbà en minuts des de comerços locals— no com una app global de riders autònoms, sinó com una plataforma de proximitat per barris, amb repartiment contractat i acords directes amb comerços.

La diferència clau respecte al model original: a Espanya, la Llei Rider (2021) va fer que els repartidors haguessin de ser assalariats, cosa que va encarir estructuralment el model d'autònoms. Qualsevol reconstrucció avui ha de néixer amb aquesta realitat assumida, no com a pedaç posterior.

Proposta (marcada com a proposta): començar amb una sola ciutat i 2-3 barris densos, no amb una xarxa nacional. L'objectiu no és competir amb Glovo sinó ocupar el nínxol que el gegant va deixar: comerç de barri, restauració local i entregues de curta distància amb marge per unitat positiu des del primer dia.

El mercat de lliurament a domicili a Espanya no va desaparèixer amb la retirada de Glovo: el que va canviar és qui l'opera i amb quin model. Hi ha demanda consolidada de:

• Restauració a domicili en barris densos, on el client valora rapidesa sobre preu.
• Comerç de proximitat (fruiteria, farmàcia, supermercat de barri) que vol digitalitzar-se sense cedir tot el marge.
• Empreses i oficines amb comandes recurrents (esmorzars, material d'oficina).

Advertiment: no disposo de dades verificades sobre la mida exacta d'aquest mercat post-Glovo. Qualsevol xifra de TAM/SAM que es faci servir en un pla real ha de validar-se amb fonts sectorials (associacions de restauració, informes de consultores, dades municipals de llicències) abans de comprometre capital.

Proposta de model (a validar):

• Comissió per comanda al comerç (rang estimat 15-25%, a validar segons categoria).
• Tarifa de lliurament al client, modulada per distància i franja horària.
• Subscripció mensual per a clients recurrents (lliuraments inclosos o amb descompte).
• Repartiment amb contracte laboral (no autònoms), amb torns definits per barri.

La clau econòmica: densitat per barri. Un repartidor amb 3-4 comandes per hora en un radi de 2 km pot ser rendible; el mateix repartidor amb 1 comanda per hora en un radi de 8 km no ho serà mai. El model ha de néixer amb aquesta disciplina, no aprendre-la després.

Proposta de fases (a validar):

1. Fase 0 — Validació (2-3 mesos): acords signats amb 15-25 comerços d'un sol barri, llista d'espera de clients, i una operació manual (WhatsApp + repartidor propi) per mesurar demanda real abans d'escriure codi.
2. Fase 1 — Producte mínim (3-4 mesos): app de client i panell de comerç, pagaments integrats, gestió de torns. Un sol barri, un equip de 3-5 repartidors contractats.
3. Fase 2 — Densificació (6 mesos): arribar a 2-3 barris contigus, mesurar marge per comanda i per repartidor.
4. Fase 3 — Replicació: només si la unitat econòmica és positiva, obrir una segona ciutat amb el mateix manual.

Estimació (rang, a validar amb pressupostos reals):

• Desenvolupament de producte (app + panell + backend): 60.000-120.000 € si es fa amb equip intern petit o agència; menys si s'usa programari existent.
• Equip humà inicial (2-3 persones, 6 mesos): 90.000-150.000 €.
• Repartidors contractats (3-5 persones, 6 mesos, cost empresa): 60.000-100.000 €.
• Màrqueting i captació de comerços: 15.000-30.000 €.
• Legal, llicències, assegurances, comptabilitat: 10.000-20.000 €.
• Capital de rodatge (6-9 mesos): 30.000-60.000 €.

Total orientatiu per a la fase 0-1: 250.000-450.000 € (estimació àmplia, a validar). És un ordre de magnitud molt inferior al d'un operador nacional, però suficient per demostrar si el model funciona en un barri abans d'escalar.

• Risc laboral i normatiu: el model de repartiment ha de complir la Llei Rider des del disseny; qualsevol atall a la contractació laboral és un risc existencial.
• Risc de densitat: si no s'assoleix volum per barri, la unitat econòmica no tanca. És el risc número u.
• Risc de competència: operadors consolidats poden replicar el model de proximitat si funciona.
• Risc de dependència de comerços: pocs comerços grans poden imposar condicions; cal diversificar.
• Risc financer: el capital de rodatge s'esgota abans d'assolir marge positiu si la captació és lenta.

Les lliçons de l'informe original, aplicades a una reconstrucció:

1. La logística urbana és un negoci de densitat, no de cobertura. Glovo va créixer en amplada; una reconstrucció ha de créixer en profunditat per barri.
2. El model laboral no és un detall, és l'estructura de costos. Qui el tracti com un pedaç acabarà pagant-lo amb escreix.
3. El comerç local és soci, no proveïdor. Qui el tracti com a canal acabarà competint-hi.
4. La validació manual abans del codi estalvia capital. La temptació de construir producte abans de vendre és el camí més car.
5. El capital d'arrencada és finit; la disciplina de marge per unitat és el que decideix si hi ha segona fase.

En resum: el que es pot construir avui amb l'essència de Glovo és més petit, més lent i més legal —i precisament per això, més probable que sobrevisqui.

Quan un proveïdor de programari de lliurament tanca o és absorbit, els seus clients perden tres coses alhora: la capacitat de despatxar comandes noves, l'accés a l'historial de lliuraments (proves de lliurament, incidències, liquidacions a repartidors) i la integració amb els seus propis sistemes (TPV, ERP, botigues en línia). El registre mercantil de GLOVOAPP23 SL mostra una estructura societària que ha passat per diverses ampliacions de capital i nomenaments de consellers i apoderats entre 2019 i 2025 [BORME / BOE (via OpenMercantil), 2026-02-11], cosa que il·lustra com la governança d'aquests operadors canvia sovint i com el risc de discontinuïtat és real per als comerços que hi deleguen l'última milla.

El producte no pretén substituir un marketplace de lliurament, sinó ser la capa que un comerç o un operador logístic controla. El problema concret: exportar i continuar operant un flux de lliuraments quan el sistema d'origen deixa de respondre.

Tres serveis i un bus d'esdeveniments, tots desplegables en un sol Kubernetes o en un VPS amb Docker Compose per a clients petits.

``` [Comerç / TPV] --HTTPS--> [api-gateway] | +---------------+---------------+ | | | [orders-svc] [dispatch-svc] [settlement-svc] | | | +-------+-------+-------+-------+ | | [event-log] [postgres] (append-only) (estat actual) | [webhook-relay] --> sistemes del client ```

• orders-svc: ingesta de comandes (API pròpia + importador CSV/JSON de l'historial exportat del proveïdor que tanca). Motiu: el primer dia útil del client és la migració, no l'operació nova.
• dispatch-svc: assigna comandes a repartidors amb una regla determinista i auditable (distància, càrrega, finestra horària). Motiu: si l'assignació és opaca no es pot defensar davant d'un repartidor o d'un client.
• settlement-svc: calcula liquidacions per repartidor a partir dels esdeveniments de lliurament. Motiu: és la funció que genera més disputes i la que més es troba a faltar quan marxa el proveïdor.
• event-log: registre append-only (taula Postgres particionada per mes, o Kafka si el volum ho justifica). Motiu: l'historial ha de ser reconstruïble i exportable en qualsevol moment; és la garantia contra el proper tancament.
• webhook-relay: reenvia esdeveniments amb reintents i signatura HMAC. Motiu: els sistemes dels clients ja consumeixen webhooks; canviar el format els obligaria a refer la integració.

Postgres 15+, amb `event_log` com a font de veritat i taules d'estat derivades.

```sql -- Estat actual, derivat de l'event_log CREATE TABLE orders ( id uuid PRIMARY KEY, external_ref text UNIQUE, -- id al sistema d'origen merchant_id uuid NOT NULL, status text NOT NULL, -- created|assigned|picked_up|delivered|failed|cancelled pickup_at timestamptz NOT NULL, dropoff_lat numeric(9,6) NOT NULL, dropoff_lng numeric(9,6) NOT NULL, created_at timestamptz NOT NULL DEFAULT now() );

CREATE TABLE couriers ( id uuid PRIMARY KEY, merchant_id uuid NOT NULL, display_name text NOT NULL, active boolean NOT NULL DEFAULT true );

CREATE TABLE assignments ( id uuid PRIMARY KEY, order_id uuid NOT NULL REFERENCES orders(id), courier_id uuid NOT NULL REFERENCES couriers(id), assigned_at timestamptz NOT NULL, released_at timestamptz, reason text -- per què es va assignar o alliberar );

CREATE TABLE deliveries ( id uuid PRIMARY KEY, order_id uuid NOT NULL REFERENCES orders(id), courier_id uuid NOT NULL REFERENCES couriers(id), delivered_at timestamptz, proof_type text, -- photo|signature|pin proof_ref text );

-- Registre immutable; cap UPDATE ni DELETE CREATE TABLE event_log ( seq bigserial PRIMARY KEY, occurred_at timestamptz NOT NULL, aggregate_type text NOT NULL, -- order|assignment|delivery|settlement aggregate_id uuid NOT NULL, event_type text NOT NULL, payload jsonb NOT NULL, idempotency_key text UNIQUE ); CREATE INDEX ON event_log (aggregate_id, seq); ```

Motiu de `idempotency_key`: els webhooks dels proveïdors que tanquen solen reintentar; sense clau única l'historial es duplica i les liquidacions surten inflades. Motiu de `reason` a `assignments`: permet reconstruir per què una comanda va anar a un repartidor concret, cosa necessària per respondre reclamacions.

REST/JSON amb OpenAPI 3.1, autenticació per API key per comerç i OAuth2 per a usuaris humans.

• `POST /v1/orders` — crea comanda; accepta `external_ref` per idempotència.
• `POST /v1/orders/import` — càrrega massiva de l'historial exportat (CSV o JSON del proveïdor sortint). Respon `202` amb `job_id`.
• `POST /v1/orders/{id}/assign` — assignació manual o forçada; retorna l'`assignment_id`.
• `POST /v1/deliveries/{id}/proof` — puja prova de lliurament (foto o PIN); retorna `proof_ref`.
• `GET /v1/settlements?courier_id=&from=&to=` — liquidació calculada.
• `GET /v1/events?since_seq=` — exportació incremental de l'historial; és la via de sortida si el client marxa.
• Webhooks sortints: `order.created`, `order.assigned`, `delivery.completed`, `delivery.failed`, signats amb HMAC-SHA256 i capçalera `X-Signature`.

Integracions previstes, per ordre: TPV/ERP via webhook, fulls de càlcul via CSV, i un adaptador d'importació per als formats d'exportació més habituals del mercat. Motiu de començar per webhook i CSV: són les interfícies que qualsevol comerç pot consumir sense equip tècnic propi.

1. `event_log` + `orders` + importador (`POST /v1/orders/import`). Sense historial importat el producte no té cap valor el dia u.
2. `dispatch-svc` amb assignació determinista i `POST /v1/orders/{id}/assign`. És la funció operativa mínima.
3. `webhook-relay` amb reintents i signatura. És el que fa que el client no hagi de canviar res als seus sistemes.
4. `settlement-svc` en versió simple (suma de lliuraments per repartidor i període).
5. Proves de lliurament (`proof`) i exportació `GET /v1/events`.

Motiu de l'ordre: cada pas és utilitzable sol i cap depèn d'un pas posterior per demostrar valor.

• Volum: un comerç mitjà pot generar 200-2.000 comandes/dia; l'`event_log` creix a ~5-10 esdeveniments per comanda. Amb particions mensuals i retenció de 24 mesos, Postgres aguanta fins a ~10M d'esdeveniments sense Kafka. Motiu de no començar amb Kafka: complexitat operativa que un client petit no pot mantenir.
• Risc: formats d'importació desconeguts. Mitigació: importador basat en mapes de columnes configurables i un pas de validació que rebutja files sense `external_ref` ni data.
• Risc: duplicació per reintents. Mitigació: `idempotency_key` única i resposta `200` amb el recurs existent en cas de repetició.
• Risc: pèrdua de confiança en les liquidacions. Mitigació: cada línia de liquidació referencia els `event_log.seq` que la justifiquen.
• Risc legal: les dades de repartidors i clients són personals; cal xifrat en repòs i política de retenció explícita. Motiu: el producte tracta dades que el proveïdor sortint també tractava i el client n'és el responsable.

• Test d'importació real: agafar un export de mostra (anonimitzat) d'un operador de lliurament i verificar que `POST /v1/orders/import` reprodueix l'historial amb el mateix recompte de comandes i estats.
• Test d'idempotència: enviar el mateix webhook dues vegades i comprovar que `event_log` té una sola fila i que la resposta és idèntica.
• Test d'assignació determinista: mateixa entrada, mateixa sortida; i `reason` present a cada `assignment`.
• Test de liquidació: per a un conjunt de lliuraments conegut, la suma de `settlements` ha de quadrar amb la suma de `deliveries` i cada línia ha de resoldre a esdeveniments existents.
• Test de sortida: `GET /v1/events?since_seq=0` ha de retornar un historial complet i reimportable en un sistema buit (round-trip). És el criteri que demostra que el producte compleix la seva promesa: que el proper tancament no torni a fer perdre res.