Je passais beaucoup trop de temps à entretenir mes sneakers.

À l'époque, j'étais vraiment passionné par les sneakers, et les nettoyer correctement faisait partie du plaisir. Mais lorsque je ne voulais pas m'en occuper moi-même, il n'existait aucun moyen simple de trouver une personne à qui je pourrais confier une paire en toute confiance.

J'ai donc commencé à imaginer le service que j'aurais moi-même voulu utiliser.

CleanShoes était ma tentative de créer une marketplace à la demande pour le nettoyage de sneakers — reliant les personnes qui voulaient faire nettoyer leurs chaussures à celles prêtes à le faire.

En résumé : Uber pour l'entretien des sneakers.

CleanShoes était un projet personnel : j'ai donc travaillé sur l'ensemble du produit.

• Concept produit et positionnement
• Parcours utilisateurs
• UX et design d'interface
• Développement iOS
• Développement backend
• Conception de la base de données
• Intégration des API
• Déploiement cloud
• Distribution de la bêta et tests

C'était l'un de mes premiers projets où je ne me contentais pas d'implémenter quelque chose.

J'avais une idée, je l'ai transformée en produit, j'ai conçu l'expérience, construit l'infrastructure derrière, puis essayé de la mettre entre les mains de vraies personnes.

Le point de départ était simple : comment rendre la demande d'un service de nettoyage de sneakers aussi facile que la commande de n'importe quel autre service depuis son téléphone ?

J'ai conçu l'expérience autour de cette idée et volontairement gardé le produit concentré sur l'essentiel.

Comme l'expérience était pensée d'abord pour iOS, j'ai développé l'application nativement avec SwiftUI, en utilisant UIKit lorsque j'avais besoin de davantage de contrôle.

J'ai également construit une API NestJS, reliée à PostgreSQL via Prisma, et déployé le backend sur AWS.

Une fois l'application suffisamment stable pour sortir de mon propre téléphone, j'ai distribué des versions bêta via TestFlight.

C'était censé être le moment où construire laisserait place à l'apprentissage auprès des utilisateurs.

Cela ne s'est pas vraiment produit.

Et c'est finalement devenu la partie la plus utile du projet.

Le produit lui-même ne représentait que la moitié du problème.

CleanShoes était une marketplace de services à deux faces. D'un côté, il fallait des personnes à la recherche d'un service de nettoyage de sneakers. De l'autre, des personnes prêtes à le proposer.

Sans suffisamment d'activité des deux côtés, l'expérience s'effondrait.

On peut construire une excellente interface, un backend solide et une application fonctionnelle — mais rien de tout cela ne crée la densité dont une marketplace a besoin pour devenir utile.

C'est quelque chose que je comprenais intellectuellement au départ.

Je n'avais pas compris son importance avant d'essayer de lancer le produit.

J'avais consacré la majeure partie de mon énergie au produit.

Très peu à sa distribution.

CleanShoes n'a jamais atteint le niveau d'adoption que j'espérais.

Le problème n'était pas mon incapacité à construire l'application.

Le problème était d'avoir considéré que construire le produit était la partie la plus difficile.

Pour une marketplace, ce n'était pas le cas.

Je devais créer suffisamment de demande initiale, attirer des prestataires, instaurer de la confiance et concentrer l'activité jusqu'à ce que le produit devienne utile par lui-même.

À l'époque, j'avais très peu d'expérience en marketing ou en acquisition d'utilisateurs, et aucune véritable stratégie pour y parvenir.

L'application existait donc.

La marketplace, non.

Un produit qui fonctionne n'est pas la même chose qu'un business qui fonctionne.

C'était probablement la leçon la plus importante.

J'avais passé des mois à réfléchir au fonctionnement technique et visuel du produit. J'avais beaucoup moins réfléchi à la manière dont les premiers utilisateurs arriveraient réellement.

Aujourd'hui, je traiterais la distribution comme une composante du produit dès le premier jour.

Certains produits ont besoin d'élan avant de pouvoir apporter de la valeur.

Un outil autonome peut parfois être utile dès son tout premier utilisateur.

Une marketplace est différente.

S'il n'y a pas d'offre pertinente lorsqu'une personne arrive — ou pas de demande lorsqu'un prestataire s'inscrit — aucune des deux parties n'a vraiment de raison de rester.

J'ai appris que le problème d'activation devait être conçu avec autant d'intention que l'application elle-même.

Livrer le produit restait important.

CleanShoes n'est pas devenu le business que j'imaginais.

Mais c'est l'un des projets qui m'a fait passer de l'écriture de logiciel à la réflexion sur des produits dans leur ensemble.

J'ai dû prendre des décisions concernant l'expérience, la technologie, l'infrastructure, les utilisateurs et, au final, la distribution.

Le résultat n'était pas celui que je souhaitais.

Les enseignements, eux, sont restés.

iOS

SwiftUISwiftUIKit

Backend

Node.jsNestJSAPI RESTFirebase

Données

PostgreSQLPrisma

Infrastructure

AWSEC2

Bêta & livraison

TestFlightXcodeGit

Produit & Design

FigmaNotion