Un SaaS sur-mesure, construit pour ton métier et mis en production.

Le problème que ça règle

Tu as une idée de produit, un marché que tu connais mieux que personne, et aucune équipe technique. Les options qui se présentent sont toutes mauvaises à leur manière : recruter un CTO avant d’avoir un produit, lever pour financer une équipe avant d’avoir un client, ou lancer un MVP no-code qui tiendra jusqu’à ce que les premiers vrais utilisateurs arrivent.

Ce que tu cherches, en réalité, ce n’est pas « quelqu’un qui code ». C’est quelqu’un qui prend la responsabilité de faire exister le produit : arbitrer ce qu’on construit, le construire, le mettre en ligne, et rester quand il faut le corriger.

Ce que veut dire « sur-mesure », concrètement

Un SaaS sur-mesure n’est pas un site avec une base de données. C’est un ensemble de briques dont aucune n’est optionnelle si le produit doit tenir devant de vrais utilisateurs payants :

• Un socle — base de données modélisée pour ton métier, authentification, gestion des rôles, isolation des données entre clients. C’est la partie que personne ne voit et dont tout dépend.
• Les modules métier — la raison d’être du produit, celle pour laquelle aucun outil du marché ne convient.
• Un back-office — parce que tu passeras plus de temps dans l’espace d’administration que tes utilisateurs dans l’application. Créer un compte, corriger une donnée, comprendre pourquoi un client se plaint : sans ça, chaque incident te ramène vers moi.
• La facturation — Stripe, les abonnements, les essais, les changements de plan, les échecs de paiement. Beaucoup plus de cas particuliers qu’il n’y paraît.
• La mise en production — déploiement, sauvegardes vérifiées, monitoring, et un plan de restauration qu’on a réellement testé au moins une fois.

La méthode : couper d’abord

La première séance ne sert pas à lister ce qu’on va construire. Elle sert à décider ce qu’on ne construira pas.

Presque tous les projets arrivent avec une liste de trente fonctionnalités qui décrit une solution imaginée, rarement le problème. Mon travail commence là : comprendre le travail réel que le produit doit remplacer, puis redécouper le périmètre jusqu’à obtenir un premier lot qui ait un sens seul — quelque chose qu’on peut mettre entre les mains de quelqu’un et sur quoi il peut répondre autre chose que « c’est joli ».

Le reste n’est pas abandonné. Il est repoussé à un lot ultérieur, avec la raison écrite noir sur blanc. Cette raison compte autant que la coupe : six mois plus tard, elle t’évite de reconstruire par réflexe une fonctionnalité dont le terrain a déjà démontré l’inutilité.

Comment on travaille

Par lots chiffrés et livrés séparément. Chaque lot a un périmètre écrit, un prix, et se termine par une mise en production. Pas de tunnel de six mois au terme duquel on découvre ensemble que le produit ne correspond pas.

Avec un seul interlocuteur. Tu me parles, je construis. Il n’y a ni chef de projet qui traduit, ni équipe à qui expliquer deux fois, ni téléphone arabe entre ce que tu as dit et ce qui est développé.

Sur une stack délibérément ennuyeuse. TypeScript, Next.js, Postgres, Stripe. Rien d’exotique : ce sont des choix pour lesquels on trouve des développeurs, de la documentation et des réponses. L’originalité, en infrastructure, se paie toujours plus tard et se paie par toi.

Ce que je ne fais pas

Je ne prends pas les projets où le produit est censé remplacer une stratégie commerciale qui n’existe pas encore. Si personne n’a encore payé pour le problème que tu veux résoudre, du logiciel sur-mesure est la façon la plus chère possible de le vérifier — et je te le dirai pendant l’appel plutôt qu’après le devis.

Je ne prends pas non plus les projets de site vitrine ou de e-commerce standard. Des outils excellents existent, ils coûtent trente fois moins cher, et te vendre du développement à leur place serait malhonnête.