CISSTECH
Pièce nº 004Trempé

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.

Période
2026
Format
Forfait
Rôle
Vision produit · développement
Nature
SaaS multi-commerces
Front
Angular · Storybook · Design system
Back
NestJS · Stripe · Twilio
Données
Firestore
Infra
GCP · Firebase Auth · Pulumi
Outillage
Nx · GitHub Actions
Le tournant

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.

Le cadrage

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.

La signature technique

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.

À quoi ça ressemble

Le suivi, côté commerçant et côté client

La page d'accueil de Trackin
Le tableau de bord côté commerçant
La liste des prestations à suivre
Le détail d'une prestation
Le paiement en ligne
L'écran de connexion et son mode démo
Une idée à challenger ?
Voir le site Voir les wireframes