Colibid

Colibid era una startup del sector fintech amb seu a València. La informació disponible no permet precisar quin producte o servei concret oferia ni quin era el seu model de negoci.

No consta la data de fundació ni el nom de les persones fundadores. Les dades disponibles no inclouen informació sobre el procés de constitució de l'empresa.

No consta amb precisió quina activitat desenvolupava Colibid dins del sector fintech, ni quin tipus de clients o usuaris tenia. La font disponible (Valencia Plaza, 25 de febrer de 2026) es limita a informar del tancament.

No consta informació sobre l'evolució de l'empresa, la seva facturació, el nombre de clients, les rondes de finançament o qualsevol altre indicador d'activitat durant la seva trajectòria.

La causa del tancament no consta a les dades disponibles. L'única informació verificada és que el diari Valencia Plaza va publicar el 25 de febrer de 2026 la notícia del tancament de la startup.

No consta informació sobre la continuïtat de cap producte, tecnologia o equip de Colibid després del tancament.

No consta la identitat dels fundadors ni la seva situació actual. Per obtenir aquesta informació caldria consultar el registre mercantil corresponent (Registre Mercantil de València) i les fonts periodístiques que hagin seguit la trajectòria de la companyia.

Amb les dades disponibles no es pot extreure cap lliçó operativa específica sobre el sector fintech ni sobre les causes del tancament, atès que la informació verificada es limita a la notícia del cessament. Qualsevol conclusió sobre el model de negoci, la gestió o l'entorn de mercat requeriria fonts addicionals que no consten en aquest corpus.

Del que va ser Colibid només en tenim una dada sòlida: era una startup fintech amb seu a València que va tancar el 25 de febrer de 2026, segons Valencia Plaza [Valencia Plaza, 2026-02-25]. La causa del tancament no consta enlloc. Això vol dir que no podem dir "van fallar per X" ni "els va faltar Y": qualsevol afirmació d'aquest tipus seria inventada.

Per tant, la reconstrucció no pot ser "refer Colibid tal com era". Ha de ser una proposta nova que ocupi l'espai que una fintech valenciana pot ocupar avui amb probabilitats raonables d'èxit. La meva proposta (marcada com a proposta, no com a fet) és:

Una fintech de proximitat per a pimes i autònoms de la Comunitat Valenciana: cobrament, finançament de circulant i conciliació comptable en una sola eina, amb acompanyament humà en valencià/castellà i integració amb els gestors i assessories locals.

La diferència respecte d'una fintech genèrica no és la tecnologia —que avui és commodity— sinó el canal: les assessories i gestories valencianes com a porta d'entrada. Això és una hipòtesi de negoci, no una dada sobre Colibid.

El mercat rellevant és el de serveis financers digitals per a pimes i autònoms. Dades de context (a validar amb fonts primàries abans de qualsevol decisió):

• La Comunitat Valenciana té un teixit de pimes i autònoms significatiu, amb concentració forta a València i el seu àrea metropolitana. Estimació: desenes de milers d'autònoms i pimes amb necessitats de cobrament i circulant; xifra exacta a validar amb dades de la Generalitat i de les associacions de gestors.
• El nínxol on una fintech petita pot competir no és el del particular (massiu, dominat per grans actors) sinó el de la pime de 1 a 20 treballadors que avui treballa amb banca tradicional i fulls de càlcul.
• El canal de les assessories és clau: una sola assessoria pot portar desenes de clients. Estimació: 200–400 assessories actives a la província de València, a validar.

No tinc cap dada verificada sobre quants clients tenia Colibid ni quin nínxol atacava. Qualsevol comparació seria especulació.

Proposta (no dada):

• Subscripció SaaS per a la pime: quota mensual per compte, amb tiers segons volum de factures. Estimació de preu: 29–99 €/mes per compte, a validar amb proves de disposició a pagar.
• Comissió per finançament de circulant: quan la pime avança factures, un marge sobre l'operació. Estimació: 1–3 % per operació, depèn del cost del capital i del partner financer.
• Canal d'assessories: les assessories recomanen l'eina i reben una comissió recurrent o descompte per als seus clients. Això redueix el cost d'adquisició, que és el forat on moren moltes fintechs.
• Ingressos accessoris: integracions, formació i serveis d'implantació per a pimes mitjanes.

El punt crític: el negoci de finançament requereix un partner bancari o una llicència; no es pot començar finançant amb capital propi. La primera fase ha de ser només programari + canal, i el finançament s'afegeix quan hi ha volum i partner.

Proposta, en fases:

1. Fase 0 (mesos 0–3) — Validació: 15–25 entrevistes amb assessories i pimes de València. Objectiu: confirmar el dolor concret (cobrament lent? conciliació? accés a circulant?) i el preu que pagarien. Cap línia de codi encara.
2. Fase 1 (mesos 3–9) — MVP de programari: cobrament i conciliació bàsica, integrada amb els programes de comptabilitat que fan servir les assessories. 10–20 pimes pilot via 2–3 assessories col·laboradores.
3. Fase 2 (mesos 9–18) — Canal: acord formal amb 10–20 assessories, comissió recurrent, suport en valencià/castellà. Mètrica clau: retenció mensual i nombre de clients per assessoria.
4. Fase 3 (mesos 18+) — Finançament: només amb partner bancari o fintech de finançament, i només si la fase 2 demostra volum i baixa morositat.

Fites de decisió: si al mes 9 no hi ha 10 pimes pagant, es reconverteix o s'atura. Aquesta disciplina és el que sol faltar.

Totes les xifres són estimacions meves, a validar:

• Equip fundador mínim (2 persones a temps complet, 12 mesos): 80.000–120.000 € en sous i càrregues. Rang ampli segons si els fundadors es paguen o no.
• Desenvolupament del MVP (1–2 developers externs o un soci tècnic): 30.000–60.000 € si és extern; molt menys si hi ha soci tècnic.
• Legal, constitució, compliment normatiu inicial (RGPD, contractes, possible assessorament sobre serveis de pagament): 8.000–20.000 €.
• Màrqueting i canal (material per a assessories, esdeveniments, primeres comissions): 10.000–25.000 €.
• Infraestructura i eines (12 mesos): 5.000–12.000 €.
• Coixí (3 mesos de marge): 15.000–30.000 €.

Total estimat per als primers 12 mesos: 60.000–150.000 €, segons si hi ha soci tècnic i si els fundadors es paguen sou. És un rang, no un pressupost: caldrà ajustar-lo amb pressupostos reals.

• Risc de causa desconeguda: no sabem per què va tancar Colibid. Pot ser que el mercat valencià de fintech de proximitat sigui més dur del que sembla. Aquest és el risc número u i no es pot eliminar, només mitigar amb validació abans d'invertir.
• Risc de canal: dependre d'assessories vol dir dependre de tercers que poden canviar de prioritat. Cal diversificar el canal des del principi.
• Risc regulatori: qualsevol servei de pagament o finançament té requisits normatius. Començar només amb programari redueix aquest risc; afegir finançament l'augmenta molt.
• Risc de competència: les eines de facturació i cobrament són un mercat saturat. La diferència ha de ser el canal i el servei local, no la funcionalitat.
• Risc financer: 60.000–150.000 € és poc per a una fintech, i això vol dir que no hi ha marge per a errors llargs. Cal fites de decisió clares.

Lliçons que es poden extreure de l'expedient original, sense inventar-ne la causa:

• La dada verificada és mínima: nom, sector, lloc i data de tancament. Això recorda que qualsevol reconstrucció ha de començar per validar el mercat, no per copiar un model que no coneixem.
• El tancament no consta motivat: en absència de causa, la prudència mana. Cal assumir que el model original tenia un problema que no veiem i dissenyar el nou amb hipòtesis explícites i fites d'aturada.
• L'essència aprofitable és el context, no el producte: una fintech valenciana amb arrel local i canal de proximitat té sentit avui; replicar un producte del qual no sabem res, no.
• Qui ho hauria de fer: un equip fundador amb un perfil de negoci local (coneixement d'assessories i pimes valencianes) i un perfil tècnic capaç de construir el MVP barat. No cal un equip gran: cal un equip que validi abans de construir i que sàpiga aturar-se si les fites no es compleixen.

Aquest informe no substitueix una due diligence sobre el cas original; la font disponible és una sola notícia [Valencia Plaza, 2026-02-25] i la resta són estimacions i propostes meves.

El crèdit al consum espanyol és un actiu molt fragmentat: milers de préstecs petits, amb condicions heterogènies, que no tenen un mercat secundari líquid. Un particular que vol sortir d'un préstec o un petit prestador que vol rotar capital no té un preu de referència; només té el preu que li ofereix la seva entitat, que és opac. Colibid, segons la nota de tancament de Valencia Plaza (2026-02-25), era una fintech valenciana que va cessar l'activitat el 2026; la causa de tancament no consta al registre, de manera que aquesta especificació no pretén explicar per què va tancar, sinó descriure què caldria construir perquè un producte així fos tècnicament sòlid.

La proposta és un mercat secundari de crèdit entre particulars amb subhauction inversa: el venedor publica un lot de deute amb un preu màxim, i els compradors competeixen a la baixa. El valor tècnic no és la subhasta en si, sinó la capacitat de verificar que el deute existeix, que el preu és executable i que la liquidació és traçable.

Arquitectura de tres plans separats perquè el risc financer no contamini el domini del producte:

``` [Client web/mòbil] | v [API Gateway + auth] -> [BFF] | | v v [Subhasta (stateless)] [Llibre de deute (event-sourced)] | | +----------> [Bus d'esdeveniments: Kafka] | +---------------+---------------+ | | | [Liquidació] [Compliment/KYC] [Notificacions] | | v v [Ledger] [Registre d'auditoria] ```

Decisions i motius:

• Event sourcing al llibre de deute: cada canvi de titularitat és un esdeveniment immutable. Motiu: en un mercat financer, la reconstrucció de l'estat en una data és requisit d'auditoria, no un extra.
• Subhasta stateless amb estat al bus: el servei de subhasta no guarda estat propi; llegeix i escriu esdeveniments. Motiu: permet escalar horizontalment i reiniciar sense perdre licitacions.
• Ledger separat del llibre de deute: el deute és el contracte; el ledger és el moviment de diners. Motiu: barrejar-los fa impossible quadrar caixa sense reconciliar contractes.
• KYC com a servei síncron al camí crític de la primera operació, asíncron després: motiu: no es pot permetre operar sense verificar, però no es pot bloquejar cada licitació per una crida externa.

Entitats principals (PostgreSQL per a estat, Kafka per a esdeveniments):

```sql -- Lot de deute publicat CREATE TABLE lot ( id UUID PRIMARY KEY, venedor_id UUID NOT NULL, import_nominal NUMERIC(14,2) NOT NULL, tipus_interes NUMERIC(5,4), data_venciment DATE, preu_maxim NUMERIC(14,2) NOT NULL, -- sostre de la subhasta inversa estat TEXT NOT NULL CHECK (estat IN ('esborrany','publicat','adjudicat','liquidat','cancel·lat')), creat_el TIMESTAMPTZ NOT NULL DEFAULT now() );

-- Licitació a la baixa CREATE TABLE licitacio ( id UUID PRIMARY KEY, lot_id UUID REFERENCES lot(id), comprador_id UUID NOT NULL, preu_ofert NUMERIC(14,2) NOT NULL, creat_el TIMESTAMPTZ NOT NULL DEFAULT now(), UNIQUE (lot_id, comprador_id) -- una oferta per comprador, revisable );

-- Esdeveniments del llibre (font de veritat) CREATE TABLE esdeveniment_llibre ( seq BIGSERIAL PRIMARY KEY, agregat_id UUID NOT NULL, -- lot_id tipus TEXT NOT NULL, -- LotPublicat, LicitacioRebuda, Adjudicat, Liquidat payload JSONB NOT NULL, creat_el TIMESTAMPTZ NOT NULL DEFAULT now() );

-- Moviments de diners CREATE TABLE moviment_ledger ( id UUID PRIMARY KEY, lot_id UUID NOT NULL, deutor_id UUID NOT NULL, creditor_id UUID NOT NULL, import NUMERIC(14,2) NOT NULL, estat TEXT NOT NULL CHECK (estat IN ('pendent','confirmat','fallit')), referencia_externa TEXT ); ```

Decisions i motius:

• `preu_maxim` al lot, no a la licitació: la subhasta inversa necessita un sostre definit pel venedor; sense ell, el guanyador pot ser un preu irreal.
• `UNIQUE (lot_id, comprador_id)`: evita que un comprador saturi la subhasta amb ofertes; la revisió és un `UPDATE` amb historial a `esdeveniment_llibre`.
• `seq` al llibre: permet reconstruir l'estat per ordre i detectar forats.
• `referencia_externa` al ledger: obliga a traçar cada moviment contra el proveïdor de pagaments.

API REST versionada, amb idempotència obligatòria a les escriptures (`Idempotency-Key`).

``` POST /v1/lots -- crear esborrany POST /v1/lots/{id}/publicar -- publica i obre subhasta POST /v1/lots/{id}/licitacions -- { preu_ofert } POST /v1/lots/{id}/adjudicar -- tanca i selecciona guanyador GET /v1/lots/{id}/estat -- estat + historial d'esdeveniments POST /v1/liquidacions -- inicia liquidació d'un lot adjudicat GET /v1/ledger/{lot_id} -- moviments ```

Integracions:

• KYC/AML: proveïdor extern (p. ex. un servei de verificació d'identitat), cridat de forma síncrona a l'onboarding i asíncrona a cada operació. Motiu: compliment normatiu sense bloquejar el flux.
• PSP / pagaments SEPA: per a la liquidació. Motiu: el mercat és espanyol i la liquidació ha de ser traçable via referència SEPA.
• Registre d'auditoria: escriptura append-only de cada crida que canvia estat. Motiu: en un producte financer, la defensa davant d'una reclamació és el log.

1. Motor de subhasta inversa amb el cicle `publicat → adjudicat`, incloent-hi el sostre de preu i la regla de desempat (preu més baix; a igualtat, primer a arribar). Motiu: és el nucli del producte i el que valida si hi ha mercat.
2. Llibre de deute event-sourced amb reconstrucció d'estat. Motiu: sense traçabilitat no hi ha producte financer defensable.
3. Ledger mínim + liquidació SEPA en entorn de proves. Motiu: valida el circuit complet abans d'obrir a usuaris reals.
4. KYC bàsic i registre d'auditoria. Motiu: requisit per operar, no una fase posterior.

No es construeix primer: app mòbil nativa, gamificació, ni mercat secundari de segon nivell.

• Volum inicial: centenars de lots i milers de licitacions al mes; PostgreSQL + Kafka cobreixen de sobres. No cal sharding.
• Latència de subhasta: objectiu < 200 ms per licitació; el coll d'ampolla és la validació de KYC, que s'ha de cachejar.
• Risc de doble adjudicació: dues licitacions simultànies al mateix preu. Mitigació: bloqueig optimista per `lot_id` i regla de desempat determinista.
• Risc de liquidació parcial: el comprador guanyador no paga. Mitigació: dipòsit o garantia prèvia a l'adjudicació; el ledger ha de suportar `fallit`.
• Risc regulatori: el mercat secundari de crèdit entre particulars pot requerir autorització. Risc alt i no tècnic; cal validació legal abans de producció.
• Risc de dades personals: el deute porta dades del deutor. Cal minimització i xifratge en repòs.

• Proves d'integració del cicle complet: crear lot → licitar → adjudicar → liquidar, amb ledger quadrat. Criteri: suma de moviments = import adjudicat.
• Proves de concurrència: N licitacions simultànies al mateix lot; una sola adjudicació, historial coherent.
• Reconstrucció del llibre: reproduir l'estat des dels esdeveniments i comparar-lo amb l'estat materialitzat. Criteri: coincidència exacta.
• Proves de fallada de liquidació: simular PSP que retorna error; el ledger ha de quedar en `fallit` i el lot en estat recuperable.
• Auditoria de compliment: cada operació ha de tenir traça KYC i registre d'auditoria associats. Criteri: cap operació sense les dues traces.
• Pilot tancat: 20–50 usuaris verificats en entorn controlat abans d'obrir. Criteri: zero incidències de doble adjudicació i liquidació quadrada al 100%.

Nota de fonts: la dada de tancament i la seva data provenen de Valencia Plaza (2026-02-25); la causa de tancament no consta al registre i, per tant, no s'afirma cap causa en aquest document.