Tylko 3 dni i 400 dolarów – krok po kroku nauczysz się, jak zbudować własną platformę Launchpad

Oryginalny tytuł: I Built a Launchpad in 3 Days for $400 (and so can you)
Oryginalny autor: ultra

Tłumaczenie: Luffy, Foresight News

W zeszły weekend, pracując po godzinach, stworzyłem projekt Blind, aby udowodnić: stworzenie znaczącego produktu nie wymaga milionów dolarów finansowania, miesięcy pracy, a nawet zespołu.

Blind to platforma do emisji tokenów zbudowana na łańcuchu Base, działająca w oparciu o infrastrukturę Flaunch. Próbuje ona nowego mechanizmu: pozwala twórcom tokenów samodzielnie decydować, które informacje osobiste ujawnić podczas emisji tokena.

Dzięki temu twórcy mogą wykorzystać swoją reputację lub kwalifikacje jako gwarancję, nie musząc całkowicie ujawniać swojej prawdziwej tożsamości ani ponosić problemów związanych z byciem „twarzą tokena”. Dodatkowo, twórcy mogą ustawić progi dostępu, pozwalając uczestniczyć tylko użytkownikom spełniającym minimalne wymagania.

Cel artykułu

Celem tego artykułu jest podzielenie się uniwersalnym schematem przejścia od „pomysłu” do „produktu”.

Jak często powtarzam, obecne 6-12 miesięcy to „złoty okres realizacji pomysłów” – dzięki narzędziom AI przekształcenie pomysłu w rzeczywistość jest wyjątkowo łatwe, ale niewiele osób zdaje sobie z tego sprawę. Dla tych, którzy są gotowi poświęcić czas, to bez wątpienia ogromna okazja arbitrażowa.

Mam nadzieję, że ten artykuł zainspiruje więcej osób do spróbowania vibecoding, przekształcenia swoich pomysłów w rzeczywistość i przywrócenia Web3 do czasów, gdy dominowali niezależni deweloperzy i małe zespoły, a innowacje pojawiały się każdego dnia.

Artykuł zakłada, że czytelnik ma już pewne podstawy techniczne, zna narzędzia deweloperskie, zarządzanie repozytoriami kodu oraz podstawowe komponenty.

Etap 0: Źródło inspiracji

Pojęcie „bramkowania kapitału społecznego” kiełkowało w mojej głowie od kilku miesięcy. Podczas częstego korzystania z Kaito, Ethos, fantasy.top, time.fun i badania wskaźników SocialFi, w dyskusjach wielokrotnie pojawiało się pytanie: dlaczego nikt nie stworzył dashboardu, który integruje profile użytkowników ze wszystkich tych platform i ocenia ich kwalifikacje na podstawie punktów i danych?

W ciągu ostatnich 6 miesięcy obszar „wskaźników twórców” szybko się rozwinął – dziś można ocenić wartość osoby lub konta na podstawie różnych wymiarów danych.

Czy można więc użyć tych wskaźników do ustawienia „progów uczestnictwa” (np. warunków dostępu do emisji tokena)? Czy można pozwolić twórcom samodzielnie decydować, które wskaźniki ujawnić publicznie, a jednocześnie ukryć swoją prawdziwą tożsamość?

Do działania zmotywowało mnie to, że Pump.fun zebrał 500 millions dolarów finansowania, a ostatnio heaven zebrał 20 millions dolarów. Moim zdaniem, oba te produkty nie są szczególnie trudne do stworzenia – dlaczego więc ich wyceny są tak zawyżone? A podobnych udanych platform emisji jest wiele, wszystkie zebrały ogromne środki.

Uczciwie mówiąc, w tej branży, aby zachować racjonalność, już nie przejmujemy się „logiką wyceny tokenów”; często sama wycena nie ma żadnego sensu.

Tak czy inaczej, to wywołało moje osobiste wyzwanie: czy mogę w jeden weekend, przy minimalnych kosztach i bez zewnętrznej pomocy, stworzyć produkt na podobnym poziomie?

Moim celem nie było stworzenie produktu komercyjnego, emisja tokena, ani nawet zarabianie pieniędzy, lecz udowodnienie, że „to jest możliwe” i zachęcenie innych do podążania tą ścieżką.

Etap 1: Rozbicie problemu

Mając pomysł, pierwszym krokiem jest rozbicie go na kluczowe komponenty i podjęcie decyzji dla każdego z nich. Dla „platformy emisji z kontrolą dostępu społecznego” wyróżniłem następujące podproblemy:

Wybór stosu technologicznego on-chain

Pierwsza decyzja to „na którym łańcuchu wdrożyć”, co wpłynie na wszystkie kolejne etapy realizacji. W tamtym czasie miałem dwa jasne wybory: Solana i Base.

Solana

Zalety:

· Łańcuch z najwyższym wolumenem transakcji memecoinów;

· Efekt reflektora: każdy projekt wdrożony tutaj łatwo zyskuje uwagę.

Wady:

· Niska elastyczność wdrożenia, konieczność stosowania istniejących standardów tokenów;

· Wysoka złożoność deweloperska, potrzeba wielu obejść;

· Długi cykl rozwoju;

· Wysokie i niestabilne koszty infrastruktury.

Base

Zalety:

· Najwyższy wolumen transakcji memecoinów wśród łańcuchów EVM;

· Doskonałe wsparcie dla deweloperów;

· Świetne doświadczenie deweloperskie EVM;

· Możliwość bezpośredniego wykorzystania istniejącej infrastruktury.

Wady:

· Wolumen memecoinów niższy niż na Solana.

Ponieważ Blind nie jest projektem komercyjnym, a jedynie weekendowym ćwiczeniem, nie musimy brać pod uwagę „potencjalnego zwrotu finansowego” – wystarczy wybrać opcję, która nie sprawi, że proces deweloperski będzie bolesny. Ostatecznie wybraliśmy EVM. Przy tworzeniu aplikacji blockchain, EVM to najbardziej dojrzała i przyjazna infrastruktura, pozwalająca na szybki, efektywny i rozsądny rozwój.

Wykorzystanie istniejącej infrastruktury

Po wyborze łańcucha, kolejnym krokiem jest znalezienie SDK (zestawów narzędzi deweloperskich) lub gotowych kontraktów, aby uniknąć pisania wszystkiego od zera. Szczególnie w przypadku smart kontraktów, priorytetem jest korzystanie z audytowanych rozwiązań, co znacząco zmniejsza ryzyko bezpieczeństwa.

Na szczęście w ekosystemie EVM jest mnóstwo zasobów do ponownego użycia, a główne opcje to:

· Rozwój w oparciu o DEX-y takie jak Uniswap, budując własną logikę kontroli dostępu na bazie Uniswap V4;

· Rozwój w oparciu o infrastrukturę istniejących platform emisji (np. SDK Flaunch), która ma już wbudowane indeksowanie, przesyłanie metadanych, konfigurację krzywych emisji, zarządzanie etapami itd.

Znów wybraliśmy „ścieżkę najmniejszego oporu”: rozwój na bazie Flaunch. Dzięki temu mogliśmy skupić się na „społecznych cechach platformy emisji + prezentacji frontendu”, nie tracąc czasu i pieniędzy na konfigurację puli, infrastrukturę indeksowania, kontrakty podziału zysków i inne podstawowe funkcje.

„Skoro mądrzejsi od ciebie już to zrobili, po co wymyślać koło na nowo?”

Sposób wdrożenia tokena

Po wyborze SDK trzeba zdecydować „kto faktycznie wdraża token”, są dwie opcje:

Opcja 1: Użytkownik inicjuje transakcję wdrożenia tokena

· Konieczność stworzenia kontraktu proxy, aby upewnić się, że parametry emisji wybrane przez użytkownika spełniają wymagania platformy;

· Trzeba znaleźć sposób na śledzenie wszystkich wdrożonych tokenów w istniejącym subgraphie Flaunch.

Opcja 2: Użytkownik przesyła „żądanie wdrożenia” do backendu, a wdrożenie wykonuje bot platformy

· Wszystkie tokeny wdrażane przez własny EOA (zewnętrzne konto) platformy, co ułatwia śledzenie wszystkich tokenów wyemitowanych przez platformę w indeksatorze;

· Możliwość zapewnienia, że wszystkie emisje przestrzegają jednolitych, standaryzowanych parametrów.

Wybraliśmy opcję „wdrożenie przez backend”: ułatwia to śledzenie tokenów i pozwala ściślej kontrolować „treść i sposób wdrożenia”, a w przyszłości daje możliwość rozwoju.

Wszystkie tokeny będą wdrażane przez portfel kontrolowany przez backend.

W istocie, „odchudziliśmy SDK Flaunch”, usuwając wszystkie niepotrzebne funkcje i zostawiając tylko te, które można wywołać przez backend.

Zbieranie danych społecznościowych

Kolejny krok to skupienie się na funkcjach społecznościowych. Musimy określić, które wymiary danych są wartościowe dla platformy emisji. Idealna kombinacja powinna odzwierciedlać zarówno „stan konta użytkownika”, jak i „reputację użytkownika”.

Ostatecznie wybrałem następujące wymiary danych:

· Liczba obserwujących (API X)

· Liczba obserwowanych (API X)

· Czas od rejestracji konta (API X)

· Liczba polubień (API X)

· Liczba wartościowych obserwujących (Moni API)

· Liczba kluczowych użytkowników interakcji (Moni API)

· Wynik reputacji (Ethos API)

· Wynik zasięgu treści (Kaito API)

Taka kombinacja pozwala twórcom wyróżnić się, udowadniając swoje kwalifikacje wielowymiarowymi danymi, bez konieczności całkowitego ujawniania tożsamości.

Przetwarzanie danych społecznościowych i ochrona prywatności

Podczas rejestracji użytkownika zbieramy wszystkie powyższe dane, ale jak zaprojektować warstwę prywatności?

Naszą zasadą jest „domyślna ochrona prywatności”: wszystkie dane są domyślnie niepubliczne, aby uniknąć wycieków; użytkownik może samodzielnie zdecydować, które wymiary danych ujawnić. Ponadto, użytkownik powinien mieć możliwość „zamazania” danych (np. mając 43 000 obserwujących, może wybrać wyświetlanie „40 000+”), oferując półanonimowe odniesienie.

Dodatkowo, czy przetwarzanie danych powinno opierać się na „scentralizowanym backendzie + żądaniach HTTPS”, czy na złożonych technikach zero-knowledge proof?

Nasze rozwiązanie to połączenie obu:

· Wszystkie dane przechowywane są w bazie danych Postgres, frontend pobiera je bezpośrednio przez API HTTPS. Kontrola dostępu przebiega według następującego procesu:

· Użytkownik chce uczestniczyć → żąda od backendu „dowodu dostępu”;

· Backend sprawdza, czy użytkownik spełnia progi ustawione przez twórcę;

· Backend zwraca podpisaną wiadomość zawierającą „adres portfela użytkownika + znacznik czasu wygaśnięcia”;

· Smart kontrakt weryfikuje ważność podpisu.

Etap 2: Realizacja deweloperska

Przed rozpoczęciem kodowania, sporządź listę potrzebnych narzędzi:

· Railway (hosting backendu): 20 USD / miesiąc

· Vercel (hosting frontendu): 15 USD / miesiąc

· Cursor (narzędzie deweloperskie, tryb Claude 4 MAX): 200 USD / miesiąc + 100 USD kredytów

· Domenę strony: 30 USD / rok

· X Premium+ (członkostwo konta, zwiększa zasięg + pozwala publikować długie posty): 40 USD / miesiąc

· ChatGPT: do projektowania logo + identyfikacji wizualnej marki, można zastąpić innym znanym narzędziem

· Całkowity koszt ok. 405 USD (przy założeniu, że Vercel nie przekroczy limitu subskrypcji).

Uwaga: aby przyspieszyć rozwój, faktycznie wykorzystałem więcej kredytów Cursor (tryb MAX). Jeśli nie zależy ci na tempie, możesz wybrać tańszy model.

Projekt architektury

Większość projektów wymaga 4 kluczowych komponentów:

· Frontend: hostowany na Vercel (osobne repozytorium GitHub);

· Backend: hostowany na Railway (osobne repozytorium GitHub);

· Baza danych: Postgres na Railway;

· Baza cache: Redis na Railway.

W skrócie, Vercel obsługuje wszystkie funkcje frontendu; Railway bezpiecznie hostuje „niewidoczne dla użytkownika” usługi rdzeniowe, takie jak przetwarzanie danych, wdrażanie tokenów, API, cache itd.

Większość architektur backendowych wygląda mniej więcej tak (tak, dane są w „kuli”).

Kolejność rozwoju

Zawsze zalecam najpierw rozwijać funkcje kluczowe, a na końcu prezentację frontendu.

Dla tego projektu najważniejszą funkcją (i wymagającą najpierw testów kompatybilności) jest emisja tokena.

Ponieważ zdecydowaliśmy, że wdrożenie tokena wykona backendowy EOA, możemy utworzyć nowe repozytorium git dla backendu i zacząć zgłębiać dokumentację SDK Flaunch.

Dokumentacja opisuje wszystkie dostępne obecnie funkcje konfiguracyjne, a nawet zawiera fragmenty kodu ułatwiające integrację. Dostępne są też API do pobierania danych oraz subgraph automatycznie indeksujący wszystko, co dzieje się na Flaunch (w tym tokeny uruchamiane z frontendu Blind).

1) Testowanie funkcji emisji tokena

W nowym repozytorium backendu, pierwszym krokiem jest skonfigurowanie środowiska lokalnego i przetestowanie, czy można wyemitować token przez SDK. Najpierw można napisać prosty skrypt Node, później przerobić go na endpoint serwera Express, który po wywołaniu z odpowiednimi parametrami wdroży token.

Ten krok jest naprawdę prosty, prawdopodobnie wystarczy jedno polecenie i trochę debugowania.

Co więcej, koszt gazu wdrożenia tokena to mniej niż 0,01 USD! Oznacza to, że możemy zaoferować użytkownikom całkowicie darmową usługę wdrożenia tokena.

2) Pobieranie danych społecznościowych

Drugim krokiem jest rozwinięcie kolejnej kluczowej funkcji: scoringu społecznościowego. Dla wszystkich wybranych wcześniej wymiarów danych należy przejrzeć dokumentację każdego API, a następnie utworzyć endpoint w serwerze Express, który na podstawie nazwy użytkownika zwróci wszystkie dane. Następnie można je zapisać w bazie Postgres na Railway.

3) Proces rejestracji

Na tym etapie rozwój staje się nieco bardziej złożony, bo trzeba równolegle rozwijać frontend. Wybraliśmy Next.js jako framework frontendowy, ponieważ najlepiej współpracuje z Vercel i obsługuje middleware do uwierzytelniania.

W procesie rejestracji chcemy, aby użytkownik najpierw połączył portfel, potem uwierzytelnił się przez X, a na końcu zarejestrował się przez nasz endpoint.

Najpierw przeglądamy dokumentację API uwierzytelniania X, implementujemy prostą stronę rejestracji na frontendzie i tworzymy endpoint rejestracji na backendzie.

Podczas rejestracji musimy też pobrać wszystkie dane z kroku 2) i zapisać je w bazie, dodając wpis z adresem portfela. Wszystkie żądania do endpointu rejestracji powinny być uwierzytelniane zarówno przez klucz X, jak i podpis portfela, aby zapobiec podszywaniu się.

Po poprawnym działaniu należy dodać uwierzytelnianie do endpointu wdrożenia tokena, tak aby tylko zarejestrowani użytkownicy mogli wdrażać tokeny. Dla innych endpointów poza rejestracją zdecydowaliśmy się na uwierzytelnianie tylko przez podpis portfela, aby uniknąć każdorazowego logowania przez X.

4) Ustawienia prywatności

Po zakończeniu procesu rejestracji i wdrożeniu przechowywania danych, kolejnym krokiem jest rozwinięcie ustawień prywatności:

· Utworzenie tabeli ustawień widoczności danych w bazie (domyślnie wszystkie dane są prywatne);

· Opracowanie endpointu do zmiany ustawień prywatności przez uwierzytelnionych użytkowników;

· Napisanie funkcji pomocniczych, umożliwiających użytkownikom wybór zamazania danych;

· Stworzenie komponentu edycji ustawień prywatności na frontendzie.

5) Sprawdzenie i optymalizacja endpointów

Po przygotowaniu usług kluczowych należy dokonać następujących optymalizacji:

Wszystkie kluczowe funkcje serwera są gotowe, teraz trzeba upewnić się, że wszystkie endpointy korzystają z uwierzytelniania tam, gdzie to konieczne, i nie ujawniają żadnych danych osobowych przy publicznym dostępie. Można też użyć cache Redis do optymalizacji niektórych API, aby odciążyć serwer. Na koniec dodaliśmy kilka API do pobierania publicznych profili użytkowników, właścicieli tokenów i ich danych, danych tokenów itd.

6) Rozwój frontendu

Teraz czas stworzyć atrakcyjną stronę. Najpierw wybieramy motyw, strony do wyświetlenia i zaczynamy usuwać „prywatne” części. Do wyświetlania listy tokenów z niestandardowym sortowaniem i innych danych możemy polegać na subgraphie Flaunch, filtrując po adresie wdrożeniowym jako naszym EOA. Na stronie szczegółów tokena, szybki sposób na pokazanie wykresu to osadzenie prostego iframe DexScreener.

7) Testowanie

Wszystko wreszcie gotowe. Testujemy ścieżkę użytkownika, wdrażamy wszystko na Vercel i Railway, dzielimy się dostępem z przyjaciółmi, aby zebrać feedback. Celem jest stworzenie środowiska identycznego z produkcyjnym.

8) Optymalizacja na podstawie feedbacku

To ostatni krok przed oficjalnym uruchomieniem.

Etap 3: Publiczne uruchomienie

Publiczne uruchomienie składa się z dwóch kroków: najpierw budowa marki, potem promocja rynkowa.

Budowa marki

Nie wspominałem wcześniej o budowie marki, bo można to zrobić w dowolnym momencie, ale najlepiej przed rozpoczęciem prac nad frontendem. Kluczowe elementy marki (nazwa, logo, kolorystyka, domena) powinny być „proste i łatwe do rozpoznania”.

Osobiście bardzo lubię zabawę „nazwa jednowyrazowa + gra słów w domenie”:

· Nazwa projektu to „Blind” (oznacza „ślepy zakład”, nawiązując do kupowania tokenów przy ograniczonych informacjach);

· Kolorystyka celowo bardzo jasna, w stylu „beast design”, przywodząca na myśl dokumenty w alfabecie Braille’a, co nawiązuje do tematu „Blind”;

· Logo: wygenerowane przez ChatGPT (na podstawie istniejącego motywu);

Promocja rynkowa

Czas, by cały świat dowiedział się o naszym MVP (minimalnie działającym produkcie)! Zazwyczaj najlepszym sposobem, by inni się dowiedzieli, nie jest bezpośrednie informowanie, lecz wywołanie zamieszania.

Marketing zamieszania

Przed oficjalną promocją warto upewnić się, że MVP jest kompletne. Najlepiej rozpocząć działania marketingowe tydzień przed uruchomieniem, by skupić uwagę publiczności w jednym tygodniu i łatwiej wejść na listy trendów w social mediach.

Główne cele tego tygodnia:

· Zachęcić więcej osób do obserwowania konta projektu na X i włączenia powiadomień;

· Publikować niejasne zapowiedzi, żartobliwe treści, ale nigdy nie ujawniać wprost funkcji projektu;

· Zostawiać „wskazówki”, by użytkownicy sami zgadywali w komentarzach i generowali szum.

Wskaźniki próżności: spraw, by użytkownicy nie byli sami

Skutecznym narzędziem wspierającym „marketing zamieszania” jest „ranking”! Ludzie chcą być „pierwsi”, ale nie chcą „wejść za wcześnie”. Twoim zadaniem jest „ożywić platformę przed uruchomieniem”.

„Rejestracja + ranking” daje następujące korzyści:

· Wcześniejsze zachęcenie użytkowników do rejestracji, rozłożenie ruchu na stronie, testowanie stabilności systemu;

· Utrzymanie zainteresowania projektem: „czy wcześniejsza rejestracja daje korzyści?” – użytkownicy włączają powiadomienia;

· Ludzie lubią „być lepsi od innych”: ranking łatwo udostępnić, a użytkownicy odkrywają ciekawe dane o swoim koncie;

· Ułatwia zespołowi promowanie „danych wzrostowych”.

Przed uruchomieniem Blind liczba prerejestrowanych użytkowników przekroczyła 40 000!

Uwaga: jeśli dodasz mechanizm „linków zaproszeniowych”, tempo wzrostu będzie jeszcze szybsze.

24-godzinne odliczanie

Czas ujawnić kluczowe funkcje Blind! Przy publikacji artykułu poinformuj użytkowników, by mieli konkretny czas oczekiwania. Ostatnie 24 godziny skupiają uwagę na Blind. 24 godziny pozwalają przygotować się użytkownikom z każdej strefy czasowej.

Publikacja artykułu o uruchomieniu

W tym momencie użytkownicy odświeżają twoje konto X – czas opublikować artykuł! Powinien on szczegółowo opisywać:

· Kluczowe funkcje Blind;

· Oficjalny czas uruchomienia;

· Nie musi być zbyt techniczny ani wymieniać wszystkich funkcji – skup się na „motywacji deweloperskiej”, „kluczowym pomyśle” i „atrakcyjności projektu”;

Jeśli trzeba dodać szczegóły techniczne, można je umieścić w osobnej dokumentacji poza artykułem.

Etap 4: Oficjalne uruchomienie!

W artykule należy podać, że „czas uruchomienia to 24 godziny po publikacji”. W tym momencie prerejestrowani użytkownicy są gotowi, czekają na wdrożenie tokenów. Następnie należy:

· Przełączyć wszystkie środowiska na tryb produkcyjny;

· Przełączyć konto wdrażającego EOA;

· Być w gotowości na ewentualne błędy podczas uruchomienia (błędy zawsze się zdarzają).

Gotowe, oficjalne uruchomienie!

Podsumowanie

Podczas tworzenia MVP zawsze wybieraj „ścieżkę najmniejszego oporu”. Nie musisz dążyć do perfekcji od razu – możesz stopniowo optymalizować w środowisku produkcyjnym. Wykorzystanie okazji jest często ważniejsze niż „czekanie, aż wszystko będzie gotowe”.

Pamiętaj jednak: pierwsze wrażenie jest kluczowe. Doświadczenie użytkownika przy pierwszej wizycie na platformie bezpośrednio wpływa na jego długoterminową opinię – nie licz, że większość użytkowników będzie śledzić „aktualizacje funkcji”.

Proces tworzenia tego projektu pobocznego był bardzo ciekawy, dużo się nauczyłem i stworzyłem narzędzie, które „ludzie mogą wykorzystać do emisji tokenów”.