GLOVOAPP23 SL

GLOVOAPP23 SL és una societat mercantil de responsabilitat limitada constituïda a Barcelona l'any 2015, classificada al corpus com a startup del sector del programari i SaaS. D'acord amb la fitxa registral, la seva raó social és GLOVOAPP23 SL i el seu estat registral és actiu. El capital social actual consta en 295.649 euros.

La societat forma part de l'entramat del grup Glovo: al corpus apareixen altres societats amb els mateixos fundadors o administradors sota la denominació Glovo, també ubicades a Barcelona i actives.

La constitució de la societat es data el 2015, segons les dades del corpus. El registre no detalla en la informació disponible l'escriptura de constitució ni els socis inicials; aquesta dada no consta.

El que sí que consta al BORME és una trajectòria de canvis en l'òrgan d'administració i en el capital. El 7 d'agost de 2019 es nomena auditor individual Deloitte SL. El 26 de novembre de 2019 es fa una ampliació de capital de 27.723,87 euros, amb un capital resultant de 158.828,27 euros, i una modificació estatutària que crea les participacions "Classe D". El 2021 i el 2022 es produeixen diverses ampliacions de capital successives.

La classificació del corpus situa l'empresa en el sector del programari i SaaS. La informació registral disponible no detalla l'objecte social ni els productes concrets de GLOVOAPP23 SL; aquest extrem no consta a les dades facilitades.

Pel nom i per la vinculació amb el grup Glovo, es tracta d'una de les societats instrumentals del grup, però el corpus no permet afirmar quina funció operativa o de serveis digitals desenvolupava específicament aquesta societat. Qualsevol afirmació més concreta sobre la seva activitat requeriria consultar l'objecte social a l'escriptura o als estatuts dipositats al Registre Mercantil.

El registre mostra un període d'activitat financera i organitzativa sostingut entre 2019 i 2022. Les ampliacions de capital documentades al BORME són les següents:

• 28 d'agost de 2019: 544,92 euros, fins a 131.104,40 euros.
• 26 de novembre de 2019: 27.723,87 euros, fins a 158.828,27 euros, amb creació de les participacions "Classe D".
• 11 de desembre de 2019: 13.241,40 euros, fins a 172.069,67 euros.
• 27 de gener de 2020: 3.526,92 euros, fins a 175.596,59 euros.
• 1 de juliol de 2021: 715,60 euros, fins a 204.853,54 euros.
• 3 d'agost de 2021: 10.268,88 euros (fins a 215.122,42 euros) i 74.297,87 euros (fins a 289.420,29 euros).
• 3 d'agost de 2021: 644,58 euros, fins a 290.064,87 euros.
• 3 de gener de 2022: 1.350,35 euros (fins a 291.415,22 euros), 1.322,33 euros (fins a 292.737,55 euros) i 2.911,05 euros (fins a 295.648,60 euros).

En paral·lel, el registre recull nomenaments de consellers i apoderats. L'11 d'abril de 2022 es nomenen consellers Ian William Osborne, David Pieter Jan Vandepitte, Lars Niklas Ostberg, Seaya Capital Gestión SGEIC SA, Nicolás Cirilo Ibáñez Scott i Pierre (el nom del qual no consta complet a les dades). El 9 de març de 2023 es nomena auditor KPMG Auditores SL i es revoquen consellers, entre els quals Niall Fraser Wass i Ian William Osborne.

No consta que GLOVOAPP23 SL hagi tancat. D'acord amb la fitxa registral, l'estat de la societat és actiu i la darrera acta recollida al corpus és del 4 d'agost de 2025, amb nomenaments d'apoderats mancomunats. Per tant, no es pot parlar de tancament ni de dissolució.

El corpus no conté cap indici de liquidació, concurs o extinció. Si l'empresa ha estat objecte de reestructuració societària dins del grup, aquest extrem no consta a les dades facilitades.

Atès que la societat continua activa segons el registre, no es pot parlar d'herència en el sentit de llegat d'una empresa desapareguda. El que sí que documenta el corpus és la seva funció com a vehicle societari del grup Glovo: les successives ampliacions de capital, la creació de classes de participacions i la rotació d'administradors i apoderats són característiques d'una societat instrumental dins d'un grup en expansió.

La informació disponible no permet quantificar l'impacte econòmic o laboral de la societat ni identificar actius o marques que se'n derivin.

Els administradors que consten al corpus són Jorge Oleart Godia, Lars Niklas Ostberg i David Pieter Jan Vandepitte. Segons les actes registrals:

• Jorge Oleart Godia consta nomenat secretari no conseller el 30 de juliol de 2025.
• Lars Niklas Ostberg i David Pieter Jan Vandepitte consten com a consellers nomenats l'11 d'abril de 2022.

El corpus no indica la seva situació actual més enllà d'aquests nomenaments, ni les seves participacions o càrrecs en altres societats del grup més enllà de les que apareixen com a vinculades. Per conèixer la seva trajectòria actual caldria consultar les fitxes registrals de les altres societats del grup Glovo i les darreres actes dipositades al Registre Mercantil de Barcelona.

• En grups de creixement ràpid, les societats instrumentals com GLOVOAPP23 SL es caracteritzen per ampliacions de capital freqüents i de poca quantia individual: entre 2019 i 2022 se'n documenten nou, la majoria per sota dels 30.000 euros. Això indica que el capital social no és el termòmetre de la mida real del negoci, sinó un instrument de configuració societària.
• La creació de classes de participacions (les "Classe D" el 2019) és un senyal habitual d'entrada d'inversors amb drets diferenciats; per a un analista, és un punt de consulta obligat per entendre l'estructura de control.
• La rotació d'apoderats mancomunats i solidaris (desenes de nomenaments i revocacions entre 2019 i 2025) reflecteix una estructura de govern corporativa centralitzada, on els apoderats són operatius i els consellers representen els inversors.
• Per avaluar una societat d'aquest tipus no n'hi ha prou amb el capital social: cal consultar els comptes dipositats i les actes d'ampliació per conèixer les primes d'emissió, que és on es concentra habitualment l'aportació real dels inversors.

El que les fonts permeten afirmar és que GLOVOAPP23 SL és una societat mercantil barcelonina constituïda el 2015, classificada com a startup de software i SaaS, amb un capital social de 295.649 € i un govern corporatiu sofisticat: consellers (Jorge Oleart Godia, Lars Niklas Ostberg, David Pieter Jan Vandepitte), auditoria de KPMG (nomenat el 2023) i una xarxa àmplia d'apoderats mancomunats i solidaris que s'ha anat renovant entre 2019 i 2025 [BORME via OpenMercantil, 2026-02-11]. Això dibuixa una estructura de grup amb inversió institucional i operació multi-mercat, no un negoci unipersonal.

La proposta de reconstrucció que té sentit avui, amb la mateixa essència tecnològica, és una plataforma de programari de logística d'última milla venuda com a SaaS i operada com a servei (B2B2C): programari d'encaminament, assignació de repartidors, seguiment en temps real i liquidació de pagaments, que comerços, cadenes de restauració i flotes de repartiment independents lloguen per gestionar les seves pròpies entregues. És a dir, es ven la infraestructura, no la marca de consum.

Aquesta és una proposta, no una descripció del que GlovoApp23 feia: l'expedient registral no detalla el producte.

El mercat rellevant és el de programari i serveis per a la logística urbana de darrera milla. Es pot segmentar en tres demandants:

• Comerços i cadenes de restauració que volen controlar la seva pròpia entrega sense dependre d'un marketplace.
• Flotes de repartiment independents i cooperatives de riders que necessiten programari d'assignació i facturació.
• Operadors logístics i retail que volen afegir entrega urbana sense construir tecnologia pròpia.

No disposo de dades verificades de mida de mercat en aquest expedient, i per tant no n'aportaré xifres com a fet. Com a estimació a validar, el segment de programari de logística d'última milla a l'Estat és competitiu i amb pressió de preus, cosa que afavoreix entrants especialitzats en nínxols (vertical de restauració, flotes cooperatives, mercats mitjans) més que no pas plataformes generalistes.

Proposta de model, amb tres línies d'ingrés:

1. Subscripció SaaS per comerç o per flota (quota mensual per establiment o per repartidor actiu). És ingrés recurrent i previsible.
2. Comissió per entrega gestionada (percentatge o tarifa fixa sobre el volum processat per la plataforma).
3. Serveis d'implantació i integració (API, connexió amb TPV i sistemes de comandes), facturació puntual.

L'estructura de costos és la típica de SaaS amb component operatiu: equip de producte i enginyeria, infraestructura cloud, suport, i —si s'opera la flota— cost variable de repartiment. El marge brut dependrà molt de si es ven només programari (marge alt) o programari més operació (marge més baix i més intensiu en capital humà).

Estimació a validar: un model mixt SaaS + comissió pot arribar a marge brut del 55–70% en la part de programari i del 15–25% en la part operativa. Són rangs orientatius, no dades de l'empresa.

Proposta en quatre fases, amb terminis estimats a validar:

• Fase 0 — Validació (mesos 1–3). Entrevistes amb 20–30 comerços i 3–5 flotes de Barcelona; definir el producte mínim (encaminament + seguiment + liquidació). Cost estimat: 15.000–30.000 € (equip fundador i recerca).
• Fase 1 — MVP i pilots (mesos 4–9). Construir el nucli del programari i tancar 3–5 clients pilots a Barcelona. Mètrica objectiu: entregues gestionades i retenció. Cost estimat: 120.000–250.000 € (desenvolupament, infraestructura, suport).
• Fase 2 — Comercialització (mesos 10–18). Equip comercial lleuger, integracions amb TPV, primers contractes anuals. Cost estimat: 250.000–450.000 € addicionals.
• Fase 3 — Escalat (mesos 19–36). Expansió a Madrid i segona ciutat, possible ronda de finançament. Cost estimat: 500.000 €–1,5 M € addicionals, a validar segons creixement.

Barcelona és el punt de partida lògic per la concentració de restauració, turisme i ecosistema tecnològic, coherent amb la ubicació verificada de la societat.

Estimació a validar, no dades de l'empresa. Per posar en marxa la proposta fins a la fase 1 (MVP + pilots):

• Equip fundador i primers contractes: 60.000–120.000 € (2–3 persones, 9 mesos).
• Desenvolupament de producte i infraestructura: 60.000–120.000 €.
• Legal, constitució i compliment (RGPD, contractes): 8.000–15.000 €.
• Màrqueting i vendes inicials: 15.000–30.000 €.
• Capital de maniobra i imprevistos: 20.000–40.000 €.

Total orientatiu fins a MVP amb pilots: 160.000–325.000 €. Per comparar amb una dada verificada: el capital social de GLOVOAPP23 SL és de 295.649 € [BORME via OpenMercantil, 2026-02-11], xifra que se situa dins d'aquest rang però que no equival a la inversió real necessària (el capital social no és el cost de llançament). Caldrà validar cada partida amb pressupostos reals.

• Risc de producte: construir programari que el mercat no adopti perquè els comerços prefereixen el marketplace existent. Mitigació: pilots pagats abans d'escalar.
• Risc competitiu: plataformes consolidades i solucions de logistics-as-a-service. Mitigació: nínxol vertical i servei proper.
• Risc regulatori i laboral: el marc dels repartidors a l'Estat ha canviat i afecta qualsevol model que operi flota. Cal assessorament legal específic; no en tinc dades verificades en aquest expedient.
• Risc financer: el cicle de vendes B2B és llarg i el capital inicial pot esgotar-se abans d'arribar a recurrència. Mitigació: fites de finançament per fase.
• Risc de govern: l'expedient mostra una estructura de consell i apoderats complexa i canviant [BORME via OpenMercantil, 2026-02-11]; en una reconstrucció caldria un govern simple i àgil al principi.

Les lliçons que es poden extreure de l'expedient original, més enllà del cas concret:

1. La tecnologia sola no és el negoci: el que acredita l'expedient és una estructura de capital i govern sofisticada, no un producte. La reconstrucció ha de començar per un client que pagui, no per una plataforma.
2. El capital social no és el cost de llançament: 295.649 € de capital social és una dada registral, no un pressupost. Cal separar sempre les dues coses.
3. El govern corporatiu es complica amb el creixement: consellers, apoderats i auditories són senyals de maduresa, però també de complexitat. Una reconstrucció ha de començar simple.
4. Barcelona és una base raonable per a logística urbana i SaaS, per concentració de demanda i ecosistema.
5. Cal validar abans d'invertir: cap xifra d'aquest informe és una dada de l'empresa; totes les estimacions són a validar amb pressupostos i pilots reals.

En resum: el perfil que hauria d'emprendre-ho és un equip petit amb experiència en logística urbana i producte SaaS, capacitat de vendre B2B a Barcelona i disciplina per validar cada fase abans d'escalar —no un intent de replicar la marca o l'escala d'un operador consolidat.

Un operador de lliurament a última milla necessita coordinar en temps real tres actors —comerç, repartidor i client final— mentre manté una comptabilitat exacta de qui cobra què i quan. Els sistemes genèrics d'e-commerce no resolen el despatx dinàmic (assignar la comanda correcta al repartidor correcte en segons), ni la conciliació de comissions, ni la traçabilitat fiscal de cada pagament a repartidors autònoms.

El producte és un SaaS multi-tenant que dona a cada operador (tenant) el seu propi espai de despatx, catàleg de comerços, flota de repartidors i llibre de liquidacions. El problema central és la consistència entre el món operatiu (temps real, idempotència, reintents) i el món financer (exactitud al cèntim, auditabilitat). La referència d'empresa (GLOVOAPP23 SL, constituïda el 2015 a Barcelona, amb ampliacions de capital successives i auditoria per KPMG des del 2023 —vegeu [BORME / BOE via OpenMercantil, 2026-02-11]) mostra una estructura on la governança i l'auditoria són rellevants: el sistema ha de produir rastres auditables per defecte.

Arquitectura orientada a serveis amb dos plans clarament separats:

``` ┌─────────────────────────────┐ Apps client ───► │ API Gateway (auth, rate) │ Comerç/Repart. └──────────────┬──────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Order Svc │ │ Dispatch Svc │ │ Settlement Svc │ │ (CRUD + FSM)│◄────────►│ (matching geo) │ │ (liquidacions) │ └──────┬──────┘ └────────┬────────┘ └────────┬────────┘ │ │ │ ▼ ▼ ▼ ┌──────────────────────────────────────────────────────────────────┐ │ Event Bus (Kafka) — topics: orders, dispatch, payments │ └──────────────────────────────────────────────────────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Postgres │ │ Redis (geo set, │ │ Ledger (Postgres│ │ (orders, │ │ locks, ETA) │ │ append-only) │ │ tenants) │ └─────────────────┘ └─────────────────┘ └─────────────┘ ```

Decisions i motius:

• Separació Order / Dispatch / Settlement en serveis distints. El despatx té requisits de latència (assignació < 2 s) i el de liquidació té requisits de consistència forta. Barrejar-los obligaria a escalar el despatx amb les mateixes garanties que els pagaments, encarint-ho innecessàriament.
• Kafka com a bus d'esdeveniments. Permet que el Settlement consumeixi esdeveniments de comanda de manera asíncrona i idempotent, i dona un log reproduïble per a auditoria (requisit plausible donada l'auditoria externa de l'empresa de referència, KPMG des del 2023).
• Redis amb geo-sets per al matching. L'assignació repartidor↔comanda és una consulta geoespacial de proximitat; Redis `GEOADD`/`GEOSEARCH` resol en mil·lisegons el que PostGIS faria en desenes.
• Ledger append-only a Postgres. Els pagaments no s'actualitzen mai in-place; cada moviment és una fila nova amb `entry_id` i `correlation_id`. Això fa la conciliació trivial i auditable.
• Multi-tenant per `tenant_id` a totes les taules amb Row-Level Security de Postgres, en lloc de bases de dades separades per tenant: simplifica operacions i és suficient per a desenes d'operadors.

Esquema relacional (Postgres) amb esdeveniments com a font de veritat per a l'estat financer.

```sql -- Tenants i configuració tenants(id uuid PK, name text, commission_bps int, currency char(3), created_at timestamptz)

-- Comerços merchants(id uuid PK, tenant_id uuid FK, name text, location geography(Point,4326), active bool)

-- Repartidors couriers(id uuid PK, tenant_id uuid FK, name text, status text, -- 'offline'|'available'|'busy' last_location geography(Point,4326), updated_at timestamptz)

-- Comandes amb màquina d'estats orders(id uuid PK, tenant_id uuid FK, merchant_id uuid FK, courier_id uuid NULL, status text, -- 'created'|'assigned'|'picked_up'|'delivered'|'cancelled' total_cents int, currency char(3), created_at timestamptz, version int)

-- Esdeveniments de comanda (event sourcing per a auditoria) order_events(id bigserial PK, order_id uuid FK, type text, payload jsonb, occurred_at timestamptz, correlation_id uuid)

-- Ledger financer append-only ledger_entries(id bigserial PK, tenant_id uuid FK, order_id uuid NULL, account text, -- 'merchant_payable'|'courier_payable'|'platform_revenue' amount_cents int, -- signat: + crèdit, - dèbit correlation_id uuid, created_at timestamptz) ```

Motius:

• `total_cents` com a enter: mai floats per a diners.
• `version` a `orders` per a control de concurrència optimista en les transicions d'estat.
• `order_events` desacobla l'estat actual de la seva història: es pot reconstruir qualsevol comanda en qualsevol moment (requisit d'auditoria).
• `ledger_entries` amb `correlation_id` permet conciliar cada pagament amb la comanda i l'esdeveniment que el va originar.

API REST (v1) per a clients:

• `POST /v1/orders` — crea comanda; retorna `202` amb `order_id` i `correlation_id`. Idempotent via capçalera `Idempotency-Key`.
• `POST /v1/couriers/{id}/location` — heartbeat de posició (cada 5 s); actualitza Redis i Postgres de forma asíncrona.
• `GET /v1/orders/{id}` — estat actual + historial resumit.
• `POST /v1/orders/{id}/transitions` — transició d'estat validada per la FSM; retorna `409` si la transició no és permesa.

Webhooks sortints cap a comerços: `order.assigned`, `order.delivered`, `order.cancelled`, signats amb HMAC-SHA256 i reintents amb backoff exponencial (màx. 5 intents).

Integracions:

• Passarel·la de pagament (Stripe Connect o equivalent) per als cobraments al client final i els pagaments als repartidors; el Settlement Svc crea transferències a partir del ledger.
• Proveïdor de mapes/routing (OSRM o Mapbox) per a ETA i distàncies.
• Facturació electrònica per als repartidors autònoms: generació de factures a partir del ledger, amb sèrie i numeració per tenant.

Ordre de construcció per maximitzar valor demostrable:

1. Nucli de comandes + FSM (`Order Svc` + Postgres + `order_events`). Sense això no hi ha producte. Inclou idempotència i transicions validades.
2. Despatx bàsic (`Dispatch Svc` + Redis geo): assignació manual i automàtica per proximitat, amb heartbeat de repartidor.
3. Ledger i conciliació mínima: cada comanda entregada genera entrades de ledger; un informe diari per tenant.
4. API de comerç + webhooks perquè un comerç pugui integrar-se.
5. Pagaments reals via passarel·la i facturació electrònica.

El criteri és: primer el flux operatiu complet (comanda→despatx→entrega), després el flux financer, perquè el financer depèn dels esdeveniments del primer.

Mides: un tenant petit pot generar 1.000 comandes/dia i 200 repartidors actius; un tenant gran, 50.000 comandes/dia i 5.000 repartidors. El despatx ha de suportar pics de 10× en hores punta.

Riscos tècnics i mitigacions:

• Latència d'assignació: si Redis cau, el despatx degrada. Mitigació: rèplica Redis amb failover i fallback a PostGIS (més lent però funcional).
• Duplicació de pagaments: reintents del Settlement podrien pagar dues vegades. Mitigació: `correlation_id` únic al ledger i clau d'idempotència a la passarel·la.
• Deriva de posició: heartbeats perduts fan que un repartidor sembli disponible quan no ho és. Mitigació: TTL de 30 s a Redis i marcatge automàtic a `offline`.
• Consistència eventual entre estat de comanda i ledger: un esdeveniment pot processar-se tard. Mitigació: el Settlement reconstrueix des del log de Kafka i el ledger és idempotent per `correlation_id`.
• Compliment fiscal de repartidors autònoms: canvis normatius poden afectar la facturació. Mitigació: la generació de factures és un servei aïllat amb plantilles versionades.

• Tests de la FSM: taula de transicions permeses/prohibides amb cobertura del 100%; cap transició il·legal ha de ser possible.
• Tests d'idempotència: enviar la mateixa `POST /v1/orders` dues vegades retorna la mateixa comanda i no duplica ledger.
• Tests de conciliació: per a un lot de comandes sintètiques, la suma del ledger ha de quadrar exactament amb el total de comandes menys comissions (assert d'igualtat al cèntim).
• Proves de càrrega: simular 10× el pic d'un tenant gran i verificar que l'assignació es manté < 2 s al p99.
• Proves de caos: matar Redis i verificar que el despatx continua via fallback; matar un consumidor de Kafka i verificar que el ledger es reconstrueix sense duplicats.
• Auditoria: exportació del log d'esdeveniments i del ledger en format immutable (CSV signat) per a revisió externa, coherent amb el context d'auditoria de l'empresa de referència ([BORME / BOE via OpenMercantil, 2026-02-11]).