Construire Contractly Pro en solo : les leçons de livrer en équipe d'une seule personne

Il n'y a pas de « ce n'est pas mon service » quand vous êtes tout le service

Construire Contractly Pro en solo signifie que chaque décision — architecture, textes de l'interface, quelle fonctionnalité sort ce mois-ci, quel email de support reçoit une réponse en premier — passe par une seule personne. Cela semble épuisant, et certains jours ça l'est, mais cela supprime aussi toute une catégorie de friction qui ralentit les équipes plus grandes : il n'y a pas de taxe de coordination. Si je décide que quelque chose doit changer, ça change. Pas de ticket, pas de réunion de planification de sprint, pas d'attente de la feuille de route d'une autre équipe.

La contrepartie, c'est que tout ce que je ne priorise pas ne se fait tout simplement pas. Personne d'autre pour rattraper le manque. Cette contrainte a façonné presque toutes les décisions réelles que j'ai prises en construisant ce produit.

Ce qui a été volontairement abandonné

Au tout début, j'avais esquissé une version bien plus ambitieuse de Contractly Pro — des comptes d'équipe, des portails clients avec leur propre connexion, une place de marché pour des modèles de contrats, des analyses approfondies sur les taux de conversion devis-contrat. Tout cela figure encore sur la feuille de route sous une forme ou une autre. Rien de tout cela n'est sorti en premier.

Ce qui est sorti en premier, c'est la version la plus étroite possible du flux central : créer un devis, le convertir en contrat, le faire signer, le transformer en facture, être payé. C'est tout. Pas de tableaux de bord, pas d'analyses, pas de fonctionnalités collaboratives. La logique était simple — si le flux central n'est pas solide, rien de ce qui l'entoure n'a d'importance, et s'il l'est, tout le reste peut être ajouté sans redessiner les fondations.

• Abandonné : les comptes d'équipe multi-utilisateurs (la v1 est conçue pour un utilisateur unique)
• Abandonné : une place de marché publique de modèles
• Abandonné : des tableaux de bord d'analyse et de reporting approfondis
• Conservé, non négociable : la numérotation séquentielle des factures, la validité des signatures électroniques et l'exactitude des enregistrements de paiement

La partie la plus difficile n'est pas le code

J'écris des logiciels pour vivre, donc le volet technique de la construction d'un SaaS a été la partie la plus prévisible. La partie la plus difficile a été tout ce qui l'entoure : écrire des textes d'interface qu'un freelance sans patience pour le jargon comprendra réellement, décider ce que signifie « terminé » pour une fonctionnalité sans chef de produit pour valider, et résister à l'envie de continuer à peaufiner quelque chose au lieu de le livrer et d'apprendre de l'usage réel.

« Construire en solo ne signifie pas tout faire soi-même pour toujours. Cela signifie être délibéré sur ce que l'on fait en premier, parce qu'il n'y a pas d'équipe pour rattraper ce que l'on ne fait pas. »

L'autre partie difficile, c'est le support. Chaque rapport de bug, chaque email « comment faire X », chaque retour arrive directement chez moi. C'est bien plus de travail que d'avoir une équipe de support — mais c'est aussi la boucle de retour la plus rapide que j'aie jamais eue sur un logiciel. Quand un vrai freelance vous dit que le flux de signature de contrat est confus, vous ne l'apprenez pas trois trimestres plus tard dans un rapport NPS. Vous l'apprenez cet après-midi-là, et vous pouvez généralement livrer un correctif dans la semaine.

Ce que je dirais à quelqu'un qui démarre la même chose

Choisissez la plus petite version utile du flux de travail central, livrez-la, et mettez-la entre les mains de vrais utilisateurs avant de vous sentir à l'aise avec à quel point elle semble inachevée. Tout ce que j'ai construit après ce premier flux central a été informé par l'observation de vrais freelances l'utilisant — pas en devinant ce qu'ils voudraient à partir d'un cahier des charges que j'aurais écrit seul.

Essayer Contractly Pro gratuitement →