← Retour
01·Projet
Live · Scaling

MyCleanHub

mycleanhub.fr

Aperçu

Hero MyCleanHub — Programme fondateur, 100 places à pourvoirHero MyCleanHub — Programme fondateur, 100 places à pourvoir

Dashboard pro — accueil, calendrier, prochaines missions, CA du moisDashboard pro — accueil, calendrier, prochaines missions, CA du mois

Statistiques pro — CA, missions, top services, top clientsStatistiques pro — CA, missions, top services, top clients

Le problème

Les pros du nettoyage en France gèrent leur business avec WhatsApp, un carnet, et Excel. Résultat : double-bookings réguliers, devis qui traînent, factures perdues, attestations SAP impossibles à générer en janvier quand les clients réclament leur crédit d'impôt.

Les marketplaces existantes (AlloVoisins, ListMinut) prennent 20 à 25% de commission et ne fournissent aucun outil de gestion.

La solution

MyCleanHub est un SaaS-marketplace hybride : côté client, on trouve un pro vérifié et on réserve sur ses créneaux libres. Côté pro, on récupère un outil de gestion complet — planning anti-double-booking, devis et factures auto, génération d'attestations SAP NOVA en 1 clic.

Modèle économique : 0% de commission à vie pour les 100 premiers pros fondateurs, puis grille progressive (0/5/10%) selon que le client vient via parrainage pro ou via la plateforme.

Stack technique

  • Front : HTML/CSS/JS vanilla. Aucun framework, aucun bundler. Volontaire — vitesse de dev maximale, pas de migration v→v+1.
  • Back : Supabase (Postgres + Auth + Realtime + Edge Functions Deno).
  • Paiement : Stripe Connect Express (split commission automatique entre la plateforme et le pro).
  • Mails transactionnels : Resend, domaine mycleanhub.fr vérifié (DKIM/SPF/DMARC).
  • Notifications push : table notifications partagée entre web et l'app mobile CleanSpot, broadcastée via Supabase Realtime.
  • Crons : pg_cron + pg_net qui déclenchent les Edge Functions à intervalle fixe (briefing matinal, relances clients, recap stats).

Décisions techniques notables

Trigger anti-double-booking au niveau DB. Plutôt que valider côté front (faillible) ou côté API (race conditions), une fonction Postgres bloque l'insertion d'un booking qui chevauche un créneau déjà pris. Le front n'a qu'à proposer les créneaux libres via une RPC.

Flow urgence guest. Un visiteur peut poster une mission urgente sans créer de compte (formulaire ultra-court, 90s). Magic link envoyé sur son mail, et un trigger DB rattache automatiquement la résa au compte créé a posteriori.

Blocage des coordonnées dans le chat. Un trigger BEFORE INSERT sur direct_messages détecte les numéros, emails et URLs externes via regex et bloque le message. Garde-fou business : forcer les paiements via la plateforme.

Ce qui m'a pris du temps

  • Configuration SMTP Resend pour les mails Auth Supabase (signup, reset password) — pas évident parce que Supabase tronque les \r\n invisibles dans app_config.
  • Stripe Connect Express : KYC + ACH + RIB FR pour les pros, complexe à tester en sandbox.
  • RLS policies pour les guests non-authentifiés (anon role + WITH CHECK strict).

Ce que je referais différemment

Partir directement avec un framework côté front (Next.js ou Astro) pour les pages SEO. Le HTML/JS vanilla est rapide à itérer mais commence à coûter cher en duplication de code (navbar, footer, helpers auth) au-delà de 20 pages.

Lefti2K

Built in Paris · Indépendant

Local time
—:—:— UTC
Status
All systems operational
© 2026 · Bilal Hamzav2026.05.05