Bipi

Bipi consta com una startup del sector de software i SaaS amb seu a Barcelona (Barcelona). Segons les dades disponibles, la seva raó social és BIPI i el seu estat registral és actiu.

No consta a la font disponible cap descripció de la seva activitat concreta, del producte que oferia ni del model de negoci.

No consta. La font disponible no recull la data de fundació, els fundadors ni les circumstàncies de la creació de l'empresa.

No consta. La font disponible no descriu quin producte o servei oferia Bipi ni a quin tipus de client s'adreçava, més enllà de la classificació sectorial com a software i SaaS.

No consta. La font disponible no aporta dades sobre l'evolució del negoci, el creixement, la facturació, el finançament o les fites assolides.

No consta cap tancament. D'acord amb les dades facilitades, l'estat registral de Bipi és actiu. La font disponible no indica cap procés de dissolució, concurs, venda o transformació societària.

No consta. La font disponible no recull cap element sobre el llegat de l'empresa, productes derivats, equips que hagin continuat el projecte o impacte en el sector.

No consta. La font disponible no identifica els fundadors de Bipi ni aporta cap traça sobre la seva situació actual.

Per aprofundir-hi, es podrien consultar el Registre Mercantil de Barcelona (comptes anuals i càrrecs), el BORME per a actes societaris i les bases de dades d'empreses i de finançament de startups.

Amb la informació disponible no es pot extreure cap lliçó operativa específica sobre el sector, perquè la font no documenta l'activitat, l'estratègia ni l'evolució de Bipi. Qualsevol conclusió sobre el seu cas seria una suposició i, per tant, no es formula.

Per poder-ne treure aprenentatges aplicables caldria disposar, com a mínim, de les dades registrals (comptes dipositats, canvis d'administradors, ampliacions i reduccions de capital) i de fonts periodístiques que documentin el producte, els clients i les decisions de gestió.

Bipi operava en el negoci de la subscripció de cotxes: el client paga una quota mensual i obté un vehicle amb assegurança, manteniment i impostos inclosos, sense comprar-lo ni comprometre's a un leasing llarg. Aquesta és l'essència que es pot reconstruir avui.

La proposta actual seria la mateixa idea, però amb una diferència clau de disseny: en lloc de comprar o finançar una flota pròpia gran (que és el que fa pesant el model), començar amb una flota mínima pròpia o en cessió de tercers i un programari de gestió propi. És a dir, separar el que és producte (l'accés flexible al cotxe) del que és actiu (la propietat de la flota).

Nota: aquesta és una proposta de reconstrucció, no una descripció de com operava Bipi, de la qual només tenim la informació pública recollida a la font citada.

El mercat de referència és el de mobilitat flexible per subscripció: usuaris que volen cotxe sense comprar-lo, per períodes curts o mitjans, amb tot inclòs. És un mercat real i actiu a Espanya i Europa, on conviuen operadors de subscripció, de rènting i de carsharing.

El que no podem afirmar amb la font disponible és la mida exacta del mercat de Bipi ni la seva quota. Qualsevol xifra de mercat que es faci servir per al pla s'ha de tractar com a estimació a validar amb dades d'un estudi de mercat propi abans d'invertir.

El segment més plausible per començar és el d'usuaris urbans que necessiten cotxe de forma intermitent (feina, caps de setmana, desplaçaments puntuals) i que no volen assumir la compra ni un contracte llarg.

Model proposat (a validar):

• Ingressos: quota mensual de subscripció per vehicle, amb durada mínima curta (per exemple, 1 mes) i possibilitat de canvi de vehicle. Proposta.
• Estructura de costos lleugera: en lloc de comprar flota, començar amb flota en cessió o lloguer a operadors, de manera que el cost variable acompanyi els ingressos. Proposta.
• Marge: el marge dependria de la diferència entre la quota cobrada i el cost real del vehicle (lloguer/amortització, assegurança, manteniment, impostos). Aquest marge s'ha de calcular amb números reals abans de llançar. Estimació a validar.
• Programari: el valor diferencial és la plataforma de gestió de subscripcions, contractes, flota i cobraments; és el que permet escalar sense multiplicar costos fixos. Proposta.

No tenim dades verificades sobre els preus que aplicava Bipi, de manera que qualsevol xifra de quota és una estimació de treball, no un fet.

Fases proposades (a validar):

1. Fase 0 — Validació (1-2 mesos): entrevistes a usuaris potencials i càlcul del cost real per vehicle i mes amb un o dos operadors de flota. Objectiu: saber si el marge és positiu abans de vendre res.
2. Fase 1 — Pilot tancat (3-6 mesos): 10-20 vehicles en cessió, plataforma mínima (contractes, cobrament, gestió d'incidències), un sol segment de client.
3. Fase 2 — Obertura controlada: ampliar flota i segments només si el marge per vehicle és positiu i la rotació és raonable.
4. Fase 3 — Escalat: negociar condicions de flota a escala i, si cal, incorporar flota pròpia de forma gradual.

Cada fase ha de tenir un criteri d'aturada clar (per exemple, marge negatiu per vehicle o rotació massa baixa).

Totes les xifres següents són estimacions de rang, a validar, no dades de Bipi:

• Desenvolupament de la plataforma mínima: rang orientatiu de 30.000–80.000 € (estimació), segons si es fa amb equip propi o extern.
• Flota inicial en cessió/lloguer: cost variable per vehicle; el número dependrà de les condicions negociades (estimació a validar amb operadors).
• Assegurances i manteniment: cost per vehicle i mes, a cotitzar amb asseguradores (estimació a validar).
• Equip mínim: 2-4 persones en la fase pilot (producte, operacions i comercial), cost salarial segons mercat (estimació).
• Màrqueting i adquisició inicial: pressupost de prova, a definir segons el cost per client que es mesuri al pilot (estimació).

La conclusió pràctica: el cost d'entrada és moderat si la flota no es compra, i molt alt si es compra. Aquesta és la decisió financera central del projecte.

• Risc de marge: si la quota no cobreix el cost real del vehicle, el model no funciona a escala. Cal validar-ho abans de créixer.
• Risc de rotació: si els clients mantenen el vehicle massa temps o massa poc, la gestió de flota es complica i el marge es deteriora.
• Risc de dependència de tercers: si la flota és en cessió, el negoci depèn de les condicions dels operadors.
• Risc de competència: el mercat de mobilitat flexible té operadors consolidats; cal un nínxol clar.
• Risc de reputació del nom: si es reutilitza la marca Bipi, cal valorar si el tancament anterior afecta la confiança del client. Proposta: valorar si convé una marca nova.

Lliçons de l'informe original (a partir de la informació pública disponible):

• El producte no és el cotxe, és la gestió. El valor està en la plataforma i en l'operació, no en posseir flota.
• La flota pesada mata el marge. Començar lleuger i escalar només amb números positius.
• Cal validar el marge per vehicle abans de créixer. És la lliçó central d'un model de subscripció.
• El nínxol és més segur que el mercat general. Un segment concret amb necessitat clara és millor punt de partida que competir de front.
• Qui ho hauria de fer: un equip petit amb experiència en operacions de flota o mobilitat i en producte digital, capaç de negociar amb operadors i de mesurar costos amb rigor. No cal un equip gran; cal un equip que sàpiga comptar el cost real per vehicle i mes.

El negoci de subscripció de vehicles té tres fonts de complexitat que un SaaS genèric no cobreix: l'estat físic del vehicle canvia (disponible, reservat, lliurat, en manteniment, retornat), el contracte genera cobraments periòdics que han de quadrar amb el calendari real d'ús, i la flota té costos variables (assegurança, manteniment, sancions) que determinen el marge per unitat.

La font disponible ([Wikipedia] Bipi — Wikipédia) situa Bipi com una startup de Barcelona del sector Software i SaaS; a partir d'aquí, la solució que es descriu no pretén replicar detalls interns no verificats, sinó resoldre el problema operatiu estàndard del model: evitar dobles reserves, evitar cobraments duplicats o fallits en silenci, i saber en tot moment quin vehicle és rendible i quin no.

El problema central és la consistència entre tres estats que viuen en sistemes diferents: l'estat del vehicle (físic), l'estat del contracte (legal/comercial) i l'estat del cobrament (financer). Si no es modelen explícitament i amb transicions validades, apareixen els errors típics: cotxe lliurat a dos clients, subscripció activa sense cobrament, o baixa de contracte sense retorn de vehicle registrat.

Arquitectura de microserveis moderada, no per moda sinó perquè els cicles de canvi són diferents: la flota canvia poc i ha de ser molt estable; la facturació canvia sovint per requisits fiscals i de passarel·la de pagament; el panell operatiu canvia constantment. Separar-los permet desplegar facturació sense tocar el domini de flota.

Components:

• API Gateway (p. ex. Kong o AWS API Gateway): autenticació, rate limiting i enrutament. Motiu: un únic punt d'entrada per a panell, app de client i integracions.
• Servei de Flota (Node.js/NestJS o Go): CRUD de vehicles, transicions d'estat, assignació a contracte. Motiu: el cicle de vida del vehicle és el domini més crític i ha de tenir transicions explícites.
• Servei de Subscripcions (Node.js/NestJS): contractes, períodes, pauses, cancel·lacions, càlcul de pròrrogues. Motiu: la lògica de calendari i prorrateig és complexa i canvia sovint.
• Servei de Facturació (Python o Node): generació de factures, cobraments recurrents, reintents, conciliació. Motiu: la integració amb Stripe i la idempotència requereixen un servei aïllat i auditable.
• Servei de Notificacions: correu i push per a recordatoris de pagament, lliuraments i retorns.
• Base de dades: PostgreSQL per servei (database-per-service) amb esquemes separats. Motiu: aïllament de fallades i evolució independent; PostgreSQL perquè les transaccions i les restriccions d'integritat són necessàries per a reserves i cobraments.
• Cua d'esdeveniments: RabbitMQ o SQS per a esdeveniments de domini (`vehicle.reserved`, `subscription.activated`, `invoice.paid`). Motiu: desacoblar facturació de flota i permetre reintents.
• Cache: Redis per a disponibilitat de vehicles en temps real al panell.

Flux principal (text):

``` Client tria vehicle -> API Gateway -> Subscripcions crea reserva (estat PENDING) -> Subscripcions publica vehicle.reserved -> Flota marca vehicle RESERVED -> Facturació crea primera factura i cobra (idempotent per subscription_id+period) -> Si cobrament OK: Subscripcions activa contracte, Flota marca vehicle DELIVERED -> Si cobrament KO: reintents programats; si s'esgota, reserva expira i vehicle torna a AVAILABLE ```

Cada transició d'estat s'escriu en una taula d'auditoria (`state_transitions`) amb actor, timestamp i motiu. Motiu: sense auditoria no es pot resoldre una disputa de cobrament o de disponibilitat.

Esquema relacional a PostgreSQL, amb taules per domini. Les claus i restriccions són part del disseny, no un afegit.

Flota

```sql vehicles ( id UUID PK, vin TEXT UNIQUE NOT NULL, plate TEXT UNIQUE NOT NULL, model TEXT NOT NULL, status TEXT NOT NULL CHECK (status IN ('AVAILABLE','RESERVED','DELIVERED','MAINTENANCE','RETIRED')), location_id UUID NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() )

vehicle_state_transitions ( id BIGSERIAL PK, vehicle_id UUID NOT NULL REFERENCES vehicles(id), from_status TEXT, to_status TEXT NOT NULL, reason TEXT, actor TEXT NOT NULL, occurred_at TIMESTAMPTZ NOT NULL DEFAULT now() ) ```

Subscripcions

```sql subscriptions ( id UUID PK, customer_id UUID NOT NULL, vehicle_id UUID NOT NULL REFERENCES vehicles(id), plan_id UUID NOT NULL, status TEXT NOT NULL CHECK (status IN ('PENDING','ACTIVE','PAUSED','CANCELLED','ENDED')), start_date DATE NOT NULL, end_date DATE, monthly_price_cents INTEGER NOT NULL CHECK (monthly_price_cents > 0), created_at TIMESTAMPTZ NOT NULL DEFAULT now() )

-- Restricció clau: un vehicle no pot tenir dues subscripcions actives CREATE UNIQUE INDEX one_active_subscription_per_vehicle ON subscriptions (vehicle_id) WHERE status IN ('PENDING','ACTIVE','PAUSED'); ```

Motiu de l'índex parcial: garanteix a nivell de base de dades que no es pot assignar el mateix vehicle a dos contractes actius, independentment de la lògica d'aplicació.

Facturació

```sql invoices ( id UUID PK, subscription_id UUID NOT NULL REFERENCES subscriptions(id), period_start DATE NOT NULL, period_end DATE NOT NULL, amount_cents INTEGER NOT NULL, status TEXT NOT NULL CHECK (status IN ('DRAFT','OPEN','PAID','FAILED','VOID')), external_payment_id TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), UNIQUE (subscription_id, period_start) ) ```

Motiu de la clau única `(subscription_id, period_start)`: fa idempotent la generació de factures; un reintent del job no pot crear una segona factura del mateix període.

Costos de flota (per calcular marge)

```sql vehicle_costs ( id BIGSERIAL PK, vehicle_id UUID NOT NULL REFERENCES vehicles(id), cost_type TEXT NOT NULL CHECK (cost_type IN ('INSURANCE','MAINTENANCE','FINE','DEPRECIATION')), amount_cents INTEGER NOT NULL, incurred_on DATE NOT NULL ) ```

API REST versionada (`/v1`), autenticada amb OAuth2/JWT. Els endpoints crítics són idempotents.

Flota

• `GET /v1/vehicles?status=AVAILABLE&location_id=...` — llistat amb filtre; cache Redis de 30 s.
• `POST /v1/vehicles/{id}/transitions` — cos `{ "to": "MAINTENANCE", "reason": "..." }`; retorna 409 si la transició no és permesa per la màquina d'estats.

Subscripcions

• `POST /v1/subscriptions` — requereix capçalera `Idempotency-Key`; retorna 201 o el recurs existent si la clau ja s'ha vist.
• `POST /v1/subscriptions/{id}/pause` i `/cancel` — validen l'estat d'origen.

Facturació

• `POST /v1/invoices/{id}/charge` — idempotent per `invoice_id`; crida Stripe amb la mateixa clau d'idempotència.
• `POST /v1/webhooks/stripe` — verifica signatura, actualitza `invoices.status` i publica `invoice.paid` o `invoice.failed`.

Integracions externes

• Stripe (o similar) per a cobraments recurrents i SEPA. Motiu: no construir gestió de targetes ni compliment PCI propi.
• Proveïdor de correu transaccional (SendGrid/Postmark) per a notificacions.
• Webhook entrant de Stripe com a font de veritat del cobrament; el nostre estat no es marca `PAID` fins que arriba el webhook, no per la resposta síncrona. Motiu: la resposta síncrona pot perdre's i el webhook és el registre fiable.

Ordre pensat per tenir un producte operatiu mínim que ja generi ingressos i no perdi diners:

1. Model de dades i màquina d'estats del vehicle amb auditoria. Sense això, res més és fiable.
2. Servei de Subscripcions amb l'índex únic d'activitat per vehicle i la creació idempotent de contractes.
3. Servei de Facturació amb generació de factures per període i cobrament idempotent via Stripe, inclòs el webhook.
4. Panell operatiu mínim: llistat de vehicles per estat, accions de transició, i vista de subscripcions actives amb estat de cobrament.
5. Notificacions de recordatori i de fallada de cobrament.

Es deixa per a una segona fase: càlcul de marge per vehicle, app de client, pauses i prorrateig avançat, i integració de sancions.

Mides: per a una flota de fins a ~2.000 vehicles i ~5.000 subscripcions actives, un PostgreSQL per servei amb una instància mitjana és suficient; el volum de factures és de l'ordre de desenes de milers l'any, trivial per a PostgreSQL. La càrrega real és la latència del panell i la fiabilitat dels webhooks, no el volum.

Riscos tècnics i mitigació

• Doble reserva: mitigat per l'índex únic parcial i per la idempotència de `POST /v1/subscriptions`; cal provar-ho amb tests de concurrència.
• Cobrament duplicat: mitigat per la clau única `(subscription_id, period_start)` i per `Idempotency-Key` cap a Stripe.
• Webhook perdut: mitigat amb un job de reconciliació diari que consulta Stripe per factures `OPEN` amb més de 24 h.
• Deriva d'estat vehicle/contracte: mitigat amb esdeveniments i una comprovació periòdica que detecta vehicles `DELIVERED` sense subscripció `ACTIVE`.
• Complexitat de microserveis prematura: risc d'excés d'enginyeria; mitigació: començar amb els tres serveis de domini i un sol desplegament orquestrat, separant només quan el volum ho justifiqui.

• Tests de domini: màquina d'estats del vehicle amb tots els parells origen/destí i els casos prohibits (esperat 409).
• Tests de concurrència: dues peticions simultànies de reserva del mateix vehicle; exactament una ha de reeixir (verificant