Clintu

Clintu era una startup del sector de los marketplaces. Según la información disponible, se trataba de una aplicación para encontrar personas que ofrecen servicios de limpieza del hogar, tal como recoge TreceBits en el titular de la noticia de cierre.

La ubicación de la empresa no consta en los datos disponibles, ni tampoco la fecha de fundación ni la identidad de los fundadores.

No consta en los datos disponibles ninguna información sobre el año de fundación, los fundadores, el origen del proyecto ni las etapas iniciales de la empresa.

De acuerdo con TreceBits, Clintu era una aplicación para encontrar personas que ofrecen servicios de limpieza del hogar. Es decir, operaba como intermediario entre usuarios que buscaban servicios de limpieza doméstica y personas que los ofrecían.

No consta en los datos disponibles el modelo de negocio concreto (comisiones, suscripciones u otros), el ámbito geográfico de operación ni el volumen de usuarios o de profesionales registrados.

No consta en los datos disponibles ninguna información sobre la evolución del negocio, el crecimiento, las rondas de financiación ni los resultados económicos de la empresa en ningún periodo.

Según TreceBits, Clintu cerró en marzo de 2026. La causa del cierre no consta en los datos disponibles: la fuente citada recoge el hecho del cierre, pero no aporta el motivo.

No consta en los datos disponibles ninguna información sobre el destino de la plataforma, la base de usuarios, la marca o la tecnología de Clintu después del cierre.

No consta en los datos disponibles la identidad de los fundadores de Clintu, ni por tanto cuál es su situación actual. Para intentar documentarlo, se podría consultar el registro mercantil para identificar a los administradores de la sociedad, así como las notas de prensa y entrevistas publicadas durante los años de actividad de la startup.

• En un marketplace de servicios domésticos, la confianza entre usuario y profesional es el producto: sin mecanismos verificables de selección, valoración y resolución de incidencias, la plataforma no sostiene la recurrencia.
• La limpieza del hogar es un servicio con alta rotación de profesionales y márgenes ajustados; el modelo de comisión debe cubrir el coste de adquisición tanto de usuarios como de profesionales de manera simultánea.
• La información pública disponible sobre el cierre es mínima; para futuros casos, conviene documentar desde el primer momento las métricas operativas (usuarios activos, recurrencia, coste de adquisición) para poder analizar su viabilidad con datos y no con impresiones.

Clintu era, segons la font disponible, una aplicació per trobar netejadores de la llar [TreceBits, 2026-03-28]. La seva essència era la intermediació de confiança: posar en contacte una llar que necessita neteja periòdica o puntual amb una persona que ofereix el servei, reduint la fricció de trobar, comparar i contractar.

Avui aquesta essència continua tenint sentit, però el context ha canviat: la confiança (verificació d'identitat, assegurança, valoracions reals) i la gestió laboral (contractació, fiscalitat, substitucions) són les dues peces que fan o desfan aquests models. La proposta no és "repetir Clintu", sinó construir un servei de confiança per a la llar amb una capa operativa més sòlida.

Nota: aquesta secció és una proposta de reconstrucció, no una descripció verificada del que feia Clintu en detall.

El mercat de serveis domèstics (neteja, cura de la llar) és estructuralment gran i fragmentat: molta demanda recurrent, molta oferta informal i poca estandardització. Això explica per què han existit i existeixen diversos actors que intenten intermediar-hi.

El que la font confirma és que Clintu operava en aquest nínxol i que va tancar el març de 2026 [TreceBits, 2026-03-28]. El que no sabem, perquè no consta a les dades verificades, és la mida del seu mercat, la seva quota, el nombre d'usuaris o els motius del tancament. Qualsevol xifra de mercat que es faci servir en un pla real caldrà validar-la amb fonts pròpies (estudis sectorials, dades d'ocupació, enquestes a llars i a professionals).

Proposta (a validar):

• Comissió per transacció sobre cada servei contractat a través de la plataforma, amb un percentatge que caldrà fixar segons el preu/hora de mercat.
• Subscripció per a llars amb necessitats recurrents (neteja setmanal o quinzenal), que dona previsibilitat d'ingressos.
• Serveis addicionals (substitucions, neteja profunda puntual, gestió de contractes) com a línies de marge.

La clau del model no és la comissió sinó la retenció: si la llar i la professional es queden a la plataforma, hi ha negoci; si es desintermedien al segon servei, el model s'esquerda. Això és una hipòtesi de disseny, no una dada verificada sobre per què va tancar Clintu.

Proposta per fases (estimació, a validar):

1. Fase 0 — Diagnòstic (2-4 setmanes): entendre per què va tancar Clintu i què va fallar al mercat. Sense això, es repeteixen errors. Cal parlar amb antics usuaris i professionals si és possible.
2. Fase 1 — Pilot en una sola ciutat (2-3 mesos): oferta limitada, verificació manual de professionals, assegurança i contracte tipus. Objectiu: validar que la gent paga i que es queda.
3. Fase 2 — Producte mínim (3-4 mesos): app o web lleugera, pagaments, valoracions, gestió de substitucions.
4. Fase 3 — Escalat selectiu: només si la retenció i la unit economics del pilot quadren.

Xifres estimades i a validar (rang orientatiu per a un pilot d'una ciutat, primers 6-9 mesos):

• Equip fundador mínim (2-3 persones a temps parcial/ple): 40.000–90.000 € en el període, segons dedicació i cost laboral.
• Desenvolupament del producte (MVP): 15.000–40.000 € si es fa amb equip propi o extern lleuger.
• Legal, assegurances i compliment (contractes, protecció de dades, assegurança de responsabilitat): 3.000–8.000 €.
• Màrqueting de llançament (adquisició local, contingut, comunitat): 5.000–15.000 €.
• Operació i suport (verificació de professionals, atenció): 5.000–12.000 €.

Total orientatiu: 70.000–165.000 € per arribar a un pilot validat. Són estimacions de consultor, no dades de Clintu ni pressupostos tancats.

• Desintermediació: llar i professional es poden entendre fora de la plataforma. Cal valor afegit real (assegurança, substitucions, garantia).
• Complexitat laboral i fiscal: la relació entre plataforma, professional i llar és delicada jurídicament; un mal disseny genera risc legal i reputacional.
• Confiança i qualitat: un sol incident greu pot enfonsar la marca en un mercat local i petit.
• Causa de tancament desconeguda: com que no consta per què va tancar Clintu [TreceBits, 2026-03-28], no es pot descartar que el problema fos estructural del model i no d'execució. Aquest és el risc número u i cal investigar-lo abans d'invertir.
• Adquisició cara: competir per atenció en un mercat amb molts actors pot encarir el cost per client.

Lliçons que es poden extreure de l'experiència de Clintu (a partir de la informació disponible, sense conèixer la causa verificada del tancament):

1. Un marketplace de confiança no es guanya amb una app, sinó amb operació. La tecnologia és la part fàcil; la verificació, les assegurances i la gestió de conflictes són el negoci.
2. La retenció mana. Si els usuaris no repeteixen dins la plataforma, la comissió no sosté l'estructura.
3. Cal entendre el tancament abans de rellançar. No consta la causa [TreceBits, 2026-03-28]; qui vulgui reconstruir-ho ha de començar per aquí, no per la idea.
4. El pilot local és el millor test. Val més validar en una ciutat amb números reals que dissenyar un pla nacional sobre hipòtesis.
5. El model laboral és part del producte. Ignorar-lo és el camí més curt a repetir errors.

Nota final: aquest informe barreja fets verificats (el tancament i la descripció bàsica de Clintu segons TreceBits) amb propostes de reconstrucció clarament marcades. Les xifres són estimacions de consultor i requereixen validació abans de qualsevol decisió d'inversió.

Un marketplace de neteja domèstica ha de resoldre simultàniament tres problemes que es reforcen entre si: (1) confiança entre desconeguts que entren a casa, (2) cobrament fiable i liquidació puntual a professionals autònoms, i (3) recurrència, perquè el valor del client no és la primera neteja sinó la repetició setmanal o quinzenal.

La font disponible només confirma el fet del tancament i el posicionament del producte ("app para encontrar limpiadoras de hogar") [TreceBits, 2026-03-28]; no documenta la causa. Per tant, aquesta especificació no assumeix cap causa verificada i tracta els riscos coneguts del sector com a hipòtesis de disseny a mitigar, no com a diagnòstic del cas Clintu.

El problema tècnic concret és: com fer que una reserva recurrent sigui tan fiable com un contracte laboral sense crear una relació laboral, i com garantir que el professional cobra encara que el client no pagui a temps.

Arquitectura de monolític modular amb serveis extrems extrets, desplegada en un sol proveïdor cloud (per exemple AWS) amb contenidors. Motiu: un marketplace de dues bandes amb volum inicial baix no justifica microserveis complets, però sí que necessita aïllar els dominis amb requisits regulatoris i de disponibilitat diferents.

Blocs:

``` [App mòbil client] [App mòbil pro] [Backoffice ops] | | | +-------- API Gateway (auth JWT) ---+ | +-------------------+-------------------+ | | | [Servei Booking] [Servei Payments] [Servei Trust] agenda, matching escrow, payouts KYC, ressenyes | | | +--------- PostgreSQL (schema per domini) ---+ | [Cua d'esdeveniments (SQS/Kafka)] | [Workers: recordatoris, liquidacions, antifrau] ```

Decisions i motius:

• PostgreSQL amb un schema per domini en lloc de bases separades: transaccions ACID entre reserva i pagament, que és el punt crític; es pot separar més endavant si cal.
• Escrow al servei de pagaments, no al de booking: el cicle de vida dels diners (autorització, captura, retenció, payout) és més lent i auditable que el de la reserva.
• Cua d'esdeveniments per a efectes secundaris (recordatoris, liquidacions, càlcul de reputació): permet reintents idempotents i desacobla la latència de la reserva de la dels pagaments.
• Servei de confiança separat: conté dades personals sensibles (documents d'identitat) amb requisits de xifratge i retenció diferents de la resta; aïllar-lo redueix la superfície de compliment.

Entitats principals (PostgreSQL, esquema simplificat):

```sql -- Identitat i confiança professional(id, user_id, estat_verificacio, document_kyc_ref, asseguranca_polissa_id, zones_servei[], tarifa_base_centims, rating_mitja, num_serveis) client(id, user_id, adreca_principal, metode_pagament_preferit)

-- Oferta i reserva servei_template(id, professional_id, durada_min, preu_centims, tipus) reserva(id, client_id, professional_id, inici_ts, fi_ts, estat, preu_centims, comissio_centims, serie_recurrent_id, versio) serie_recurrent(id, client_id, professional_id, regla_rrule, propera_ocurrencia)

-- Diners pagament(id, reserva_id, estat, import_centims, stripe_payment_intent_id, capturat_ts, retingut_fins_ts) payout(id, professional_id, periode, import_centims, estat, transfer_id)

-- Reputació ressenya(id, reserva_id, autor_id, destinatari_id, puntuacio, text, publicada_ts) incidencia(id, reserva_id, tipus, obert_per, estat, resolucio_ts) ```

Decisions i motius:

• `reserva.versio` per control optimista: dues persones poden intentar reservar el mateix slot; la versió evita doble reserva sense bloquejos llargs.
• `retingut_fins_ts` al pagament: modela explícitament la finestra d'escrow (per exemple 48 h després del servei) abans d'alliberar el payout; és el mecanisme que protegeix el client i, alhora, dona al professional una data de cobrament certa.
• `serie_recurrent` amb regla RRULE: la recurrència és el nucli del negoci; guardar-la com a regla (no com a reserves individuals generades) permet canviar-la i cancel·lar-la sense tocar l'historial.
• Ressenya lligada a `reserva_id`: només es pot valorar un servei realment prestat, cosa que elimina ressenyes falses per construcció.

API REST versionada (`/v1`) amb OpenAPI com a contracte. Endpoints clau:

• `POST /v1/reserves` — crea reserva; retorna `409` amb el slot alternatiu si hi ha conflicte de versió.
• `POST /v1/reserves/{id}/cancel·lar` — aplica política de cancel·lació segons hores d'antelació.
• `POST /v1/series` — crea recurrència; valida disponibilitat de les properes N ocurrències.
• `POST /v1/pagaments/intent` — retorna client secret per a confirmació al mòbil.
• `POST /v1/webhooks/stripe` — idempotent per `event_id`; actualitza estat de pagament i dispara payout.
• `GET /v1/professionals?zona=&data=` — cerca amb disponibilitat real.

Integracions externes i motiu:

• Stripe Connect (Express) per a pagaments i payouts: resol KYC de professionals i separació de fons sense construir infraestructura financera pròpia.
• Proveïdor KYC (per exemple Onfido) per a verificació d'identitat: requisit de confiança i possible obligació AML segons jurisdicció.
• Notificacions push (FCM/APNs) i SMS per a recordatoris: la no-show és el principal cost ocult d'aquests marketplaces.
• Assegurança RC via API de broker: emetre cobertura per reserva confirmada, no per compte, per ajustar cost i responsabilitat.

Ordre deliberat, perquè cada fase desbloqueja la següent:

1. Identitat i verificació de professionals (KYC + assegurança per reserva). Sense confiança no hi ha primera transacció.
2. Reserva amb disponibilitat real i control de conflictes (calendari, `versio`, zona de servei).
3. Pagament amb escrow i payout programat (Stripe Connect, webhooks idempotents, liquidació setmanal).
4. Ressenyes lligades a reserva i incidències (mínim: cancel·lació, no-show, disputa).
5. Recurrència (series + recordatoris). És el que converteix el marketplace en negoci; arriba després que la transacció única funcioni.
6. Backoffice d'operacions per resoldre incidències manualment abans d'automatitzar-les.

• Liquiditat de dues bandes: si no hi ha prou professionals per zona, la cerca retorna buit i el client no torna. Mitigació: llançament per zones tancades amb densitat mínima garantida, no obertura nacional.
• No-show i cancel·lacions tardanes: impacte directe en ingressos i reputació. Mitigació: recordatoris multi-canal, penalització escalonada i reasignació automàtica a professional alternatiu.
• Risc de requalificació laboral: com més controla la plataforma preus, horaris i assignació, més s'assembla a un empleador. Decisió tècnica: el professional fixa tarifa i accepta o rebutja reserves; la plataforma no assigna obligatòriament. Cal revisió legal per jurisdicció.
• Compliment de dades personals: documents d'identitat i adreces són dades sensibles; xifratge en repòs, retenció limitada i accés auditat al servei de confiança.
• Frau en payouts: comptes falsos que cobren sense prestar servei. Mitigació: KYC previ al primer payout, escrow amb finestra de disputa i límits inicials de volum.
• Cost de pagaments: comissions per transacció sobre tiquets petits; cal modelar el marge per reserva abans de fixar la comissió.

• Test de conflicte de reserva: dues peticions concurrents al mateix slot han de produir exactament una reserva i un `409`; prova de càrrega amb 100 peticions simultànies per slot.
• Test d'escrow: simulació de webhook de Stripe duplicat (mateix `event_id`) no ha de generar doble payout; verificació d'idempotència a tots els handlers.
• Test de cicle complet en entorn de proves: reserva → pagament → servei → finestra de disputa → payout, amb temps comprimits.
• Mètrica d'acceptació de la fase 1: percentatge de reserves amb professional verificat i assegurat = 100%; cap reserva sense cobertura.
• Mètrica de producte: taxa de recurrència (reserves que generen una segona reserva del mateix client en 30 dies) i taxa de no-show per sota d'un llindar definit abans del llançament.
• Validació de compliment: revisió legal del model de relació amb el professional i de la política de retenció de dades abans de la primera liquidació real.