MVP
Le MVP ne teste pas un produit. Il teste une hypothèse. Si l'hypothèse est fausse, tout le reste est construit sur du sable.
Le MVP de BeYourself doit valider une seule chose : est-ce que la valeur perçue du profil d'identité est suffisante pour justifier l'effort de cataloguer sa garde-robe ? Cette question est fondamentale. Si la réponse est non — si les utilisateurs voient le profil et ne font pas l'effort d'uploader — alors le produit entier repose sur une promesse vide. Toutes les autres features sont secondaires à cette validation.
- Style questionnaire (5 questions visuelles)
- Profil_v0 instantané post-questionnaire
- Item upload + AI analysis (OpenAI Vision)
- Wardrobe catalog (grid simple)
- Suggestion basique (2 combos, pas de météo)
- Outfit logging 1-tap
- Auth (Apple + Google uniquement)
- Paywall test (€8.99, mesure willingness)
- >65% complètent le questionnaire
- >35% uploadent 10+ items en D7
- >40% acceptent la première suggestion
- >10% cliquent sur le paywall (intent)
- D7 rétention >25% sur première cohorte
- Au moins 3 utilisateurs utilisent l'app sans qu'on leur demande
- <40% complètent le questionnaire → repositionnement
- <20% uploadent items après profil_v0 → valeur insuffisante
- <20% acceptent suggestion → AI insuffisante
- D7 <15% → l'habitude ne se forme pas
- Aucun utilisateur n'ouvre l'app spontanément après J3
| Feature supprimée | Raison | Risque si incluse trop tôt |
|---|---|---|
| Notifications push matinales | Impossible de former l'habitude sans valider d'abord que la suggestion elle-même est bonne. Une mauvaise suggestion pushée crée une association négative permanente. | Habituation à des notifs médiocres → désinstallation définitive |
| Purchase Alignment Check | Nécessite un profil mature (30+ items). En MVP, le profil est trop immature pour produire un score crédible. Un score incorrect détruit la confiance dans la feature avant qu'elle soit viable. | Score faux → "cette app ne fonctionne pas" → churn |
| Style Journal | Pas assez de données en MVP pour être intéressant. Un journal vide est plus décourageant qu'une feature absente. | Empty state perçu comme un produit inachevé |
| B2B Pro (stylistes) | Produit distinct qui nécessite une architecture multi-tenant. Doit être conçu séparément — ne jamais bolter du multi-tenant sur une architecture mono-user. | Dette technique structurelle sur la gestion des permissions |
| Features sociales | La construction de la communauté avant le PMF est la recette du produit fantôme. Les features sociales sans contenu natif sont des déserts. | Communauté vide → perception de produit mort |
| Dark mode / Customisation UI | Investissement UI significatif pour zéro impact sur le PMF. À construire après validation. | Temps de dev perdu sur une préférence, pas sur la valeur |
| Décision | Acceptable ? | Justification |
|---|---|---|
| Pas de gestion offline complète | ✓ OK | Le Firestore SDK gère un cache basique. L'offline avancé est une optimisation, pas un prérequis de valeur. |
| Background removal via API externe (pas maison) | ✓ OK | Remove.bg ou équivalent. Cost acceptable en MVP (0.02$/image). Ne jamais construire un background removal maison avant 100K items. |
| Règles de suggestion basées sur des règles (pas ML) | ✓ OK | En MVP avec 10-20 items, un algorithme de matching par couleur + type est plus fiable qu'un ML sous-alimenté. |
| Analytics basique Firebase uniquement (pas PostHog) | ✓ OK | Firebase events suffisent pour les décisions MVP. PostHog vient en V1 quand le volume justifie l'analyse fine. |
| Pas de cache AI (SHA256) | Attention | Acceptable en MVP (<1K users), mais l'implémentation du cache doit être planifiée avant 5K users — les coûts explosent vite. |
| Questionnaire sans sauvegarde partielle | Attention | Acceptable si le questionnaire est court (<3 min). Au-delà, la perte de données intermédiaires crée de la frustration. |
| Pas de gestion RGPD complète | ✗ Interdit | La politique de confidentialité et les droits utilisateur (export, suppression) sont légalement obligatoires en France dès le premier utilisateur. Ce n'est pas optionnel. |
| Authentification email/password seulement (sans Apple/Google) | ✗ Interdit | Sans Sign in with Apple, le taux de complétion d'onboarding chute de 35%. C'est une feature de conversion critique, pas un confort. |
Le piège du MVP "trop complet" : chaque feature ajoutée au MVP allonge le time-to-market, dilue le focus de l'équipe, et complexifie la lecture des signaux de validation. Si le MVP contient 15 features, impossible de savoir laquelle a causé le succès ou l'échec. Le MVP doit être assez minimal pour que les apprentissages soient clairs.
V1 — Post-Validation
La V1 n'est pas construite après le MVP. Elle est construite après la confirmation que le MVP a validé son hypothèse. Cette distinction est fondamentale.
- Morning suggestion avec météo + agenda
- Push notifications contextuelles (heure configurable)
- Context input (humeur 3 sec + contexte)
- Style Clarity Score visible + expliqué
- Paywall optimisé (triggers post-aha)
- Purchase Alignment Check
- Style Journal (timeline basique)
- Memory triggers (3+ mois d'absence)
- Bulk import Vinted / commandes
- Privacy Dashboard (RGPD complet)
- B2B Pro beta fermée (20 stylistes)
- Profile sharing (opt-in public)
- Referral program basique
- PostHog analytics complet
- iOS Widget (suggestion écran d'accueil)
En V1, les utilisateurs commenceront à demander des features. Ce n'est pas une raison de les construire. La demande utilisateur n'est pas une stratégie produit. Voici ce qui sera demandé et pourquoi c'est différé :
| Feature demandée | Raison du différé |
|---|---|
| Feed social / partage de tenues | Besoin 1000 utilisateurs actifs minimum pour que le feed social ne soit pas vide. En V1, un feed vide est plus nocif que l'absence de feature. La demande vient des "Performeurs sociaux" — segment à risque de dérive de la proposition identitaire. |
| Marketplace / recommandations d'achat | La confiance doit être établie avant de monétiser via le commerce. Un utilisateur qui découvre que BeYourself est sponsorisé par des marques avant d'avoir confiance = destruction de la différenciation "pas de pub". |
| Partage vers Instagram / TikTok direct | L'intégration deep avec les réseaux sociaux crée des dépendances API instables. En V1 : export image natif suffit. L'intégration directe vient en V2 avec les style cards du Wrapped. |
| Version desktop complète | 90% des comportements core (upload, suggestion matinale, log) sont mobiles. La version desktop est un investissement avec peu de retour en V1. |
V2 — Croissance
La V2 ne commence que quand la rétention D30 est stable et que le MRR croît de façon prévisible. Scaler sans rétention solide, c'est remplir un seau percé.
- Style Wrapped annuel (partage viral)
- Shareable style cards (DNA, score)
- Co-styling basique (partage tenue avec amie)
- Intégration Vinted officielle (partenariat)
- Occasion Planner (voyage, événement)
- Cloud Run migration (vs Cloud Functions)
- Cloud Memorystore Redis (cache suggestions)
- Optimisation coûts AI (cache SHA256)
- pgvector optimisation (embeddings profil)
- Modèle ML custom V1 (fine-tuning basique)
- B2B Pro scale (200 stylistes)
- Commerce intentionnel (curation partenaires)
- Expansion géo (Belgique, Suisse, Canada)
- API Intelligence Marché (beta marques)
- Annual plan push (après 90j d'usage)
La croissance amplifie les problèmes existants. Ce qui était gérable à 10K users devient critique à 100K.
| Risque | Mécanisme | Mitigation à préparer en V1 |
|---|---|---|
| Explosion coûts Firestore | À 100K users × 500 reads/jour × €0.06/100K = €3K/mois uniquement en lectures. Non-linéaire si les sessions s'allongent. | Dénormaliser les documents Firestore, activer le cache client agressif, monitorer les reads/user/jour dès 10K. |
| Qualité suggestions plateau | Le moteur rule-based du MVP plafonné à 60-65% SAR. Au-delà, il faut du ML réel pour progresser. | Logger toutes les données de feedback (accepté/refusé/modifié) dès le MVP pour avoir le dataset d'entraînement en V2. |
| Dérive communautaire (features sociales) | Les features sociales V2 peuvent attirer les "Performeurs Sociaux" et dériver la communauté vers la performance vs l'identité. | Définir la modération community guidelines avant le lancement des features sociales. Pas de features sociales sans équipe de modération. |
| Recrutement bloquant | En V2, il faut recruter un ML engineer et un second PM. Ces profils sont rares et longs à recruter (3-6 mois). | Commencer le recrutement ML engineer dès M8 (V1 avancée) pour être opérationnel en V2. |
Vision
Long Terme
Pas une super app. Une position défendable construite sur des données irréplicables et une relation irremplaçable.
En 2027-2029, si BeYourself exécute correctement, il n'est plus une app de mode. Il est devenu la plateforme de référence pour l'identité visuelle personnelle en Europe. Cette position se construit par couches :
Couche 1 (3 ans) — La donnée irréplicable : avec 1M+ profils actifs et 50M+ outfits loggés, BeYourself possède le dataset le plus précis au monde sur les préférences esthétiques réelles (comportementales, pas déclaratives). Cette donnée prend 3 ans à accumuler. Aucun concurrent ne peut la répliquer en moins de 3 ans, même avec des ressources illimitées.
Couche 2 (4 ans) — L'API d'identité marques : les directeurs artistiques et équipes de collection des marques mode premium (Sandro, A.P.C., Rouje, Jacquemus) utilisent l'API BeYourself Intelligence pour comprendre ce que leurs clients portent réellement — pas ce qu'ils disent aimer dans des sondages. Ce B2B à haute marge devient le second moteur de revenus, indépendant de la croissance consumer.
Couche 3 (5 ans) — L'extension naturelle : l'identité visuelle vestimentaire est la porte d'entrée. Une fois que BeYourself maîtrise cette couche, l'extension vers l'intérieur (design d'appartement), l'identité professionnelle (executive presence), et potentiellement l'identité numérique (avatar cohérent avec l'identité physique) devient organique. Pas une décision stratégique forcée — une suite logique d'une relation de confiance établie.
| Avantage défendable | Pourquoi difficile à répliquer | Condition de construction |
|---|---|---|
| Dataset comportemental stylistique | Il faut des années d'interactions réelles (pas de scraping possible). Chaque jour d'usage ajoute de la valeur au dataset. Les données de port réel (vs aspiration) n'existent nulle part ailleurs. | Logger tous les feedbacks de suggestion dès le MVP. Ne jamais supprimer ces données. |
| Switching cost émotionnel | Le profil d'identité de l'utilisateur est unique à BeYourself. Le journal de style est son histoire. On ne "migre" pas son identité vers une autre app — on la recrée de zéro. | Activer le journal dès la V1. Chaque log est un verrouillage émotionnel. |
| Réseau B2B de stylistes | Un réseau de 500+ stylistes professionnels prescripteurs est impossible à construire rapidement. Chaque styliste est un canal d'acquisition B2C et un validateur de qualité produit. | Lancer la beta Pro stylistes dès la V1 (20 stylistes), ne jamais les traiter comme secondaires. |
| Modèle ML propriétaire (V2+) | Un modèle fine-tuné sur des données BeYourself produit des résultats 20-30% supérieurs aux modèles génériques pour l'analyse de vêtements. Ce gap s'élargit avec le temps. | Logger toutes les corrections utilisateurs sur l'AI analysis dès le MVP. Ce sont les données d'entraînement futures. |
Priorisation
Le framework de priorisation de BeYourself n'est pas RICE générique. Il pondère l'impact identitaire — parce que c'est le différenciateur du produit.
Score = (Reach × Identity_Impact × Retention_Impact × Revenue_Impact) / Effort
La différence avec RICE : Identity_Impact remplace Confidence. Chaque feature est notée sur son impact sur la profondeur de l'identité utilisateur (1-5). Une feature qui nourrit le profil d'identité est systématiquement prioritaire sur une feature qui nourrit l'engagement superficiel.
| Feature | Reach | Identity (1-5) | Rétention (1-5) | Revenue (1-5) | Effort (S/M/L) | Score |
|---|---|---|---|---|---|---|
| Morning Suggestion + Push | 100% | M | P0 | |||
| Style Clarity Score visible | 100% | S | P0 | |||
| Purchase Alignment Check | 60% (profil mature) | M | P1 | |||
| Style Journal | 80% | M | P1 | |||
| B2B Pro (stylistes) | 5% (pro users) | L | P1 | |||
| Style Wrapped | 100% | M | P2 | |||
| Features sociales (co-styling) | 40% | L | P3 |
Construire ce que les utilisateurs demandent, pas ce dont ils ont besoin. Les utilisateurs demandent des features de confort (partage, personnalisation de l'interface, filtres supplémentaires). Ils ne demandent jamais "améliorez la qualité de votre moteur de suggestion de 15%". Pourtant, c'est la seconde décision qui a 10× plus d'impact sur la rétention.
Traiter la dette technique comme secondaire jusqu'à ce qu'elle bloque. La dette s'accumule exponentiellement. Une architecture Firestore mal conçue à 10K users coûte 2 semaines de refactoring. La même architecture à 200K users coûte 3 mois de refactoring et des migrations en production avec des risques de downtime.
Lancer une feature "à moitié faite" pour tenir une deadline. Une suggestion matinale qui déçoit 3 matins consécutifs est pire qu'une suggestion matinale absente. La qualité du cœur produit ne peut pas être sacrifiée pour une date.
Estimation
Complexité
Les features qui paraissent simples cachent souvent la plus grande complexité. L'inverse est aussi vrai.
Paraît trivial. Le vrai travail est dans le design des questions et la validation que le profil_v0 résultant est suffisamment précis et différenciant.
Le goulot d'étranglement réel. La gestion des états asynchrones (upload → background removal → AI → Firestore realtime update → UI update) crée une chaîne complexe avec des points de défaillance multiples.
Le pré-calcul nocturne par timezone est plus complexe qu'il n'y paraît. À 10K users dans 5 timezones différentes, les Cloud Scheduler jobs doivent être précis au fuseau horaire et efficaces en coût.
L'interface est simple. La complexité est dans le pipeline de calcul : embeddings CLIP par item, clustering par couleur, détection de patterns comportementaux. Ce pipeline doit être conçu pour être recalculé efficacement après chaque log.
La Share Extension iOS/Android (partage depuis Safari) est plus complexe que l'upload in-app. Chaque app d'e-commerce a des structures HTML différentes pour extraire l'image du produit.
Le multi-tenant doit être conçu dès le départ dans le schéma Firestore et les Security Rules. L'ajouter après coup nécessite une migration de données majeure.
La génération de cartes visuelles à la volée pour des milliers d'utilisateurs en même temps (décembre) crée un spike de charge prévisible mais intense. Le rendu des cartes doit être asynchrone et mis en cache.
// regle_complexite : si une feature "paraît simple", ajouter 50% au temps estimé. Si une feature "paraît complexe", creuser les simplifications possibles avant d'estimer. Dans 80% des cas, les features complexes peuvent être simplifiées sans perdre 90% de leur valeur.
Estimation
Coûts
Les startups sous-estiment systématiquement trois postes : les coûts AI à l'échelle, le temps de recrutement, et le support client.
Budget total estimé : MVP build = €80-120K (équipe 4 mois). V1 complète = €250-350K (équipe 6 mois post-MVP). Break-even théorique : avec 2000 abonnés premium à €8.99 + 30 stylistes Pro à €49 = ~€19.5K MRR. Break-even mensuel (hors salaires) possible à M8-12. Les startups qui manquent de cash ici ne manquent pas de PMF — elles manquent de runway pour atteindre le seuil de rétention qui justifie la conversion.
Estimation
Délais
La timeline réaliste est toujours plus longue que la timeline optimiste. Le multiplicateur standard : prendre l'estimation, multiplier par 1.5, et être prêt à multiplier encore par 1.3.
| Facteur | Délai typique | Mitigation |
|---|---|---|
| App Store Review (iOS) | 3-7 jours par soumission | Soumettre 10 jours avant la date de lancement. Toujours avoir une version de secours prête. Ne jamais planifier de lancement le vendredi. |
| Recrutement senior Flutter/Dart | 2-4 mois | Commencer le recrutement avant que le besoin soit urgent. Envisager des freelances pour les pics de dev en MVP. |
| Intégration OpenAI instable | 1-3 jours par incident | Implémenter la couche d'abstraction AIProvider dès le début. Un fallback vers Gemini Flash doit être testable en 1 heure. |
| Firebase Security Rules debug | 2-5 jours par module | Tester les Security Rules avec le Firebase Emulator dès le début. Les bugs de Rules en production sont difficiles à diagnostiquer. |
| Design → Dev handoff | +20-30% de temps dev | Utiliser Figma avec les tokens du Design System directement dans les composants Flutter. Aucune valeur numérique dans les specs — uniquement des tokens. |
| QA multi-devices | 1-2 semaines | iPhone SE (petit écran), iPhone 15 Pro Max (grand écran), Samsung Galaxy A53 (Android mid-range) → les 3 devices minimum à couvrir. |
Dépendances
Une dépendance acceptable aujourd'hui peut devenir existentielle demain. Identifier les risques maintenant pour ne pas les subir à l'échelle.
Cœur de l'analyse d'items. Risque : changement de tarification (déjà arrivé 3× en 2 ans), API rate limits en période de spike, dégradation de qualité entre versions de modèles. Mitigation absolue : AIProvider abstraction dès J1. Tester Gemini Vision chaque trimestre pour maintenir une alternative activable en 4h.
Distribution principale iOS. Risque existentiel : une politique de refus sur la catégorie "mode" ou "données personnelles vestimentaires" peut bloquer la distribution. Construire une PWA web en parallèle à partir de la V1 pour ne jamais être dépendant d'un seul canal de distribution.
Auth, Firestore, Storage, Cloud Functions. Vendor lock-in fort sur les Security Rules Firestore — elles ne sont pas portables. Mitigation : encapsuler toute la logique métier dans les Cloud Functions (pas dans les Rules), documenter le schéma Firestore indépendamment. En cas de migration forcée, les Functions sont extractibles.
Paiements et abonnements. Risque faible en Europe. Frais standard : 1.4%+€0.25. À €8.99/mois, Stripe prend ~€0.38 par transaction = 4.2% du revenu. Acceptable jusqu'à €5M ARR puis négocier enterprise pricing. Migration vers une alternative (Paddle, LemonSqueezy) est envisageable mais coûte 2-4 semaines dev.
Non-critique techniquement. L'analyse AI fonctionne sans background removal — c'est une amélioration de qualité, pas un prérequis. Si Remove.bg change ses tarifs ou son API, dégrader proprement vers l'image brute le temps de trouver une alternative (rembg open-source, Clipdrop API).
iOS 16+ exige un opt-in explicite. Taux d'acceptation moyen sur apps lifestyle : 40-55%. Si ce taux baisse (tendance à la baisse depuis 2023), la rétention via la suggestion matinale est directement impactée. Mitigation : widget iOS/Android comme backup de la notification. Email opt-in pour les non-push-users.
La dépendance la plus sous-estimée. Flutter/Dart senior est un profil rare en France. Le délai de recrutement réaliste est 3-6 mois avec onboarding. Si le recrutement est initié trop tard, le MVP est bloqué. Commencer le recrutement au moins 3 mois avant le début du développement. Prévoir des freelances Dart de qualité comme backup.
Le B2B Pro nécessite d'avoir des stylistes en beta avant de construire la feature. Ce n'est pas une dépendance technique — c'est une dépendance de distribution. Commencer le recrutement des 20 stylistes beta dès M2 du projet (avant même d'avoir la feature). Utiliser LinkedIn, Instagram pro, les associations de styling.