In nur 3 Tagen und mit 400 US-Dollar: Schritt-für-Schritt-Anleitung zum Aufbau einer Launchpad-Plattform

Originaltitel: I Built a Launchpad in 3 Days for $400 (and so can you)
Originalautor: ultra

Übersetzung: Luffy, Foresight News

Letztes Wochenende habe ich Überstunden gemacht, um das Projekt Blind zu entwickeln – einfach um zu beweisen: Um ein sinnvolles Produkt zu bauen, braucht es weder Millionen an Finanzierung, noch monatelange Arbeit, noch ein Team.

Blind ist eine Token-Launch-Plattform, die auf der Base-Chain entwickelt wurde und auf der Infrastruktur von Flaunch läuft. Sie probiert einen ganz neuen Mechanismus aus: Token-Ersteller können beim Launch selbst entscheiden, welche persönlichen Informationen sie öffentlich machen.

So können Creator ihre Reputation oder Qualifikationen als Referenz nutzen, ohne ihre echte Identität komplett offenzulegen oder die typischen Probleme eines „Token-Botschafters“ auf sich zu nehmen. Außerdem können sie Zugangsbeschränkungen festlegen, sodass nur Nutzer mit Mindestvoraussetzungen teilnehmen dürfen.

Ziel dieses Artikels

Dieser Artikel soll meinen allgemeinen Rahmen vom „Gedanken“ zum „Produkt“ teilen.

Wie ich oft sage: Die nächsten 6–12 Monate sind die „goldene Zeit für die Umsetzung von Ideen“. Mit Hilfe von KI-Tools ist es extrem einfach, Ideen in die Realität umzusetzen – aber nur wenige erkennen das. Für alle, die bereit sind, Zeit zu investieren, ist das eine riesige Arbitrage-Chance.

Ich hoffe, dieser Artikel inspiriert mehr Menschen, sich am vibecoding zu versuchen, ihre Ideen umzusetzen und Web3 wieder zu einem Bereich zu machen, der von unabhängigen Entwicklern und kleinen Teams dominiert wird, in dem täglich Innovationen entstehen.

Der Artikel setzt voraus, dass die Leser über gewisse technische Grundlagen verfügen und mit Entwicklungstools, Code-Repository-Management und gängigen Komponenten vertraut sind.

Phase 0: Inspirationsquelle

Die Idee des Social-Capital-Gatekeepings schwirrte schon seit Monaten in meinem Kopf herum. Beim häufigen Einsatz von Tools wie Kaito, Ethos, fantasy.top, time.fun und der Analyse von SocialFi-Kennzahlen tauchte immer wieder eine Frage auf: Warum gibt es kein Dashboard, das die Profile der Nutzer auf all diesen Plattformen zusammenführt und mit Scores und Daten die Qualifikation bewertet?

In den letzten sechs Monaten ist das Feld der „Creator Metrics“ rasant gewachsen. Heute kann man anhand verschiedenster Datenpunkte den Wert einer Person oder eines Accounts einschätzen.

Könnte man diese Kennzahlen nicht als „Teilnahmeschwellen“ (z.B. für Token-Launches) nutzen? Und könnten Creator selbst entscheiden, welche Kennzahlen sie öffentlich machen und dabei ihre echte Identität verbergen?

Was mich letztlich zum Handeln brachte, war die Nachricht, dass Pump.fun 500 Millionen Dollar eingesammelt hat und heaven kürzlich 20 Millionen Dollar. Meiner Meinung nach ist die Entwicklung dieser beiden Produkte nicht besonders schwierig – warum also diese extremen Bewertungen? Und es gibt viele weitere erfolgreiche Launch-Plattformen, die riesige Summen eingesammelt haben.

Um fair zu sein: In diesem Bereich diskutieren wir eigentlich nicht mehr rational über „Token-Bewertungslogik“; oft ist die Bewertung einfach völlig irrational.

Wie auch immer, das hat meinen persönlichen Ehrgeiz geweckt: Kann ich an einem Wochenende, mit minimalen Kosten und ohne externe Hilfe, ein vergleichbares Produkt bauen?

Mein Ziel war nicht, ein kommerzielles Produkt zu bauen, einen Token zu launchen oder Geld zu verdienen, sondern zu beweisen, dass es möglich ist – und andere zu ermutigen, diesen Weg zu gehen.

Phase 1: Problemanalyse

Mit der Idee im Kopf ist der erste Schritt, sie in Kernkomponenten zu zerlegen und für jede Komponente Entscheidungen zu treffen. Für eine „Launch-Plattform mit Social-Gating“ habe ich folgende Teilfragen herausgearbeitet:

Wahl des On-Chain-Tech-Stacks

Die wichtigste Entscheidung ist: „Auf welcher Chain deployen?“ Diese Wahl beeinflusst alle weiteren Implementierungsschritte. Es gab zwei klare Optionen: Solana und Base.

Solana

Vorteile:

· Die Chain mit dem höchsten Memecoin-Volumen;

· Scheinwerfer-Effekt: Jedes Projekt, das hier gelauncht wird, bekommt leicht Aufmerksamkeit.

Nachteile:

· Geringe Flexibilität, man muss sich an bestehende Token-Standards halten;

· Hohe Entwicklungskomplexität, viele Workarounds nötig;

· Längere Entwicklungszyklen;

· Hohe und instabile Infrastrukturkosten.

Base

Vorteile:

· Höchstes Memecoin-Volumen unter den EVM-Chains;

· Gute Unterstützung für Entwickler;

· Hervorragende EVM-Entwicklungserfahrung;

· Bestehende Infrastruktur kann direkt genutzt werden.

Nachteile:

· Memecoin-Volumen nicht so hoch wie bei Solana.

Da Blind kein kommerzielles Projekt ist, sondern ein Wochenend-Experiment, mussten wir keine „potenziellen finanziellen Erträge“ berücksichtigen, sondern nur, dass die Entwicklung nicht zu schmerzhaft wird. Am Ende haben wir uns für EVM entschieden. Für Blockchain-Anwendungen ist EVM die ausgereifteste und angenehmste Infrastruktur, mit der wir schnell, effizient und klug entwickeln können.

Wiederverwendbare bestehende Infrastruktur

Nach der Chain-Wahl folgt die Suche nach wiederverwendbaren SDKs oder fertigen Smart Contracts, um nicht bei Null anfangen zu müssen. Besonders bei Smart Contracts sollte man bevorzugt geprüfte Verträge nutzen, um Sicherheitsrisiken zu minimieren.

Glücklicherweise gibt es im EVM-Ökosystem viele Ressourcen. Wir hatten zwei Hauptoptionen:

· Entwicklung auf Basis von Uniswap oder anderen DEXen, mit eigener Zugangskontroll-Logik auf Uniswap V4;

· Entwicklung auf Basis der Infrastruktur bestehender Launch-Plattformen (wie das Flaunch SDK), das bereits Indexing, Metadaten-Upload, Launch-Kurven-Konfiguration, Phasenmanagement usw. integriert hat.

Wir haben uns erneut für den „Weg des geringsten Widerstands“ entschieden: Entwicklung auf Basis von Flaunch. So konnten wir uns auf die sozialen Features und das Frontend konzentrieren, ohne Zeit und Geld für grundlegende Funktionen wie Pool-Konfiguration, Indexing oder Revenue-Sharing-Contracts zu verschwenden.

„Wenn klügere Leute die Arbeit schon erledigt haben, warum das Rad neu erfinden?“

Token-Deployment-Modell

Nach der SDK-Wahl musste entschieden werden, „wer das Token-Deployment tatsächlich ausführt“. Es gab zwei Ansätze:

Variante 1: Nutzer starten die Transaktion und deployen den Token selbst

· Entwicklung eines Proxy-Contracts nötig, um sicherzustellen, dass die gewählten Launch-Parameter den Plattformanforderungen entsprechen;

· Es muss eine Möglichkeit gefunden werden, alle deployten Tokens im bestehenden Flaunch-Subgraph zu tracken.

Variante 2: Nutzer reichen einen „Deployment-Request“ beim Backend ein, das Deployment erfolgt durch einen Plattform-Bot

· Alle Tokens werden vom Plattform-eigenen EOA (Externally Owned Account) deployed, was das Tracking im Indexer erleichtert;

· Einheitliche Standard-Parameter für alle Launches gewährleistet.

Wir haben uns für das „Backend-Service-Deployment“ entschieden: Das macht das Token-Tracking einfacher und ermöglicht eine strengere Kontrolle über Inhalt und Art des Deployments – mit Upgrade-Potenzial für die Zukunft.

Alle Tokens werden von einer Wallet deployed, die vom Backend kontrolliert wird.

Im Wesentlichen haben wir das Flaunch SDK „abgespeckt“ und alle unnötigen Funktionen entfernt, sodass nur noch die vom Backend aufrufbaren Teile übrig bleiben.

Soziale Datenerhebung

Jetzt zum Social Feature. Wir mussten bestimmen, welche Daten für eine Launch-Plattform wertvoll sind. Die ideale Kombination sollte sowohl den „Account-Status“ als auch die „Reputation“ des Nutzers widerspiegeln.

Am Ende habe ich folgende Datenpunkte ausgewählt:

· Followerzahl (X Platform API)

· Anzahl der Gefolgten (X Platform API)

· Account-Alter (X Platform API)

· Anzahl der Likes (X Platform API)

· Anzahl wertvoller Follower (Moni API)

· Anzahl der Kern-Interaktionsnutzer (Moni API)

· Reputation Score (Ethos API)

· Content-Spread-Score (Kaito API)

Mit dieser Kombination können Creator ihre Qualifikation über verschiedene Datenpunkte beweisen, ohne ihre Identität komplett offenzulegen.

Soziale Datenverarbeitung und Datenschutz

Bei der Registrierung sammeln wir alle oben genannten Daten – aber wie gestalten wir den Datenschutz?

Unser Prinzip ist „Privacy by Default“: Alle Daten sind standardmäßig privat, um Leaks zu vermeiden; Nutzer können für jeden Datenpunkt selbst entscheiden, ob sie ihn öffentlich machen. Außerdem sollte es möglich sein, Daten „unscharf“ anzuzeigen (z.B. bei 43.000 Followern nur „40k+“ anzeigen), um halb-anonyme Referenzen zu bieten.

Außerdem stellt sich die Frage: Sollen wir die Datenverarbeitung auf ein „zentralisiertes Backend + HTTPS Requests“ stützen oder komplexe Zero-Knowledge-Proofs einsetzen?

Unsere Lösung kombiniert beides:

· Alle Daten werden in einer Postgres-Datenbank gespeichert, das Frontend holt sie per HTTPS-API direkt ab. Das Gatekeeping läuft so ab:

· Nutzer will teilnehmen → fordert beim Backend ein „Zugangszertifikat“ an;

· Backend prüft, ob der Nutzer die vom Creator gesetzten Schwellen erfüllt;

· Backend gibt eine signierte Nachricht mit „Wallet-Adresse + Ablaufzeitpunkt“ zurück;

· Der Smart Contract prüft die Gültigkeit der Signatur.

Phase 2: Entwicklung und Umsetzung

Vor dem Start der Entwicklung habe ich eine „Tool-Liste“ erstellt:

· Railway (Backend-Hosting): 20 USD/Monat

· Vercel (Frontend-Hosting): 15 USD/Monat

· Cursor (Dev-Tool, inkl. Claude 4 MAX): 200 USD/Monat + 100 USD Credits

· Domain: 30 USD/Jahr

· X Premium+ (Account-Mitgliedschaft, für Reichweite + Longposts): 40 USD/Monat

· ChatGPT: Für Logo- und Branddesign, kann durch andere Tools ersetzt werden

· Gesamtkosten ca. 405 USD (sofern Vercel nicht über das Limit geht).

Hinweis: Um die Entwicklung zu beschleunigen, habe ich tatsächlich mehr Cursor-Credits (MAX-Modell) genutzt als geplant. Wer es nicht eilig hat, kann günstigere Modelle wählen.

Architekturdesign

Die meisten Projekte benötigen vier Kernkomponenten:

· Frontend: Gehostet auf Vercel (eigenes GitHub-Repo);

· Backend: Gehostet auf Railway (eigenes GitHub-Repo);

· Datenbank: Postgres auf Railway;

· Cache: Redis auf Railway.

Vercel übernimmt alle Frontend-Funktionen; Railway hostet die „unsichtbaren“ Kernservices wie Datenverarbeitung, Token-Deployment, API, Caching usw. sicher.

Die Backend-Architektur sieht meist so aus (ja, die Daten liegen in der „Kugel“):

Entwicklungsreihenfolge

Ich empfehle immer, mit den Kernfunktionen zu beginnen und das Frontend zuletzt zu machen.

Für dieses Projekt ist das wichtigste Feature (und das, was zuerst auf Kompatibilität getestet werden muss) der Token-Launch.

Da wir festgelegt haben, dass das Backend-EOA das Token-Deployment übernimmt, können wir ein neues Git-Repo fürs Backend anlegen und uns in die Flaunch-SDK-Dokumentation vertiefen.

Die Doku listet alle aktuellen Launch-Features auf und bietet sogar Code-Snippets für die Integration. Es gibt auch API-Endpunkte zum Datenabruf und einen Subgraph, der alles auf Flaunch automatisch indexiert (inklusive Tokens, die vom Blind-Frontend gestartet werden).

1) Test des Token-Launch-Features

Im neuen Backend-Repo ist der erste Schritt, eine lokale Umgebung aufzusetzen und zu testen, ob man per SDK erfolgreich einen Token launchen kann. Wir können ein einfaches Node-Skript schreiben, das später zu einem Express-Server-Endpoint wird. Mit den richtigen Parametern kann der Token dann deployed werden.

Dieser Schritt ist recht simpel, meist reicht ein Prompt und etwas Debugging.

Und das Gas für den Token-Launch kostet weniger als 0,01 USD! Das heißt, wir können den Nutzern einen komplett kostenlosen Token-Launch-Service bieten.

2) Abruf der Social Data

Als nächstes folgt das zweite Kernfeature: Social Scoring. Für alle gewählten Datenpunkte schauen wir uns die API-Dokumentation an, bauen einen Endpoint im Express-Server, der alle Daten zum Usernamen zurückliefert, und speichern diese in unserer Postgres-Datenbank auf Railway.

3) Registrierungsprozess

Ab hier wird es etwas komplexer, da Frontend- und Backend-Repo parallel entwickelt werden müssen. Wir haben uns für Next.js als Frontend-Framework entschieden, weil es am besten von Vercel unterstützt wird und Middleware für Authentifizierung bietet.

Im Registrierungsprozess sollen Nutzer zuerst ihre Wallet verbinden, sich dann über X authentifizieren und schließlich unseren Endpoint für die Registrierung aufrufen.

Wir schauen uns die X-Auth-API an, bauen ein einfaches Registrierungs-Frontend und einen Backend-Endpoint.

Im Registrierungsprozess extrahieren wir alle Daten aus Schritt 2) und speichern sie in der Datenbank, plus Wallet-Adresse. Alle Requests an den Registrierungs-Endpoint müssen sowohl X-Key- als auch Wallet-Signatur-Authentifizierung durchlaufen, um Identitätsdiebstahl zu verhindern.

Wenn alles läuft, fügen wir dem Token-Deployment-Endpoint Authentifizierung hinzu, sodass nur registrierte Nutzer Tokens launchen können. Für alle anderen Endpoints reicht die Wallet-Signatur, um X-Logins zu vermeiden.

4) Privatsphäre-Einstellungen

Nach Abschluss des Registrierungsprozesses und der Datenspeicherung folgt die Entwicklung der Privatsphäre-Einstellungen:

· Anlegen einer Tabelle für Sichtbarkeitseinstellungen in der Datenbank (standardmäßig alles privat);

· Entwicklung eines Endpoints zur Änderung der Privatsphäre-Einstellungen für authentifizierte Nutzer;

· Hilfsfunktionen, um unscharfe Datenanzeige zu ermöglichen;

· Entwicklung einer Frontend-Komponente zur Bearbeitung der Privatsphäre-Einstellungen.

5) Endpoint-Check und Optimierung

Wenn die Kernservices stehen, folgt die Optimierung:

Alle Server-Kernfunktionen sind bereit, jetzt müssen wir sicherstellen, dass alle Endpoints bei Bedarf Authentifizierung nutzen und keine persönlichen Daten öffentlich werden. Mit Redis-Caching können wir einige APIs optimieren, um die Serverlast zu reduzieren. Schließlich fügen wir noch APIs hinzu, um öffentliche Profile, Token-Owner und deren Daten, Token-Daten usw. abzurufen.

6) Frontend-Entwicklung

Jetzt ist es Zeit für eine schöne Website. Wir legen das Theme und die Seiten fest und entfernen die „privaten“ Bereiche. Für die Anzeige einer sortierten Token-Liste und anderer Daten nutzen wir den Flaunch-Subgraph und filtern nach dem Deployer-Account (unser EOA). Für die Token-Detailseite betten wir ein einfaches DexScreener-iframe ein, um Charts schnell anzuzeigen.

7) Testing

Alles ist endlich bereit. Wir testen den User-Flow, deployen alles auf Vercel und Railway und teilen Freunden den Zugang, um Feedback zu bekommen. Ziel ist eine 1:1 Produktionsumgebung.

8) Optimierung nach Feedback

Das ist der letzte Schritt vor dem Launch.

Phase 3: Öffentlicher Launch

Der öffentliche Launch läuft in zwei Schritten: Zuerst Brand-Building, dann Marketing.

Brand-Building

Bisher habe ich Brand-Building nicht erwähnt, weil es jederzeit gemacht werden kann – am besten aber vor dem Frontend-Dev. Die Kernelemente (Name, Logo, Farben, Domain) sollten „einfach und einprägsam“ sein.

Ich mag besonders das „Einwort-Name + Domain-Wordplay“-Prinzip:

· Projektname: „Blind“ (Anspielung auf „Blind Investment“, also Token-Kauf mit wenig Infos);

· Farbpalette: Extra grelles Light-Theme im „Beast-Style“, erinnert an Braille-Dokumente und passt zum „Blind“-Thema;

· Logo: Mit ChatGPT generiert (Prompt mit dem aktuellen Theme);

Marketing

Jetzt ist es Zeit, der Welt unser MVP (Minimum Viable Product) zu zeigen! Die beste Methode ist meist nicht, es direkt zu sagen, sondern Verwirrung zu stiften.

Confusion Marketing

Vor dem offiziellen Marketing sollte das MVP komplett sein. Am besten startet man eine Woche vor Launch, um die Aufmerksamkeit auf einen Zeitraum zu bündeln und die Social-Media-Trends zu dominieren.

Das Hauptziel dieser Woche:

· Mehr Leute sollen dem X-Account folgen und Benachrichtigungen aktivieren;

· Vage Teaser und Memes posten, aber nie die Funktion direkt verraten;

· „Hinweise“ streuen, damit die Community in den Kommentaren spekuliert und so Hype erzeugt.

Vanity Metrics: Nutzer nicht allein lassen

Ein effektives Mittel beim „Confusion Marketing“ ist das „Leaderboard“! Menschen wollen „früh dabei sein“, aber nicht „zu früh“. Deine Aufgabe: Die Plattform soll schon vor dem Launch „leben“.

„Registrierung + Leaderboard“-Aktionen bieten folgende Vorteile:

· Nutzer werden früh zur Registrierung animiert, Traffic verteilt sich, Systemstabilität wird getestet;

· Nutzer bleiben am Ball: „Gibt es Vorteile für frühe Registrierung?“ → Benachrichtigungen werden aktiviert;

· Menschen lieben es, „besser als andere“ zu sein: Leaderboard-Rankings werden gern geteilt, Nutzer entdecken interessante Daten zu ihren Accounts;

· Das Team kann mit „Growth Metrics“ nach außen werben.

Vor dem Blind-Launch gab es schon über 40.000 Pre-Registrierungen!

Hinweis: Mit einem „Invite-Link“-Feature wäre das Wachstum noch schneller.

24h-Countdown-Teaser

Jetzt ist es Zeit, die Kernfunktion von Blind zu enthüllen! Beim Artikel-Release sollte man das ankündigen, damit die Leute einen festen Zeitpunkt haben, auf den sie sich freuen können. Die letzten 24 Stunden sind für alle Zeitzonen genug Vorbereitung.

Launch-Artikel veröffentlichen

Jetzt aktualisieren alle Nutzer ständig dein X-Profil – Zeit für den Launch-Artikel! Darin sollten folgende Punkte klar werden:

· Die Kernfunktionen von Blind;

· Das offizielle Launch-Datum;

· Kein übertrieben technischer Fokus, keine Feature-Liste – wichtig sind „Motivation“, „Kernidee“ und „Projekt-Attraktivität“;

Technische Details können in separaten Dokumenten bereitgestellt werden.

Phase 4: Offizieller Launch!

Im Artikel sollte stehen: „Launch ist 24 Stunden nach Veröffentlichung“. Die Pre-Registrierten sind bereit, jetzt werden Tokens deployed. Jetzt müssen wir:

· Alle Umgebungen auf Produktion umstellen;

· Den Deployer-EOA wechseln;

· Bereit sein, Fehler beim Launch zu beheben (Fehler passieren immer).

Fertig, offizieller Launch!

Fazit

Beim MVP-Development immer den „Weg des geringsten Widerstands“ wählen. Perfektion ist nicht nötig, man kann im Live-Betrieb iterativ verbessern. Timing ist oft wichtiger als „alles fertig haben“.

Aber: Der erste Eindruck zählt. Die erste Nutzererfahrung entscheidet über die langfristige Wahrnehmung – die meisten Nutzer verfolgen keine „Feature Updates“.

Dieses Side-Project war sehr spannend, ich habe viel gelernt und ein Tool gebaut, das Leute vielleicht für Token-Launches nutzen werden.