Cabify

Cabify, con razón social CABIFY, S.L., es una empresa del sector de la movilidad constituida en Barcelona en el año 2013. De acuerdo con el registro, la empresa consta como activa. El corpus no recoge ningún acto de disolución, liquidación o transformación societaria.

Se trata, por tanto, de un caso de empresa que no ha cerrado según la información disponible, y no de un caso de cierre o transformación. El informe describe lo que consta y señala explícitamente lo que no consta.

La sociedad se constituyó en el año 2013 en Barcelona, según la cronología registral disponible. Los fundadores que constan en el corpus son Juan de Antonio, como consejero delegado (CEO), y Álex Viaplana, como cofundador.

El corpus no aporta detalle sobre el capital inicial, los socios, las rondas de financiación ni las circunstancias concretas de la constitución. Estos elementos no constan en los datos facilitados.

El corpus clasifica la empresa dentro del sector de la movilidad, pero no detalla el modelo de negocio, los servicios concretos ni el perfil de clientes. Esta información no consta en los datos disponibles.

El corpus no contiene datos sobre la evolución del negocio, los ingresos, el crecimiento, las rondas de financiación ni los hitos comerciales de la empresa. Esta información no consta.

Cabify no consta como empresa cerrada. De acuerdo con el registro, la sociedad es activa. El corpus no recoge ningún acto de disolución, concurso, liquidación ni transformación societaria.

Por tanto, este apartado no tiene contenido aplicable al caso: no hay ningún cierre documentado en los datos facilitados.

El corpus no permite identificar ninguna herencia, discontinuidad ni efecto derivado de un cierre, dado que la empresa consta como activa. Esta información no consta.

El corpus menciona a Juan de Antonio como CEO y a Álex Viaplana como cofundador, sin indicar cambios en su vinculación con la empresa. No consta ninguna información sobre su situación actual más allá de estas menciones.

Para ampliar este punto se podrían consultar fuentes registrales actualizadas (BORME y Registro Mercantil de Barcelona) y la información corporativa de la empresa, que no forman parte del corpus facilitado.

• El corpus no documenta ningún cierre de Cabify, de modo que no se pueden extraer lecciones sobre causas de fracaso o de transformación. Cualquier conclusión en este sentido excedería los datos disponibles.
• La ficha registral es útil para confirmar constitución, ubicación, estado y administradores, pero no permite inferir nada sobre el modelo de negocio ni sobre la financiación de una empresa de movilidad.
• Para analizar una empresa de movilidad habría que disponer de datos operativos (volumen de viajes, mercados, estructura de costes, regulación aplicable), que no constan en el corpus.
• La clasificación como "startup" y el estado "activa" son compatibles, pero no equivalen a rentabilidad ni a consolidación; el corpus no aporta ningún dato financiero que permita valorarlo.

Avís previ: la premissa de l'encàrrec ("una empresa que va tancar") no es pot sostenir amb les dades verificades. Cabify, S.L. consta com a activa i constituïda el 2013 a Barcelona, amb Juan de Antonio com a CEO i Álex Viaplana com a cofundador (font: Wikipedia). No tinc cap font verificada que indiqui tancament. Per tant, tot el que segueix és un exercici hipotètic de proposta, no una reconstrucció d'una empresa desapareguda.

La idea, avui, seria construir una plataforma de mobilitat amb conductor professional (no ride-hailing de particulars) en un mercat on la regulació, la fiscalitat i la competència han canviat molt des del 2013. L'essència seria: agregar demanda, professionalitzar l'oferta de conductors i vehicles, i cobrar una comissió per viatge, amb èmfasi en flotes i serveis corporatius.

El mercat de mobilitat urbana amb conductor a Espanya i Llatinoamèrica existeix i està consolidat, però és intensiu en capital i molt regulat. Els elements que un nou entrant hauria de validar (no són dades verificades de Cabify, sinó hipòtesis de mercat a contrastar):

• Regulació per ciutat: llicències VTC, ràtios, restriccions horàries i requisits de flota varien per municipi i comunitat; cal validar cas per cas.
• Competència: hi ha operadors consolidats i plataformes globals; un nou entrant hauria de trobar un nínxol (corporatiu, aeroportuari, ciutats mitjanes, flotes pròpies).
• Cost d'adquisició: tant de passatgers com de conductors; és el principal motor de cremat de caixa en aquest sector (estimació qualitativa, a validar amb dades de cohort).

Proposta (no verificada):

• Comissió per viatge sobre el preu pagat pel passatger (rang habitual del sector: 15–25%; estimació, a validar).
• Contractes B2B: comptes corporatius amb facturació mensual, que redueixen el cost d'adquisició i estabilitzen ingressos.
• Flotes associades: acords amb titulars de llicències VTC per garantir oferta sense assumir el cost fix dels vehicles.
• Serveis complementaris: aeroport, esdeveniments, trasllats interurbans (a validar per ciutat).

El punt crític és l'equilibri oferta-demanda per ciutat: sense densitat de conductors no hi ha temps d'espera acceptable, i sense demanda no hi ha conductors que hi vulguin operar.

Proposta, per fases (a validar):

1. Fase 0 — Validació legal (1–3 mesos): confirmar requisits de llicència VTC i ràtios a la ciutat pilot; assessoria jurídica local.
2. Fase 1 — Ciutat pilot (3–6 mesos): llançar en una sola ciutat amb flota associada limitada (rang estimat: 50–150 vehicles; a validar) i un producte B2B inicial.
3. Fase 2 — Densitat i unitat econòmica (6–12 mesos): mesurar temps d'espera, cost per viatge i marge per ciutat; no expandir fins a unitat econòmica positiva o camí clar.
4. Fase 3 — Segona ciutat (12–18 mesos): replicar només si la fase 2 dona números.

Totes les xifres són estimacions de rang, no dades verificades, i requereixen validació:

• Constitució, legal i llicències: rang estimat 20.000–80.000 € (depèn de ciutat i nombre de llicències VTC; a validar).
• Producte i tecnologia (MVP): rang estimat 150.000–400.000 € (app passatger, app conductor, panell d'operacions; a validar).
• Equip inicial (6–12 persones, 12 mesos): rang estimat 400.000–900.000 € (a validar segons salaris i ubicació).
• Màrqueting i adquisició inicial: rang estimat 100.000–300.000 € per ciutat pilot (a validar).
• Capital de maniobra i imprevistos: 15–25% addicional sobre el total (estimació).

Ordre de magnitud total per a un pilot d'un any en una ciutat: rang estimat 0,8–2,0 M€, a validar amb un pressupost detallat.

• Regulatori: canvis de ràtio o moratòries poden invalidar el model en una ciutat (risc alt, a validar per jurisdicció).
• Competència i guerra de preus: els operadors consolidats poden subsidiar viatges; un entrant petit no ho pot sostenir.
• Efecte xarxa: sense densitat, el producte no és competitiu; cal capital per cremar durant la fase de densitat.
• Laboral i reputacional: la relació amb conductors i flotes és sensible; cal un model contractual clar des del dia 1.
• Risc de premissa: l'encàrrec parteix d'un tancament no verificat; qualsevol pla que assumeixi aquest fet seria invàlid.

Lliçons del que hauria estat l'informe original (i del que les dades permeten dir):

• Verificar la premissa abans de planificar: les dades registrals diuen "activa"; un pla de reconstrucció sense fet de tancament verificat no és un pla, és una hipòtesi. La primera lliçó és separar fet verificat de proposta.
• El valor està en l'execució local, no en la idea: una plataforma de mobilitat és un negoci regulat ciutat a ciutat; qui ho hauria de fer és un equip amb capacitat legal, operativa i de flota a la ciutat pilot, no només un equip tecnològic.
• Cal capital pacient i disciplina de fases: l'error típic és expandir abans de demostrar unitat econòmica en una ciutat.
• Perfil recomanat (proposta): un equip fundador amb experiència en operacions de transport o flotes, un responsable legal/regulatori i un producte tècnic capaç de llançar un MVP en 3–6 mesos; acompanyat d'inversors que acceptin un horitzó de 18–24 mesos fins a la segona ciutat.

Nota final: si l'objectiu real és analitzar Cabify com a empresa activa (estratègia, mercat, competència), puc fer-ho, però llavors l'informe hauria de canviar de format: no seria un pla de reconstrucció, sinó una anàlisi de negoci en funcionament.

Cabify és una startup del sector software i SaaS amb seu a Barcelona, registrada com a activa segons les dades disponibles; la referència pública [Wikipedia] Cabify descriu la seva activitat com a plataforma de mobilitat amb conductor (ride-hailing) operant en diversos mercats de parla hispana i portuguesa. El problema tècnic central d'aquest tipus de producte no és l'app de passatger, sinó el despatx: decidir en menys d'un segon quin conductor rep cada sol·licitud, amb regles de preu diferents per ciutat, i deixar un rastre auditable de cada decisió per facturar i resoldre disputes.

Els errors típics que cal evitar i que aquesta especificació ataca de front:

• Assignació feta amb consultes SQL sobre la taula de posicions: no escala i bloqueja la base de dades transaccional.
• Preus calculats dins del codi de l'app mòbil: impossibilita canviar tarifes per mercat sense publicar una versió nova.
• Estat del viatge com a camps mutables (`status`, `driver_id`) sense historial: no es pot reconstruir per què un viatge es va cancel·lar ni qui tenia la responsabilitat en un moment donat.

Tres plans separats, comunicats per esdeveniments:

``` [App passatger] --HTTPS--> [API Gateway] --> [Servei de Reserves] --event--> [Bus (Kafka)] [App conductor] --WSS----> [Servei de Presència] --posicions--> [Redis GEO + PostGIS] | [Bus] --> [Motor de Despatx] --oferta--> [Servei de Presència] --WSS--> [App conductor] [Bus] --> [Motor de Preus] --> tarifa aplicada [Bus] --> [Llibre Major] --> [Facturació per mercat] ```

• Servei de Reserves (HTTP, stateless): rep la sol·licitud, valida el passatger, crea l'agregat `Ride` en estat `REQUESTED` i publica `ride.requested`. Escriu a PostgreSQL només l'estat inicial; la resta és event-sourcing.
• Servei de Presència (WebSocket): manté les connexions dels conductors, rep `driver.location` cada 3-5 s i l'escriu a Redis amb índex geoespacial (`GEOADD`). És l'única peça que ha de respondre en mil·lisegons.
• Motor de Despatx (consumidor de Kafka): per cada `ride.requested`, consulta Redis GEO per candidats en un radi creixent (1 km → 2 km → 4 km), puntua i envia ofertes per WebSocket amb timeout de 15 s i reintent a un altre conductor.
• Motor de Preus: servei independent amb una regla per mercat (Barcelona, Madrid, Ciutat de Mèxic...). Rep `ride.requested` i retorna `fare.quoted`; les tarifes viuen en configuració versionada, no al codi.
• Llibre Major: consumidor que projecta tots els esdeveniments econòmics (`fare.quoted`, `ride.completed`, `ride.cancelled`) en un model de doble entrada per a facturació.

Motiu de les decisions: Redis GEO perquè les consultes de proximitat sobre PostGIS amb escriptures constants de posició degraden el rendiment de les transaccions; event-sourcing perquè el viatge és un procés amb estats i disputes que exigeixen auditoria; motor de preus aïllat perquè els canvis tarifaris per mercat són freqüents i no han de requerir desplegar el nucli.

Agregat `Ride` (event-sourced, persistit a `ride_events`):

```sql CREATE TABLE ride_events ( ride_id uuid NOT NULL, seq int NOT NULL, event_type text NOT NULL, -- requested|offered|accepted|started|completed|cancelled payload jsonb NOT NULL, actor text NOT NULL, -- passenger|driver|system occurred_at timestamptz NOT NULL DEFAULT now(), PRIMARY KEY (ride_id, seq) ); ```

Projecció de lectura `rides` (per consultes ràpides, reconstruïble):

```sql CREATE TABLE rides ( ride_id uuid PRIMARY KEY, passenger_id uuid NOT NULL, driver_id uuid, market text NOT NULL, -- 'es-bcn', 'mx-cdmx' status text NOT NULL, pickup geography(Point,4326) NOT NULL, dropoff geography(Point,4326) NOT NULL, fare_quoted numeric(10,2), fare_final numeric(10,2), currency char(3) NOT NULL, created_at timestamptz NOT NULL ); CREATE INDEX ON rides USING gist (pickup); ```

Taules de suport:

• `drivers` (id, market, vehicle_type, estat de disponibilitat).
• `fare_rules` (market, versió, condicions jsonb, vigència) — versionada per poder recalcular un viatge antic amb la regla que s'hi va aplicar.
• `ledger_entries` (ride_id, compte, import, moneda, tipus) — doble entrada per a facturació.

Motiu: `geography(Point,4326)` perquè les distàncies siguin en metres reals independentment de la latitud; `fare_rules` versionada perquè una disputa de preu es pugui resoldre amb la tarifa vigent en el moment del viatge.

• `POST /v1/rides` — crea la sol·licitud; retorna `ride_id` i `fare.quoted`. Idempotent per `Idempotency-Key`.
• `GET /v1/rides/{id}` — estat projectat; lectura eventualment consistent (SLA < 200 ms).
• `POST /v1/rides/{id}/cancel` — cancel·lació amb actor; genera esdeveniment i possible càrrec segons regla de mercat.
• `WS /v1/driver/stream` — canal bidireccional: el conductor envia `location` i `availability`; rep `offer` i `offer_expired`.
• `POST /internal/dispatch/offer-response` — acceptació/rebuig d'oferta des del servei de presència.
• Integracions externes: passarel·la de pagament (tokenització, captura diferida en finalitzar el viatge) i proveïdor de mapes/routing per a distància i ETA (cridat pel motor de preus, amb caché per cel·la de 500 m).

Motiu: WebSocket per al conductor perquè el despatx necessita push en menys d'un segon; HTTP idempotent per al passatger perquè els reintents de xarxa mòbil no han de duplicar viatges ni càrrecs.

1. Esquelet d'esdeveniments: `ride_events` + projecció `rides` + servei de reserves amb `POST /v1/rides` i `GET /v1/rides/{id}`. Sense despatx encara.
2. Servei de presència amb Redis GEO i simulador de conductors (per provar sense flota real).
3. Motor de despatx amb radi creixent i timeout d'oferta; mètrica d'assignació per segon.
4. Motor de preus amb una sola regla de mercat (Barcelona) i versió de tarifa.
5. Llibre major i facturació bàsica en finalitzar viatge.

Motiu de l'ordre: cada peça es pot validar amb les anteriors; el simulador de conductors permet provar el despatx abans de tenir apps mòbils.

• Volum de posicions: 5.000 conductors actius × 1 posició/4 s ≈ 1.250 escriptures/s a Redis; assumible amb un sol node, però cal partició per mercat si se superen els 20.000 conductors.
• Risc: bucle d'ofertes si el timeout i el reintent no són idempotents — mitigació: `offer_id` únic i estat `OFFERED` a l'agregat.
• Risc: doble assignació per consum concurrent de Kafka — mitigació: partició per `ride_id` i escriptura amb `seq` esperat (optimistic concurrency).
• Risc: latència del motor de preus dins del camí crític — mitigació: caché de tarifes per mercat i càlcul de distància amb caché per cel·la.
• Risc: consistència eventual entre projecció i esdeveniments — mitigació: reconstrucció de projecció des de `ride_events` i alerta si el lag supera 5 s.

• Test d'assignació: amb 1.000 conductors simulats i 100 sol·licituds/s, el 95% de les sol·licituds han de rebre oferta en menys de 3 s (p95), mesurat en entorn d'staging.
• Test d'idempotència: 10 reintents del mateix `POST /v1/rides` amb la mateixa `Idempotency-Key` han de produir un sol `ride_id` i un sol esdeveniment `requested`.
• Test de preus per mercat: la mateixa ruta a Barcelona i a un altre mercat amb regles diferents ha de retornar tarifes diferents i traçables a la versió de `fare_rules`.
• Test de reconstrucció: esborrar la projecció `rides`, reproduir `ride_events` i obtenir exactament el mateix estat final.
• Test de disputa: un viatge cancel·lat ha de poder-se auditar mostrant la seqüència d'esdeveniments amb actor i hora.

Nota sobre fonts: les afirmacions sobre l'activitat de Cabify es basen en la referència [Wikipedia] Cabify; les dades registrals (startup, sector software i SaaS, seu a Barcelona, estat actiu) provenen de les dades verificades facilitades.