Il voulait une app. Je lui ai proposé un actif.
Un commerçant voulait une application de suivi sur mesure. La meilleure valeur que je pouvais lui apporter n'était pas du code, mais une vision produit : Trackin, le suivi de prestations pour les commerces de service.
- Front
- Angular · Storybook · Design system
- Back
- NestJS · Stripe · Twilio
- Données
- Firestore
- Infra
- GCP · Firebase Auth · Pulumi
- Outillage
- Nx · GitHub Actions
Transformer un coût en actif
La demande était simple : un magasin de nettoyage de sneakers, des clients qui appellent tous les jours pour savoir si leur paire est prête, l'envie d'une app pour suivre l'avancement. J'aurais pu dire oui et facturer une application que le client aurait été seul à utiliser.
Je lui ai posé une autre question : combien d'autres commerces ont exactement le même problème ? Pressings, cordonniers, réparateurs. La réponse était évidente. Payer pour une app, c'est une dépense ; construire un SaaS, c'est créer un actif, qu'il utilise, pour le même prix, et que d'autres peuvent payer à leur tour.
Du besoin d'un seul au produit de plusieurs
On a élargi le cadre sans tomber dans l'excès : du problème initial aux commerces concernés, puis à un MVP volontairement simple, avec des rôles clairs (professionnel, client, administrateur) et une architecture pensée pour grandir dès le départ. Le tout validé par une étude de marché avant la première ligne de code.
C'est là qu'un freelance apporte le plus : challenger une demande, éviter une mauvaise décision, transformer un coût subi en produit qui rapporte.
Un mode démo, sans le moindre serveur
Sur l'écran de connexion, un bouton « Démo ». Un clic, et l'application bascule entièrement hors ligne : plus aucun serveur, et pourtant 90 % des fonctionnalités continuent de tourner. Aucune infrastructure de démonstration à maintenir, aucune base à polluer, des tests bien plus simples.
Tout ça tient à un seul choix d'architecture côté front : les mêmes ports que consomme l'application peuvent être servis par un adaptateur local au lieu du réseau. La même discipline hexagonale que celle qui structure ce site, mise au service d'une démo qui ne coûte rien.
Même discipline côté infrastructure : Firebase et Firestore ne sont pas branchés en direct sur le front, mais derrière un backend NestJS isolé par cette même architecture hexagonale. Un choix de coût assumé, adapté à un projet qui n'avait pas besoin de PostgreSQL, et qui garde le métier découplé de l'infra : changer de socle reviendrait à réécrire un adaptateur, pas l'application. Aucun verrouillage fournisseur.
Le suivi, côté commerçant et côté client





