Cabify

Cabify, amb raó social CABIFY, S.L., és una empresa del sector de la mobilitat constituïda a Barcelona l'any 2013. D'acord amb el registre, l'empresa consta com a activa. El corpus no recull cap acte de dissolució, liquidació o transformació societària.

Es tracta, per tant, d'un cas d'empresa que no ha tancat segons la informació disponible, i no d'un cas de tancament o transformació. L'informe descriu el que consta i assenyala explícitament allò que no consta.

La societat es va constituir l'any 2013 a Barcelona, segons la cronologia registral disponible. Els fundadors que consten al corpus són Juan de Antonio, com a conseller delegat (CEO), i Álex Viaplana, com a cofundador.

El corpus no aporta detall sobre el capital inicial, els socis, les rondes de finançament ni les circumstàncies concretes de la constitució. Aquests elements no consten a les dades facilitades.

El corpus classifica l'empresa dins del sector de la mobilitat, però no detalla el model de negoci, els serveis concrets ni el perfil de clients. Aquesta informació no consta a les dades disponibles.

El corpus no conté dades sobre l'evolució del negoci, els ingressos, el creixement, les rondes de finançament ni les fites comercials de l'empresa. Aquesta informació no consta.

Cabify no consta com a empresa tancada. D'acord amb el registre, la societat és activa. El corpus no recull cap acte de dissolució, concurs, liquidació ni transformació societària.

Per tant, aquest apartat no té contingut aplicable al cas: no hi ha cap tancament documentat a les dades facilitades.

El corpus no permet identificar cap herència, discontinuïtat ni efecte derivat d'un tancament, atès que l'empresa consta com a activa. Aquesta informació no consta.

El corpus esmenta Juan de Antonio com a CEO i Álex Viaplana com a cofundador, sense indicar canvis en la seva vinculació amb l'empresa. No consta cap informació sobre la seva situació actual més enllà d'aquestes mencions.

Per ampliar aquest punt es podrien consultar fonts registrals actualitzades (BORME i Registre Mercantil de Barcelona) i la informació corporativa de l'empresa, que no formen part del corpus facilitat.

• El corpus no documenta cap tancament de Cabify, de manera que no se'n poden extreure lliçons sobre causes de fracàs o de transformació. Qualsevol conclusió en aquest sentit excediria les dades disponibles.
• La fitxa registral és útil per confirmar constitució, ubicació, estat i administradors, però no permet inferir res sobre el model de negoci ni sobre el finançament d'una empresa de mobilitat.
• Per analitzar una empresa de mobilitat caldria disposar de dades operatives (volum de viatges, mercats, estructura de costos, regulació aplicable), que no consten al corpus.
• La classificació com a "startup" i l'estat "activa" són compatibles, però no equivalen a rendibilitat ni a consolidació; el corpus no aporta cap dada financera que ho permeti valorar.

Reconstruir l'essència de Cabify avui no vol dir clonar una app de VTC genèrica. Vol dir muntar un operador de mobilitat urbana amb conductor professional, flota pròpia o concertada i marca de servei, en un mercat on la diferència ja no la fa tenir una app (qualsevol pot llogar-ne una de blanca), sinó la qualitat del servei, la disponibilitat real de vehicles i el compliment normatiu.

La proposta, marcada com a proposta meva i no com a fet de l'empresa original: començar en una sola ciutat (Barcelona), amb una flota limitada i controlada, servei B2B (empreses amb compte corporatiu) com a nucli de facturació, i una capa tecnològica pròpia mínima (app de passatger, app de conductor, panell de despatx). L'essència a preservar és la del 2013: mobilitat amb conductor professional i estàndard de servei alt, no micromobilitat ni transport públic.

El que està verificat: Cabify es va constituir el 2013 a Barcelona, al sector mobilitat, i consta activa al registre ([Wikipedia] Cabify — Wikipedia). Això confirma que el segment de mobilitat urbana amb conductor ha estat un mercat real i durador a l'Estat, no una moda.

El que és anàlisi meva (no verificat): el mercat actual es divideix en (a) VTC per app, molt competitiu en preu i sotmès a ràtios de llicències per comunitat autònoma; (b) taxi regulat, amb barreres d'entrada per llicència; (c) transport corporatiu i d'esdeveniments, menys sensible al preu i més sensible a la fiabilitat. La bretxa on una marca com la descrita pot entrar avui és (b) i (c): servei pactat, facturació a empresa i garantia de vehicle, més que no pas competir per la cursa del preu més baix. Mida exacta del mercat: a validar amb dades d'associacions sectorials i registres de llicències; no en disposo de xifres verificades.

Model proposat (no extret de l'empresa original, que no tinc documentada més enllà de les dades del registre):

• Ingressos per comissió sobre cada viatge (percentatge per al conductor o flota concertada) més subscripció corporativa per compte d'empresa amb facturació mensual.
• Flota mixta: un nucli petit de vehicles propis per garantir disponibilitat en hores punta i contractes, i la resta concertada amb conductors professionals.
• Preu no competitiu per baix: es ven fiabilitat, traçabilitat i factura, no el viatge més barat.
• Mètriques a vigilar: viatges per vehicle i dia, ocupació de flota, cost per viatge completat, retenció de comptes corporatius.

Percentatges i imports concrets: proposta a validar, no dades de l'empresa.

Fases, marcades com a proposta:

1. Mesos 0-3 — Validació: tancar 5-10 comptes corporatius pilots a Barcelona, assegurar llicències VTC vigents i un primer grup de 10-20 conductors. Cost baix, risc baix.
2. Mesos 3-9 — Operació mínima: llançar app de passatger i de conductor, operar una flota de 20-40 vehicles (propis + concertats), mesurar compliment de servei.
3. Mesos 9-18 — Escala a una segona ciutat només si la unitat econòmica de Barcelona és positiva.
4. Mesos 18+ — Capa B2B reforçada (integracions amb despesa d'empresa, facturació centralitzada).

Cada fase amb un criteri d'aturada explícit (si no s'assoleix X viatges/dia, no s'escala). X: a definir amb dades reals.

Totes les xifres són estimacions meves, no dades verificades, i cal validar-les amb pressupostos reals:

• Tecnologia (app passatger, app conductor, panell, backend): rang orientatiu 80.000-250.000 € segons si es compra plataforma de tercers o es desenvolupa.
• Flota inicial (20-40 vehicles, lísing o concertació): lísing per vehicle en rang de 400-900 €/mes; compra directa molt més alta. A validar amb proveïdors.
• Llicències i compliment normatiu: cost variable per comunitat autònoma; a validar amb l'autoritat de transport.
• Equip humà mínim (operacions, tecnologia, comercial): rang 150.000-400.000 €/any per a un equip de 5-10 persones.
• Màrqueting i captació B2B: 20.000-80.000 € en el primer any.

Ordre de magnitud total per als primers 12 mesos: 300.000-800.000 €, amb un marge d'error alt. És una estimació de planificació, no un pressupost.

• Regulatori: el nombre de llicències VTC està limitat per normativa autonòmica; és el risc número u i pot bloquejar l'escala. A validar abans de res.
• Competència de preu: els operadors grans poden absorbir pèrdues; una marca nova no pot competir per tarifa.
• Dependència de conductors: si la flota concertada marxa a un competidor, el servei cau.
• Capital: la mobilitat consumeix caixa abans de rendir; cal finançament per a 18-24 mesos, no per a 6.
• Risc de dades: aquí no tinc cap fet verificat de tancament ni de causes; qualsevol afirmació sobre per què hauria cessat seria inventada i no la faig.

Lliçons que es poden extreure de l'únic que està verificat de l'original (constitució el 2013 a Barcelona, sector mobilitat, dos fundadors, un com a CEO i un com a cofundador, i estat actiu al registre):

• Un equip fundador amb rols clars i complementaris (un CEO orientat a negoci i un soci orientat a producte/operacions) és el patró que la dada del registre reflecteix; replicar aquesta dualitat és més útil que buscar un sol heroi.
• Barcelona com a mercat de prova és una decisió raonable: ciutat densa, regulació coneguda i prou gran per validar sense escalar.
• Longevitat: l'empresa consta activa des del 2013, cosa que suggereix que l'essència (mobilitat amb conductor professional) aguanta cicles; el que mata aquests negocis no sol ser la idea sinó el compliment normatiu i el caixa.
• Per tant, qui ho hauria de fer és un equip disposat a començar petit, amb disciplina regulatòria i capital per a dos anys, no un equip que busqui créixer per màrqueting.

Nota final: no tinc cap font verificada que indiqui que Cabify va tancar; l'informe tracta la reconstrucció com a exercici. Si la premissa de tancament és ferma, caldria aportar la font registral corresponent abans de publicar-lo com a cas real.

Una plataforma de mobilitat que opera en diversos mercats i amb flotes mixtes (conductors autònoms, flotes col·laboradores i vehicles de l'operador) té tres punts de fricció que es retroalimenten:

1. Assignació opaca. L'assignació de viatges sol resoldre's amb cues i proximitat geogràfica simple. Això genera disputes ("per què no m'ha tocat aquest viatge?"), incentius perversos i una experiència de passatger inconsistent entre mercats.
2. Liquidació fràgil. El càlcul de comissions, bonificacions, peatges, cancel·lacions i ajustos es fa sovint en lots nocturns amb regles duplicades entre el servei de viatges i el de facturació. Els errors es descobreixen tard i són cars de reconciliar.
3. Manca d'auditoria. Quan hi ha una reclamació (conductor o passatger), no hi ha un registre reproduïble de per què es va prendre una decisió. Sense traçabilitat, cada disputa es resol manualment.

La solució proposada és un motor de despatx determinista i auditable que pren decisions reproduïbles a partir d'un snapshot d'estat, i un servei de liquidació que deriva els imports de la mateixa font de veritat que el despatx, de manera que el que es decideix i el que es paga no divergeixin mai.

Arquitectura de microserveis orientada a esdeveniments, amb un nucli síncron de baixa latència (despatx) i un pla de processament asíncron (liquidació, analítica, notificacions).

``` ┌──────────────────────────────┐ Apps client ──┤ API Gateway (auth, rate limit)│ Apps conductor│ │ └───────────────┬──────────────┘ │ ┌────────────────────────┼─────────────────────────┐ │ │ │ ┌──────▼──────┐ ┌────────▼────────┐ ┌────────▼────────┐ │ Trip Service│ │ Dispatch Engine │ │ Pricing Service │ │ (estat viatge)│ │ (subhasta+match)│ │ (tarifes) │ └──────┬──────┘ └────────┬────────┘ └────────┬────────┘ │ │ │ │ ┌───────────────┴──────────┐ │ │ │ Event Bus (Kafka) │◄─────────────┘ │ └───────────────┬──────────┘ │ │ ┌──────▼──────┐ ┌────────▼────────┐ ┌─────────────────┐ │ Geo Index │ │ Settlement Svc │ │ Audit Log Store │ │ (PostGIS + │ │ (ledger) │ │ (append-only) │ │ Redis GEO) │ └────────┬────────┘ └─────────────────┘ └─────────────┘ │ ┌──────▼──────┐ │ Payouts / │ │ Facturació │ └─────────────┘ ```

Decisions i motius:

• Separació despatx / liquidació. El despatx ha de respondre en mil·lisegons; la liquidació pot trigar segons. Barrejar-los obligaria a fer transaccions llargues al camí crític. Es comuniquen per esdeveniments, no per crides síncrones.
• Kafka com a bus. Necessitem un log ordenat per clau (viatge o conductor) i replay per reconstruir l'estat de liquidació. Un bus sense retenció (p. ex. només cues) no permetria auditar ni reprocessar.
• PostGIS + Redis GEO. PostGIS és la font de veritat geoespacial (consultes correctes, radis, polígons de zona); Redis GEO és una caché de proximitat per al camí calent. Si Redis cau, el despatx degrada a PostGIS amb més latència però no s'atura.
• Audit log append-only. Cada decisió de despatx desa l'snapshot d'entrades (candidats, puntuacions, pesos) i la sortida. És el que fa possible reproduir una decisió mesos després.
• Idempotència per clau natural. Tots els consumidors d'esdeveniments processen amb `event_id` i clau de negoci (p. ex. `trip_id`), de manera que un replay no duplica liquidacions.

Model relacional (PostgreSQL) per a l'estat transaccional i esdeveniments immutables per a l'auditoria. Els imports es guarden en unitats menors enteres (cèntims) per evitar errors de coma flotant.

```sql -- Conductor i disponibilitat CREATE TABLE driver ( driver_id UUID PRIMARY KEY, market_id TEXT NOT NULL, fleet_id UUID, -- NULL si autònom status TEXT NOT NULL, -- active | suspended | offboarded created_at TIMESTAMPTZ NOT NULL );

CREATE TABLE driver_offer ( -- ofertes enviades en una subhasta offer_id UUID PRIMARY KEY, trip_id UUID NOT NULL, driver_id UUID NOT NULL, score NUMERIC(6,4) NOT NULL, offered_at TIMESTAMPTZ NOT NULL, responded_at TIMESTAMPTZ, response TEXT -- accepted | rejected | expired );

-- Viatge CREATE TABLE trip ( trip_id UUID PRIMARY KEY, market_id TEXT NOT NULL, rider_id UUID NOT NULL, driver_id UUID, state TEXT NOT NULL, -- requested|assigned|in_progress|completed|cancelled requested_at TIMESTAMPTZ NOT NULL, assigned_at TIMESTAMPTZ, completed_at TIMESTAMPTZ, fare_minor BIGINT, -- cèntims currency CHAR(3) NOT NULL );

-- Decisió de despatx auditable CREATE TABLE dispatch_decision ( decision_id UUID PRIMARY KEY, trip_id UUID NOT NULL, input_snapshot JSONB NOT NULL, -- candidats, puntuacions, pesos, versió del motor chosen_driver_id UUID, engine_version TEXT NOT NULL, decided_at TIMESTAMPTZ NOT NULL );

-- Llibre major de liquidació (append-only) CREATE TABLE ledger_entry ( entry_id UUID PRIMARY KEY, trip_id UUID NOT NULL, driver_id UUID NOT NULL, kind TEXT NOT NULL, -- fare|commission|bonus|toll|cancellation_fee|adjustment amount_minor BIGINT NOT NULL, -- signe: + a favor del conductor, - en contra currency CHAR(3) NOT NULL, rule_version TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL ); CREATE UNIQUE INDEX ux_ledger_idem ON ledger_entry (trip_id, driver_id, kind, rule_version); ```

Motius:

• `input_snapshot` en JSONB: el conjunt de candidats i pesos varia per mercat i versió del motor; un esquema rígid obligaria a migracions constants. El JSONB permet reproduir la decisió sense perdre informació.
• `engine_version` i `rule_version`: sense versionar regles, un canvi de comissió faria irreconciliables els càlculs històrics.
• Índex únic d'idempotència al ledger: garanteix que un replay d'esdeveniments no generi dobles pagaments.

APIs REST/JSON per a clients i conductors, i esdeveniments per a sistemes interns. Totes les respostes inclouen `request_id` per correlacionar amb l'audit log.

Endpoints principals (v1):

``` POST /v1/trips # sol·licita viatge; retorna trip_id i estat GET /v1/trips/{trip_id} # estat i dades de despatx (sense PII innecessària) POST /v1/drivers/{id}/offers/{offer_id}/respond # accept | reject GET /v1/drivers/{id}/earnings?from=&to= # resum des del ledger POST /v1/settlements/recompute # reprocessa un rang (operacions, idempotent) ```

Esdeveniments (Kafka, clau = `trip_id`):

``` trip.requested → Dispatch Engine trip.assigned → Trip Service, Settlement trip.completed → Settlement, Analytics trip.cancelled → Settlement ledger.entry.posted → Payouts, Facturació ```

Integracions externes:

• Passarel·la de pagament per a cobraments al passatger i pagaments al conductor; es tracta com a sistema extern amb reconciliació diària per `payout_batch_id`.
• Proveïdor de mapes/routing per a distància i ETA; s'usa com a input del càlcul de tarifa, mai com a font de veritat de la decisió.
• Sistema fiscal/facturació per mercat: consumeix `ledger.entry.posted` i genera documents; no recalcula imports.

Motiu de disseny: el despatx i la liquidació comparteixen els mateixos esdeveniments i versions de regla, de manera que la font de veritat és única. Les integracions externes són sempre downstream i mai al camí crític de l'assignació.

Ordre d'implementació pensat per reduir risc i obtenir valor aviat:

1. Trip Service + model de dades base (trip, driver, estats). Sense això no hi ha res a despatxar ni liquidar.
2. Dispatch Engine v0 determinista: subhasta per proximitat + puntuació simple, amb `dispatch_decision` desat des del primer dia. Encara que la puntuació sigui bàsica, l'auditoria ha d'existir des del principi (afegir-la després és car).
3. Settlement Svc amb ledger idempotent i una sola regla de comissió per mercat. Validar el cicle complet viatge → esdeveniment → apunt al ledger.
4. Audit log i eina de reproducció d'una decisió a partir de `input_snapshot`.
5. Integració de pagaments amb reconciliació diària.
6. Pricing Service amb tarifes per mercat i versionat de regles.

Es deixa per a fases posteriors: optimització avançada de matching (ML), bonificacions dinàmiques i multi-mercat complet.

Mides orientatives (per dimensionar, no compromeses):

• Despatx: pic de ~2.000 sol·licituds/minut per mercat gran; latència objectiu p95 < 300 ms per decisió.
• Esdeveniments: ~10× el volum de viatges (ofertes, respostes, estats); retenció de 30 dies al bus i arxiu a object storage.
• Ledger: ~5-10 apunts per viatge; creixement lineal amb viatges, partició per mes i mercat.

Riscos tècnics i mitigació:

| Risc | Impacte | Mitigació | |---|---|---| | Biaix o manipulació del motor de matching | Disputes, frau | Snapshot auditable + revisió periòdica de distribucions per conductor | | Replay d'esdeveniments