J'ai construit une plateforme de lancement en 3 jours avec 400 dollars
TechFlow SélectionTechFlow Sélection
J'ai construit une plateforme de lancement en 3 jours avec 400 dollars
Partage de mon cadre général passant de « l'idée » au « produit ».
Dédié à des analyses Web3 approfondiesRédaction : ultra
Traduction : Luffy, Foresight News
Le week-end dernier, j'ai travaillé en heures supplémentaires pour créer le projet Blind, afin de prouver qu'il est possible de construire un produit significatif sans financement à plusieurs millions de dollars, sans mois de travail, ni même une équipe.
Blind est une plateforme de lancement de jetons (Launchpad) développée sur la chaîne Base, fonctionnant grâce aux infrastructures de Flaunch. Elle expérimente un nouveau mécanisme : permettre aux créateurs de jetons de choisir eux-mêmes quelles informations personnelles ils souhaitent rendre publiques lors de l'émission de leurs jetons.
Cela leur permet d'utiliser leur réputation ou leurs qualifications comme garantie tout en n'ayant pas besoin de révéler complètement leur identité, ni d'assumer les inconvénients habituels liés au rôle de « porte-parole du jeton ». En outre, les créateurs peuvent définir des seuils d'accès au prévente, autorisant uniquement les utilisateurs remplissant certaines conditions minimales à participer.
Objectif de cet article
Cet article vise à partager le cadre général que j'ai suivi pour passer de « l'idée » au « produit ».
Comme je le dis souvent, ces 6 à 12 prochains mois constituent une période dorée pour concrétiser des idées. Grâce aux outils d'intelligence artificielle, transformer une idée en réalité est plus facile que jamais, mais peu de gens en ont conscience. Pour ceux prêts à investir du temps, il s'agit d'une formidable opportunité d'arbitrage.
J'espère que cet article encouragera davantage de personnes à essayer le vibecoding, à transformer leurs idées en produits concrets et à ramener Web3 vers ce domaine où des développeurs indépendants et de petites équipes menaient l'innovation quotidienne.
Nous supposons ici que le lecteur possède déjà des bases techniques, maîtrise les outils de développement, la gestion des dépôts de code et connaît les composants courants.
Étape 0 : Origine de l'inspiration
L'idée de contrôle d'accès basé sur le capital social mûrit dans mon esprit depuis plusieurs mois. En utilisant fréquemment Kaito, Ethos, fantasy.top, time.fun et en étudiant les indicateurs SocialFi, une question revenait régulièrement : pourquoi personne ne crée-t-il un tableau de bord capable de regrouper le profil d'un utilisateur sur toutes ces plateformes, d'évaluer ses qualifications via des scores et des données ?
Au cours des six derniers mois environ, le domaine des « indicateurs de créateurs » a connu une croissance fulgurante. Il est désormais possible d'évaluer la valeur d'une personne ou d'un compte selon divers critères.
Pourrait-on utiliser ces indicateurs comme « seuil de participation » (par exemple, condition d'accès à un lancement de jeton) ? Et pourrait-on permettre aux créateurs de décider eux-mêmes quels indicateurs divulguer au public tout en masquant leur identité réelle ?
Ce qui m'a véritablement poussé à me lancer fut la levée de fonds de 500 millions de dollars par Pump.fun, puis celle de 20 millions de dollars par heaven. À mes yeux, la complexité technique de ces deux produits n'est pas très élevée. Alors pourquoi leurs valorisations sont-elles si extravagantes ? De nombreux autres plateformes similaires ont également levé d'énormes sommes.
Il faut être honnête : dans ce domaine, pour rester rationnel, nous avons cessé de nous interroger sur la logique derrière la valorisation des jetons ; souvent, cette valorisation n'a tout simplement aucun sens.
Mais cela a néanmoins lancé un défi personnel : pouvais-je, en un seul week-end, avec un coût minimal et sans aide externe, créer un produit de niveau comparable ?
Mon objectif n'était ni de créer un produit commercial, ni de lancer un jeton, ni même de gagner de l'argent, mais de prouver que « c'est faisable », dans l'espoir que davantage de personnes empruntent ce chemin.
Étape 1 : Décomposition du problème
Une fois l'idée formulée, la première étape consiste à la décomposer en composants clés et à prendre des décisions pour chacun d'eux. Concernant une « plateforme de lancement avec contrôle d'accès social », j'ai identifié les sous-problèmes suivants :
Choix de la pile technologique blockchain
La décision principale concerne « sur quelle chaîne déployer », choix qui influencera tous les aspects suivants. Deux options claires se présentaient alors : Solana et Base.
Solana
Avantages :
-
Chaîne avec le plus fort volume de transactions de « memecoins » ;
-
Effet de visibilité : tout projet déployé ici attire relativement vite l'attention.
Inconvénients :
-
Flexibilité limitée, obligation de suivre les standards existants de jetons ;
-
Développement complexe, nécessitant de nombreuses solutions détournées ;
-
Cycle de développement long ;
-
Coût élevé et instabilité des infrastructures.
Base
Avantages :
-
Plus fort volume de transactions de « memecoins » parmi les chaînes EVM ;
-
Bon support aux développeurs ;
-
Expérience de développement EVM excellente ;
-
Possibilité de réutiliser directement des infrastructures existantes.
Inconvénients :
-
Volume de transactions de « memecoins » inférieur à Solana.
Comme Blind n'est pas un projet commercial mais un exercice réalisé en un week-end, nous n'avons pas à considérer les décisions liées au « retour financier potentiel ». Nous devons simplement choisir l'option qui rendra le développement le moins pénible.
Nous avons donc opté pour EVM. Dans le développement d'applications blockchain, EVM offre l'infrastructure la plus mature et la meilleure expérience, permettant une avancée rapide, efficace et judicieuse.
Infrastructures existantes réutilisables
Après avoir choisi la chaîne, l'étape suivante consiste à rechercher des SDK (kits de développement logiciel) ou contrats prêts à l'emploi afin d'éviter de tout coder depuis zéro. En particulier pour les contrats intelligents, privilégier des contrats audités réduit fortement les risques de sécurité.
Heureusement, l'écosystème EVM regorge de ressources réutilisables. Nous avions deux principales options :
-
Développer sur DEX comme Uniswap, en construisant soi-même toute la logique de contrôle d'accès sur la base d'Uniswap V4 ;
-
Développer sur l'infrastructure existante d'une plateforme de lancement (comme le SDK de Flaunch), qui inclut déjà indexation, téléchargement des métadonnées, configuration des courbes d'émission, gestion des phases de prévente, etc.
Nous avons encore choisi le « chemin de moindre résistance » : développer sur Flaunch. Cela nous permet de nous concentrer sur « l'aspect social de la plateforme + l'affichage frontal », sans perdre de temps ni d'argent sur des fonctionnalités de base comme la configuration des pools, l'indexation ou les contrats de partage des revenus.
« Quand des personnes plus intelligentes que vous ont déjà fait le travail, pourquoi refaire la roue ? »
Méthode de déploiement des jetons
Une fois le SDK choisi, il fallait décider « qui exécutera réellement le déploiement du jeton ». Deux options étaient envisageables :
Option 1 : L'utilisateur lance une transaction pour déployer le jeton
-
Nécessite le développement d'un contrat proxy garantissant que les paramètres choisis par l'utilisateur respectent les exigences de la plateforme ;
-
Nécessite de trouver un moyen de suivre tous les jetons déployés dans l'indexeur actuel de Flaunch.
Option 2 : L'utilisateur soumet une « demande de déploiement » au backend, qui sera exécutée par un robot de la plateforme
-
Tous les jetons sont déployés par un compte EOA (compte externe) appartenant à la plateforme, facilitant le suivi de tous les jetons lancés via l'indexeur ;
-
Garantit que tous les lancements respectent des paramètres standardisés.
Nous avons choisi l'option « déploiement par service backend » : elle simplifie le suivi des jetons, renforce le contrôle sur « ce qui et comment est déployé », et laisse place à des améliorations futures.
Tous les jetons seront déployés par un portefeuille contrôlé par le backend.
En substance, nous avons « simplifié le SDK de Flaunch », en supprimant toutes les fonctionnalités inutiles, ne conservant que celles appelables par requête backend.
Collecte des données sociales
Passons maintenant à la fonction sociale. Nous devons déterminer quelles dimensions de données ont de la valeur pour la plateforme de lancement. La combinaison idéale doit refléter à la fois « l'état du compte utilisateur » et « sa réputation ».
Finalement, j'ai retenu les dimensions suivantes :
-
Nombre d'abonnés (API X)
-
Nombre d'abonnements (API X)
-
Âge du compte (API X)
-
Nombre de mentions « J'aime » (API X)
-
Nombre d'abonnés à fort potentiel (API Moni)
-
Nombre d'utilisateurs interagissant activement (API Moni)
-
Score de réputation (API Ethos)
-
Score de diffusion du contenu (API Kaito)
Cette combinaison permet aux créateurs de prouver leurs qualifications à travers plusieurs dimensions sans avoir à révéler entièrement leur identité, et ainsi se démarquer.
Traitement des données sociales et protection de la vie privée
Lors de l'inscription, nous collectons toutes ces données. Mais comment concevoir le volet confidentialité ?
Notre principe est « la confidentialité par défaut » : toutes les données sont privées par défaut pour éviter les fuites ; chaque utilisateur décide librement si chaque dimension de données est publique. En outre, les utilisateurs peuvent « flouter » leurs données (par exemple, afficher « 40k+ » au lieu de 43 000 abonnés), offrant une référence semi-anonyme.
Doit-on traiter les données via un « backend centralisé + requêtes HTTPS », ou recourir à des technologies complexes comme les preuves à divulgation nulle (zero-knowledge proofs) ?
Nous adoptons une approche hybride :
-
Toutes les données sont stockées dans une base Postgres ; le frontend récupère les informations directement via une API HTTPS. Le contrôle d'accès au prévente suit ce processus :
-
L'utilisateur souhaite participer au prévente → demande une « preuve d'éligibilité » au backend ;
-
Le backend vérifie si l'utilisateur remplit les critères fixés par le créateur ;
-
Le backend renvoie un message signé contenant « l'adresse du portefeuille + un horodatage d'expiration » ;
-
Le contrat intelligent valide la signature.
Étape 2 : Mise en œuvre du développement
Avant de commencer, dressons une « liste des outils » nécessaires :
-
Railway (hébergement backend) : 20 $/mois
-
Vercel (hébergement frontend) : 15 $/mois
-
Cursor (outil de développement, avec mode Claude 4 MAX) : 200 $/mois + 100 $ de crédits
-
Nom de domaine : 30 $/an
-
X Premium+ (abonnement compte, pour augmenter la visibilité + publier des articles longs) : 40 $/mois
-
ChatGPT : pour concevoir le logo et l'identité visuelle, ou tout autre outil similaire
Coût total environ 405 $ (en supposant que Vercel reste dans les limites de son abonnement).
Note : pour accélérer le développement, j'ai utilisé plus de crédits Cursor que prévu (avec le modèle MAX). Si la rapidité n'est pas cruciale, des modèles moins coûteux peuvent être utilisés.
Conception de l'architecture
La plupart des projets nécessitent quatre 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 : base Postgres sur Railway ;
-
Base de données cache : base Redis sur Railway.
En résumé, Vercel gère toutes les fonctions frontales ; Railway héberge de façon sécurisée les services centraux invisibles aux utilisateurs, tels que le traitement des données, le déploiement des jetons, les interfaces API, la mise en cache, etc.
L'architecture backend de la majorité des projets ressemble à ceci (oui, les données sont stockées dans une « sphère »).
Ordre de développement
Je recommande toujours de développer d'abord les fonctionnalités principales, puis de finaliser l'interface.
Dans ce projet, la fonctionnalité centrale (et celle dont la compatibilité doit être testée en premier) est le lancement de jetons.
Étant donné que nous avons décidé que le déploiement serait effectué par un EOA backend, nous pouvons créer un nouveau dépôt git pour le backend et commencer à étudier la documentation du SDK Flaunch.
Cette documentation présente toutes les fonctionnalités disponibles concernant la configuration du lancement, fournit même des extraits de code utiles pour l'intégration. Ils proposent également des points d'accès API pour récupérer les données, ainsi qu'un sous-graphe capable d'indexer automatiquement tout ce qui se passe sur Flaunch (y compris les jetons lancés depuis l'interface Blind).
1) Tester la fonction de lancement de jetons
Dans le nouveau dépôt backend, la première étape consiste à configurer l'environnement local et tester si un jeton peut être lancé via le SDK. Nous pouvons écrire un simple script Node, puis le transformer en une interface Express. Appeler cette interface avec des paramètres spécifiés lancera le déploiement du jeton.
Cette étape est en réalité très simple, probablement réalisable en une seule instruction + quelques ajustements mineurs.
Et les frais de gaz pour le déploiement d'un jeton coûtent moins de 0,01 $ ! Cela signifie que nous pouvons offrir un service de déploiement gratuit aux utilisateurs.
2) Récupérer les données sociales
La deuxième étape consiste à développer une autre fonction clé : l'évaluation sociale. Pour chaque dimension de données sélectionnée précédemment, nous devons consulter la documentation de chaque API, puis créer un point d'accès dans le serveur Express qui renvoie toutes les données en fonction du nom d'utilisateur. Ces données seront ensuite stockées dans notre base Postgres sur Railway.
3) Processus d'inscription
À ce stade, le développement devient un peu plus complexe, car il faut aussi avancer sur le dépôt frontend. Nous choisissons Next.js comme framework frontend car il est optimisé pour Vercel et prend en charge les middlewares d'authentification.
Dans le processus d'inscription, nous voulons que l'utilisateur lie d'abord son portefeuille, s'authentifie via X, puis s'inscrive en appelant notre point d'accès.
Nous consultons d'abord la documentation de l'API d'authentification X, implémentons une page d'inscription simple côté frontend, et créons un point d'inscription dans le dépôt backend.
Pendant l'inscription, nous extrayons toutes les données de l'étape 2), les stockons dans la base, et ajoutons une entrée pour l'adresse du portefeuille. Toutes les requêtes envoyées au point d'inscription doivent être authentifiées via une clé X et une signature de portefeuille pour éviter les usurpations d'identité.
Une fois tout fonctionnel, nous ajoutons une authentification au point de déploiement des jetons, afin que seuls les utilisateurs inscrits puissent lancer un jeton. Pour tout autre point d'accès, nous décidons d'utiliser uniquement l'authentification par message signé du portefeuille, évitant ainsi de devoir se connecter à X à chaque fois.
4) Paramètres de confidentialité
Une fois le processus d'inscription et le stockage des données mis en place, l'étape suivante est de développer les paramètres de confidentialité :
-
Créer dans la base de données une table de visibilité des données (toutes les données sont privées par défaut) ;
-
Développer une interface modifiable par les utilisateurs authentifiés ;
-
Écrire des fonctions utilitaires permettant de masquer les données (floutage) ;
-
Développer un composant frontend pour modifier les paramètres de confidentialité.
5) Vérification et optimisation des interfaces
Une fois les services principaux opérationnels, voici les optimisations à réaliser :
Toutes les fonctionnalités principales du serveur sont prêtes. Nous devons maintenant nous assurer que tous les points d'accès utilisent l'authentification quand nécessaire, et qu'aucune information personnelle n'est exposée lors d'un accès public. Nous pouvons aussi utiliser Redis pour mettre en cache certaines API, évitant ainsi une surcharge inutile du serveur. Enfin, nous ajoutons plusieurs API pour récupérer le profil public d'un utilisateur, les propriétaires de jetons et leurs données, les données des cryptomonnaies, etc.
6) Développement frontend
Il est temps de créer un site attrayant. Nous définissons d'abord le thème, les pages à afficher, et commençons à retirer les parties « privées ». Pour afficher la liste des jetons triés personnalisés et d'autres données, nous pouvons nous appuyer sur le sous-graphe de Flaunch, filtré par l'adresse du déployeur (notre EOA). Pour la page de détail du jeton, la méthode rapide pour afficher un graphique est d'intégrer un iframe simple de 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 recueillir des retours. L'objectif est de créer un environnement identique à la production.
8) Optimisation selon les retours
C'est la dernière étape avant le lancement.
Étape 3 : Lancement public
Le lancement public comporte deux étapes : construction de la marque, puis promotion.
Construction de la marque
Je n'ai pas mentionné plus tôt la création de la marque car elle peut être faite à tout moment, bien qu'il soit préférable de la terminer avant le développement frontend. Les éléments clés de la marque (nom, logo, palette de couleurs, nom de domaine) doivent être « simples et facilement reconnaissables ».
J'aime particulièrement l'approche « nom à un mot + jeu de mots sur le domaine » :
-
Nom du projet : « Blind » (signifiant « investissement aveugle », faisant référence à l'achat de jetons avec peu d'informations) ;
-
Nom de domaine : goblind.xyz, fusion astucieuse de « go blind » (investissement aveugle), « goblin » (gobelin, avec une touche ludique) et « goblin'd » (devenir gobelin) ;
-
Palette de couleurs volontairement claire et éblouissante, associée à un style de design « brut », rappelant les documents en braille, en lien avec le thème « Blind » ;
-
Logo : généré via ChatGPT (en utilisant le thème existant comme contexte).
Promotion
Il est temps que le monde découvre notre MVP (produit minimum viable) ! Généralement, la meilleure façon de faire connaître quelque chose n'est pas de l'annoncer directement, mais de susciter la confusion.
Marketing par la confusion
Avant la promotion officielle, assurez-vous que le MVP est pleinement fonctionnel. Idéalement, commencez la campagne une semaine avant le lancement, afin de concentrer l'attention du public sur une période courte, facilitant l'accès aux classements sociaux.
Les objectifs clés de cette semaine sont :
-
Inciter davantage de personnes à suivre le compte X du projet et activer les notifications ;
-
Publier des annonces floues, des jeux de mots, sans jamais révéler clairement les fonctionnalités ;
-
Laisser des « indices » pour que les internautes spéculent spontanément dans les commentaires, générant ainsi du buzz pour vous.
Indicateurs de vanité : éviter que les utilisateurs ne se sentent seuls
Un bon complément au « marketing par la confusion » est le « classement » ! Les gens veulent « prendre de l'avance », mais redoutent aussi d'être « trop précoces ». Votre mission : « faire vivre la plateforme avant même son lancement ».
L'activité « inscription + classement » offre plusieurs avantages :
-
Encourage les inscriptions anticipées, répartit le trafic du site et teste la stabilité du système ;
-
Garde les utilisateurs engagés : « y a-t-il un avantage à s'inscrire tôt ? », les incitant à activer les notifications ;
-
Les gens aiment se sentir supérieurs : un classement est facilement partageable et permet aux utilisateurs de découvrir des données intéressantes sur leur propre compte ;
-
Facilite la communication externe sur les « données de croissance ».
Avant son lancement, Blind comptait déjà plus de 40 000 utilisateurs pré-inscrits !
Note : ajouter un mécanisme de « lien d'invitation » accélérerait encore la croissance.
Compte à rebours de 24 heures
Il est temps de révéler les fonctionnalités clés de Blind ! Publiez un article pour leur indiquer précisément quand attendre. Dernières 24 heures pour verrouiller vos hypothèses sur Blind. Ce délai permet à toutes les zones horaires de se préparer.
Publication de l'article de lancement
À ce moment-là, les utilisateurs rafraîchissent votre page X. C'est le moment de publier ! L'article doit expliquer en détail :
-
Les fonctionnalités principales de Blind ;
-
La date de lancement officiel ;
-
Ne pas être trop technique, ni lister toutes les fonctionnalités ; mettez l'accent sur « la motivation du développement », « l'idée centrale » et « l'attrait du projet » ;
-
Si des détails techniques sont nécessaires, fournissez-les dans un document séparé.
Étape 4 : Lancement officiel !
L'article doit préciser que le « lancement aura lieu 24 heures après la publication ». À ce moment, les utilisateurs pré-inscrits sont prêts et attendent de pouvoir déployer leurs jetons. Ensuite, nous devons :
-
Basculer tous les environnements en mode production ;
-
Changer le compte EOA déployeur ;
-
Être prêts à intervenir en cas d'erreur (car elles arrivent toujours).
Voilà, c'est parti !
Conclusion
Lors du développement d'un MVP, choisissez toujours le « chemin de moindre résistance ». Inutile de chercher la perfection dès le départ ; vous pouvez itérer progressivement en production. Saisir l'opportunité est souvent plus important que d'attendre que tout soit parfait.
Mais attention : la première impression est cruciale. L'expérience initiale d'un utilisateur détermine directement sa perception à long terme de la plateforme. Ne comptez pas sur la majorité des utilisateurs pour suivre attentivement les « mises à jour ».
Ce projet secondaire a été très intéressant à développer. J'ai beaucoup appris et créé un outil que des gens pourraient vraiment utiliser pour lancer des jetons.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@0x_ultra
