Bipi

Bipi consta como una startup del sector de software y SaaS con sede en Barcelona (Barcelona). Según los datos disponibles, su razón social es BIPI y su estado registral es activo.

No consta en la fuente disponible ninguna descripción de su actividad concreta, del producto que ofrecía ni del modelo de negocio.

No consta. La fuente disponible no recoge la fecha de fundación, los fundadores ni las circunstancias de la creación de la empresa.

No consta. La fuente disponible no describe qué producto o servicio ofrecía Bipi ni a qué tipo de cliente se dirigía, más allá de la clasificación sectorial como software y SaaS.

No consta. La fuente disponible no aporta datos sobre la evolución del negocio, el crecimiento, la facturación, la financiación o los hitos alcanzados.

No consta ningún cierre. De acuerdo con los datos facilitados, el estado registral de Bipi es activo. La fuente disponible no indica ningún proceso de disolución, concurso, venta o transformación societaria.

No consta. La fuente disponible no recoge ningún elemento sobre el legado de la empresa, productos derivados, equipos que hayan continuado el proyecto o impacto en el sector.

No consta. La fuente disponible no identifica a los fundadores de Bipi ni aporta ningún rastro sobre su situación actual.

Para profundizar, se podrían consultar el Registro Mercantil de Barcelona (cuentas anuales y cargos), el BORME para actos societarios y las bases de datos de empresas y de financiación de startups.

Con la información disponible no se puede extraer ninguna lección operativa específica sobre el sector, porque la fuente no documenta la actividad, la estrategia ni la evolución de Bipi. Cualquier conclusión sobre su caso sería una suposición y, por tanto, no se formula.

Para poder extraer aprendizajes aplicables sería necesario disponer, como mínimo, de los datos registrales (cuentas depositadas, cambios de administradores, ampliaciones y reducciones de capital) y de fuentes periodísticas que documenten el producto, los clientes y las decisiones de gestión.

La font disponible [Wikipedia] Bipi descriu l'empresa com una startup del sector software i SaaS amb seu a Barcelona. A partir d'aquí, la reconstrucció que proposo (marcada com a proposta, no com a fet) és un servei de subscripció de cotxes que elimini la fricció de comprar, finançar i assegurar un vehicle: una quota mensual única que inclogui cotxe, assegurança, manteniment i impostos, contractada 100% en línia i cancel·lable amb preavisos curts.

La diferència respecte al Bipi original no la podem afirmar amb dades verificades; el que sí que podem fer és dissenyar el model amb els estàndards actuals: app mòbil, entrega a domicili, flota flexible i gestió digital del cicle de vida del contracte.

No disposo de dades verificades sobre la mida del mercat de Bipi ni sobre la seva base de clients. El que sí que és verificable és que el sector de la mobilitat per subscripció existeix i ha crescut a Europa en els darrers anys, amb operadors de leasing flexible i subscripció de vehicles.

Proposta a validar: el mercat objectiu seria el conductor urbà de 25-45 anys que vol un cotxe per períodes de 6 a 24 mesos sense compromís de compra, a Barcelona i àrea metropolitana com a mercat inicial. La mida d'aquest segment s'hauria de quantificar amb dades d'INE, DGT i estudis de mobilitat abans de comprometre inversió.

Proposta de model (no verificada com a model del Bipi original):

• Ingressos: quota mensual de subscripció per vehicle, amb marges sobre el cost de flota, assegurança i manteniment.
• Estructura de costos: adquisició o lísing de flota, assegurances, manteniment, logística d'entrega i recollida, i equip comercial/digital.
• Palanca SaaS: la plataforma de gestió de subscripcions (contractes, pagaments, incidències, telemetria) podria llicenciar-se a tercers, cosa que connectaria amb el perfil "software i SaaS" que la font atribueix a l'empresa.

Estimació a validar: un marge brut objectiu del 20-30% per vehicle i mes seria raonable en aquest sector, però caldria confirmar-lo amb cotitzacions reals de flota i assegurances.

Proposta en fases:

1. Fase 0 (mesos 0-3): validació del segment amb 20-30 entrevistes, cotització de flota i assegurances, i definició del producte mínim.
2. Fase 1 (mesos 3-9): pilot amb 10-20 vehicles en subscripció a Barcelona, plataforma pròpia mínima i mesura de retenció i sinistralitat.
3. Fase 2 (mesos 9-18): escalat a 100-200 vehicles si el pilot mostra unit economics positius, i exploració del llicenciament de la plataforma.

Cada fase hauria de tenir criteris de sortida clars (retenció, marge per vehicle, cost d'adquisició de client) abans de passar a la següent.

Totes les xifres són estimacions a validar, no dades verificades:

• Fase 0: 15.000-30.000 € (validació, assessoria legal i financera, prototip).
• Fase 1 (pilot): 100.000-250.000 €, principalment flota (10-20 vehicles en lísing), assegurances, plataforma i equip mínim.
• Fase 2 (escalat): 300.000-800.000 € addicionals segons el ritme d'escalat de flota.

Rang total per arribar a un pilot operatiu: 150.000-400.000 € (estimació). La xifra depèn críticament de si la flota es finança amb lísing (menys capital inicial) o es compra.

• Capital intensiu: la flota consumeix caixa; un model de subscripció requereix finançament o lísing ben negociat.
• Sinistralitat i depreciació: els costos d'assegurança i la pèrdua de valor dels vehicles poden erosionar el marge.
• Competència: operadors de leasing i grans grups de mobilitat poden replicar el model amb més escala.
• Risc regulatori i fiscal: el tractament fiscal de la subscripció i les normatives de mobilitat urbana poden canviar.
• Risc de validació: no tenim dades verificades que el segment objectiu pagui la quota necessària per ser rendible.

Lliçons que es poden extreure de l'experiència de Bipi (amb la cautela que no disposem de dades verificades sobre les causes del seu tancament):

• El producte és la flota i el contracte, no només l'app: la tecnologia és necessària però no suficient; el marge viu en la gestió de flota i assegurances.
• Cal validar els unit economics abans d'escalar: créixer en vehicles sense marge positiu per unitat amplifica les pèrdues.
• El finançament de flota és l'habilitador crític: qui controla el cost del capital controla el model.
• L'equip ha de combinar mobilitat, finances i producte digital: un perfil només tecnològic no sosté un negoci intensiu en actius.

En resum: la reconstrucció té sentit si es fa amb disciplina financera des del primer vehicle i amb un soci de flota o lísing que assumeixi part del risc d'actiu.

Bipi operava en el sector de la subscripció de vehicles a Barcelona, un model que combina la flexibilitat del lloguer amb la comoditat de la propietat. Segons la informació disponible a [Wikipedia], Bipi va tancar les seves operacions malgrat tenir un producte en un mercat amb demanda. El problema tècnic que resoldria aquesta plataforma és la manca d'una infraestructura de software que permeti gestionar de forma rendible una flota de vehicles en subscripció: càlcul de preus dinàmics segons l'ús, la durada i l'estat del vehicle, gestió automatitzada de contractes i assegurances, i visibilitat en temps real de la rendibilitat per vehicle.

La solució proposada no és un marketplace genèric, sinó un sistema operatiu de flota (fleet OS) que integra la gestió física dels vehicles amb la gestió financera de les subscripcions.

L'arquitectura es basa en microserveis desplegats en un clúster de Kubernetes, amb una API Gateway com a punt d'entrada únic. Els serveis principals són:

• Fleet Service: gestiona l'estat de cada vehicle (disponible, llogat, en manteniment, baixa).
• Subscription Service: gestiona els contractes de subscripció, renovacions i cancel·lacions.
• Pricing Engine: calcula el preu dinàmic de cada subscripció.
• Billing Service: genera factures i gestiona pagaments.
• Telemetry Ingestor: rep dades de telemetria dels vehicles (quilometratge, estat del motor) via MQTT.

La comunicació entre serveis és asíncrona mitjançant un bus d'esdeveniments (Kafka) per a esdeveniments de domini (per exemple, `VehicleReturned`, `SubscriptionRenewed`), i síncrona via REST per a consultes. Aquesta decisió es pren perquè la gestió de flotes requereix tolerància a fallades i desacoblament temporal: un vehicle pot retornar-se mentre el servei de facturació està en manteniment.

El desplegament és en un núvol públic (AWS) amb una base de dades PostgreSQL per a dades transaccionals i Redis per a caché de preus i sessions.

El model de dades principal es basa en PostgreSQL amb les taules següents:

```sql CREATE TABLE vehicles ( id UUID PRIMARY KEY, vin VARCHAR(17) UNIQUE NOT NULL, model VARCHAR(100) NOT NULL, status VARCHAR(20) NOT NULL CHECK (status IN ('available','subscribed','maintenance','retired')), mileage_km INTEGER NOT NULL DEFAULT 0, acquisition_cost_eur NUMERIC(10,2) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );

CREATE TABLE subscriptions ( id UUID PRIMARY KEY, vehicle_id UUID NOT NULL REFERENCES vehicles(id), customer_id UUID NOT NULL, start_date DATE NOT NULL, end_date DATE, monthly_price_eur NUMERIC(10,2) NOT NULL, status VARCHAR(20) NOT NULL CHECK (status IN ('active','cancelled','expired')), created_at TIMESTAMPTZ NOT NULL DEFAULT now() );

CREATE TABLE pricing_rules ( id UUID PRIMARY KEY, vehicle_model VARCHAR(100) NOT NULL, base_price_eur NUMERIC(10,2) NOT NULL, mileage_factor NUMERIC(5,4) NOT NULL DEFAULT 1.0, duration_discount_pct NUMERIC(5,2) NOT NULL DEFAULT 0.0, valid_from DATE NOT NULL, valid_to DATE ); ```

La decisió d'usar PostgreSQL en lloc d'una base de dades NoSQL es justifica perquè les subscripcions i factures requereixen transaccions ACID i integritat referencial. La taula `pricing_rules` permet versionar els preus sense desplegar codi nou.

L'API pública és REST amb autenticació OAuth2 (JWT) i versionada (`/v1/`). Els endpoints principals són:

• `GET /v1/vehicles?status=available` — llista vehicles disponibles.
• `POST /v1/subscriptions` — crea una subscripció; el cos inclou `vehicle_id`, `customer_id`, `duration_months`.
• `GET /v1/subscriptions/{id}/price` — retorna el preu calculat pel Pricing Engine.
• `POST /v1/telemetry` — ingesta de dades de telemetria (intern, protegit per mTLS).

Integracions externes:

• Passarel·la de pagament (Stripe) per a cobraments recurrents via webhooks.
• Proveïdor d'assegurances via API REST per a la validació de cobertura en crear una subscripció.
• Sistema de gestió de manteniment (webhook) per actualitzar l'estat del vehicle a `maintenance`.

El Pricing Engine exposa un endpoint intern `POST /internal/price` que rep `vehicle_model`, `duration_months` i `estimated_km` i retorna el preu mensual. La decisió de separar el càlcul de preus en un servei dedicat permet canviar les regles de preu sense tocar el codi de subscripcions.

La primera fase (MVP, 12 setmanes) ha d'incloure:

1. Fleet Service amb CRUD de vehicles i canvi d'estat.
2. Subscription Service amb creació i cancel·lació de subscripcions.
3. Pricing Engine amb regles bàsiques (preu base per model, descompte per durada).
4. Billing Service amb integració a Stripe per a cobraments mensuals.
5. API Gateway amb autenticació JWT.

Es deixa per a la fase 2 la telemetria en temps real, el manteniment predictiu i el portal de client. La raó és que sense un cicle complet de subscripció i cobrament no es pot validar el model de negoci.

Mides: el MVP requereix un equip de 3 desenvolupadors (backend), 1 DevOps i 1 product manager. La infraestructura estimada és de 2 nodes Kubernetes (4 vCPU, 16 GB RAM) i una instància PostgreSQL gestionada (db.t3.medium). Cost mensual estimat: 800–1.200 €.

Riscos tècnics:

• Integració amb assegurances: si l'API del proveïdor no és fiable, caldrà un mecanisme de reintents i una cua de dead-letter. Mitigació: implementar un circuit breaker.
• Preus dinàmics: el Pricing Engine pot convertir-se en un coll d'ampolla si es crida sincrònicament en cada petició. Mitigació: caché Redis amb TTL de 5 minuts i càlcul asíncron per a canvis massius.
• Telemetria: l'ingestor MQTT pot rebre pics de dades; cal un buffer persistent (Kafka) abans d'escriure a PostgreSQL.

La validació es fa en tres nivells:

1. Tests unitaris i d'integració per a cada servei (cobertura mínima del 80% en el Pricing Engine i el Billing Service).
2. Entorn de staging amb dades sintètiques de 50 vehicles i 100 subscripcions; s'executen proves de càrrega amb k6 per validar que el càlcul de preus respon en menys de 200 ms amb 100 peticions concurrents.
3. Pilot amb usuaris reals: 10 vehicles i 20 subscriptors durant 4 setmanes, mesurant la taxa de conversió, el churn i el marge per vehicle. Els resultats es comparen amb les mètriques històriques de Bipi (si estan disponibles) o amb benchmarks del sector.

La validació final és la rendibilitat per vehicle: el marge mensual (ingressos per subscripció menys costos de flota, assegurança i manteniment) ha de ser positiu en el pilot.