只要3天400美元，手把手教你搭建一個Launchpad平台

原文標題：I Built a Launchpad in 3 Days for $400 (and so can you)
原文作者：ultra

原文編譯：Luffy，Foresight News

上週末，我做出了 Blind這個項目，就是為了證明：打造有意義的產品，不需要數百萬美元融資、數月工時，甚至不需要團隊。

Blind 是基於 Base 鏈開發的代幣發行平台（Launchpad），依托 Flaunch 的基礎設施運作。它嘗試了一種全新機制：讓代幣創作者在發行代幣時，自主選擇公開哪些個人資訊。

這樣一來，創作者既能利用自己的聲譽或資質背書，又無需完全公開真實身份，也不用承擔成為“代幣代言人”通常會帶來的麻煩。此外，創作者還能設定預售准入門檻，只允許滿足最低條件的使用者參與。

本文目的

本文旨在分享我從「想法」到「產品」的一般框架。

正如我常說的，當下這 6-12 個月是「想法落地黃金期」，借助 AI 工具，將創意變為現實異常容易，但很少有人意識到這一點。對於願意投入時間的人來說，這無疑是個巨大的套利機會。

我希望這篇文章能激勵更多人嘗試 vibecoding，將自己的想法變為現實，讓 Web3 回歸那個由獨立開發者和小團隊主導、每日都有創新誕生的領域。

本文預設讀者已具備一定技術基礎，熟悉開發工具、程式碼倉庫管理及常見元件知識。

階段 0：靈感來源

社交資本門控這個想法，其實在我腦海裡已經醞釀了幾個月。在頻繁使用 Kaito、Ethos、fantasy.top、time.fun 等工具及研究 SocialFi 指標的過程中，討論裡反覆出現一個問題：為什麼沒人做一個儀錶盤，能整合顯示用戶在所有這些平台的個人資料，用分數和數據來評估用戶資質？

過去 6 個月左右，「創作者指標」領域迅速崛起，如今人們可以透過各種資料維度評估一個人或一個帳號的價值。

那麼，能不能用這些指標來設定「參與門檻」（例如代幣發行的進入條件）？又能不能讓創作者自主決定向大眾揭露哪些指標，同時隱藏自己的真實身分？

真正促使我動手開發的，是看到 Pump.fun 的 ICO 融資了 5 億美元，最近 heaven 的 ICO 也融了 2000 萬美元。在我看來，這兩款產品的開發難度不算高，為什麼估值能這麼誇張？而且類似的成功發行平台還有很多，都融到了龐大資金。

公平地說，在這個領域，為了保持理性，我們其實已經不再糾結「代幣估值邏輯」；很多時候，估值本身就毫無道理可言。

但無論如何，這引發了我的個人挑戰：我能不能在一個週末內，以極低的成本、不依賴外部幫助，做出一個水平相當的產品？

我的目標不是打造商業產品、發行代幣，甚至不是賺錢，而是證明「這件事能做到」，並希望更多人追隨這條路徑。

階段 1：問題拆解

有了想法後，第一步是將其拆解為核心組件，並針對每個組件做出決策。對於「帶社交准入控制的發行平台」，我梳理出以下幾個 子問題：

鏈上技術堆疊選擇

首要決策是「部署在哪條鏈上」，這個選擇會影響後續所有實現環節。當時有兩個明確選項：Solana 和 Base。

Solana

優點：

· 土狗幣交易量最高的鏈；

· 聚光燈效應：任何部署在這裡的項目都容易獲得一定關注度。

劣勢：

· 實現彈性低，必須遵循現有代幣標準；

· 開發複雜度高，需要大量變通方案；

· 開發週期長；

· 基礎設施成本高且不穩定。

Base

優點：

· EVM 系鏈中「土狗幣」交易量最高；

· 對開發者支援完善；

· EVM 開發體驗；

· 可直接復用現有基礎設施。

劣勢：

· 「土狗幣」交易量不如 Solana。

由於 Blind 並非商業項目，只是一個週末練手作品，我們無需考慮「潛在財務回報」相關決策，只需選擇「不讓開發過程太痛苦」的方案。最終我們選擇了 EVM。在開發區塊鏈應用時，EVM 是最成熟、體驗最好的區塊鏈基礎設施，能讓我們快速、有效率且明智地推進開發。

可重複使用的現有基礎設施

確定鏈之後，下一步是尋找可重複使用的 SDK（軟體開發工具包）或現成合約，避免從零開始寫入程式碼。尤其是智能合約部分，優先使用經過審計的合約，能大幅降低安全風險。

幸運的是，EVM 生態中有大量可重複使用資源，我們主要有兩個選擇：

·基於 Uniswap 等 DEX 開發，在 Uniswap V4 基礎上自行發行所有准入控制邏輯；

SDK）開發，此 SDK 已內建索引、元資料上傳、發行曲線配置、預售階段管理等功能。

我們再次選擇「阻力最小的路徑」：基於 Flaunch 開發。這樣一來，我們可以專注於「發行平台的社交屬性 + 前端展示」，無需在資金池配置、索引基礎設施、收益分成合約等基礎功能上浪費時間和金錢。

「既然比你聰明的人已經把活兒乾完了，何必再重複造輪子呢？」

代幣部署方式

確定 SDK後，需要決策「誰來實際執行代幣部署」，有兩個方案可選：

方案 1：用戶發起交易部署代幣

· 需開發代理合約，確保用戶選擇的發行參數符合平台要求；現有子圖索引器中追蹤所有已部署代幣。

方案 2：使用者向後端提交「部署請求」，由平台機器人執行部署

· 所有代幣均由平台自有 EOA（外部擁有帳戶）部署，便於在索引器中追蹤平台發行的所有代幣；

· 可確保所有發行都遵循統一的標準化參數。

我們選擇了「後端服務部署」方案：這讓代幣追蹤更簡單，也能更嚴格地控制「部署內容與方式」，未來還具備升級空間。

所有代幣都將由後端控制的錢包部署。

本質上，我們相當於「精簡了 Flaunch SDK」，移除所有不需要的功能，只保留後端請求可呼叫的部分。

社交資料收集

接下來聚焦社交功能。我們需要確定哪些資料維度對發行平台有價值。理想的資料組合應同時反映「用戶帳號狀態」與「用戶聲譽」。

最終我選定了以下資料維度：

· 粉絲數（X 平台 API）

· 關注數（X 平台 API）

· 帳號註冊時長（poni 平台 API）

· 核心互動用戶數（Moni API）

· 聲譽分數（Ethos API）

· 內容傳播度分數（Kaito API）

這樣的組合能讓創作者在無需完全暴露身份的情況下，透過多維度資料證明自己的資質，脫穎而出。

社群資料處理與隱私權保護

使用者註冊時，我們會收集上述所有數據，但隱私權層面該如何設計？

我們的原則是「預設隱私優先」：所有資料預設為不公開，避免洩漏；使用者可自主決定每個資料維度是否公開。此外，還應允許用戶「模糊化展示數據」（例如實際上有 4.3 萬粉絲，可選擇顯示「4 萬 +」），提供半匿名的數據參考。

另外，資料處理應依賴「中心化後端 + HTTPS 請求」，還是採用複雜的零知識證明技術？

我們的方案是兩者結合：

· 所有資料儲存在 Postgres 資料庫中，前端透過 HTTPS API 直接從資料庫取得資訊。預售存取控制則採用下列流程：

· 用戶希望參與預售 → 向平台後端請求「准入證明」；

· 後端驗證使用者是否滿足創作者設定的門檻；

· 後端回傳包含「用戶戳記碼」編號智能合約驗證簽名有效性。

階段 2：開發實作

開始開發前，先列出所需「工具清單」：

· Railway（後端託管）：20 美元 / 月

· Railway（後端託管）：20 美元 / 月

Verp/cel月

· Cursor（開發工具，含 Claude 4 MAX 模式）：200 美元 / 月 + 100 美元 credits

· 網站網域：30 美元 / 年

· 網站 編號 月

· ChatGPT：用於設計 Logo + 品牌視覺，也可替換為其他熟悉的工具

· 總成本約 405 美元（假設 Vercel 未超訂閱限額）。

附註：為加快開發，我實際用了比預期更多的 Cursor credits（啟用 MAX 模型）。如果不追求開發速度，可選擇更便宜的模型。

架構設計

大多數專案都需要 4 個核心元件：

· 前端：託管在 Vercel（單獨的 GitHub 倉庫）；

· 資料儲存資料庫：Railway 上的 Postgres 資料庫；

· 快取資料庫：Railway 上的 Redis 資料庫。

簡單來說，Vercel 負責所有前端相關功能；Railway 則安全託管「用戶不可見」的核心服務，如資料處理、代幣部署、API 介面、資訊快取等。

大多數後端的架構都像下面這樣（沒錯，資料存在「球」裡）。

開發順序

我總是建議先開發核心功能，最後做前端展示。

對本專案而言，最核心的功能（也是需要先測試相容性的功能）是代幣發行。

由於我們已確定「由後端 EOA 執行代幣部署」，因此我們可以為後端建立一個新的 git 儲存庫，並開始深入研究 Flaunch SDK 文件。

該文件概述了目前在啟動配置方面所有可行的功能，甚至提供了一些便於整合的程式碼片段。它們還提供了一些用於檢索資料的 API 端點，以及一個子圖，可以自動索引 Flaunch 上發生的所有事情（包括從 Blind 前端啟動的代幣）。

1）測試代幣發行功能

在新的後端倉庫中，第一步是搭建本地環境，測試能否透過 SDK 成功發行代幣。我們可以先寫一個簡單的 Node 腳本，後續再將其改造為 Express 伺服器接口，呼叫該接口並傳入指定參數，即可完成代幣部署。

這個步驟其實很簡單，大機率只需一次提示詞 + 少量調試就能搞定。

而且代幣部署的 Gas 費不到 0.01 美元！這意味著我們可以為用戶提供完全免費的代幣部署服務。

2）拉取社交資料

第二步是發展另一個核心功能：社交分數。針對先前選定的所有資料維度，我們需要查看每個 API 的文檔，然後在 Express 伺服器中建立一個端點，該端點會根據使用者名稱返回所有資料。然後，我們可以將這些資料儲存在我們在 Railway 上建立的 Postgres 資料庫中。

3）註冊流程

到這一步，開發會變得稍微複雜，需要同時推進前端倉庫的開發。我們選擇 Next.js 作為前端框架，原因是它對 Vercel 支援最好，且支援中間件實作驗證。

在註冊流程中，我們希望使用者先連結他們的錢包，然後透過 X 進行身份驗證，最後透過呼叫我們的端點進行註冊。

我們首先查看 X 驗證 API 文檔，在前端實作一個簡單的註冊頁面，並在後端儲存庫上建立一個註冊端點。

在註冊過程中，我們還需要提取步驟 2) 中的所有資料並將其儲存在資料庫中，並額外新增一個錢包位址項目。所有發送至註冊端點的請求都應同時進行 X 金鑰認證和錢包簽章認證，以防止身分冒充。

一切正常後，我們還需要在代幣部署端點新增身份驗證，以便只有註冊用戶才能部署代幣。對於註冊端點以外的任何端點，我們決定僅透過錢包簽署訊息進行身份驗證，以避免每次都使用 X 登入。

4）隱私設定

完成註冊流程並實現資料儲存後，下一步是開發隱私設定：

在資料庫中建立資料可見性設定表（預設為所有資料皆為私有）；

· 開發已認證使用者可呼叫的隱私設定修改介面；

· 撰寫輔助函數，支援使用者選擇模糊化展示資料；

·編輯元件。

5）介面檢查與最佳化

核心服備就緒後，需做以下優化：

所有伺服器核心功能均已準備就緒，現在我們需要確保所有端點在需要時都使用身份驗證，並且在公開訪問時不會洩露任何個人資訊。我們還可以使用 Redis 快取來優化部分 API，以避免伺服器不必要的負擔。最後，我們添加了幾個 API，用於獲取用戶公開個人資料、代幣所有者及其資料、幣種資料等。

6）前端開發

現在是時候創建一個美觀的網站了。我們先確定主題、要顯示的頁面，並開始移除「私人」部分。對於顯示自訂排序的代幣清單和其他數據，我們可以依賴 Flaunch 的子圖，並根據部署者地址進行過濾，以此作為我們的 EOA。對於代幣詳情頁面，快速顯示圖表的方法是嵌入一個簡單的 DexScreener iframe。

7）測試

一切終於準備就緒。測試使用者流程，將所有內容部署到 Vercel 和 Railway，並與朋友分享存取權以獲取回饋。目標是打造一個與生產環境 1:1 一致的環境。

8）根據回饋最佳化

這是上線前的最後一步。

階段 3：公開上線

公開上線分為兩步驟：先做品牌建設，再進行市場推廣。

品牌建設

之前我沒提品牌建設，是因為它隨時可以做，但最好在前端開發前完成。品牌核心要素（名稱、Logo、配色、網域）需符合「簡潔、易辨識」的原則。

我個人很喜歡的一個玩法是「單字命名 + 網域組合玩梗」：

· 專案名選了「Blind」（意為「盲投」，暗指用戶在資訊有限的情況下購買代幣）； blind」（盲投）、「goblin」（地精，帶點趣味感）、「goblin'd」（地精化）三個意義；

· 配色方案故意選了亮到刺眼的淺色模式，搭配「野獸派」設計風格，讓人聯想到文檔

市場推廣

是時候讓全世界知道我們的 MVP（最小可行產品）了！通常來說，讓別人知道的最好方式不是 直白告知，而是 製造困惑。

困惑行銷

正式推廣前，建議先確保 MVP 功能完整。最好在上線前一周啟動行銷，這樣能將大眾注意力集中在一週內，更易佔據社群平台話題榜。

這一週的核心目標是：

· 讓更多人專注於項目的 X 帳號，並開啟通知；

· 發佈模糊的預告、玩梗內容，但絕不直白透露項目功能；

· 留下「線索」，讓網友在別評論

虛榮指標：讓使用者不再孤單

搭配「困惑行銷」的有效手段是「排行榜」！人們既想「搶先」，又不想「太早入場」。你的任務是「讓平台未上線先『活』起來」。

「註冊 + 排行榜」活動有以下好處：

·事先引導使用者註冊，分散網站流量，測試系統穩定性;

人們喜歡「比別人強」的感覺：排行榜排名容易分享，也能讓用戶發現自己帳號的有趣數據；

· 便於團隊對外宣傳「成長數據」。

Blind 上線前，預註冊用戶就突破了 4 萬人！

附註：若加入「邀請連結」機制，成長速度會更快。

24 小時倒數預告

是時候揭曉 Blind 的核心功能了！文章發佈時請告知他們，這樣他們就能有個具體的時間期待。最後 24 小時，鎖定你對 Blind 內容的猜測。 24 小時讓所有時區的人都能做好準備。

發佈上線文章

此時使用者都在刷新你的 X 帳號首頁，是時候發布文章了！文章中需詳細說明：

· Blind 的核心功能；

· 正式上線時間；

· 無需過於技術化，也不用羅列所有功能，重點「開發動機」「開發動機」

「開引擎計畫」「開引擎計畫」“開發動機”“開引擎”“重點”（p>”“開發動機”“開引擎項目”“重點”（p>”）重點項目（p>“開引擎”“重點”（p>“開發動機”）重點項目（p>“開引擎”“重點”（p>“開發動機”）重點項目（p>“開引擎”“重點”（p>“開發動機”）重點項目（p>“開引擎”“重點”（p>”）重點項目，“開發動機”“開引擎項目”“重點”（p>“開引擎項目”“重點”（p>”“開引擎項目”“重點”（p>“開發動機”）重點項目（p>“開引擎”“重點”；

如需補充技術細節，可在文章外單獨提供文件。

階段 4：正式上線！

文章中需說明「上線時間為文章發布後 24 小時」。此時預先註冊用戶已做好準備，就等部署代幣了。接下來，我們要：

· 將所有環境切換到生產模式；

· 切換部署者 EOA 帳號；

· 隨時待命，應對上線可能發生的錯誤（錯誤總是會發生）。

好了，正式上線！

總結

開發 MVP 時，永遠選擇「阻力最小的路徑」。無需追求一步到位的完美，可在生產環境中逐步迭代優化。抓住時機往往比「等一切準備就緒」更重要。

但也要注意：第一印象至關重要。使用者第一次造訪平台的體驗，會直接決定他們對平台的長期認知，別指望大多數用戶會持續關注「功能更新」。

這個副業專案開發過程非常有趣，我學到了很多，也做了一個「人們可能會用來發行代幣」的工具。

原文連結