Une V1 utile ne cherche pas à "tout faire". Elle cherche à valider vite une proposition de valeur, avec un socle propre et évolutif. Après avoir accompagné une douzaine de startups vers leur première livraison, on voit toujours les mêmes dérives : périmètre qui gonfle de 40 % en cours de route, choix d'architecture remis à plus tard, qualité sacrifiée pour "aller vite".

Le résultat : une démo fragile qui ne survit pas au premier utilisateur payant. Pire encore, elle force une refonte totale 6 mois plus tard, ce qui gaspille le temps gagné initialement. On a vu des équipes "gagner" 6 semaines en envoyant du code sans tests, puis en perdre 16 à corriger les bugs en production et à refactoriser l'architecture bâclée. Le gain était faux.

👉 Le bon objectif : livrer une version testable et réellement exploitable, pas une démo pour lever des fonds. La question n'est pas "combien de features on a ?" mais "est-ce que ce produit peut survivre à 100 utilisateurs payants sans s'effondrer ?"

Pourquoi les V1 dérivent (et comment l'éviter)

Les 70 % des débordements de délai proviennent de trois erreurs récurrentes.

D'abord, le périmètre n'est jamais vraiment gelé. On commence avec une liste de "must have" de 15 points : auth, dashboard, export CSV, notifications, intégration Slack, etc. Dès la semaine 3, après les premières démos internes, on en a 24. La co-founder veut ajouter "bulk actions", un dev propose d'intégrer Zapier "pendant qu'on y est", un testeur demande un mode dark. Semaine 5, vous êtes à 32 items, le deadline glisse déjà.

Deuxième : les décisions architecturales traînent en longueur. Quelle DB ? PostgreSQL ou DynamoDB ? Quel backend : Next.js API routes ou Node/Express ? Comment l'auth ? OAuth ou JWT custom ? Ces choix devraient être verrouillés semaine 1 : ils influencent tout le reste. Au lieu de ça, on dit "on verra en codant", et semaine 3, vous vous rendez compte que vous avez construit sur la mauvaise fondation.

Troisième : la qualité devient un curseur. Pour "ne pas prendre de retard", on baisse les stabilité (skip les tests), les perfs (optimisation ? après launch), les logs (trop complexe maintenant). Résultat en semaine 8 : un produit si bugué que 50 % des testeurs l'abandonnent après 5 min. Les vrais utilisateurs payants ? Ils ne vont jamais venir.

Les équipes qui réussissent en 90 jours appliquent trois principes simples : cadrage strict dès le jour 1, décisions architecturales verrouillées avant de coder une seule ligne, et qualité de base non négociable (stabilité, perfs minimales, sécurité, logs) qui n'est jamais le compromis quand on "manque de temps".

Semaine 1 : les décisions à prendre (avant de toucher au code)

Prenez 3-4 jours pour aligner le produit, l'équipe et la tech sur cinq points clés. C'est court, c'est tendu, mais c'est non-négociable.

Problème utilisateur à résoudre : défini en une phrase, testable. "Aider les freelances à facturer en moins de 5 min" marche. "Plateforme complète de gestion d'activité" est trop vague. Vous pouvez demander à un testeur "peux-tu facturer un client en 5 min ?" et il peut répondre oui ou non. C'est ça qu'il faut.

Parcours critique à valider : quel flux utilisateur doit absolument marcher sans friction ? Pour une app de facturation : créer un compte → ajouter un client → générer une facture → la télécharger. Voilà. Si ce flux marche parfaitement et que tout le reste est cassé, vous pouvez lancer. Si ce flux est bugué, vous ne lancez pas.

Critères de succès mesurables : pas "l'app doit être bonne". Mesurable, c'est : 20 utilisateurs testeurs créent une facture sans contact support dans la semaine 1. Les pages chargent en moins de 2 sec sur 4G. Le taux d'abandon du flux principal est < 20 %. C'est chiffré, c'est vérifiable, c'est là qu'on va juger la V1.

Décisions architecturales : Database (Postgres ou Mongo ?), backend (Next.js, Node/Express, Ruby on Rails ?), auth (OAuth, JWT, sessions ?), déploiement (Vercel, fly.io, EC2 ?). Ces choix prennent 1-2 jours à prendre sérieusement, 2 semaines à refondre après. Donc on les verrouille semaine 1. Pas "parfait", juste "bon assez pour 90 jours".

Dette acceptable vs bloquante : vous acceptez de laisser "export PDF avancé avec custom branding" à la V2. C'est nice-to-have. Mais une authentification fragile ? Non. Des données perdues si le server crash ? Non. Un UI tellement lente qu'on attend 3 sec à chaque clic ? Non. Distinguez : dans ce qui est hors périmètre, qu'est-ce qui pourrait casser le produit ? Ça, on le fait en V1.

Ce cadrage écrit, partagé et signé mentalement sauve des mois de débat. Il devient votre Constitution : quand une demande arrive semaine 4 (et ça arrive toujours), vous demandez simplement "ça rentre dans notre périmètre V1 ?" et vous avez une réponse claire. Zéro ambiguïté.

Cadence sur 90 jours : phases et livrables clés

Chaque semaine : démo interne lundi, retours marcredi, arbitrages rapides jeudi. Rien ne traîne au-delà de 48h.

Le socle à construire en priorité (et pourquoi c'est non-négociable)

Semaines 3-5, construisez dans cet ordre exact. Cet ordre est scientifique : chaque bloc déverrouille le suivant.

1. Authentification + rôles (4-5 jours). Utilisateur, admin (ou plus de rôles si votre produit l'exige). À la main avec sessions, Auth0, Firebase, peu importe. Ce qui compte : c'est la fondation pour le reste. Sans auth, vous ne pouvez rien tester en multi-user.

2. Flux principal E2E (7-9 jours). Du login à l'action clé : créer une facture, envoyer un message, uploader un document, publier un post. Rien de beau, zéro polish. Juste : ça marche de bout en bout en local. Un testeur qui logue peut faire l'action et voir le résultat.

3. Data schema + API (5-6 jours). Base DB correctement structurée (migrations, foreign keys, indices on the right columns). Endpoints API stables (vous allez les refactor en V2, mais pas en V1.1 parce que l'architecture était cassée). Testable localement ou sur une DB de staging.

4. Analytics basique (2-3 jours). Qui logue ? Quel événement déclenche une conversion ? Utilisateur crée une facture = événement "invoice_created". Événement envoyé à Segment, Amplitude ou un simple webhook. Vous devez mesurer le funnel : 100 créent un compte, 70 ajoutent un client, 50 créent une facture. C'est ça qui vous dit si votre UX est bonne.

Ce socle représente 60-70 % du travail initial. Les 30-40 % restants (UI polish, animations, edge cases, perf fine-tuning) se font semaines 6-12, après que vous ayez itéré sur le feedback. Respectez cet ordre : trop d'équipes construisent l'UI d'abord, polissent les micro-interactinos, et découvrent semaine 6 que le flux principal n'a pas de sens utilisateur.

Qualité : ce qui ne se négocie jamais

Sur chaque ligne de code :

"Une V1 rapide mais instable coûte 4× plus cher : déception utilisateurs, bug reports, patches en urgence, confiance cassée."

Stabilité parcours critiques : les bugs au chemin principal sont corrigés avant de pousser. Tests E2E basiques (Playwright, Cypress) dès la semaine 4. Perfs acceptables : < 2.5 sec chargement initial, < 1 sec interaction. Mesurez avec Lighthouse, optimisez une fois. Sécurité minimale : HTTPS, validation entrée, pas de secrets en Git, OWASP top 10 de base. Logs + monitoring : chaque erreur backend logguée, alertes sur erreurs 500 dès la semaine 9. Vous n'attendez pas la V1.1 pour avoir de la visibilité.

Ce n'est pas perfectionnisme. C'est d'éviter la bombe à retardement.

Cas concret : quand ça marche vraiment

Une marketplace de services (nettoyage, plomberie, électricité) qu'on a lancée il y a 18 mois. Semaine 1 : équipe de 4 (1 PO, 2 devs, 1 designer). Cadrage brutal. Périmètre V1 : 80 items au départ, réduits à 45 après deux jours de discussion. Les vrais critères : 20 nettoyeurs crée un profil, 20 clients envoient une demande, 10 demandes reçoivent une offre. C'était tout.

Semaines 2-5 : auth (Passportjs + PostgreSQL), flux principal E2E (client envoie demand → nettoyeur reçoit notification → envoie offre → client valide ou refuse). La DB : structure simple mais cohérente (users, services, requests, offers). Zéro tentative de "tout prévoir", zéro migrations bâclées. Semaine 4, premiers testeurs. Chaos attendu : un bug majeur (notifications ne partaient pas), corrigé en 3h parce que les logs étaient là.

Semaines 6-8 : les retours étaient clairs. Les clients voulaient pouvoir voir l'historique des services, les nettoyeurs voulaient pouvoir refuser une demande facilement. Deux semaines pour itérer.

Semaines 9-10 : perf complètement optimisée, Lighthouse 90+, Core Web Vitals stable. Monitoring en place (Sentry pour les erreurs, PostHog pour l'usage).

Semaine 11 : première vraie offre de nettoyage payante. Semaine 13, 8 transactions. Semaine 16, 50+ par semaine. La V2 a pris 6 semaines (payments Stripe, système de rating, chat entre client et nettoyeur) parce que la base était solide.

L'équipe n'a pas dérapé. Pas parce qu'ils étaient parfaits. Parce que : (1) le périmètre était clair et respecté, (2) les décisions tech étaient en place d'emblée, (3) la qualité n'a jamais été le compromis. Résultat : 18 mois plus tard, ils ont 150 nettoyeurs payants, revenue 5-figure/mois, et aucune bombe de dette technique qui menace.

Rythme d'exécution réel : comment garder le cap

Planning sprint : 1-2 semaines, limité à 15-20 points de charge. Changement de scope milieu de sprint = aucun. C'est noir ou blanc. Démo hebdomadaire : 45 min maximum, interne ou avec stakeholders. Ça force à finir les features, pas à traîner sur du polish. Feedback centralisé : un Slack channel, une issue tracker. Les demandes arrivent là, pas par DM, pas par mail. Elles sont triées, vous dites "V1 ou V2 ?" et hop, c'est tracé. Arbitrages rapides : la PO ou le co-founder a le pouvoir de trancher en 15 min. Pas de débat infini.

👉 Résultat concret : vous gagnez 2-3 semaines juste en éliminant le bruit et en prenant des décisions vite.

Ce que ça change réellement côté business

Lancer 12 semaines plus tôt au lieu de 20, c'est 8 semaines d'utilisateurs payants de plus en année 1. Concrètement : même si seulement 10-15 clients paient au jour 1, vous apprenez leur besoin réel en temps réel, pas sur du papier. Vous ajustez le produit rapidement : telle feature n'intéresse personne, telle autre on peut la vendre 2× plus chère. Vous validez ou tuez votre hypothèse de marché avant de brûler le budget marketing en PPC.

Une V1 solide (pas parfaite, solide) permet une V2 en 6-8 semaines, pas 12. Parce que vous itérez sur des fondations stables (une DB bien pensée, une API cohérente, des tests E2E qui passent) au lieu de refactorer du code cassé tous les 2 jours.

Coût aussi : une équipe qui déraille et arrive à jour 180 avec un produit instable, ça force une refonte totale et 4-6 mois perdus. Une équipe qui cadre, arrive à jour 90 avec un produit qu'on peut itérer. L'économie est brutale.

👉 En 90 jours, on ne cherche pas la perfection. On cherche le bon équilibre : assez rapide pour apprendre du marché réel, assez solide pour que ce marché réel ne déteste pas le produit.

Ce cadre a marché sur des apps de gestion de tâches, des marketplaces, des outils B2B. Les détails changeaient (une marketplace a besoin de payment processing, une app SaaS non), le rythme restait. Inprogress accompagne des équipes qui appliquent exactement ce système : cadrage fort semaine 1, pas d'appel de scope mid-flight, delivery itérative, mesure constante.