Лише за 3 дні та 400 доларів: покрокова інструкція зі створення Launchpad-платформи

Оригінальна назва: I Built a Launchpad in 3 Days for $400 (and so can you)
Оригінальний автор: ultra

Переклад: Luffy, Foresight News

Минулого вікенду я працював понаднормово над проєктом Blind, щоб довести: створення значущого продукту не потребує мільйонних інвестицій, місяців роботи чи навіть команди.

Blind — це платформа для запуску токенів на основі Base chain, яка працює на інфраструктурі Flaunch. Вона випробовує новий механізм: дозволяє творцям токенів самостійно обирати, яку особисту інформацію розкривати під час запуску токену.

Таким чином, творці можуть використовувати свою репутацію чи кваліфікацію як гарантію, не розкриваючи повністю свою справжню особистість і не беручи на себе проблеми, які зазвичай виникають у "амбасадорів токенів". Крім того, творці можуть встановлювати пороги доступу, дозволяючи брати участь лише користувачам, які відповідають мінімальним вимогам.

Мета цієї статті

Мета цієї статті — поділитися універсальною структурою шляху від "ідеї" до "продукту".

Як я часто кажу, зараз ці 6-12 місяців — "золота епоха реалізації ідей": за допомогою AI-інструментів втілити ідею в реальність надзвичайно просто, але мало хто це усвідомлює. Для тих, хто готовий інвестувати час, це величезна можливість для арбітражу.

Я сподіваюся, що ця стаття надихне більше людей спробувати vibecoding, втілити свої ідеї в життя і повернути Web3 до тієї епохи, коли незалежні розробники та невеликі команди щодня створювали інновації.

Стаття розрахована на читачів із певною технічною базою, знайомих із інструментами розробки, управлінням репозиторіями коду та знанням основних компонентів.

Етап 0: Джерело натхнення

Ідея соціального капіталу як фільтра зріла в моїй голові кілька місяців. Часто використовуючи Kaito, Ethos, fantasy.top, time.fun та досліджуючи SocialFi-метрики, у дискусіях постійно виникало питання: чому ніхто не зробив дашборд, який би інтегрував профілі користувачів з усіх цих платформ і оцінював їхню кваліфікацію за балами та даними?

За останні 6 місяців сфера "метрик творців" стрімко зросла, і тепер можна оцінювати цінність людини чи акаунта за різними даними.

Чи можна використовувати ці метрики для встановлення "порогу участі" (наприклад, для запуску токену)? А чи можна дозволити творцям самостійно вирішувати, які метрики розкривати публічно, приховуючи свою справжню особистість?

Справжнім поштовхом до розробки стало те, що Pump.fun залучив 500 millions доларів, а нещодавно heaven — ще 20 millions доларів. На мою думку, складність розробки цих продуктів не така вже й висока, то чому ж оцінка така захмарна? І подібних успішних платформ для запуску токенів багато, і всі вони залучили величезні кошти.

Чесно кажучи, у цій сфері, щоб зберегти раціональність, ми вже не переймаємося "логікою оцінки токенів"; часто сама оцінка не має жодного сенсу.

Але так чи інакше, це стало для мене особистим викликом: чи зможу я за один вікенд, з мінімальними витратами і без сторонньої допомоги, створити продукт не гірший за ці?

Моя мета — не створити комерційний продукт, не запускати токен і навіть не заробити грошей, а довести, що "це можливо", і надихнути більше людей піти цим шляхом.

Етап 1: Декомпозиція проблеми

Маючи ідею, перший крок — розбити її на основні компоненти й прийняти рішення щодо кожного з них. Для "платформи запуску з соціальним контролем доступу" я виділив такі підзадачі:

Вибір технологічного стеку

Головне рішення — "на якій мережі розгортати", оскільки це вплине на всі подальші етапи. На той момент було два очевидних варіанти: Solana та Base.

Solana

Переваги:

· Найбільший обсяг торгів "shitcoins";

· Ефект прожектора: будь-який проєкт тут легко отримує увагу.

Недоліки:

· Низька гнучкість реалізації, потрібно дотримуватися існуючих стандартів токенів;

· Висока складність розробки, багато обхідних рішень;

· Довший цикл розробки;

· Висока й нестабільна вартість інфраструктури.

Base

Переваги:

· Найбільший обсяг торгів "shitcoins" серед EVM-ланцюгів;

· Чудова підтримка розробників;

· Відмінний досвід розробки для EVM;

· Можна напряму використовувати існуючу інфраструктуру.

Недоліки:

· Обсяг торгів "shitcoins" менший, ніж у Solana.

Оскільки Blind — не комерційний проєкт, а просто експеримент на вихідних, ми не враховували "потенційний фінансовий зиск", а обрали шлях, який не зробить розробку болісною. Врешті ми обрали EVM. Для розробки блокчейн-додатків EVM — це найзріліша й найзручніша інфраструктура, яка дозволяє швидко, ефективно й розумно рухатися вперед.

Використання існуючої інфраструктури

Після вибору мережі наступний крок — пошук SDK або готових контрактів, щоб не писати все з нуля. Особливо для смарт-контрактів краще використовувати вже аудовані рішення, щоб знизити ризики безпеки.

На щастя, в екосистемі EVM багато ресурсів, і ми мали два основні варіанти:

· Розробка на основі Uniswap чи інших DEX, самостійна реалізація логіки контролю доступу на базі Uniswap V4;

· Розробка на основі інфраструктури існуючих платформ запуску (наприклад, SDK Flaunch), який вже містить індексацію, завантаження метаданих, налаштування кривої запуску, управління етапами тощо.

Ми знову обрали "шлях найменшого опору": розробку на базі Flaunch. Це дозволило зосередитися на "соціальних функціях платформи запуску + фронтенді", не витрачаючи час і гроші на базові функції, як-от налаштування пулу, індексація, контракти розподілу доходу тощо.

"Якщо розумніші за тебе вже зробили цю роботу, навіщо вигадувати велосипед?"

Спосіб розгортання токену

Після вибору SDK потрібно вирішити, "хто саме буде розгортати токен". Є два варіанти:

Варіант 1: Користувач ініціює транзакцію для розгортання токену

· Потрібно розробити проксі-контракт, щоб гарантувати, що параметри запуску відповідають вимогам платформи;

· Потрібно знайти спосіб відстежувати всі розгорнуті токени у поточному субграфі Flaunch.

Варіант 2: Користувач надсилає "запит на розгортання" на бекенд, а бот платформи виконує розгортання

· Усі токени розгортаються через EOA (externally owned account) платформи, що спрощує відстеження всіх токенів, запущених платформою;

· Можна гарантувати, що всі запуски відповідають єдиним стандартним параметрам.

Ми обрали варіант "розгортання через бекенд": це спрощує відстеження токенів і дозволяє суворіше контролювати "зміст і спосіб розгортання", а в майбутньому — масштабувати функціонал.

Усі токени розгортаються гаманцем, який контролюється бекендом.

По суті, ми "спростили SDK Flaunch", прибравши всі непотрібні функції й залишивши лише ті, які можна викликати через бекенд-запити.

Збір соціальних даних

Далі фокус на соціальних функціях. Потрібно визначити, які дані цінні для платформи запуску. Ідеальний набір має відображати і "статус акаунта", і "репутацію користувача".

Я зупинився на таких метриках:

· Кількість підписників (X API)

· Кількість підписок (X API)

· Вік акаунта (X API)

· Кількість лайків (X API)

· Кількість цінних підписників (Moni API)

· Кількість основних взаємодій (Moni API)

· Репутаційний бал (Ethos API)

· Бал поширення контенту (Kaito API)

Такий набір дозволяє творцям довести свою кваліфікацію через багатовимірні дані, не розкриваючи повністю особистість, і виділитися серед інших.

Обробка соціальних даних і захист приватності

Під час реєстрації користувача ми збираємо всі ці дані, але як забезпечити приватність?

Наш принцип — "приватність за замовчуванням": усі дані спочатку приватні, щоб уникнути витоку; користувач сам вирішує, які дані розкривати. Крім того, користувач може "розмити" дані (наприклад, маючи 43 000 підписників, показати "40 000+"), надаючи напіванонімну інформацію.

Також, чи обробляти дані через "централізований бекенд + HTTPS-запити", чи використовувати складні zero-knowledge докази?

Наш підхід — комбінований:

· Усі дані зберігаються у базі даних Postgres, фронтенд отримує їх через HTTPS API. Контроль доступу реалізовано так:

· Користувач хоче взяти участь → надсилає запит на "доказ доступу" на бекенд;

· Бекенд перевіряє, чи відповідає користувач порогу, встановленому творцем;

· Бекенд повертає підписане повідомлення з "адресою гаманця користувача + часом закінчення дії";

· Смарт-контракт перевіряє дійсність підпису.

Етап 2: Реалізація розробки

Перед початком розробки складаємо "чекліст інструментів":

· Railway (бекенд-хостинг): $20/місяць

· Vercel (фронтенд-хостинг): $15/місяць

· Cursor (інструмент розробки, включно з Claude 4 MAX): $200/місяць + $100 credits

· Домен сайту: $30/рік

· X Premium+ (акаунт для підвищення видимості + довгі пости): $40/місяць

· ChatGPT: для дизайну логотипу та бренду, можна замінити іншим знайомим інструментом

· Загальна вартість близько $405 (якщо не перевищено ліміт Vercel).

Примітка: щоб прискорити розробку, я використав більше Cursor credits (MAX-модель). Якщо не поспішати, можна обрати дешевшу модель.

Архітектурний дизайн

Більшість проєктів потребують 4 основних компоненти:

· Фронтенд: хоститься на Vercel (окремий GitHub-репозиторій);

· Бекенд: хоститься на Railway (окремий GitHub-репозиторій);

· База даних: Postgres на Railway;

· Кеш: Redis на Railway.

Простіше кажучи, Vercel відповідає за всі фронтенд-функції; Railway — за "невидимі користувачу" сервіси: обробку даних, розгортання токенів, API, кешування тощо.

Більшість бекенд-архітектур виглядають так (так, дані зберігаються у "кулі").

Порядок розробки

Я завжди раджу спочатку розробляти основний функціонал, а вже потім фронтенд.

Для цього проєкту найважливіша функція (і та, яку треба першою перевірити на сумісність) — запуск токену.

Оскільки ми вирішили, що токени розгортає бекенд EOA, можна створити новий git-репозиторій для бекенду й почати вивчати документацію Flaunch SDK.

У документації описані всі можливі функції для налаштування запуску, навіть є готові фрагменти коду для інтеграції. Також є API для отримання даних і субграф, який автоматично індексує всі події на Flaunch (включно з токенами, запущеними через Blind).

1) Тестування функції запуску токену

У новому бекенд-репозиторії перший крок — налаштувати локальне середовище й перевірити, чи можна через SDK успішно запустити токен. Можна написати простий Node-скрипт, а потім перетворити його на Express-ендпоінт, який приймає параметри й розгортає токен.

Цей крок дуже простий, зазвичай достатньо одного промпту й мінімального дебагу.

І газ за розгортання токену — менше $0.01! Це означає, що ми можемо надати користувачам повністю безкоштовний сервіс запуску токенів.

2) Отримання соціальних даних

Другий крок — розробка ще однієї ключової функції: соціального скорингу. Для кожної обраної метрики потрібно переглянути документацію API й створити в Express сервері ендпоінт, який повертає всі дані за іменем користувача. Потім ці дані зберігаються у Postgres на Railway.

3) Процес реєстрації

На цьому етапі розробка трохи ускладнюється, бо треба паралельно працювати й над фронтендом. Ми обрали Next.js як фреймворк, бо він найкраще підтримується Vercel і дозволяє реалізувати автентифікацію через middleware.

Під час реєстрації користувач спочатку підключає гаманець, потім проходить автентифікацію через X, і нарешті реєструється через наш ендпоінт.

Спочатку вивчаємо документацію X API для автентифікації, реалізуємо просту сторінку реєстрації на фронті й створюємо реєстраційний ендпоінт на бекенді.

Під час реєстрації також потрібно отримати всі дані з кроку 2) і зберегти їх у базі, додавши адресу гаманця. Усі запити до реєстраційного ендпоінту мають проходити X-автентифікацію й підпис повідомлення гаманцем, щоб уникнути підміни особи.

Після цього потрібно додати автентифікацію до ендпоінту запуску токену, щоб тільки зареєстровані користувачі могли запускати токени. Для інших ендпоінтів, окрім реєстрації, ми вирішили використовувати лише підпис повідомлення гаманцем, щоб не змушувати користувача щоразу логінитися через X.

4) Налаштування приватності

Після завершення реєстрації й збереження даних наступний крок — розробка налаштувань приватності:

· Створити таблицю налаштувань видимості даних у базі (за замовчуванням усі дані приватні);

· Розробити ендпоінт для зміни налаштувань приватності для автентифікованих користувачів;

· Написати допоміжні функції для "розмиття" даних;

· Розробити фронтенд-компонент для редагування налаштувань приватності.

5) Перевірка й оптимізація ендпоінтів

Після готовності основних сервісів потрібно провести такі оптимізації:

Усі основні функції сервера готові, тепер треба переконатися, що всі ендпоінти використовують автентифікацію, коли це потрібно, і не розкривають персональні дані при публічному доступі. Можна використати Redis для кешування деяких API, щоб зменшити навантаження на сервер. Нарешті, додаємо кілька API для отримання публічного профілю користувача, власників токенів і їхніх даних, даних про токени тощо.

6) Фронтенд-розробка

Час створити гарний сайт. Визначаємо тему, сторінки для відображення й починаємо прибирати "приватні" частини. Для списку токенів із кастомним сортуванням та іншими даними можна використовувати субграф Flaunch і фільтрувати за адресою деплоєра (наш EOA). Для сторінки токену швидко показати графік можна через простий iframe DexScreener.

7) Тестування

Нарешті все готово. Тестуємо користувацький флоу, деплоїмо все на Vercel і Railway, ділимося доступом із друзями для фідбеку. Мета — створити середовище, ідентичне продакшену.

8) Оптимізація за фідбеком

Це останній крок перед запуском.

Етап 3: Публічний запуск

Публічний запуск складається з двох етапів: спочатку брендінг, потім маркетинг.

Брендінг

Я не згадував брендінг раніше, бо його можна робити будь-коли, але краще завершити до фронтенду. Основні елементи бренду (назва, логотип, кольори, домен) мають бути "простими й впізнаваними".

Мені дуже подобається підхід "однослова назва + домен із грою слів":

· Назва проєкту — "Blind" (натяк на "сліпу" купівлю токену при обмеженій інформації);

· Кольорова схема — навмисно яскрава, у стилі "бруталізм", асоціюється з шрифтом Брайля, що перегукується з темою "Blind";

· Логотип: згенеровано через ChatGPT (з підказкою на основі теми);

Маркетинг

Час повідомити світ про наш MVP! Зазвичай найкращий спосіб — не пряме повідомлення, а створення інтриги.

Інтригуючий маркетинг

Перед офіційним запуском переконайтеся, що MVP повністю функціональний. Краще почати маркетинг за тиждень до запуску, щоб зосередити увагу аудиторії й потрапити в топи соцмереж.

Основні цілі цього тижня:

· Залучити більше підписників на X-акаунт проєкту й увімкнути сповіщення;

· Публікувати інтригуючі анонси, меми, але не розкривати функціонал напряму;

· Залишати "підказки", щоб користувачі самі здогадувалися в коментарях і створювали хайп.

Віртуальні метрики: щоб користувачі не були самотні

Ефективний інструмент разом із "інтригуючим маркетингом" — "таблиця лідерів"! Люди хочуть "бути першими", але не "занадто рано". Ваше завдання — "оживити платформу до запуску".

Переваги "реєстрації + таблиці лідерів":

· Залучає користувачів до ранньої реєстрації, розподіляє трафік, тестує стабільність системи;

· Користувачі стежать за проєктом: "Чи буде бонус за ранню реєстрацію?" — вмикають сповіщення;

· Люди люблять "бути кращими": рейтинг легко ділитися, а ще можна побачити цікаві дані про свій акаунт;

· Легко показати "дані зростання" для зовнішнього PR.

До запуску Blind кількість попередньо зареєстрованих користувачів перевищила 40 000!

Примітка: якщо додати механіку "реферальних посилань", зростання буде ще швидшим.

24-годинний зворотний відлік

Час розкрити основний функціонал Blind! Під час публікації статті повідомте про це, щоб користувачі знали, коли чекати. Останні 24 години — час для всіх часових поясів підготуватися.

Публікація статті про запуск

Тепер усі оновлюють вашу X-сторінку — час публікувати статтю! У ній потрібно детально описати:

· Основний функціонал Blind;

· Час офіційного запуску;

· Не потрібно надто технічних деталей чи повного переліку функцій — головне передати "мотивацію розробки", "основну ідею" і "привабливість проєкту";

Технічні деталі можна винести в окрему документацію.

Етап 4: Офіційний запуск!

У статті потрібно вказати, що "запуск через 24 години після публікації". На цей момент попередньо зареєстровані користувачі вже готові, залишилося лише запустити токени. Далі потрібно:

· Перевести всі середовища у продакшен;

· Перемкнути EOA-акаунт деплоєра;

· Бути напоготові для вирішення помилок (вони завжди трапляються).

Готово, офіційний запуск!

Висновок

Під час розробки MVP завжди обирайте "шлях найменшого опору". Не потрібно прагнути ідеалу з першого разу — можна поступово вдосконалювати продукт у продакшені. Важливіше встигнути, ніж "дочекатися повної готовності".

Але пам'ятайте: перше враження дуже важливе. Досвід першого відвідування платформи визначає довгострокове сприйняття, не розраховуйте, що більшість користувачів стежитимуть за "оновленнями функцій".

Цей побічний проєкт був дуже цікавим, я багато чому навчився й створив інструмент, який "можливо, хтось використає для запуску токенів".