Ça dépend du produit, et je détaille mes choix quand on en est là. Ce qui compte c’est la raison derrière : un choix technique qui ne répond à aucune contrainte du produit est un choix pris pour le confort de celui qui code. Ça se paye plus tard, et c’est toi qui payes.
Tu as un produit à sortir.
Je construis des applications mobiles et des produits en ligne pour des gens qui veulent les mettre entre les mains de vrais utilisateurs.
20 minutes, je regarde ce que tu veux sortir
Mes réalisations
Entre ton idée et un produit que des gens utilisent tous les jours, il y a un espace dont personne ne parle.
Ce n’est pas la technique qui bloque. C’est de trancher ce qui part en V1, ce qui attend, et ce qu’on refuse même quand ça ressemble à une bonne idée.
Un produit qui sort avec tout ce qu’on avait imaginé sort trop tard et coûte trop cher. Et quand il sort, personne ne sait quelle partie servait vraiment.
Le pire moment pour refaire un produit, c’est quand il marche
Tant que tu as vingt utilisateurs, ce qui tient mal ne se voit pas.
Ça se voit à mille. Tu as des retours à traiter, des gens qui comptent sur toi, du revenu qui rentre, et c’est là qu’on te dit qu’il faut reprendre les fondations. Tu n’as ni le temps ni l’envie, et tu n’as pas le choix.
Je ne vais pas te sortir un pourcentage, aucune moyenne honnête n’existe là-dessus. Mais ce n’est jamais le premier budget qui fait mal. C’est le second, celui que personne n’avait prévu.
Prendre ces décisions au départ ne rend pas le projet moins cher. Ça évite de le refaire au pire moment.
Ce que je construis
Un MVP
Le périmètre minimum pour que ton produit existe, soit utilisé, et te dise si tu tiens quelque chose. C’est le point de départ le plus fréquent, et souvent le plus malin.
Si tu cherches un outil pour faire tourner ta propre entreprise, ce n’est pas cette page.
Voir les outils de gestionLe périmètre de la V1 décide de tout
La question n’est pas ce que ton produit fera un jour. C’est ce qu’il doit absolument faire pour que quelqu’un l’utilise et y revienne.
Le reste attend. Pas parce que ça n’a pas d’intérêt, mais parce que tu ne sais pas encore laquelle de tes trente idées est celle qui compte. Tes utilisateurs te le diront mieux que n’importe quelle réunion.
Ce tri est le travail le plus utile que je fais sur un projet, et c’est celui qu’on saute le plus souvent.
Les décisions structurantes
Celles dont personne ne parle avant de signer, alors autant le faire ici.
L’architecture
Le découpage décide de ce que tu pourras ajouter sans tout casser. Une architecture pensée pour la V1 te bloque à la V3.
Le schéma de données
Le sujet le plus ennuyeux et le plus déterminant. Ce que tu enregistres et comment c’est relié conditionne tout ce que tu pourras retrouver et analyser dans un an. Une donnée non collectée est perdue.
La montée en charge
Pas de sur-ingénierie pour dix mille utilisateurs dès le premier jour, ça coûte cher pour rien. Mais pas d’impasse qui t’oblige à repartir de zéro quand tu y arrives.
L’authentification, les rôles et les permissions
Trivial tant qu’il y a un seul type d’utilisateur. Chantier entier dès qu’il y en a trois.
La facturation
Abonnements, échecs de paiement, changements de plan, résiliations, proratas. Presque jamais anticipé, toujours douloureux à greffer après coup.
Les données personnelles
Ce que tu collectes, où c’est hébergé, qui y accède, ce qui se passe à la suppression d’un compte. En amont, jamais après.
Sur chacune je te dis ce que je recommande et pourquoi. La décision reste la tienne.
Les questions qu’on me pose
Si la tienne n’y est pas, pose-la moi en appel, ou écris-moi plus bas.
Quatre critères, et aucun autre. Ce que le produit doit faire. Du temps réel, de la synchronisation entre appareils ou du traitement lourd n’appellent pas les mêmes choix qu’un produit de gestion classique. La charge attendue quand ça marche, pas celle du premier mois. Le coût d’infrastructure à l’usage. Certaines briques sont très confortables à écrire et deviennent chères dès que le volume monte. Ça se sait avant de les choisir. La reprise. Une stack que personne ne maîtrise autour de toi te met en difficulté le jour où tu cherches un renfort ou un successeur. Une techno à la mode n’est pas un argument. Je t’explique mes choix et tu dois pouvoir les discuter.
Peu au démarrage, et ça suit ta croissance. C’est normal et ça se prévoit : tu as l’ordre de grandeur des coûts d’infrastructure avant qu’on commence, pas quand la facture arrive.
À toi. Je ne loue rien et je ne garde rien en otage. Le détail est écrit dans le contrat, avant qu’on commence.
Ça arrive, et je préfère te le dire. C’est exactement pour ça qu’on sort un périmètre réduit d’abord : pour le savoir vite, avec l’argent que tu n’as pas encore dépensé.
Le choix se prend sur les contraintes réelles du produit : notifications fiables, usage hors ligne, accès aux capteurs, présence sur les stores. Si rien de tout ça n’est indispensable, une PWA sort plus vite, se déploie sans passer par la validation d’un store, et coûte nettement moins cher à maintenir. Le natif se justifie quand ces contraintes existent vraiment, pas par principe. Le desktop quand l’usage est quotidien et intensif, ou qu’il faut toucher au système de fichiers et au matériel.
Ça dépend du périmètre, et avancer un chiffre maintenant serait inventer. Ce que je peux te dire c’est comment on le détermine : on cadre ce qui doit exister pour que le produit serve, on sort le reste de la V1, et le calendrier tombe une fois ce périmètre arrêté.
Oui, ça fait partie de ce que je fais. J’audite d’abord ce qui existe et je te dis franchement ce qui vaut le coup d’être gardé. Reprendre coûte parfois plus cher que refaire, et tu mérites de le savoir avant de t’engager.
C’est la bonne question, et peu de gens osent la poser. Un produit doit pouvoir être repris. Ça se prépare pendant qu’on construit : code lisible, choix documentés, rien de bricolé dans un coin.
Aucun de ces projets ne ressemble au précédent, je n’ai pas de grille. Après notre appel je sais de quoi on parle, et tu as une proposition chiffrée et détaillée. Rien à signer pour l’avoir.
On en parle ?
Vingt minutes au téléphone. Tu me racontes ce que tu veux sortir, je te dis ce que j’en pense et ce que je vois venir. Et si je pense que ce n’est pas à moi de le faire, je te le dirai aussi.
Not ready for a call yet?
I'll reply within 24h.
Information sent through this form or when booking a call is only used to answer your request. Learn more about your data