3日間で400ドル使ってLaunchpadプラットフォームを構築した

2025.08.29

共有先

TechFlow厳選深潮セレクト

3日間で400ドル使ってLaunchpadプラットフォームを構築した

「アイデア」から「製品」までの私の汎用的なフレームワークを共有します。

2025.08.29 - 10:20:09

Launchpad

Web3業界の深掘り報道に専念し潮流を洞察

「アイデア」から「製品」までの私の汎用的なフレームワークを共有します。

執筆：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が5億ドルのICO資金調達を行い、最近ではheavenも2000万ドルのICO資金を調達したニュースを見てのことでした。私の目には、これらの製品の開発難易度はそれほど高くないのに、なぜこれほど誇張された評価を受けているのかが不思議でした。そして同様の成功事例を持つ発行プラットフォームが他にも多数存在し、巨額の資金を調達していることに気づきました。

公正に言えば、この分野においては合理的な判断を保つために、「トークンの評価論理」にこだわることはもはや意味がありません。多くの場合、評価自体が道理に反しているのです。

しかし、それでもなお私は自分に問いかけました。わずか週末のうちに、極めて低いコストで、外部支援なしに同等レベルの製品を作ることは可能だろうか？

私の目標は商業製品を作ったり、トークンを発行したり、あるいは儲けることではなく、「それが可能である」ことを証明し、より多くの人がこの道を歩んでくれることを願うものです。

段階1：問題の分解

アイデアを得た後、最初のステップはそれを主要な構成要素に分解し、各要素に対して意思決定を行うことです。「ソーシャルアクセス制御付き発行プラットフォーム」の場合、以下のサブ問題を整理しました：

オンチェーン技術スタックの選択

最初の重要な決定は「どのチェーンに展開するか」です。この選択肢はその後のすべての実装工程に影響します。当時、明確な選択肢はSolanaとBaseの二つでした。

Solana

利点：

ドージコイン取引量が最も高いチェーン；
注目効果：ここに展開されるプロジェクトは自然とある程度の注目を集めやすい。

欠点：

柔軟性が低く、既存のトークン基準に従う必要がある；
開発が複雑で、多くの迂回策が必要；
開発期間が長い；
インフラコストが高く、不安定。

Base

利点：

EVM系チェーンの中でも「ドージコイン」取引量が最も高い；
開発者サポートが充実；
EVMでの開発体験が非常に優れている；
既存のインフラをそのまま再利用できる。

欠点：

「ドージコイン」取引量はSolanaに及ばない。

Blindは商業プロジェクトではなく、あくまで週末の練習作品であるため、「潜在的な財務リターン」に関連する意思決定を考慮する必要はありません。開発プロセスが苦痛にならない選択肢を選ぶだけでよいのです。

最終的にEVMを選択しました。ブロックチェーンアプリケーションを開発する際、EVMは最も成熟し、体験の良いインフラであり、迅速かつ効率的、かつ賢明に開発を進めることができます。

再利用可能な既存インフラ

チェーンを決めた後、次のステップはSDK（ソフトウェア開発キット）や既存のコントラクトを探し、ゼロからコードを書く必要を避けることです。特にスマートコントラクトに関しては、監査済みのコントラクトを優先使用することで、セキュリティリスクを大幅に低減できます。

幸運にも、EVMエコシステムには大量の再利用可能なリソースがあります。私たちには主に二つの選択肢がありました：

UniswapなどのDEXに基づいて開発し、Uniswap V4をベースにすべてのアクセス制御ロジックを自前で構築する；
既存の発行プラットフォームのインフラ（例えばFlaunchのSDK）を使用する。このSDKにはインデックス、メタデータアップロード、発行曲線設定、プリセール管理などの機能がすでに組み込まれている。

私たちは再び「抵抗の最も少ない道」を選択しました。FlaunchのSDKをベースにすることで、「発行プラットフォームのソーシャル属性＋フロントエンド表示」に集中でき、流動性プール設定、インデックスインフラ、収益分配コントラクトといった基本機能に時間を費やす必要がなくなります。

「あなたよりも賢い人たちがすでに仕事を終えているなら、なぜ車輪を再発明する必要があるのだろうか？」

トークン展開方法

SDKを確定した後、「誰が実際にトークン展開を実行するか」を決める必要があります。選択肢は二つあります：

案1：ユーザーがトランザクションを発行してトークンを展開

ユーザーが選択した発行パラメータがプラットフォーム要件を満たすことを保証するためのプロキシコントラクトを開発する必要がある；
Flaunchの既存のサブグラフインデクサー内で展開されたすべてのトークンを追跡する方法を見つける必要がある。

案2：ユーザーがバックエンドに「展開リクエスト」を送信し、プラットフォームのロボットが展開を実行

すべてのトークンはプラットフォーム独自のEOA（外部所有アカウント）によって展開され、インデクサー内でプラットフォームが発行したすべてのトークンを簡単に追跡できる；
すべての発行が統一された標準化パラメータに従うことを保証できる。

私たちは「バックエンドサービスによる展開」方式を選びました。これによりトークンの追跡が容易になり、「何をどのように展開するか」の制御をより厳密に行えます。将来のアップグレードの余地も残されます。

すべてのトークンはバックエンドが管理するウォレットによって展開されます。

本質的には、Flaunch SDKを「簡素化」し、不要な機能を削除し、バックエンドからのリクエストで呼び出せる部分だけを残した形です。

ソーシャルデータの収集

次に、ソーシャル機能に焦点を当てます。発行プラットフォームにとって価値のあるデータ次元を特定する必要があります。理想的なデータの組み合わせは、「ユーザーのアカウント状態」と「ユーザーの評判」の両方を反映しているべきです。

最終的に私は以下のデータ次元を選びました：

フォロワー数（XプラットフォームAPI）
フォロー数（XプラットフォームAPI）
アカウント登録期間（XプラットフォームAPI）
いいね数（XプラットフォームAPI）
高価値フォロワー数（Moni API）
主要インタラクションユーザー数（Moni API）
評判スコア（Ethos API）
コンテンツ拡散度スコア（Kaito API）

このような組み合わせにより、クリエイターは完全に身元を明かさずに、多面的なデータを通じて自身の資格を示し、差別化することが可能になります。

ソーシャルデータの処理とプライバシー保護

ユーザー登録時には、上記すべてのデータを収集しますが、プライバシー面ではどのように設計すべきでしょうか？

私たちの原則は「デフォルトでプライバシー優先」です。すべてのデータはデフォルトで非公開とし、漏洩を防ぎます。ユーザーは各データ項目を個別に公開するかどうかを自分で決められます。また、「データのぼかし表示」（実際には4.3万人のフォロワーがいるが、「4万人+」と表示するなど）も可能にし、半匿名のデータ参照を提供します。

さらに、データ処理は「中央集権バックエンド＋HTTPSリクエスト」に頼るべきか、それとも複雑なゼロ知識証明技術を採用すべきか？

私たちの解決策は両者の組み合わせです：

すべてのデータはPostgresデータベースに保存され、フロントエンドはHTTPS APIを通じてデータベースから直接情報を取得します。プリセールのアクセス制御には以下の流れを採用：
ユーザーがプリセール参加を希望 → プラットフォームバックエンドに「アクセス許可証明」をリクエスト；
バックエンドがユーザーがクリエイターが設定した条件を満たしているか検証；
バックエンドが「ユーザーのウォレットアドレス＋有効期限タイムスタンプ」を含む署名メッセージを返信；
スマートコントラクトが署名の有効性を検証。

段階2：開発実装

開発開始前に、必要な「ツールリスト」をまとめておきます：

Railway（バックエンドホスティング）：20ドル/月
Vercel（フロントエンドホスティング）：15ドル/月
Cursor（開発ツール、Claude 4 MAXモード付き）：200ドル/月＋100ドル分クレジット
ウェブサイトドメイン：30ドル/年
X Premium+（アカウント会員、露出向上＋長文投稿用）：40ドル/月
ChatGPT：ロゴやブランドビジュアルのデザインに使用。他の慣れ親しんだツールに置き換え可能

総コストは約405ドル（Vercelのサブスクリプション上限を超えない前提）。

注：開発スピードを上げるために、実際には予想より多くのCursorクレジットを使用しました（MAXモデルを有効化）。開発スピードにこだわらない場合は、より安価なモデルを選べます。

アーキテクチャ設計

ほとんどのプロジェクトには4つの主要コンポーネントが必要です：

フロントエンド：Vercelにホスト（別個のGitHubリポジトリ）；
バックエンド：Railwayにホスト（別個のGitHubリポジトリ）；
データストレージ用データベース：Railway上のPostgresデータベース；
キャッシュ用データベース：Railway上のRedisデータベース。

簡単に言えば、Vercelはフロントエンド関連のすべての機能を担当します。Railwayはデータ処理、トークン展開、APIインターフェース、情報キャッシュなど、「ユーザーに見えない」コアサービスを安全にホストします。

多くのバックエンドアーキテクチャは下記のような形になります（そう、データは「球」の中にあります）。

開発順序

私は常に、まずコア機能を開発し、最後にフロントエンド表示を行うことを推奨しています。

本プロジェクトの場合、最もコアとなる機能（互換性テストも必要となる機能）はトークン発行です。

すでに「バックエンドEOAがトークン展開を実行する」ことを決定しているため、バックエンド用に新しいgitリポジトリを作成し、Flaunch SDKドキュメントの詳細を調べ始めることができます。

このドキュメントには、現在の起動設定で可能なすべての機能が概説されており、統合に便利なコードスニペットも提供されています。また、データ取得用のAPIエンドポイントと、Flaunch上で発生するすべての出来事を自動インデックスするサブグラフも提供されています（Blindのフロントエンドから起動されたトークンも含まれます）。

1）トークン発行機能のテスト

新しいバックエンドリポジトリで、最初のステップはローカル環境を構築し、SDKを使ってトークンを正常に発行できるかテストすることです。まずシンプルなNodeスクリプトを書き、その後これをExpressサーバーのAPIに改造します。このAPIを呼び出して指定パラメータを渡せば、トークン展開が完了します。

このステップは非常に簡単で、おそらく1回のプロンプト＋わずかなデバッグで完了します。

しかも、トークン展開のGas手数料は0.01ドル以下！つまり、ユーザーに完全無料のトークン展開サービスを提供できるということです。

2）ソーシャルデータの取得

第二のステップはもう一つのコア機能である「ソーシャルスコアリング」の開発です。前述のデータ次元すべてについて、それぞれのAPIドキュメントを確認し、Expressサーバーにエンドポイントを作成します。このエンドポイントはユーザー名に基づいてすべてのデータを返します。その後、これらのデータをRailway上に作成したPostgresデータベースに保存します。

3）登録フロー

この段階になると、開発はやや複雑になり、フロントエンドリポジトリの開発も並行して進める必要があります。フロントエンドフレームワークにはNext.jsを選んだ理由は、Vercelとの最高の互換性と、ミドルウェアによる認証サポートがあるためです。

登録フローでは、ユーザーがまずウォレットを接続し、次にXで本人認証を行い、最後に当社のエンドポイントを呼び出して登録することを目指します。

まずXの認証APIドキュメントを確認し、フロントエンドにシンプルな登録ページを実装し、バックエンドリポジトリに登録エンドポイントを作成します。

登録プロセス中に、ステップ2）で取得したすべてのデータを抽出し、データベースに保存すると同時に、ウォレットアドレスのエントリも追加します。登録エンドポイントへのすべてのリクエストは、Xキー認証とウォレット署名認証の両方を経る必要があります。これはなりすましを防ぐためです。

すべて正常に動作したら、トークン展開エンドポイントにも認証を追加し、登録ユーザーのみがトークンを展開できるようにします。登録エンドポイント以外のエンドポイントについては、毎回Xログインを行うのを避けるため、ウォレット署名メッセージのみによる認証を採用することにしました。

4）プライバシー設定

登録フローを完成させ、データ保存を実装した後、次のステップはプライバシー設定の開発です：

データベース内にデータ可視性設定テーブルを作成（デフォルトではすべてのデータが非公開）；
認証済みユーザーが呼び出せるプライバシー設定変更APIを開発；
ユーザーがデータのぼかし表示を選択できる補助関数を作成；
フロントエンドのプライバシー設定編集コンポーネントを開発。

5）インターフェースチェックと最適化

コアサービスが準備できた後、以下の最適化を行います：

すべてのサーバーコア機能が準備完了しました。次に、必要なときにすべてのエンドポイントが認証を使用しており、公開アクセス時に個人情報を漏らさないことを確認する必要があります。また、Redisキャッシュを使用して一部のAPIを最適化し、サーバーに不要な負荷がかからないようにします。最後に、ユーザーの公開プロフィール、トークン所有者およびそのデータ、通貨データなどを取得するためのいくつかのAPIを追加しました。

6）フロントエンド開発

ようやく美しく魅力的なウェブサイトを作成する時が来ました。テーマと表示するページを決定し、「非公開」部分の削除を始めます。カスタムソートされたトークンリストやその他のデータを表示するには、Flaunchのサブグラフを利用し、展開者アドレスでフィルタリングすることで、EOAとして使用できます。トークン詳細ページでは、チャートを素早く表示するために、シンプルなDexScreenerのiframeを埋め込みます。

7）テスト

すべてがついに準備完了です。ユーザーフローをテストし、すべての内容をVercelとRailwayにデプロイし、友人とアクセス権を共有してフィードバックを得ます。目標は、本番環境と1:1で一致する環境を作ることです。

8）フィードバックに基づく最適化

これがローンチ前の最終ステップです。

段階3：公開ローンチ

公開ローンチは二段階に分けられます。まずブランディングを行い、次にマーケティングを実施します。

ブランディング

これまでブランディングに触れてこなかったのは、いつでも行えるが、フロントエンド開発前に完了するのが望ましいためです。ブランドの核心要素（名称、ロゴ、配色、ドメイン）は「シンプルで識別しやすい」原則を満たす必要があります。

私が特に好きな手法は「一字ネーミング＋ドメインの語呂合わせ」です：

プロジェクト名は「Blind」（「盲目的投資」を意味し、情報が限られた状況でユーザーがトークンを購入することを暗示）；
ドメインはgoblind.xyzを選択。これは「go blind」（盲目になる）、「goblin」（ゴブリン、遊び心がある）、「goblin'd」（ゴブリン化）の三つの意味を巧みに融合；
配色は意図的にまぶしいほどのライトモードを採用し、「表現主義」的なデザインスタイルで、点字文書を連想させ、テーマ「Blind」に呼応；
ロゴデザイン：ChatGPTで生成（既存のテーマを背景プロンプトとして使用）；