Votre premier produit en production en un mois, pas une maquette
Nous avons monté notre propre startup à Station F en 2017, et nous développons depuis 2020 le MVP de startups et de porteurs de projet. Un périmètre coupé au scalpel, un produit en ligne avec de vrais utilisateurs au bout d'un mois, et une base de code qui devient votre v1 au lieu d'être jetée. Fondateurs et développeurs nous-mêmes, nous challengeons votre périmètre avant de le chiffrer.
Cadrage, développement en sprints avec démo hebdomadaire, mise en production. Un calendrier tenu grâce à un périmètre coupé, pas un prototype vendu comme un MVP.
02
Le code est à vous
Votre dépôt, dès le premier sprint. Stack standard, projet documenté, aucune brique propriétaire ni dépendance à notre équipe.
03
Une v1, pas un jetable
On coupe le périmètre, jamais la qualité. Le MVP grandit par ajouts successifs au lieu d’être réécrit six mois plus tard.
01
Un MVP, ce n'est pas une maquette
Un MVP est la version la plus simple de votre produit qui apporte une valeur réelle à de vrais utilisateurs. Le critère est binaire : si personne ne peut s'en servir en production, ce n'est pas un MVP.
Trois objets sont régulièrement confondus. La maquette est une image dans Figma : elle valide un parcours et un design. Le prototype est cliquable mais ne traite pas de vraies données : il sert à convaincre un investisseur ou un premier client. Le MVP, lui, a des comptes, une base de données, des paiements si votre modèle en dépend, et il tourne en production.
Cette distinction n'est pas du vocabulaire. Elle décide de ce que vous allez apprendre. Une maquette vous dit si votre interface est comprise. Un MVP vous dit si votre produit est utilisé, à quelle fréquence, par qui, et sur quelle fonctionnalité vos utilisateurs reviennent. C'est la seule information qui justifie d'investir la suite.
C'est aussi pour cette raison que nous refusons de livrer un prototype sous le nom de MVP. Sans comptes ni vraies données, on ne peut rien décider.
02
Comment on coupe le périmètre
La difficulté d'un MVP n'est jamais technique, elle est éditoriale. La plupart des projets qui dérapent ont dérapé au cadrage, pas au développement.
Notre méthode tient en une contrainte : un seul parcours critique. Nous identifions l'action qui crée la valeur pour votre utilisateur, et nous développons ce parcours de bout en bout, correctement. Tout le reste attend.
Concrètement, trois questions sur chaque fonctionnalité demandée. Est-elle nécessaire pour que le parcours critique fonctionne ? Peut-elle être rendue manuellement au démarrage, par vous, dans un back-office minimal ou même dans un tableur ? Sa présence changerait-elle la décision que vous prendrez au bout de trois mois ? Si les trois réponses sont non, elle sort du périmètre du MVP et rejoint la liste de la v1.
Ce qui reste presque toujours dans un MVP : l'authentification, le parcours critique, un back-office minimal pour opérer à la main, et la mesure d'usage. Ce qui sort presque toujours : la gestion fine des rôles, les exports, les notifications, les tableaux de bord, les intégrations secondaires et le multilingue.
Vous repartez du cadrage avec un périmètre écrit, un budget, et la liste explicite de ce qui n'est pas dedans. Un périmètre flou coûte systématiquement plus cher qu'un périmètre ambitieux mais clair.
Le prix se fixe sur devis, après un appel. Voici comment nous facturons, et ce qui fait bouger le montant.
Nous ne vendons pas de forfait au projet. Nous travaillons à la durée, avec une équipe dédiée : deux semaines en formule Accélérateur ou au mois en formule Partenaire, design et site vitrine inclus, quand le rythme et le périmètre l'exigent. Le prix par période est fixé dans le devis : vous savez ce que vous dépensez chaque mois, et vous arrêtez quand le produit tient debout.
Pour un MVP, comptez un mois avec un développeur en formule Partenaire. Une contrainte réglementaire forte ou plusieurs intégrations tierces peuvent demander un mois de plus.
Ce qui fait bouger le montant n'est presque jamais le nombre d'écrans. C'est le nombre de systèmes existants auxquels il faut se connecter, le niveau de contrainte réglementaire, et la précision de votre besoin au démarrage.
En dessous de 10 000 €, vous n'achetez pas un MVP mais un prototype no-code ou une maquette. C'est un choix parfaitement défendable pour tester une hypothèse, à condition de savoir que ce n'est pas le même objet.
Un MVP se pilote à la semaine. Vous voyez le produit avancer et vous arbitrez en continu, sur quatre semaines.
Semaine 1 : cadrage Immersion dans votre marché, définition du parcours critique, arbitrage du périmètre, choix de la stack et de l'hébergement. Livrable : un périmètre écrit, un budget, un calendrier.
Semaines 2 et 3 : développement Sprints courts avec une démo chaque semaine sur un environnement que vous testez vous-même. Les priorités se réajustent à chaque démo, en fonction de ce que vous découvrez. C'est là que le fait de ne pas travailler au forfait devient un avantage : changer d'avis ne déclenche pas un avenant.
Semaine 4 : mise en production Déploiement, mesure d'usage, corrections des premiers retours utilisateurs. Vous sortez avec un produit en ligne, pas avec une recette à finir.
Ensuite, deux chemins. Soit le produit trouve son usage et on enchaîne sur la v1 au même rythme mensuel. Soit il ne le trouve pas, et vous avez dépensé un mois plutôt qu'un an pour l'apprendre.
05
No-code, IA ou MVP développé
Faire développer son MVP n'est pas toujours la bonne réponse, et vous vendre le contraire serait le meilleur moyen de vous faire perdre de l'argent.
Le no-code et les générateurs IA suffisent quand l'objectif est de tester une hypothèse vite et à budget réduit. Bubble, FlutterFlow, Lovable, Bolt ou v0 mettent un produit entre vos mains en quelques jours. Notre comparatif Bolt, Lovable, Cursor et v0 détaille ce que chacun sait faire.
Le développement s'impose quand le logiciel est le produit, quand il faut se connecter à un système existant, quand la logique métier est fine, ou quand vos données sont sensibles. La limite de ces outils apparaît rarement au démarrage : elle apparaît au passage en production, sur la sécurité, les performances et la maintenabilité. Nous l'avons documentée dans pourquoi une app Lovable ou Bolt ne scale pas.
Une troisième voie existe si vous avez déjà commencé sur un de ces outils et que le produit bloque. Nous reprenons le projet, auditons ce qui est récupérable, et le finissons proprement : voir finir un projet démarré avec Bolt, Lovable ou Cursor. Il arrive que nous conseillions de garder l'existant plus longtemps que prévu.
06
Deux MVP devenus des produits
Fondateurs passés par Station F, nous accompagnons des startups depuis 2020. Deux exemples de missions d’environ trois mois, MVP compris, dont le code a servi de base à la suite.
Carbonfact Plateforme d'évaluation de l'empreinte carbone des produits pour les marques de mode. Nous avons développé leurs MVP successifs pendant leurs cycles exploratoires, sur NestJS, Next.js et Prisma, au fil d'une mission de trois mois. La startup a ensuite levé des fonds et internalisé son équipe technique. Lire l'étude de cas.
Spliit Outil de recherche et de réservation de bureaux, avec visualisation des biens, mise en relation avec les brokers et routing cartographique. Mission de trois mois sur le premier produit, puis site vitrine et évolutions les mois suivants. Lire l'étude de cas.
Le point commun de ces projets n'est pas la stack, c'est le fait que le MVP n'a pas été jeté. Les deux ont continué à évoluer sur la même base de code.
07
Après le MVP
Un MVP réussi crée un problème neuf : il faut décider quoi construire ensuite, et avec qui. Trois situations, trois réponses.
Le produit trouve son usage et vous continuez avec nous. On enchaîne sur la v1 au même rythme mensuel, en ajoutant ce que les utilisateurs ont réclamé plutôt que ce qui figurait sur la liste initiale. C'est le cas le plus fréquent, et c'est aussi pourquoi nous ne bradons pas la qualité du MVP.
Le produit décolle et vous recrutez. Nous transmettons le projet à votre premier développeur ou à votre CTO, documentation comprise, et nous restons en renfort d'équipe le temps de la montée en charge.
Le périmètre grandit et sort du cadre du MVP : plusieurs parcours, intégrations métier, obligations réglementaires. On passe alors sur notre offre de développement web sur mesure, avec le même modèle mensuel. Et si votre produit touche à des données de santé, la trajectoire d'hébergement se prépare dès le MVP : voir notre accompagnement HDS.
Chez Bob le développeur, nous ne construisons pas seulement des
produits SaaS, nous réalisons des rêves. Bob, à la barre de notre
équipe d'experts, est bien plus qu'un développeur : il est le
co-pilote agile et dévoué de votre projet entrepreneurial.
Eux-mêmes anciens entrepreneurs, les membres de Bob
comprennent les défis auxquels vous faites face et savent comment
les transformer en opportunités.
01
En contact permanent
Nous savons que chaque entreprise est unique. C'est pourquoi Bob et son équipe mettent un point d'honneur à tisser des relations solides et authentiques avec chacun de nos clients.
02
Rapidité et efficacité : notre signature
Dans le monde des startups, le temps c'est de l'argent. Notre processus de développement agile garantit que votre produit sera sur le marché en un temps record, prêt à conquérir son audience.
Témoignages
Des fondateurs qui ont lancé avec nous
“
Nous avons fait appel à Bob dans le cadre du développement de notre site Spliit et de notre web app. Leur accompagnement était complet avec une forte expertise technique et une approche produit. Ils ont su s'adapter rapidement à notre contexte et nos besoins. Fortement recommandé!
François Bulteau · CEO - Spliit
“
Antoine nous a accompagnés quelques mois sur le développement NextJS / NestJS / Typescript de plusieurs MVP dans le cadre de nos cycles exploratoires chez Carbonfact.
La collaboration est excellente : les échanges sont clairs, efficaces. Antoine s'est très bien adapté à notre contexte et a travaillé avec beaucoup d'autonomie, ce qui était parfait à notre stade de développement.
Nous avons beaucoup apprécié sa capacité à comprendre rapidement les enjeux business et à s'assurer de l'alignement de ses choix techniques avec nos pratiques et notre stratégie.
Nous serons ravis de travailler à nouveau avec Antoine et l'équipe de Bob le Développeur.
Romain Champourlier · CTO - Carbonfact
“
Je suis satisfait de la production finale d’Hypnolib.
Points positifs : Qualité de la prestation, Réactivité, Disponibilité, Force de propositions.
Stanislas Bétoux · CEO - Hypnolib
“
Engagé pour réaliser et développer notre site internet multiplateforme et multilingue. L’équipe a été très compétente en proposant des technologies Getbiz.
L'équipe de Bob le développeur a su bien comprendre notre projet, pour nous proposer la meilleure solution de développement pour la création de notre application.
Leur accompagnement fut très professionnel et les délais respectés. Bravo et merci à toute l'équipe.
Stanislas Denis · CEO - GetBiz
“
Bob le développeur a su répondre rapidement et efficacement à chacune de nos attentes.
Leur accompagnement et leur agilité tout au long de la réalisation du projet nous ont été très précieux, et nous ont permis de répondre très rapidement aux différentes difficultés rencontrées.
Leur expertise technique et leur orientation business nous ont permis de trouver ensemble les meilleures solutions pour une réalisation plus robuste sur le long terme.
Merci à toute l’équipe !
Romain Le Drogo · Founder - Sutom
“
L'équipe a su s'adapter aux différentes exigences et être force de proposition sur les concepts originaux que nous avons soumis pour notre plateforme interne. Hâte de retravailler ensemble!
RILESUNDAYZ · Record label and publishing company
FAQ
Questions fréquentes sur le développement de MVP
01Combien coûte le développement d'un MVP ?
Nous facturons à la durée, pas au forfait : deux semaines en formule Accélérateur ou au mois en formule Partenaire, design et site vitrine inclus, au prix fixé sur devis après un appel. Un MVP demande un mois avec un développeur en Partenaire. Ce qui fait varier le montant n'est presque jamais le nombre d'écrans, mais le nombre d'intégrations avec des systèmes existants, le niveau de contrainte réglementaire, et la précision du périmètre au démarrage. En dessous de 10 000 €, vous n'achetez pas un MVP mais un prototype, ce qui peut suffire pour tester une hypothèse sans mettre le produit entre les mains de vrais utilisateurs.
02Combien de temps faut-il pour développer un MVP ?
Un mois pour un MVP mis en production, avec de vrais utilisateurs dessus. Une semaine de cadrage, deux semaines de développement en sprints avec une démo chaque semaine, une semaine de mise en production et de corrections. Ce délai tient parce que le périmètre est coupé autour d'un seul parcours critique. Les studios qui livrent en quelques jours un prototype cliquable vendent un autre produit, utile pour convaincre, inutile pour apprendre de vrais usages.
03Quelle différence entre un MVP, un prototype et une maquette ?
Une maquette est une image : elle sert à valider un parcours et un design, dans Figma. Un prototype est cliquable mais ne traite pas de vraies données : il sert à convaincre un investisseur ou un premier client. Un MVP est en production : il a des comptes, une base de données, des paiements si votre modèle en dépend, et il apporte de la valeur à de vrais utilisateurs. Seul le troisième vous apprend quelque chose de fiable sur votre marché.
04Faut-il faire son MVP en no-code ou le faire développer ?
Le no-code et les générateurs IA comme Lovable, Bolt ou v0 sont le bon choix pour tester une idée avant d'investir : quelques jours, un budget réduit, un produit entre les mains. Ils atteignent leurs limites sur la logique métier fine, le volume, les intégrations et les données sensibles. Faites développer votre MVP quand le logiciel est le produit, quand vous devez vous connecter à un système existant, ou quand une contrainte réglementaire encadre vos données. Nous reprenons aussi les projets démarrés sur ces outils quand ils butent au passage en production.
05Qui possède le code du MVP ?
Vous, à 100 %, dans votre dépôt, dès le premier sprint. Pas de licence, pas de brique propriétaire, pas de dépendance à notre équipe. Si vous recrutez un CTO ou changez de prestataire après le MVP, il reprend un projet documenté avec une stack standard : React, Next.js, Node.js, TypeScript, PostgreSQL.
06Le MVP peut-il devenir la v1 sans être réécrit ?
Oui, à condition que les coupes portent sur le périmètre et non sur la qualité. Nous réduisons le nombre de fonctionnalités, pas le niveau d'exigence sur l'architecture, les tests et la sécurité. Un MVP qu'il faut jeter six mois plus tard coûte plus cher qu'un MVP un peu plus lent à sortir. Nos clients passent en général du MVP à la v1 par ajouts successifs, sur la même base de code.
07Faut-il un associé technique pour lancer un MVP ?
Non. C'est même le cas le plus fréquent chez nous : un fondateur qui connaît son marché, pas le code. Nous jouons alors le rôle de CTO externe le temps du MVP : arbitrages techniques, choix de stack, cadrage du périmètre, recrutement du premier développeur si vous internalisez ensuite. Vous parlez à des développeurs qui ont eux-mêmes lancé et vendu un produit, pas à un chef de projet qui transmettra.
08MVP web ou application mobile ?
Sauf besoin explicite du mobile (notifications push, usage hors ligne, appareil photo, géolocalisation continue), commencez par le web. Une application web responsive se met à jour en une minute, sans validation de store, ce qui est décisif quand vous itérez chaque semaine. Si le mobile est indispensable, nous développons en React Native pour couvrir iOS et Android avec une seule base de code.
09Comment financer le développement de son MVP ?
Plusieurs dispositifs existent : la Bourse French Tech de Bpifrance, le statut Jeune Entreprise Innovante, et certaines aides régionales. Le Crédit d'Impôt Innovation couvre une partie des dépenses de conception de produit nouveau, mais seulement vos dépenses internes ou celles d'un prestataire agréé CII, ce que nous ne sommes pas : il ne porte donc pas sur nos factures. Nous fournissons les éléments techniques nécessaires aux dossiers.
10Peut-on développer un MVP qui traite des données de santé ?
Oui, et c'est une partie importante de notre activité. Un MVP e-santé impose un hébergement certifié HDS dès le premier utilisateur réel quand les données sont recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, le plus souvent une analyse d'impact RGPD, et selon la finalité du logiciel une trajectoire de marquage CE dispositif médical. Ces contraintes se traitent au cadrage, pas après : elles changent l'hébergeur, le modèle de données et la gestion des accès. Nous avons livré des produits de ce type pour l'AP-HP et des startups e-santé.
11Comment choisir son agence de développement MVP ?
Quatre questions suffisent à trier. Qui écrira réellement le code, et pouvez-vous lui parler avant de signer ? Le code est-il à vous dès le premier jour ? Quelles références vérifiables, avec des produits toujours en ligne ? Et l'agence est-elle capable de vous accompagner après le MVP, ou son modèle s'arrête-t-il à la livraison ? Une agence qui accepte de vous dire non sur une fonctionnalité vous coûtera moins cher qu'une agence qui dit oui à tout.