Je construis Academy depuis plus d'un an maintenant.
C'est une plateforme d'éducation médicale pour étudiants. Flashcards, répétition espacée, suivi d'étude, gamification. Lancement en septembre 2026.
En chemin, j'ai fait toutes les erreurs possibles. Mauvais choix tech. Over-engineering. Under-engineering. Pricing qui avait pas de sens. Features que personne avait demandées.
Voici ce que j'aurais aimé qu'on me dise avant de commencer.
Leçon 1 : choisis de la technologie ennuyeuse
Mon premier instinct était d'utiliser les outils les plus brillants. Nouveaux frameworks. Bibliothèques cutting-edge. Des trucs que j'avais lus sur Twitter.
Mauvaise idée.
Chaque nouvel outil est une courbe d'apprentissage. Chaque bibliothèque en beta est un bug potentiel. Chaque choix "excitant" c'est du temps pas passé à construire des features.
Ce que j'utilise vraiment :
- Next.js pour l'app web (stable, grosse communauté, super docs)
- NestJS pour le backend (structuré, TypeScript-first, scalable)
- Flutter pour l'app mobile (une codebase, deux plateformes)
- PostgreSQL pour la base de données (ennuyeux, fiable, ça marche)
Pas de bleeding edge. Pas de "essayons ce nouveau truc." Juste des outils qui ont été testés par des milliers de développeurs.
La meilleure technologie c'est celle à laquelle tu dois pas penser.
Leçon 2 : commence avec un VPS, pas AWS
J'ai passé des semaines à rechercher AWS. EC2, RDS, Lambda, S3, CloudFront... La complexité était accablante. Les prix imprévisibles.
Puis j'ai découvert : un simple VPS gère bien plus que tu crois.
Mon setup actuel :
- PulseHeberg PERF-4 : 4 vCPU, 8GB RAM, €10/mois
- Gère la charge de développement facilement
- Peut scaler à 2 000-5 000 utilisateurs avant de nécessiter des upgrades
AWS a du sens à l'échelle. Mais "l'échelle" c'est pas 100 utilisateurs. C'est même pas 1 000 utilisateurs. Commence simple. Upgrade quand t'as le problème, pas avant.
Leçon 3 : Stripe au-dessus de tout le reste pour les paiements
J'ai évalué RevenueCat, Paddle, Lemon Squeezy, et Stripe.
J'ai choisi Stripe. Voici pourquoi :
- RevenueCat : Super pour les abonnements mobiles, mais prend 1-2% en plus des frais de l'app store. Pour un SaaS web-first avec app mobile, ça ajoute un coût inutile.
- Paddle/Lemon Squeezy : Gèrent la TVA/taxes pour toi, mais prennent 5%+ de frais. Bien si tu détestes la conformité fiscale, cher sinon.
- Stripe : 2.9% + €0.25 par transaction. Tu gères les taxes, mais tu gardes plus d'argent.
Pour Academy (modèle freemium à €9.99/mois) :
- RevenueCat coûterait ~€0.20 extra par transaction
- Sur 1 000 abonnés, c'est €2 400/an de perdus
Je préfère passer quelques heures à configurer la conformité fiscale que perdre ce revenu.
Leçon 4 : le freemium c'est plus dur qu'on croit
Mon plan initial : tier gratuit avec features basiques, tier payant avec tout le reste.
Ça a l'air simple. Ça l'est pas.
Questions que j'avais pas anticipées :
- C'est quoi "basique" assez pour être utile mais limité assez pour convertir ?
- Comment j'empêche l'abus du tier gratuit ?
- Comment je track l'usage des features pour savoir ce qui convertit ?
- Qu'est-ce qui se passe quand un utilisateur payant downgrade ?
Ce que j'ai appris :
- Le tier gratuit devrait résoudre un problème complètement, pas donner un avant-goût de tout
- Les limites doivent être évidentes : "5 decks de flashcards" c'est plus clair que "analytics basiques"
- Track tout : quelles features gratuites mènent aux upgrades ?
- Rends l'upgrade sans friction : un clic, pas un appel commercial
Leçon 5 : ne construis pas de features que personne a demandées
J'ai passé 3 semaines à construire un dashboard analytics complexe.
Des graphiques magnifiques. Export en PDF. Vues de comparaison. Le grand jeu.
Les utilisateurs voulaient : "Montre-moi ce que j'ai étudié aujourd'hui."
C'est tout. Une simple liste. Pas un dashboard. Pas des graphiques. Une liste.
Maintenant je suis cette règle :
La meilleure feature c'est celle qui résout un vrai problème. Pas celle qui impressionne dans une démo.
Leçon 6 : mobile et web sont des produits différents
"Je vais juste faire une web app responsive" c'était mon plan initial.
Puis j'ai essayé d'utiliser ma propre app sur mobile. L'expérience était terrible. Zones de tap trop petites. Navigation confuse. Performance lente.
Les utilisateurs mobiles attendent :
- Accès hors ligne
- Notifications push
- Gestes natifs (swipe, pull to refresh)
- Temps de démarrage rapide
Une web app responsive te donne pas ça. Donc j'ai construit une app Flutter.
Mais voilà le piège : maintenant je maintiens deux codebases. Deux sets de bugs. Deux cycles de release.
Mon conseil :
- Si mobile est critique : construis natif (ou Flutter/React Native) dès le jour 1
- Si mobile est nice-to-have : commence web-only, ajoute mobile plus tard quand t'as du revenu
- N'assume jamais que responsive = mobile-ready
Leçon 7 : ton premier pricing sera faux
Mon premier pricing : €4.99/mois.
Trop cheap. Les utilisateurs supposaient que c'était de mauvaise qualité. Je laissais de l'argent sur la table.
Mon deuxième pricing : €14.99/mois.
Trop cher pour des étudiants. La conversion a chuté.
Pricing actuel : €9.99/mois.
Peut-être encore faux. Mais voici ce que j'ai appris :
- Price sur la valeur, pas le coût : Ça vaut combien de réussir un examen ? Bien plus que €9.99
- Teste le pricing tôt : Mieux vaut perdre quelques early users que de bloquer un mauvais pricing
- Les réductions annuelles marchent : 2 mois gratuits pour l'annuel = meilleure rétention + cash d'avance
- Les étudiants sont sensibles au prix : Mais ils paieront pour quelque chose qui aide vraiment
Leçon 8 : lance avant d'être prêt
Academy devait lancer en mars 2026.
Puis j'ai ajouté "une feature de plus." Puis une autre. Puis j'ai réécrit le système d'auth. Puis j'ai redesigné le dashboard.
Nouvelle date de lancement : septembre 2026.
6 mois de retard. 6 mois de construction sans feedback utilisateur. 6 mois d'hypothèses qui sont peut-être fausses.
Ce que j'aurais dû faire :
- Lancer avec les flashcards seulement
- Avoir 50 utilisateurs
- Demander ce qui manque
- Construire ça
À la place, j'ai construit une plateforme complète pour des utilisateurs imaginaires avec des besoins imaginaires.
Leçon 9 : la distribution c'est plus dur que construire
Je peux construire des features toute la journée. Faire en sorte que les gens les utilisent ? C'est la partie difficile.
Ce qui marche pour moi :
- Marketing de contenu : Articles de blog, LinkedIn (cette série !)
- Leads chauds : Les connexions de ma copine en fac de médecine
- Communautés de niche : Forums d'étudiants en médecine, serveurs Discord
Ce qui marche pas :
- La prospection à froid
- Les posts génériques sur les réseaux sociaux
- "Construis-le et ils viendront"
La vérité inconfortable : un produit médiocre avec une super distribution bat un super produit sans distribution.
Passe autant de temps sur le marketing que sur le code.
Leçon 10 : c'est un marathon, pas un sprint
Je travaille sur Academy depuis plus d'un an. C'est pas encore lancé. J'ai zéro revenu.
Certaines semaines je suis motivé. Certaines semaines je veux abandonner.
Ce qui me fait tenir :
- 10 heures/semaine maximum : Rythme soutenable, pas de burnout
- Petites victoires : T'as shippé une feature ? Célèbre.
- Vraie deadline : Septembre 2026, pas d'excuses
- Revenu diversifié : Le freelance paie les factures pendant que le SaaS grandit
Les fondateurs qui réussissent sont pas les plus intelligents. Ce sont ceux qui abandonnent pas.
La cheat sheet
| Leçon | Action |
|---|---|
| Tech ennuyeuse | Next.js, NestJS, PostgreSQL. Pas de bleeding edge. |
| Commence simple | VPS d'abord, cloud après. €10/mois gère beaucoup. |
| Stripe pour les paiements | Moins de frais, plus de contrôle, ça vaut le coup de gérer les taxes. |
| Freemium c'est dur | Tier gratuit = un problème complet résolu. |
| Construis ce qu'on demande | 3+ utilisateurs l'ont demandé → construis. Sinon, attends. |
| Mobile ≠ responsive | App native si mobile est critique. |
| Teste le pricing tôt | Ton premier prix sera faux. C'est OK. |
| Lance tôt | 50 utilisateurs avec feedback > 0 utilisateur avec produit parfait. |
| La distribution compte | Temps marketing = temps de code. |
| Rythme soutenable | 10 heures/semaine. N'abandonne pas. |
La leçon
Construire un SaaS c'est 20% de code, 80% de tout le reste.
Les choix tech comptent moins que tu crois. Le marketing compte plus que tu veux. Et le seul vrai échec c'est d'abandonner.
Je te dirai comment le lancement s'est passé en septembre.
C'est la partie 5 de ma série "Ce que j'ai appris à mes dépens". Prochain article : déploiement et DevOps, les leçons dont personne ne m'a prévenu.
Des questions ? Contacte-moi sur LinkedIn ou découvre plus sur mon blog.