Next ou TanStack ? La question n'est pas là

J'ai deux projets en production. L'un tourne sous Next.js, l'autre sous TanStack Start.

Je vais expédier la comparaison en une section, parce que ce n'est pas le sujet. Le vrai sujet, c'est ce dont personne ne parle dans les threads sur les frameworks : comment on trouve des utilisateurs.

La comparaison, vite fait

Ce portfolio tourne sous Next.js. Prospect Tracker, l'outil qui pilote mon activité freelance, tourne sous TanStack Start.

Le choix ne s'est pas joué sur des benchmarks :

Un site de contenu a besoin de pages générées au build et indexables. Un SaaS derrière un login n'a aucun besoin de SEO, mais demande une grosse gestion d'état côté client.

Deux problèmes différents, deux outils différents. C'est tout.

Le bon framework est celui dont vous connaissez déjà les pièges. L'expérience se transfère mal d'un écosystème à l'autre, et c'est elle qui vous fait coder vite.

Voilà. Vous pouvez choisir n'importe lequel des deux et livrer quelque chose de correct. Maintenant, parlons de ce qui va réellement décider du sort de votre projet.

Le produit n'est pas le problème

Coder un SaaS est devenu la partie facile. Auth, paiement, base de données : tout est résolu, documenté, et une bonne partie se génère.

Ce qui reste difficile, c'est que quelqu'un l'utilise.

J'ai mis du temps à l'accepter, parce que c'est vexant. On passe des années à devenir bon en développement, et on découvre que cette compétence ne suffit pas à faire vivre un produit.

Voici les principes que j'applique maintenant, dans l'ordre d'importance :

• Le bon message : clair, qui parle directement au problème
• Une seule feature, bien faite
• Un bon time to market : livrer avant que le marché change
• Une offre, un prix : pas de grille à trois colonnes au lancement
• Un seul canal d'acquisition : la dispersion tue

Aucun ne concerne le code.

Chercher un problème, pas une idée

L'erreur classique est de partir d'une idée qu'on trouve géniale. Le réflexe inverse est plus fiable : prendre un marché déjà validé, repérer précisément ce qui manque aux solutions existantes, et faire mieux sur ce point.

C'est le principe Lemlist. Avant eux, il existait déjà des dizaines d'outils de cold email. Le fondateur a simplement vu ce dont les utilisateurs se plaignaient chez les concurrents.

Ça élimine le biais du survivant : la demande existe déjà, il reste à mieux la servir.

Et si vous ne trouvez aucun concurrent, ce n'est pas une bonne nouvelle. C'est presque toujours le signal qu'il n'y a pas de marché.

La grille que j'utilise

Chaque idée se classe de 1 à 5 selon la saturation du marché. Le point d'entrée idéal se situe en 2-3.

Un dernier point sur le choix du marché : le B2B se monétise plus facilement que le B2C, parce que la valeur y est calculable. Un outil qui fait gagner cinq heures par mois à une PME justifie 50 à 100 € mensuels sans discussion. En B2C, il faut convaincre un particulier de sortir 9 € de sa poche, et c'est souvent plus dur.

Valider avant de coder

Avant d'écrire une ligne, il faut vérifier deux choses : le problème est réel, et des gens sont prêts à payer pour qu'il disparaisse.

Pour Prospect Tracker, j'ai fait le minimum : un formulaire Tally partagé sur mes réseaux, avant la première commande pnpm create next-app@latest.

Les réponses ont fait plus pour le produit que n'importe quelle décision d'architecture. Elles m'ont dit quoi construire en premier, et surtout ce que je pouvais laisser de côté.

Selon le temps de construction du MVP, deux approches :

• Presale : une landing page avec une section tarif, pour voir si les gens paient sur la base d'une promesse. Utile quand le MVP est rapide à construire.
• Prelaunch : une landing page avec une promesse claire, sans paiement, juste des inscriptions. Utile quand le MVP demande plus de six mois. On recontacte les inscrits une fois le produit prêt.

Il existe aussi la méthode « fake it » : rendre le service manuellement en laissant croire qu'il est automatisé. Ça teste l'intérêt réel sans investir dans la technique.

Le seul signal qui ne ment pas : trouver au moins trois personnes hors de votre entourage prêtes à payer réellement. Pas à tester gratuitement. Le montant importe peu.

Le prix se décide avant le code

L'erreur numéro un est de lancer gratuitement en se disant qu'on monétisera plus tard. Le résultat classique : beaucoup d'inscriptions, zéro revenu.

La stratégie de prix se pense avant le lancement, pas après.

Ce qu'on ne fait pas à ce stade, en revanche : choisir un nom définitif, dessiner un logo, peaufiner une landing page, affiner une grille tarifaire. Rien de tout ça ne trouve d'utilisateurs.

Le calcul qui remet les idées en place

Voilà l'exercice qui m'a le plus fait réfléchir. Partez de votre objectif de revenu et remontez :

Objectif                     10 000 € de MRR
Offre à 50 €/mois          → 200 clients payants
Conversion 10 % (freemium) → 2 000 utilisateurs actifs
Pour 2 000 inscriptions    → 50 000 à 100 000 personnes touchées

Cent mille personnes. Pour dix mille euros par mois.

Quand on voit ce chiffre, on comprend pourquoi le débat Next contre TanStack est secondaire. Aucun framework ne vous fera gagner 100 000 visiteurs.

Un seul canal

La tentation est de tout faire en même temps : Product Hunt, Reddit, cold email, ads, newsletter. C'est le meilleur moyen de tout faire mal.

Un seul canal principal au lancement. Les autres viendront après.

• Vendre organiquement : identifier les communautés où se trouve votre cible et y être présent honnêtement, sans spammer votre lien.
• Bouche-à-oreille : mettre en place un lien d'affiliation dès que les premiers clients sont contents.
• Newsletter : construire une liste avant le lancement public, pour ne pas parler dans le vide le jour J.

Ensuite l'effet boule de neige : le projet s'ébruite, des opportunités arrivent d'elles-mêmes. À ce moment-là seulement, on réinvestit dans d'autres canaux.

Écouter ce que font les gens, pas ce qu'ils disent

Une fois le produit entre les mains des premiers utilisateurs, deux signaux valent plus que tous les retours déclaratifs :

Est-ce qu'ils reviennent sans relance ? L'usage spontané est le seul indicateur fiable. Les intentions annoncées ne valent rien.

Qu'est-ce qu'ils bricolent à la main ? Ce que les gens contournent dans le produit désigne exactement la prochaine feature à construire.

C'est pour ça que je mets du tracking dès le début, avec des events PostHog un peu partout. Pas pour faire joli sur un dashboard, mais parce que sans données, on construit à l'aveugle en se fiant à son intuition.

En pratique

Les deux projets sont en prod. C'est le seul critère qui résiste à l'épreuve du temps.

Un projet livré avec un framework moyen vous apprendra plus qu'un projet parfait qui reste sur votre localhost. Le retour utilisateur, les cas limites, les vrais problèmes de perf : ça n'apparaît qu'une fois en ligne.

Et le choix de la stack est réversible. L'essentiel de votre logique métier n'en dépend pas.

Si vous hésitez entre deux technos pour votre prochain projet, trois questions suffisent :

• Lequel je connais assez pour livrer ce mois-ci ?
• Est-ce que mon projet a besoin de SEO, ou vit-il derrière un login ?
• Est-ce que je saurai déboguer un problème de prod à 22h avec cet outil ?

Puis passez à la vraie question, celle qui décidera de tout : qui va l'utiliser, et comment ces gens vont-ils en entendre parler ?

Si vous êtes freelance et que vous gérez votre prospection sur un Notion bancal, Prospect Tracker est en construction publique. Le formulaire est toujours ouvert : donner son avis. Ça vous donne aussi un accès anticipé.