Clintu

Clintu era una startup del sector dels marketplaces. Segons la informació disponible, es tractava d'una aplicació per trobar persones que ofereixen serveis de neteja de la llar, tal com recull TreceBits al titular de la notícia de tancament.

La ubicació de l'empresa no consta a les dades disponibles, ni tampoc la data de fundació ni la identitat dels fundadors.

No consta a les dades disponibles cap informació sobre l'any de fundació, els fundadors, l'origen del projecte ni les etapes inicials de l'empresa.

D'acord amb TreceBits, Clintu era una aplicació per trobar persones que ofereixen serveis de neteja de la llar. És a dir, operava com a intermediari entre usuaris que buscaven serveis de neteja domèstica i persones que els oferien.

No consta a les dades disponibles el model de negoci concret (comissions, subscripcions o altres), l'àmbit geogràfic d'operació ni el volum d'usuaris o de professionals registrats.

No consta a les dades disponibles cap informació sobre l'evolució del negoci, el creixement, les rondes de finançament ni els resultats econòmics de l'empresa en cap període.

Segons TreceBits, Clintu va tancar el març de 2026. La causa del tancament no consta a les dades disponibles: la font citada recull el fet del tancament, però no n'aporta el motiu.

No consta a les dades disponibles cap informació sobre el destí de la plataforma, la base d'usuaris, la marca o la tecnologia de Clintu després del tancament.

No consta a les dades disponibles la identitat dels fundadors de Clintu, ni per tant quina és la seva situació actual. Per intentar-ho documentar, es podria consultar el registre mercantil per identificar els administradors de la societat, així com les notes de premsa i entrevistes publicades durant els anys d'activitat de la startup.

• En un marketplace de serveis domèstics, la confiança entre usuari i professional és el producte: sense mecanismes verificables de selecció, valoració i resolució d'incidents, la plataforma no sosté la recurrència.
• La neteja de la llar és un servei amb alta rotació de professionals i marges ajustats; el model de comissió ha de cobrir el cost d'adquisició tant d'usuaris com de professionals de manera simultània.
• La informació pública disponible sobre el tancament és mínima; per a futurs casos, convé documentar des del primer moment les mètriques operatives (usuaris actius, recurrència, cost d'adquisició) per poder analitzar-ne la viabilitat amb dades i no amb impressions.

Clintu era, segons la font disponible, una aplicació per trobar netejadores de la llar [TreceBits, 2026-03-28]. L'essència del negoci era la intermediació de confiança: posar en contacte una llar que necessita ajuda domèstica amb una persona que ofereix el servei, amb algun grau de verificació, gestió i garantia per part de la plataforma.

Avui aquesta essència es podria reconstruir, però el context ha canviat respecte del moment en què va néixer Clintu. La proposta seria un servei de gestió de personal de la llar (neteja, i potencialment canguratge o petites tasques) que combini:

• Verificació real de professionals (identitat, referències, antecedents quan sigui legalment possible).
• Gestió administrativa i fiscal del que avui sovint es fa en negre o de manera informal.
• Subscripció o comissió transparent, en lloc de dependre només del volum de reserves puntuals.

Això és una proposta, no una descripció del que Clintu feia: de Clintu només tenim verificat que era una app per trobar netejadores i que va tancar el 2026.

El mercat de la neteja domèstica i del personal de la llar existeix i és gran, però és notòriament fragmentat, informal i difícil de monetitzar. Aquesta és una lectura de context, no una dada verificada sobre Clintu.

El que sí que sabem és que Clintu operava en aquest nínxol i que va tancar [TreceBits, 2026-03-28]. Això és un senyal que cal prendre's seriosament: el mercat pot existir i, alhora, el model de marketplace pur pot no ser sostenible. La causa del tancament no consta, per tant no podem atribuir-lo a cap factor concret.

Com a estimació a validar, el mercat rellevant seria:

• Llars urbanes amb dos ingressos i poc temps, disposades a pagar per confiança i comoditat.
• Professionals que volen més estabilitat i menys gestió informal.
• Empreses i administracions que necessiten proveïdors de neteja verificats.

Cal validar mida, disposició a pagar i competència local abans de comprometre cap inversió.

Proposta de model, a validar amb usuaris reals:

1. Comissió per servei sobre cada reserva gestionada per la plataforma.
2. Subscripció per a la llar (pla mensual) que inclogui gestió, garantia de substitució i suport.
3. Servei gestionat per a empreses i oficines, amb facturació i contracte.
4. Serveis addicionals (assegurança, formació, eines de gestió) com a ingressos complementaris.

La clau és no dependre d'un sol flux. Un marketplace que només cobra comissió per reserva té ingressos volàtils; afegir subscripció i clients empresarials dona més estabilitat. Aquestes línies són propostes, no el model verificat de Clintu.

Pla proposat, en fases, amb criteris de validació:

1. Fase 0 — Validació (1-2 mesos). Entrevistes a llars i a professionals, anàlisi de competència local i definició del nínxol inicial (una ciutat, un tipus de servei).
2. Fase 1 — Pilot tancat (2-3 mesos). Operar manualment amb un grup reduït de professionals verificats i llars, mesurant recurrència, satisfacció i marge real.
3. Fase 2 — Producte mínim (3-4 mesos). App o web per reservar, pagar i gestionar substitucions, amb verificació de professionals integrada.
4. Fase 3 — Escalat selectiu. Ampliar ciutats o segments només si les mètriques del pilot ho justifiquen.

Cada fase hauria de tenir un criteri d'aturada clar: si la recurrència o el marge no arriben a un llindar definit prèviament, no es passa a la següent.

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

• Fase 0 (validació): 5.000-15.000 € (temps dels fundadors, eines, alguna entrevista remunerada).
• Fase 1 (pilot): 20.000-50.000 € (operació manual, suport, verificació, màrqueting local).
• Fase 2 (producte mínim): 60.000-150.000 € (desenvolupament, disseny, legal i fiscal, assegurances).
• Fase 3 (escalat inicial): 80.000-200.000 € (màrqueting, equip, operacions).

Rang total d'arrencada fins a un producte operatiu en una ciutat: aproximadament 150.000-400.000 €, segons l'abast i si es contracta equip o es fa amb fundadors. Cal validar cada partida amb pressupostos reals abans de comprometre's.

• Causa de tancament desconeguda. No consta per què va tancar Clintu [TreceBits, 2026-03-28]. Això és el risc principal: sense saber què va fallar, es pot repetir l'error. Cal investigar-ho abans de res.
• Informalitat i competència de preu. El sector té molta oferta informal que competeix per preu; la plataforma ha de justificar el seu cost amb confiança i gestió.
• Regulació laboral i fiscal. La frontera entre intermediar i ser empleador és delicada i pot canviar el model de costos.
• Confiança i seguretat. Un incident greu pot destruir la marca; cal inversió en verificació i assegurances.
• Monetització difícil. Els marketplaces de serveis domèstics sovint tenen marge baix i recurrència irregular.

Aquest informe no proposa un currículum, sinó les lliçons que es desprenen del cas:

• Algú que conegui el sector de primera mà, no només el producte digital: la confiança i la gestió de persones són el nucli.
• Algú disposat a validar abans d'invertir, atès que la causa del tancament de Clintu no consta i no es pot descartar cap hipòtesi.
• Algú que accepti un model híbrid (comissió + subscripció + clients empresarials) en lloc de confiar només en el volum de reserves.
• Algú que prioritzi la verificació i el compliment legal, perquè és alhora el principal cost i el principal argument de venda.

La lliçó central del cas Clintu, amb la informació disponible, és que un marketplace de confiança en un sector informal necessita més que una app: necessita operació, verificació i un model d'ingressos estable. I que, sense conèixer la causa del tancament, qualsevol rellançament ha de començar per la validació, no per la inversió.

El mercat de la neteja domèstica per hores pateix tres friccions estructurals: (1) la confiança —posar una persona desconeguda a casa teva—, (2) la conciliació d'agenda entre client i professional, i (3) el pagament en efectiu que genera disputes i evasió. Clintu, segons TreceBits (2026-03-28), es presentava com "la app para encontrar limpiadoras de hogar", és a dir, un marketplace de descoberta. La descoberta sola no resol el problema: cal tancar el cicle reserva → pagament → execució → ressenya dins la plataforma.

El producte que especifiquem resol la confiança amb verificació d'identitat i antecedents bàsica, la conciliació amb un calendari de disponibilitat real per professional, i el pagament amb retenció de fons fins a 24 hores després del servei. La causa del tancament de Clintu no consta a les fonts disponibles, de manera que no atribuïm el disseny a una causa concreta; sí que assumim que un marketplace de serveis domèstics necessita una operació humana intensiva els primers mesos, i l'arquitectura ho ha de permetre.

Monòlit modular en TypeScript (Node.js + Fastify) amb PostgreSQL com a font de veritat, desplegat en un sol proveïdor cloud amb contenidors. Motiu: un marketplace de dues cares amb volum inicial baix no justifica microserveis; un monòlit modular permet extreure el motor de pagaments i el de matching més endavant sense reescriure el domini.

Components:

``` [App mòbil client] [App mòbil professional] [Panell ops web] | | | +---------- API Gateway (Fastify, JWT) --------+ | +---------------------+---------------------+ | | | Mòdul Comptes Mòdul Reserves Mòdul Pagaments (KYC, ressenyes) (calendari, matching) (escrow, payouts) | | | +---------------------+---------------------+ | PostgreSQL + Redis (PostGIS per geografia, Redis per cues i locks) ```

Decisions i motius:

• PostGIS perquè el matching és geogràfic (radi de desplaçament) i les consultes per caixa delimitadora són el coll d'ampolla principal.
• Redis amb locks distribuïts per evitar doble reserva del mateix slot de calendari; el lock s'adquireix per `(professional_id, slot_start)` amb TTL de 30 s.
• Escrow via Stripe Connect en lloc de custodiar fons nosaltres: evita llicència de pagament i trasllada el compliment KYC/AML al proveïdor.
• Cues asíncrones (BullMQ sobre Redis) per a notificacions push, recordatoris i càlcul de payouts; cap d'aquestes tasques ha de bloquejar la resposta HTTP de reserva.

Esquema relacional a PostgreSQL. Taules principals:

```sql -- Comptes unificats; el rol determina el perfil users(id uuid pk, email citext unique, phone text, role text check (role in ('client','pro','ops')), kyc_status text, created_at timestamptz)

-- Perfil professional pro_profiles(user_id uuid pk ref users, bio text, hourly_rate_cents int, service_radius_km int, location geography(Point,4326), id_verified bool, insurance_active bool, rating_avg numeric(3,2))

-- Disponibilitat declarada per franges availability(id uuid pk, pro_id uuid ref pro_profiles, starts_at timestamptz, ends_at timestamptz, status text check (status in ('open','held','booked')))

-- Reserves bookings(id uuid pk, client_id uuid ref users, pro_id uuid ref users, address geography(Point,4326), duration_min int, price_cents int, commission_cents int, status text check (status in ('pending','confirmed','in_progress','completed','cancelled','disputed')), scheduled_start timestamptz, scheduled_end timestamptz, payment_intent_id text, created_at timestamptz)

-- Ressenyes creuades (client->pro i pro->client) reviews(id uuid pk, booking_id uuid ref bookings, author_id uuid ref users, rating int check (rating between 1 and 5), comment text, created_at timestamptz, unique(booking_id, author_id))

-- Esdeveniments d'auditoria per a ops i disputes booking_events(id bigserial pk, booking_id uuid ref bookings, actor_id uuid, event_type text, payload jsonb, created_at timestamptz) ```

Motius: `geography(Point,4326)` i no lat/lng en columnes separades perquè les consultes de radi usin `ST_DWithin` amb índex GiST. `booking_events` append-only perquè les disputes necessiten traçabilitat i perquè ops pugui reconstruir què va passar sense dependre de logs d'aplicació. La comissió es desa a la reserva (no es recalcula) perquè canvis de tarifa no alterin reserves ja tancades.

API REST versionada (`/v1`), autenticació JWT amb refresh tokens. Endpoints clau:

• `POST /v1/bookings` — cos: `{pro_id, address, scheduled_start, duration_min}`. Retorna 409 si l'slot està agafat; el lock de Redis s'agafa abans de la transacció.
• `GET /v1/pros?lat=&lng=&radius_km=&date=` — cerca amb PostGIS, paginada per cursor.
• `POST /v1/bookings/:id/complete` — el client confirma; dispara l'alliberament d'escrow amb un retard de 24 h (job a BullMQ).
• `POST /v1/bookings/:id/dispute` — obre disputa; congela el payout i crea una tasca al panell d'ops.
• `POST /v1/webhooks/stripe` — idempotent per `event.id`; processa `payment_intent.succeeded`, `transfer.failed`.

Integracions externes i motiu:

• Stripe Connect (Express) per a pagaments i payouts; el professional fa onboarding KYC dins Stripe.
• Twilio Verify per a verificació de telèfon en el registre; redueix comptes falsos.
• Onfido o equivalent per a verificació d'identitat documental del professional; és el cost de confiança del model.
• Firebase Cloud Messaging per a push; recordatoris a T-24h i T-1h.

Ordre deliberat per validar la unitat econòmica abans d'invertir en automatització:

1. Comptes + verificació de telèfon + perfil professional (2-3 setmanes). Sense confiança bàsica no hi ha marketplace.
2. Calendari de disponibilitat i motor de reserves amb lock (3-4 setmanes). És el cor; un bug de doble reserva mata la confiança.
3. Pagaments amb Stripe Connect i escrow (3 setmanes). Sense pagament dins la plataforma no hi ha comissió ni disputes gestionables.
4. Panell d'ops mínim: llistat de reserves, botó de reemborsament, notes. Es construeix en paral·lel perquè els primers mesos caldrà intervenció manual.
5. Ressenyes creuades i matching per proximitat (2 setmanes). El matching es pot fer manualment al principi; les ressenyes no.

No es construeix al principi: app nativa (PWA responsive primer), xat intern (WhatsApp amb número virtual), ni subscripcions.

• Liquiditat del mercat: el risc principal no és tècnic sinó de densitat geogràfica. Cal llançar ciutat a ciutat; el codi ha de suportar un flag `city_launch` que limiti cerques a zones actives.
• Doble reserva: mitigat amb lock Redis + constraint `EXCLUDE USING gist` sobre rangs de temps a `availability`. Cal testejar-ho amb càrrega concurrent.
• Frau i no-show: el payout retingut 24 h i la verificació d'identitat redueixen el risc, però cal un fons de compensació petit (1-2% de la comissió) per als primers casos.
• Cost de KYC: Onfido costa per verificació; assumir ~2-4 € per professional i amortitzar-ho amb la primera reserva completada.
• Escalat: PostgreSQL amb PostGIS aguanta desenes de milers de professionals; el coll d'ampolla serà Stripe i les notificacions, no la base de dades.

• Mètriques de producte: ràtio de reserves completades / confirmades > 85%; temps mitjà fins a primera reserva d'un professional < 7 dies; NPS post-servei > 40.
• Tests tècnics: test de concurrència que llança 50 reserves simultànies al mateix slot i n'espera exactament 1 èxit; test d'idempotència de webhooks de Stripe; test de reconciliació diària entre `bookings` i `payment_intent` de Stripe.
• Validació operativa: durant els 3 primers mesos, revisió manual del 100% de les disputes i mesura del temps de resolució (< 48 h objectiu).
• Validació de mercat: cohort per ciutat; si una ciutat no arriba a 30 reserves/setmana en 8 setmanes, es congela el llançament i es reavalua. Aquest criteri s'ha de fixar abans de llançar, no després.