Il ne vous faut que 3 jours et 400 dollars pour apprendre pas à pas à créer une plateforme Launchpad.

Titre original : I Built a Launchpad in 3 Days for $400 (and so can you)
Auteur original : ultra

Traduction : Luffy, Foresight News

Le week-end dernier, j'ai travaillé en heures supplémentaires pour créer le projet Blind, simplement pour prouver qu'il n'est pas nécessaire d'avoir des millions de dollars de financement, des mois de travail, ni même une équipe pour construire un produit significatif.

Blind est une plateforme d’émission de tokens développée sur la chaîne Base, fonctionnant grâce à l’infrastructure de Flaunch. Elle expérimente un nouveau mécanisme : permettre aux créateurs de tokens de choisir quelles informations personnelles rendre publiques lors de l’émission de leur token.

De cette façon, les créateurs peuvent tirer parti de leur réputation ou de leurs qualifications sans avoir à révéler complètement leur identité réelle, ni à assumer les tracas habituels liés au rôle d’« ambassadeur de token ». De plus, les créateurs peuvent définir des critères d’accès, n’autorisant que les utilisateurs remplissant certaines conditions minimales à participer.

Objectif de cet article

Cet article vise à partager le cadre général qui m’a permis de passer de « l’idée » au « produit ».

Comme je le dis souvent, les 6 à 12 prochains mois constituent une « période dorée pour concrétiser les idées » : grâce aux outils d’IA, il est exceptionnellement facile de transformer une idée en réalité, mais peu de gens en sont conscients. Pour ceux prêts à investir du temps, c’est une opportunité d’arbitrage énorme.

J’espère que cet article inspirera davantage de personnes à essayer le vibecoding, à concrétiser leurs idées et à ramener le Web3 à cette époque dominée par les développeurs indépendants et les petites équipes, où l’innovation naissait chaque jour.

Cet article suppose que le lecteur possède déjà une base technique, connaît les outils de développement, la gestion des dépôts de code et les composants courants.

Étape 0 : Source d’inspiration

L’idée du « social capital gating » mûrit dans mon esprit depuis plusieurs mois. En utilisant fréquemment des outils comme Kaito, Ethos, fantasy.top, time.fun et en étudiant les indicateurs SocialFi, une question revenait sans cesse dans les discussions : pourquoi personne n’a-t-il créé un tableau de bord qui agrège les profils utilisateurs sur toutes ces plateformes, évaluant leurs qualifications à l’aide de scores et de données ?

Au cours des six derniers mois, le domaine des « indicateurs de créateurs » a connu une croissance rapide, permettant aujourd’hui d’évaluer la valeur d’une personne ou d’un compte selon divers axes de données.

Alors, pourquoi ne pas utiliser ces indicateurs pour définir des « critères de participation » (par exemple, des conditions d’accès à l’émission de tokens) ? Et pourquoi ne pas permettre aux créateurs de choisir eux-mêmes quels indicateurs rendre publics, tout en gardant leur identité réelle cachée ?

Ce qui m’a vraiment poussé à passer à l’action, c’est de voir que Pump.fun a levé 500 millions de dollars, et que heaven a récemment levé 20 millions de dollars. À mes yeux, la difficulté de développement de ces deux produits n’est pas si élevée, alors pourquoi une telle valorisation ? De plus, de nombreuses autres plateformes d’émission similaires ont également levé d’énormes fonds.

Pour être honnête, dans ce domaine, pour rester rationnel, nous ne nous attardons plus sur la « logique de valorisation des tokens » ; bien souvent, la valorisation n’a tout simplement aucun sens.

Mais quoi qu’il en soit, cela a déclenché un défi personnel : puis-je, en un week-end, avec un coût très faible et sans aide extérieure, créer un produit d’un niveau équivalent ?

Mon objectif n’est pas de créer un produit commercial, d’émettre un token, ni même de gagner de l’argent, mais de prouver que « c’est faisable » et d’espérer que plus de gens suivront cette voie.

Étape 1 : Décomposition du problème

Une fois l’idée trouvée, la première étape consiste à la décomposer en composants clés et à prendre des décisions pour chacun. Pour une « plateforme d’émission avec contrôle d’accès social », j’ai identifié les sous-problèmes suivants :

Choix du stack technique on-chain

La première décision est « sur quelle chaîne déployer », ce choix impactant toutes les étapes suivantes. Deux options claires s’offraient à moi : Solana et Base.

Solana

Avantages :

· La chaîne avec le plus grand volume de transactions de memecoins ;

· Effet projecteur : tout projet déployé ici attire facilement l’attention.

Inconvénients :

· Flexibilité de mise en œuvre faible, il faut suivre les standards existants de tokens ;

· Complexité de développement élevée, nécessitant de nombreux contournements ;

· Cycle de développement long ;

· Coût d’infrastructure élevé et instable.

Base

Avantages :

· Plus grand volume de transactions de memecoins parmi les chaînes EVM ;

· Excellent support pour les développeurs ;

· Expérience de développement EVM optimale ;

· Possibilité de réutiliser directement l’infrastructure existante.

Inconvénients :

· Le volume de transactions de memecoins est inférieur à celui de Solana.

Blind n’étant pas un projet commercial mais un exercice de week-end, nous n’avons pas à considérer le « retour financier potentiel », il suffit de choisir la solution la moins pénible à développer. Nous avons donc opté pour l’EVM. Pour le développement d’applications blockchain, l’EVM est l’infrastructure la plus mature et la plus agréable, permettant un développement rapide, efficace et intelligent.

Infrastructure existante réutilisable

Une fois la chaîne choisie, l’étape suivante consiste à chercher des SDK (kits de développement logiciel) ou des contrats existants à réutiliser, afin d’éviter de coder à partir de zéro. Surtout pour les smart contracts, il est préférable d’utiliser des contrats déjà audités pour réduire les risques de sécurité.

Heureusement, l’écosystème EVM regorge de ressources réutilisables, avec deux options principales :

·Développer sur des DEX comme Uniswap, en construisant soi-même toute la logique de contrôle d’accès sur Uniswap V4 ;

· Développer sur l’infrastructure d’une plateforme d’émission existante (comme le SDK de Flaunch), qui intègre déjà l’indexation, le téléchargement de métadonnées, la configuration des courbes d’émission, la gestion des étapes, etc.

Nous avons de nouveau choisi « la voie de la moindre résistance » : développer sur Flaunch. Ainsi, nous pouvons nous concentrer sur « l’aspect social de la plateforme d’émission + l’affichage front-end », sans perdre de temps ni d’argent sur la configuration du pool de liquidité, l’indexation, les contrats de partage de revenus, etc.

« Puisque des gens plus intelligents que vous ont déjà fait le travail, pourquoi réinventer la roue ? »

Méthode de déploiement des tokens

Après avoir choisi le SDK, il faut décider « qui exécute réellement le déploiement du token », avec deux options :

Option 1 : L’utilisateur initie la transaction pour déployer le token

· Développer un contrat proxy pour garantir que les paramètres d’émission choisis par l’utilisateur respectent les exigences de la plateforme ;

· Trouver un moyen de suivre tous les tokens déployés dans l’indexeur de sous-graphes existant de Flaunch.

Option 2 : L’utilisateur soumet une « demande de déploiement » au backend, le bot de la plateforme exécute le déploiement

· Tous les tokens sont déployés par l’EOA (compte externe) de la plateforme, ce qui facilite le suivi de tous les tokens émis par la plateforme dans l’indexeur ;

· Permet de garantir que toutes les émissions suivent des paramètres standardisés.

Nous avons choisi l’option « déploiement par le backend » : cela simplifie le suivi des tokens et permet un contrôle plus strict du contenu et de la méthode de déploiement, avec une possibilité d’évolution future.

Tous les tokens seront donc déployés par un wallet contrôlé par le backend.

En substance, nous avons « allégé le SDK Flaunch », supprimant toutes les fonctionnalités inutiles et ne conservant que la partie appelable par le backend.

Collecte des données sociales

Concentrons-nous maintenant sur la fonctionnalité sociale. Il faut déterminer quelles dimensions de données sont pertinentes pour la plateforme d’émission. L’ensemble de données idéal doit refléter à la fois « l’état du compte utilisateur » et « la réputation de l’utilisateur ».

J’ai finalement retenu les dimensions suivantes :

· Nombre d’abonnés (API X)

· Nombre de suivis (API X)

· Ancienneté du compte (API X)

· Nombre de likes (API X)

· Nombre d’abonnés de grande valeur (API Moni)

· Nombre d’utilisateurs à forte interaction (API Moni)

· Score de réputation (API Ethos)

· Score de propagation de contenu (API Kaito)

Cette combinaison permet aux créateurs de prouver leur qualification via des données multidimensionnelles, sans avoir à révéler complètement leur identité, et de se démarquer.

Traitement des données sociales et protection de la vie privée

Lors de l’inscription, nous collectons toutes les données ci-dessus, mais comment concevoir la couche de confidentialité ?

Notre principe est « privacy by default » : toutes les données sont privées par défaut, pour éviter toute fuite ; l’utilisateur peut choisir de rendre chaque dimension publique ou non. Il doit également pouvoir « flouter » l’affichage des données (par exemple, afficher « 40 000+ » au lieu de 43 000 abonnés), offrant ainsi une référence semi-anonyme.

Par ailleurs, faut-il traiter les données via un « backend centralisé + requêtes HTTPS », ou utiliser des techniques complexes de zero-knowledge proof ?

Notre solution combine les deux :

· Toutes les données sont stockées dans une base de données Postgres, le front-end récupère les informations via une API HTTPS. Le contrôle d’accès suit le processus suivant :

· L’utilisateur souhaite participer → il demande une « preuve d’accès » au backend ;

· Le backend vérifie si l’utilisateur remplit les critères définis par le créateur ;

· Le backend renvoie un message signé contenant « l’adresse du wallet utilisateur + un timestamp d’expiration » ;

· Le smart contract vérifie la validité de la signature.

Étape 2 : Développement et implémentation

Avant de commencer à développer, dressons la « liste des outils » nécessaires :

· Railway (hébergement backend) : 20 $ / mois

· Vercel (hébergement frontend) : 15 $ / mois

· Cursor (outil de développement, mode Claude 4 MAX inclus) : 200 $ / mois + 100 $ de crédits

· Nom de domaine du site : 30 $ / an

· X Premium+ (abonnement pour booster la visibilité + publier des longs posts) : 40 $ / mois

· ChatGPT : pour la conception du logo et de l’identité visuelle, ou tout autre outil similaire

· Coût total d’environ 405 $ (en supposant que Vercel ne dépasse pas la limite d’abonnement).

Note : pour accélérer le développement, j’ai utilisé plus de crédits Cursor que prévu (activation du modèle MAX). Si la vitesse n’est pas une priorité, on peut choisir un modèle moins cher.

Conception de l’architecture

La plupart des projets nécessitent 4 composants clés :

· Frontend : hébergé sur Vercel (dépôt GitHub séparé) ;

· Backend : hébergé sur Railway (dépôt GitHub séparé) ;

· Base de données de stockage : base Postgres sur Railway ;

· Base de données cache : Redis sur Railway.

En résumé, Vercel gère toutes les fonctions front-end ; Railway héberge en toute sécurité les services centraux « invisibles pour l’utilisateur », comme le traitement des données, le déploiement des tokens, les API, le cache, etc.

La plupart des architectures backend ressemblent à ceci (oui, les données sont dans la « boule »).

Ordre de développement

Je recommande toujours de développer d’abord les fonctionnalités principales, puis de s’occuper de l’affichage front-end à la fin.

Pour ce projet, la fonctionnalité la plus essentielle (et celle dont il faut tester la compatibilité en premier) est l’émission de tokens.

Puisque nous avons décidé que le déploiement des tokens serait effectué par l’EOA backend, nous pouvons créer un nouveau dépôt git pour le backend et commencer à étudier la documentation du SDK Flaunch.

La documentation présente toutes les fonctionnalités de configuration de lancement possibles, ainsi que des extraits de code pour faciliter l’intégration. Elle fournit aussi des endpoints API pour récupérer les données, ainsi qu’un sous-graphe qui indexe automatiquement tout ce qui se passe sur Flaunch (y compris les tokens lancés depuis le front-end de Blind).

1) Tester la fonctionnalité d’émission de tokens

Dans le nouveau dépôt backend, la première étape consiste à mettre en place un environnement local pour tester si l’on peut émettre un token via le SDK. On peut d’abord écrire un simple script Node, puis le transformer en une API Express qui déploie le token avec les paramètres spécifiés.

Cette étape est en réalité très simple, il suffit généralement d’un prompt et de quelques ajustements.

En plus, le gas fee pour le déploiement d’un token est inférieur à 0,01 $ ! Cela signifie que nous pouvons offrir un service de déploiement de tokens totalement gratuit aux utilisateurs.

2) Récupérer les données sociales

La deuxième étape consiste à développer une autre fonctionnalité clé : le scoring social. Pour chaque dimension de données sélectionnée précédemment, il faut consulter la documentation de chaque API, puis créer un endpoint dans le serveur Express qui retourne toutes les données en fonction du nom d’utilisateur. Ces données sont ensuite stockées dans la base Postgres sur Railway.

3) Processus d’inscription

À ce stade, le développement devient un peu plus complexe, car il faut avancer sur le dépôt frontend en parallèle. Nous avons choisi Next.js comme framework frontend, car il est le mieux supporté par Vercel et permet l’authentification via middleware.

Lors de l’inscription, nous voulons que l’utilisateur connecte d’abord son wallet, puis s’authentifie via X, puis s’enregistre via notre endpoint.

Nous consultons d’abord la documentation de l’API d’authentification X, puis implémentons une page d’inscription simple sur le frontend et créons un endpoint d’inscription sur le backend.

Lors de l’inscription, nous extrayons également toutes les données de l’étape 2) et les stockons dans la base de données, en ajoutant une entrée pour l’adresse du wallet. Toutes les requêtes envoyées au endpoint d’inscription doivent être authentifiées à la fois par la clé X et par la signature du wallet, pour éviter l’usurpation d’identité.

Une fois tout en place, il faut aussi ajouter une authentification au endpoint de déploiement de tokens, pour que seuls les utilisateurs inscrits puissent déployer des tokens. Pour les autres endpoints, nous avons choisi de n’utiliser que la signature du wallet pour l’authentification, afin d’éviter de devoir se connecter à X à chaque fois.

4) Paramètres de confidentialité

Après avoir terminé le processus d’inscription et la sauvegarde des données, l’étape suivante est de développer les paramètres de confidentialité :

· Créer une table de paramètres de visibilité des données dans la base de données (par défaut, toutes les données sont privées) ;

· Développer une interface de modification des paramètres de confidentialité accessible aux utilisateurs authentifiés ;

· Écrire des fonctions utilitaires pour permettre à l’utilisateur de choisir d’afficher les données de manière floue ;

· Développer un composant frontend pour l’édition des paramètres de confidentialité.

5) Vérification et optimisation des endpoints

Une fois les services principaux prêts, il faut les optimiser :

Toutes les fonctionnalités principales du serveur sont prêtes, il faut maintenant s’assurer que tous les endpoints utilisent l’authentification lorsque nécessaire et qu’aucune information personnelle n’est divulguée lors d’un accès public. On peut aussi utiliser le cache Redis pour optimiser certaines API et éviter de surcharger le serveur. Enfin, nous avons ajouté quelques API pour obtenir le profil public d’un utilisateur, les propriétaires de tokens et leurs données, les données des tokens, etc.

6) Développement frontend

Il est temps de créer un site web attrayant. Nous définissons d’abord le thème, les pages à afficher, puis supprimons les parties « privées ». Pour l’affichage de la liste des tokens avec tri personnalisé et autres données, nous pouvons nous appuyer sur le sous-graphe de Flaunch, en filtrant par adresse du déployeur (notre EOA). Pour la page de détails d’un token, la méthode rapide pour afficher un graphique est d’intégrer un simple iframe DexScreener.

7) Tests

Tout est enfin prêt. Testez le parcours utilisateur, déployez tout sur Vercel et Railway, et partagez l’accès avec des amis pour obtenir des retours. L’objectif est d’avoir un environnement identique à la production.

8) Optimisation selon les retours

C’est la dernière étape avant la mise en ligne.

Étape 3 : Lancement public

Le lancement public se fait en deux étapes : d’abord la construction de la marque, puis la promotion marketing.

Construction de la marque

Je n’ai pas parlé de la construction de la marque plus tôt, car elle peut se faire à tout moment, mais il vaut mieux la terminer avant le développement frontend. Les éléments clés de la marque (nom, logo, palette de couleurs, nom de domaine) doivent respecter le principe de « simplicité et reconnaissance ».

J’aime beaucoup le concept « nom d’un mot + jeu de mots avec le domaine » :

· Le nom du projet est « Blind » (sous-entendu « investissement à l’aveugle », suggérant que les utilisateurs achètent des tokens avec peu d’informations) ;

· La palette de couleurs est volontairement très claire et tape-à-l’œil, associée à un style « fauviste », évoquant un document en braille, en lien avec le thème « Blind » ;

· Conception du logo : généré par ChatGPT (avec le thème comme prompt) ;

Promotion marketing

Il est temps de faire connaître notre MVP (produit minimum viable) au monde ! En général, la meilleure façon de faire parler de soi n’est pas de tout révéler, mais de semer la confusion.

Marketing de la confusion

Avant la promotion officielle, il est conseillé de s’assurer que le MVP est complet. Il est préférable de lancer la campagne marketing une semaine avant la mise en ligne, afin de concentrer l’attention du public sur une courte période et de maximiser la visibilité sur les réseaux sociaux.

Les objectifs clés de cette semaine :

· Faire en sorte que plus de gens suivent le compte X du projet et activent les notifications ;

· Publier des teasers flous, des contenus humoristiques, sans jamais révéler clairement les fonctionnalités du projet ;

· Laisser des « indices » pour inciter les internautes à spéculer dans les commentaires, les laissant générer eux-mêmes du buzz.

Indicateurs de vanité : ne laissez pas vos utilisateurs seuls

Un moyen efficace d’accompagner le « marketing de la confusion » est le « classement » ! Les gens veulent « être les premiers », mais pas « arriver trop tôt ». Votre mission est de « faire vivre la plateforme avant même son lancement ».

L’activité « inscription + classement » présente les avantages suivants :

· Inciter les utilisateurs à s’inscrire à l’avance, répartir le trafic et tester la stabilité du système ;

· Garder les utilisateurs engagés : « Y a-t-il des avantages à s’inscrire tôt ? » et ainsi activer les notifications du compte ;

· Les gens aiment se sentir « meilleurs que les autres » : le classement est facile à partager et permet aux utilisateurs de découvrir des données intéressantes sur leur compte ;

· Facilite la communication de la « croissance » par l’équipe.

Avant le lancement de Blind, plus de 40 000 utilisateurs étaient déjà préinscrits !

Note : l’ajout d’un système de « liens d’invitation » accélérerait encore la croissance.

Annonce du compte à rebours de 24h

Il est temps de révéler la fonctionnalité principale de Blind ! Lors de la publication de l’article, informez-les de la date précise pour qu’ils puissent l’attendre. Les 24 dernières heures permettent à tous les fuseaux horaires de se préparer.

Publication de l’article de lancement

À ce moment-là, les utilisateurs rafraîchissent la page de votre compte X, il est temps de publier l’article ! L’article doit expliquer en détail :

· Les fonctionnalités principales de Blind ;

· La date et l’heure du lancement officiel ;

· Pas besoin d’être trop technique ni de lister toutes les fonctionnalités, l’essentiel est de transmettre la « motivation du développement », « l’idée centrale » et « l’attrait du projet » ;

Pour les détails techniques, fournissez une documentation séparée en dehors de l’article si nécessaire.

Étape 4 : Lancement officiel !

L’article doit préciser que « le lancement aura lieu 24 heures après la publication ». À ce stade, les utilisateurs préinscrits sont prêts, il ne reste plus qu’à déployer les tokens. Ensuite, il faut :

· Passer tous les environnements en mode production ;

· Changer le compte EOA du déployeur ;

· Être prêt à intervenir en cas de bug lors du lancement (il y en aura toujours).

Voilà, lancement officiel !

Conclusion

Lors du développement d’un MVP, choisissez toujours « la voie de la moindre résistance ». Il n’est pas nécessaire d’atteindre la perfection du premier coup, on peut itérer et optimiser en production. Saisir l’opportunité est souvent plus important que « tout attendre d’être prêt ».

Mais attention : la première impression est cruciale. L’expérience de l’utilisateur lors de sa première visite déterminera sa perception à long terme de la plateforme, ne comptez pas sur le fait que la plupart des utilisateurs suivront les « mises à jour de fonctionnalités ».

Le développement de ce projet annexe a été très amusant, j’ai beaucoup appris et j’ai créé un outil que « les gens pourraient utiliser pour émettre des tokens ».