English العربية Deutsch Español Français हिन्दी Italiano 日本語 한국어 Português (BR) Русский Türkçe 中文

モジュール E：実行プレイブック

STREETS 開発者収入コース — 有料モジュール 第9-10週 | 6レッスン | 成果物：あなたの最初の製品、公開済みで決済受付中

「アイデアからデプロイまで48時間。考えすぎない。」

あなたにはインフラがある（モジュール S）。堀がある（モジュール T）。収益エンジンの設計がある（モジュール R）。今こそ出荷する時だ。

このモジュールは、ほとんどの開発者がたどり着けない場所だ——難しいからではなく、まだコードベースを磨いたり、アーキテクチャをリファクタリングしたり、カラーパレットを微調整しているからだ。本当に重要なこと以外のすべてをやっている：つまり、お金を払える人間の前に製品を置くことだ。

出荷はスキルだ。あらゆるスキルと同様に、練習すれば楽になり、先延ばしにすれば難しくなる。待てば待つほど難しくなる。出荷すればするほど怖くなくなる。最初のローンチは雑になる。それがポイントだ。

この2週間が終わるまでに、あなたは以下を手にする：

仮定なし。「理論的には」なし。実際の製品が、インターネット上でライブで、収益を生み出せる状態になる。

モジュール R をまだ完了していなくても、このモジュールは使える——ただし、収益エンジンの設計が準備できていれば、48時間スプリントは大幅にスムーズになる。

さあ、作ろう。

レッスン 1：48時間スプリント

「土曜の朝から日曜の夜まで。製品は1つ。言い訳はゼロ。」

なぜ48時間なのか

パーキンソンの法則によれば、仕事は使える時間に合わせて膨張する。製品を作るのに6ヶ月与えれば、5ヶ月を議論に費やし、1ヶ月をストレスまみれの猛ダッシュに使うことになる。48時間与えれば、決断を下し、スコープを容赦なく削り、実際に動くものを出荷するようになる。

48時間の制約は、完璧なものを作ることではない。存在するものを作ることだ。存在は常に完璧に勝る。なぜなら、ライブ製品はデータを生み出すからだ——誰が訪問し、誰がクリックし、誰が支払い、誰が文句を言うか——そしてデータが次に何を作るべきかを教えてくれる。

私が研究してきたすべての成功した開発者製品はこのパターンに従っていた：素早く出荷し、素早く学び、素早く反復する。失敗したものは？全員が美しいREADMEファイルを持ち、ユーザーはゼロだった。

以下が分刻みのプレイブックだ。

1日目 — 土曜日

午前ブロック（4時間）：需要を検証する

コードを1行も書く前に、あなた以外の誰かがこのものを欲しがっているという証拠が必要だ。確信ではなく——証拠だ。この違いは重要だ。確信は不可能だ。証拠は4時間で達成できる。

ステップ 1：検索ボリュームチェック（45分）

以下のソースにアクセスし、製品アイデアと関連用語を検索する：

探しているもの：

良いシグナル：
- コアキーワードの月間検索数500以上
- 過去12ヶ月で上昇トレンド
- 良い回答のない「他の人はこちらも質問」が複数ある
- 競合の少ないロングテールキーワードの関連語


悪いシグナル：
- 検索関心度の低下
- 検索ボリュームがゼロ（誰もこれを探していない）
- 1ページ目が巨大企業に支配されている
- 検索用語にバリエーションがない（狭すぎる）

実例：モジュール R の収益エンジンアイデアが「SaaSダッシュボード向けTailwind CSSコンポーネントライブラリ」だとする。

検索: "tailwind dashboard components" — 月間2,900、上昇トレンド
検索: "tailwind admin template" — 月間6,600、安定
検索: "react dashboard template tailwind" — 月間1,300、上昇
関連: "shadcn dashboard", "tailwind analytics components"

判定: 需要が強い。複数のキーワード角度あり。続行。

別の例：アイデアが「Rustベースのログファイル匿名化ツール」だとする。

検索: "log file anonymizer" — 月間90、横ばい
検索: "anonymize log files" — 月間140、横ばい
検索: "PII removal from logs" — 月間320、上昇
関連: "GDPR log compliance", "scrub PII from logs"

判定: ニッチだが成長中。「PII removal」の角度が「anonymizer」の角度
より多くのボリュームがある。ポジショニングを再設定せよ。

ステップ 2：コミュニティスレッドマイニング（60分）

開発者が要望を出す場所に行き、あなたの問題領域を検索する：

記録するもの：

## スレッドマイニング結果

### スレッド 1
- **出典:** Reddit r/reactjs
- **URL:** [リンク]
- **タイトル:** "Is there a good Tailwind dashboard kit that isn't $200?"
- **アップボート:** 147
- **コメント:** 83
- **主要な引用:**
  - "Everything on the market is either free and ugly, or $200+ and overkill"
  - "I just need 10-15 well-designed components, not 500"
  - "Would pay $49 for something that actually looks good out of the box"
- **ポイント:** $200以上に対する価格感度、$29-49での支払い意欲あり

### スレッド 2
- ...

少なくとも5つのスレッドを見つけよう。もし製品の領域で何かを求めている5つのスレッドが見つからなければ、それは深刻な警告サインだ。需要が存在しないか、間違った用語で検索しているかだ。アイデアを諦める前に、異なるキーワードを試してみよう。

ステップ 3：競合調査（45分）

すでに存在するものを検索する。これは気落ちすることではない——検証だ。競合がいるということは市場があるということだ。競合がいないということは普通、ブルーオーシャンを見つけたのではなく、市場がないということだ。

各競合について記録する：

## 競合調査

### 競合 1: [名前]
- **URL:** [リンク]
- **価格:** $XX
- **彼らの優れている点:** [具体的なこと]
- **彼らのダメな点:** [レビュー/スレッドからの具体的な不満]
- **彼らのレビュー:** [G2、ProductHuntレビュー、Redditでの言及をチェック]
- **あなたの角度:** [あなたならどう違うことをするか]

### 競合 2: [名前]
- ...

金脈は「彼らのダメな点」にある。競合に対するすべての不満は、あなたの製品への機能リクエストだ。人々が文字通り、何を作るべきか、いくら請求すべきかを教えてくれている。

ステップ 4：「10人が支払う」テスト（30分）

これが最終的な検証ゲートだ。少なくとも10人がこれにお金を払うという証拠が必要だ。「関心を示した」ではない。「クールだと言った」でもない。支払うという証拠だ。

証拠のソース：

このテストに合格したら：続行。作ろう。

このテストに失敗したら：アイデア全体ではなく、角度を転換しよう。需要は隣接する領域に存在するかもしれない。諦める前に異なるポジショニングを試そう。

本音： ほとんどの開発者はコーディングしたいから検証を完全にスキップする。誰も頼んでいないものを200時間かけて作り、なぜ誰も買わないのかと不思議に思う。この4時間のリサーチは196時間の無駄な努力を節約してくれる。スキップするな。コードは簡単な部分だ。

午後ブロック（4時間）：MVPを作る

需要を検証した。競合リサーチがある。人々が何を求めていて、既存のソリューションに何が足りないかを知っている。さあ、コアの問題を解決する最小バージョンを作ろう。

3機能ルール

v0.1は正確に3つの機能を持つ。4つでも7つでもない。3つだ。

選び方：

  1. あなたの製品が行う1つのことは何か？（機能1 — コア）
  2. それを使えるようにするものは何か？（機能2 — 通常は認証、保存/エクスポート、設定）
  3. 代替品より支払う価値があるものは何か？（機能3 — 差別化要因）

それ以外はすべて「v0.2」リストに入れ、この週末は触れない。

実例 — Tailwindダッシュボードコンポーネントライブラリ：

  1. コア: 12個の本番対応ダッシュボードコンポーネント（チャート、テーブル、統計カード、ナビゲーション）
  2. 使いやすさ: ライブプレビュー付きのコピペ可能なコードスニペット
  3. 差別化: ダークモード内蔵、コンポーネントが連携して動作するよう設計（ランダムな寄せ集めではない）

実例 — PII ログスクラバー CLIツール：

  1. コア: ログファイルからPIIを検出・除去（メール、IP、名前、SSN）
  2. 使いやすさ: CLIパイプとして動作（cat logs.txt | pii-scrub > clean.txt）
  3. 差別化: 設定可能なルールファイル、15以上のログ形式を自動処理

プロジェクトをスキャフォールドする

LLMを使って作業を加速させよう。置き換えるのではなく。実践的なワークフローはこうだ：

# Webアプリをスキャフォールド（SaaSツール、ドキュメントサイト付きコンポーネントライブラリなど）
pnpm create vite@latest my-product -- --template react-ts
cd my-product
pnpm install

# Tailwind CSSを追加（開発者製品で最も一般的）
pnpm install -D tailwindcss @tailwindcss/vite

# 複数ページが必要な場合はルーティングを追加
pnpm install react-router-dom

# プロジェクト構造 — 48時間ビルドではフラットに保つ
mkdir -p src/components src/pages src/lib

# CLIツールをスキャフォールド（開発者ユーティリティ向け）
cargo init my-tool
cd my-tool

# CLIツールの一般的な依存関係
cargo add clap --features derive    # 引数パース
cargo add serde --features derive   # シリアライゼーション
cargo add serde_json                # JSON処理
cargo add anyhow                    # エラー処理
cargo add regex                     # パターンマッチング

# npmパッケージをスキャフォールド（ライブラリ/ユーティリティ向け）
mkdir my-package && cd my-package
pnpm init
pnpm install -D typescript tsup vitest
mkdir src

ビルドのためのLLMワークフロー

LLMに製品全体を作らせないこと。それは汎用的で脆弱なコードを生む。代わりに：

  1. あなたがアーキテクチャを書く：ファイル構造、データフロー、主要なインターフェース
  2. LLMがボイラープレートを生成：繰り返しのコンポーネント、ユーティリティ関数、型定義
  3. あなたがコアロジックを書く：あなたの製品を差別化する部分
  4. LLMがテストを生成：ユニットテスト、エッジケース、統合テスト
  5. あなたがすべてをレビュー・編集：あなたの名前がこの製品に刻まれる

コーディング中の並行作業：2つ目のLLMチャットを開き、ランディングページのコピー、README、ドキュメントを下書きさせよう。夜に編集するが、最初の草案は準備できている。

時間規律

午後 2:00 — 機能 1（コア機能）：2時間
           午後4時までに動かなければ、スコープを削れ。
午後 4:00 — 機能 2（使いやすさ）：1時間
           シンプルに。磨きは後で出荷する。
午後 5:00 — 機能 3（差別化要因）：1時間
           これがあなたに支払う価値を与えるもの。ここに集中せよ。
午後 6:00 — コーディングを止めよ。完璧である必要はない。

よくあるミス： 「やめる前にもう1つだけ機能を。」これが週末プロジェクトを月単位のプロジェクトにする方法だ。3つの機能があなたのスコープだ。ビルド中に素晴らしいアイデアを思いついたら、v0.2リストに書き留めて先に進め。有料顧客ができてから来週追加できる。

夜ブロック（2時間）：ランディングページを書く

ランディングページの仕事は1つ：訪問者に支払いを納得させること。美しい必要はない。明確である必要がある。

5セクション ランディングページ

成功する開発者製品のランディングページはすべてこの構造に従う。再発明するな：

セクション 1：見出し + サブ見出し
  - 8語以下で何をするか
  - 誰のためで、どんな結果を得られるか

セクション 2：問題
  - ターゲット顧客が認識する3つのペインポイント
  - スレッドマイニングからの彼ら自身の言葉を使う

セクション 3：解決策
  - 製品のスクリーンショットまたはコード例
  - 上記3つのペインポイントに対応する3つの機能

セクション 4：料金
  - 1つまたは2つのプラン。v0.1ではシンプルに。
  - サブスクリプションの場合は年払いオプション。

セクション 5：CTA（行動喚起）
  - ボタン1つ。「始める」「今すぐ購入」「ダウンロード」。
  - コアの利点を繰り返す。

実際のコピー例 — Tailwindダッシュボードキット：

# セクション 1
## DashKit — 本番対応 Tailwind ダッシュボードコンポーネント
SaaSダッシュボードを数週間ではなく数時間で出荷。
コピペ可能な12コンポーネント。ダークモード。$29。

# セクション 2
## 問題
- 汎用UIキットは500コンポーネントあるが一貫性ゼロ
- ダッシュボードUIをゼロから構築すると40時間以上かかる
- 無料オプションは2018年のBootstrapのように見える

# セクション 3
## 含まれるもの
- **12コンポーネント** 連携して動作するよう設計（ランダムな寄せ集めではない）
- **ダークモード** 内蔵 — 1つのpropで切り替え
- **コピペコード** — npm installなし、依存関係なし、ロックインなし
[コンポーネント例のスクリーンショット]

# セクション 4
## 料金
**DashKit** — $29 一括払い
- 全12コンポーネントとソースコード
- 12ヶ月間の無料アップデート
- 無制限プロジェクトで使用可能

**DashKit Pro** — $59 一括払い
- DashKitの全機能
- 8つのフルページテンプレート（アナリティクス、CRM、管理、設定）
- Figmaデザインファイル
- 優先機能リクエスト

# セクション 5
## 今週末にダッシュボードを出荷しよう。
[DashKitを購入 — $29]

実際のコピー例 — PII ログスクラバー：

# セクション 1
## ScrubLog — 数秒でログファイルからPIIを除去
あなたのログのGDPR準拠。コマンド1つで。

# セクション 2
## 問題
- あなたのログには保存すべきでないメール、IP、名前が含まれている
- 手動で墨消しすると数時間かかり、漏れも出る
- エンタープライズツールは月額$500かかり、設定に博士号が必要

# セクション 3
## 仕組み
```bash
cat server.log | scrublog > clean.log

セクション 4

料金

Personal — 無料

Pro — $19/月

セクション 5

不要なPIIの保存をやめよう。

[ScrubLog Proを入手 — $19/月]


**コピーのためのLLMワークフロー：**

1. LLMに競合調査とスレッドマイニングの結果を入力する
2. 5セクションテンプレートを使ってランディングページコピーの下書きを依頼する
3. 容赦なく編集する：すべての曖昧な表現を具体的なものに置き換える
4. 声に出して読む。どの文章でも気恥ずかしければ、書き直す。

**ランディングページを構築する：**

48時間スプリントでは、カスタムランディングページをゼロから構築するな。以下のいずれかを使う：


- **あなたの製品自身のサイト** — Webアプリなら、ランディングページをログアウト時ホームページにする
- **Astro + Tailwind** — 静的サイト、2分でVercelにデプロイ、非常に高速
- **Next.js** — 製品がすでにReactなら、マーケティングページルートを追加
- **Framer** (https://framer.com) — ビジュアルビルダー、クリーンなコードをエクスポート、無料プランあり
- **Carrd** (https://carrd.co) — 年額$19、シンプルな1ページサイト

```bash
# 最速の道：Astro静的サイト
pnpm create astro@latest my-product-site
cd my-product-site
pnpm install
# Tailwindを追加
pnpm astro add tailwind

土曜日の終わりまでにコピー付きのランディングページを持っているべきだ。カスタムイラストは不要。アニメーションも不要。明確な言葉と購入ボタンが必要だ。

2日目 — 日曜日

午前ブロック（3時間）：デプロイ

製品は本物のURLでインターネット上にライブである必要がある。localhostではない。ランダムハッシュ付きのVercelプレビューURLでもない。本物のドメインで、HTTPSで、共有でき、人々が訪問できる。

ステップ 1：アプリケーションをデプロイ（60分）

作ったものに基づいてデプロイプラットフォームを選択する：

静的サイト / SPA（コンポーネントライブラリ、ランディングページ、ドキュメントサイト）：

# Vercel — 静的サイトとNext.jsへの最速パス
pnpm install -g vercel
vercel

# 質問されるので、すべてに「はい」と答える。
# サイトは約60秒でライブになる。

バックエンドを持つWebアプリ（SaaSツール、APIサービス）：

# Railway — シンプル、良い無料プラン、データベース対応
# https://railway.app
# GitHubリポジトリを接続してデプロイ。

# またはFly.io — より多くのコントロール、グローバルエッジデプロイ
# https://fly.io
curl -L https://fly.io/install.sh | sh
fly launch
fly deploy

CLIツール / npmパッケージ：

# npmレジストリ
npm publish

# またはGitHub Releasesでバイナリとして配布
# Rustプロジェクトにはcargo-distを使用
cargo install cargo-dist
cargo dist init
cargo dist build
# バイナリをGitHubリリースにアップロード

ステップ 2：ドメインを購入（30分）

本物のドメインは年間$12だ。ビジネスに$12を投資できないなら、ビジネスを持つことに本気ではない。

購入先：

ドメイン名のヒント：

# ドメインをVercelに向ける
# Vercelダッシュボードで：Settings > Domains > ドメインを追加
# 次にレジストラのDNS設定で以下を追加：
# Aレコード: @ -> 76.76.21.21
# CNAMEレコード: www -> cname.vercel-dns.com

# またはCloudflareでDNSを使う場合：
# Cloudflare DNSパネルで同じレコードを追加するだけ
# SSLはVercelでもCloudflareでも自動

ステップ 3：基本モニタリング（30分）

2つのことを知る必要がある：サイトは稼働しているか、人々は訪問しているか。

アップタイムモニタリング（無料）：

モニタリング設定対象：
1. ランディングページURL
2. アプリのヘルスエンドポイント（該当する場合）
3. 決済Webhook URL（重要——決済が壊れたら知る必要がある）

アナリティクス（プライバシー重視）：

Google Analyticsは使うな。開発者オーディエンスはそれをブロックするし、新製品には過剰だし、プライバシー上の問題がある。

<!-- Plausible — <head>に1行 -->
<script defer data-domain="yourdomain.com"
  src="https://plausible.io/js/script.js"></script>

<!-- Umami — <head>に1行 -->
<script defer
  src="https://your-umami-instance.com/script.js"
  data-website-id="your-website-id"></script>

本音： そう、まだ収益のない製品にアナリティクスで月額$9は不要に感じる。しかし、測定できないものは改善できない。最初の1ヶ月のアナリティクスデータは、1ヶ月の推測よりも市場について多くを教えてくれる。月額$9が予算を圧迫するなら、RailwayでUmamiを無料でセルフホストしよう。

午後ブロック（2時間）：決済をセットアップ

製品がお金を受け取れないなら、それは趣味のプロジェクトだ。決済のセットアップはほとんどの開発者が思うより時間がかからない——基本フローで約20-30分だ。

オプション A：Lemon Squeezy（デジタル製品に推奨）

Lemon Squeezy (https://lemonsqueezy.com) は、決済処理、消費税、VAT、デジタルデリバリーを1つのプラットフォームで処理する。ゼロから決済受付までの最速パスだ。

最初の製品でStripeよりLemon Squeezyを選ぶ理由：

セットアップ手順：

  1. https://app.lemonsqueezy.com でサインアップ
  2. ストアを作成（ビジネス名）
  3. 製品を追加：
    • 名前、説明、価格
    • デジタルデリバリー用ファイルをアップロード（該当する場合）
    • ライセンスキーを設定（ソフトウェア販売の場合）
  4. チェックアウトURLを取得——これが「購入」ボタンのリンク先
  5. 購入後自動化のためのWebhookを設定
// Lemon Squeezy Webhookハンドラー (Node.js/Express)
// POST /api/webhooks/lemonsqueezy

import crypto from 'crypto';

const WEBHOOK_SECRET = process.env.LEMONSQUEEZY_WEBHOOK_SECRET;

export async function handleLemonSqueezyWebhook(req, res) {
  // Webhook署名を検証
  const signature = req.headers['x-signature'];
  const hmac = crypto.createHmac('sha256', WEBHOOK_SECRET);
  const digest = hmac.update(JSON.stringify(req.body)).digest('hex');

  if (signature !== digest) {
    return res.status(401).json({ error: 'Invalid signature' });
  }

  const event = req.body;

  switch (event.meta.event_name) {
    case 'order_created': {
      const order = event.data;
      const customerEmail = order.attributes.user_email;
      const productId = order.attributes.first_order_item.product_id;
      const orderId = order.id;

      console.log(`New order: ${orderId} from ${customerEmail}`);

      // ウェルカムメール送信、アクセス付与、ライセンスキー作成など
      await grantProductAccess(customerEmail, productId);
      await sendWelcomeEmail(customerEmail, orderId);

      break;
    }

    case 'subscription_created': {
      const subscription = event.data;
      const customerEmail = subscription.attributes.user_email;

      console.log(`New subscription from ${customerEmail}`);
      await createSubscription(customerEmail, subscription);

      break;
    }

    case 'subscription_cancelled': {
      const subscription = event.data;
      const customerEmail = subscription.attributes.user_email;

      console.log(`Subscription cancelled: ${customerEmail}`);
      await revokeAccess(customerEmail);

      break;
    }

    default:
      console.log(`Unhandled event: ${event.meta.event_name}`);
  }

  return res.status(200).json({ received: true });
}

オプション B：Stripe（より多くのコントロール、より多くの作業）

Stripe (https://stripe.com) はより多くのコントロールを提供するが、税金コンプライアンスを別途処理する必要がある。複雑な課金を持つSaaSに適している。

// Stripe Checkoutセッション (Node.js)
// ホスト型チェックアウトページを作成

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

export async function createCheckoutSession(req, res) {
  const session = await stripe.checkout.sessions.create({
    payment_method_types: ['card'],
    line_items: [
      {
        price_data: {
          currency: 'usd',
          product_data: {
            name: 'DashKit Pro',
            description: '12 Tailwind dashboard components + 8 templates + Figma files',
          },
          unit_amount: 5900, // $59.00（セント単位）
        },
        quantity: 1,
      },
    ],
    mode: 'payment', // 定期課金には'subscription'
    success_url: `${process.env.DOMAIN}/success?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${process.env.DOMAIN}/pricing`,
    customer_email: req.body.email, // 持っている場合は事前入力
  });

  return res.json({ url: session.url });
}

// Stripe Webhookハンドラー
export async function handleStripeWebhook(req, res) {
  const sig = req.headers['stripe-signature'];

  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body, // 生のボディ、パース済みJSONではない
      sig,
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    console.error(`Webhook signature verification failed: ${err.message}`);
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  switch (event.type) {
    case 'checkout.session.completed': {
      const session = event.data.object;
      await fulfillOrder(session);
      break;
    }
    case 'customer.subscription.deleted': {
      const subscription = event.data.object;
      await revokeSubscriptionAccess(subscription);
      break;
    }
  }

  return res.json({ received: true });
}

両プラットフォーム共通 — ローンチ前にテスト：

# Lemon Squeezy：ダッシュボードでテストモードを使用
# Lemon Squeezyダッシュボードの右上で「Test mode」を切り替え
# カード番号: 4242 4242 4242 4242、任意の将来の有効期限、任意のCVCを使用

# Stripe：テストモードAPIキーを使用
# テストカード: 4242 4242 4242 4242
# テスト拒否カード: 4000 0000 0000 0002
# 認証が必要なテストカード: 4000 0025 0000 3155

テストモードで購入フロー全体を自分で実行しよう。購入ボタンをクリックし、チェックアウトを完了し、Webhookが発火することを確認し、アクセスが付与されることを確認する。テストモードでいずれかのステップが失敗すれば、本番の顧客でも失敗する。

よくあるミス： 「ユーザーを集めてから後で決済を設定しよう。」これは逆だ。決済を設定するのは今日お金を集めるためではない——誰かが支払うかどうかを検証するためだ。価格のない製品は無料ツールだ。価格のある製品はビジネステストだ。価格自体が検証の一部だ。

夜ブロック（3時間）：ローンチ

製品はライブだ。決済は機能する。ランディングページは明確だ。今、人間に見てもらう必要がある。

ソフトローンチ戦略

最初の製品で「ビッグローンチ」はするな。ビッグローンチは完璧でなければならないというプレッシャーを生み、v0.1は完璧ではない。代わりにソフトローンチをしよう：いくつかの場所でシェアし、フィードバックを集め、重大な問題を修正してから、1-2週間後にビッグローンチをする。

ローンチプラットフォーム 1：Reddit（30分）

r/SideProject と製品に関連するニッチなサブレディット1つに投稿する。

Reddit投稿テンプレート：

Title: I built [何をするか] in a weekend — [主要な利点]

Body:
Hey [サブレディット名],

I've been frustrated with [問題] for a while, so I built
[製品名] this weekend.

**What it does:**
- [機能 1 — コアの価値]
- [機能 2]
- [機能 3]

**What makes it different from [競合]:**
[差別化要因についての正直な1段落]

**Pricing:**
[透明に。"$29 one-time" または "Free tier + $19/mo Pro"]

I'd love feedback. What am I missing? What would make this
useful for your workflow?

[製品へのリンク]

Reddit投稿のルール：

ローンチプラットフォーム 2：Hacker News（30分）

製品が技術的で興味深いなら、Show HNを投稿する。「技術的詳細」セクションで、あなたのスタック（your primary stack）に言及し、なぜそれを選んだか説明しよう——HNの読者は情報に基づいた技術的判断を好む。

Show HN テンプレート：

Title: Show HN: [製品名] – [何をするか、70文字未満]

Body:
[製品名] is [何をするかの1文説明].

I built this because [本心からの動機——自分自身のために
解決していた問題].

Technical details:
- Built with [スタック]
- [興味深い技術的判断とその理由]
- [実装の注目に値する点]

Try it: [URL]

Feedback welcome. I'm particularly interested in [HNオーディエンスへの
具体的な質問].

HNのヒント：

ローンチプラットフォーム 3：Twitter/X（30分）

ビルドインパブリックのローンチスレッドを書く：

ツイート 1（フック）：
I built [製品] in 48 hours this weekend.

It [特定の問題を解決] for [特定のオーディエンス].

Here's what I shipped, what I learned, and the real numbers. Thread:

ツイート 2（問題）：
The problem:
[ペインポイントを2-3文で説明]
[痛みを示すスクリーンショットまたはコード例を含める]

ツイート 3（解決策）：
So I built [製品名].

[動作中の製品のスクリーンショット/GIF]

It does three things:
1. [機能 1]
2. [機能 2]
3. [機能 3]

ツイート 4（技術的詳細）：
Tech stack for the nerds:
- [フロントエンド]
- [バックエンド]
- [ホスティング — 具体的なプラットフォームを記載]
- [決済 — Lemon Squeezy/Stripeを記載]
- Total cost to run: $XX/month

ツイート 5（料金）：
Pricing:
[明確な料金、ランディングページと同じ]
[製品へのリンク]

ツイート 6（お願い）：
Would love feedback from anyone who [ターゲットユーザーの説明].

What am I missing? What would make this a must-have for you?

ローンチプラットフォーム 4：関連コミュニティ（30分）

ターゲットオーディエンスがたむろしている2-3のコミュニティを特定する：

ローンチ後最初の48時間 — 何を監視するか：

追跡すべきメトリクス：
1. ユニーク訪問者（アナリティクスから）
2. ランディングページ → チェックアウトクリック率（2-5%であるべき）
3. チェックアウト → 購入コンバージョン率（1-3%であるべき）
4. 直帰率（80%を超える場合、見出し/ヒーローが間違っている）
5. トラフィックソース（訪問者はどこから来ているか？）
6. コメントとフィードバック（定性的——人々は何と言っているか？）

計算例：
- 48時間で500訪問者（Reddit + HN + Twitterからの合理的な数字）
- 3%が「購入」をクリック = 15チェックアウト訪問
- 10%が購入完了 = 1-2件の売上
- $29/件 = 最初の週末で$29-58

これは引退するためのお金ではない。検証のためのお金だ。
インターネット上の見知らぬ人からの$29は、あなたの製品に価値があることを証明する。

最初の48時間で売上がゼロでもパニックするな。ファネルを見よう：

これらにはそれぞれ異なる修正がある。だからメトリクスが重要なのだ。

あなたの番

  1. 時間をブロックしよう。 今すぐカレンダーを開いて、次の土曜日の午前8時から午後8時と日曜日の午前8時から午後8時をブロックしよう。「48時間スプリント」とラベルを付けよう。予約変更できないフライトのように扱おう。

  2. アイデアを選ぼう。 モジュール R から収益エンジンを1つ選べ。v0.1の3機能スコープを書き留めよう。1つに絞れないなら、非開発者に1文で説明できるものを選べ。

  3. 事前準備。 土曜日の前に、以下でアカウントを作成しよう：

    • Vercel、Railway、またはFly.io（デプロイ）
    • Lemon SqueezyまたはStripe（決済）
    • Namecheap、Cloudflare、またはPorkbun（ドメイン）
    • Plausible、Fathom、またはUmami（アナリティクス）
    • Better UptimeまたはUptimeRobot（モニタリング）

    平日の夜にやっておけば、土曜日はアカウント作成ではなく純粋なビルドに使える。

  4. ローンチプラットフォームを準備しよう。 ある程度のカルマを持つRedditアカウントがなければ、今週から関連するサブレディットに参加し始めよう。自己宣伝だけを投稿するアカウントはフラグが立てられる。Hacker Newsアカウントがなければ、作成していくつかの議論に参加しておこう。

レッスン 2：「出荷してから改善」マインドセット

「3機能のv0.1は、一度も出荷されないv1.0に勝る。」

完璧主義の罠

開発者は特定の失敗モードに特に影響されやすい：永遠にプライベートで作り続けること。我々は「良いコード」がどういうものか知っている。v0.1が良いコードではないことも知っている。だからリファクタリングする。エラー処理を追加する。テストをもっと書く。アーキテクチャを改善する。重要なこと以外のすべてをやっている：人間に見せることだ。

何千時間も節約する真実がここにある：顧客はあなたのソースコードを読まない。 アーキテクチャも気にしない。テストカバレッジも気にしない。気にすることは1つだけ：これは私の問題を解決するか？

スパゲッティコードだが実際の問題を解決する製品はお金を稼ぐ。美しいアーキテクチャだが問題を解決しない製品は何も稼がない。

これは悪いコードを書く言い訳ではない。優先順位の声明だ。まず出荷。次にリファクタリング。リファクタリングは実際の使用データによってより良く情報化されるからだ。

「出荷してから改善」がどう展開するか

このシナリオを考えてみよう：ある開発者がソフトウェアエンジニアリングマネージャー向けのNotionテンプレートパックをローンチする。ローンチ時の状態はこうだ：

RedditとTwitterに投稿する。これがマーケティング戦略の全てだ。

1ヶ月目の結果：

「完璧」だったか？いいえ。テンプレートにはフォーマットの不一致があった。説明の一部は汎用的だった。顧客は気にしなかった。テンプレートを自分で作る手間から解放されることを気にしていた。

3ヶ月目までに、顧客フィードバックに基づいて、開発者は：

ローンチした製品は、90日後の製品と比べてあらゆる面で劣っていた。しかし90日目のバージョンは、ローンチバージョンが開発を導くフィードバックと収益を生み出したからこそ存在した。

注： 「醜くても出荷し、素早く改善する」モデルの実世界での検証として：Josh Comeauは CSS for JavaScript Developers コースの最初の1週間で$550Kを先行販売した（出典：failory.com）。Wes Bosはイテレーティブなローンチを使って合計$10M以上の開発者コース売上を達成した（出典：foundershut.com）。両者とも不完全なv1製品からスタートし、実際の顧客フィードバックに基づいてイテレーションした。

最初の10人の顧客がすべてを教えてくれる

最初の10人の有料顧客は、あなたのビジネスで最も重要な人たちだ。お金のためではない——10件の売上で$29ずつなら$290、それは食料品を買う程度だ。彼らが重要なのは、あなたの製品開発チームへのボランティアだからだ。

最初の10人の顧客にやるべきこと：

  1. 個人的なお礼メールを送る。 自動化ではない。個人的なもの。「こんにちは、[製品]を購入いただいたのを見ました。ありがとうございます。これを積極的に開発中です——現在できないことで、やってほしいことはありますか？」

  2. すべての返信を読む。 返信しない人もいる。「いい感じ、ありがとう」と返信する人もいる。しかし10人中2-3人が、欲しいものについて長文を書いてくれる。その長文があなたのロードマップだ。

  3. パターンを探す。 10人中3人が同じ機能を求めたら、それを作れ。有料顧客からの30%の需要シグナルだ。どんなアンケートもこれほど良いデータは与えてくれない。

  4. 追加支払いの意欲を聞く。 「[機能X]付きのProプランを計画しています。$49の価値はありますか？」直接的。具体的。価格データが得られる。

最初の10人の顧客へのメールテンプレート：

件名: Quick question about [製品名]

Hey [名前],

I noticed you picked up [製品名] — thanks for being
one of the first customers.

I'm building this actively and shipping updates weekly.
Quick question: what's the ONE thing you wish it did that
it doesn't?

No wrong answers. Even if it seems like a big ask,
I want to hear it.

Thanks,
[あなたの名前]

ネガティブフィードバックの対処法

最初のネガティブフィードバックは個人的に感じるだろう。個人的ではない。データだ。

ネガティブフィードバックを処理するフレームワーク：

1. 一旦止まれ。30分間返信するな。感情的な反応は
   役に立たない。

2. フィードバックを分類する：
   a) バグ報告 — 修正せよ。感謝せよ。
   b) 機能リクエスト — バックログに追加。感謝せよ。
   c) 料金の不満 — メモせよ。パターンかどうかを確認。
   d) 品質の不満 — 調査せよ。正当か？
   e) 荒らし/理不尽 — 無視。先に進め。

3. 返信する（a, b, c, dのみ）：
   「フィードバックありがとうございます。[具体的な問題を認める]。
   [今修正中です / ロードマップに追加しました / 調査中です]。
   対応できたらお知らせします。」

4. 行動する。修正すると約束したなら、1週間以内に修正せよ。
   顧客のフィードバックが実際の変化につながることを示すこと以上に
   ロイヤリティを構築するものはない。

本音： 製品がゴミだと言う人が出てくるだろう。傷つくだろう。しかし、製品がライブでお金を稼いでいるなら、あなたはほとんどの開発者がやらないことをすでにやっている。コメント欄から批判している人は何も出荷していない。あなたはしている。出荷し続けよう。

週次イテレーションサイクル

ローンチ後、ワークフローはタイトなループになる：

月曜日：先週のメトリクスと顧客フィードバックをレビュー
火曜日：今週の改善を計画する（1つだけ、5つではない）
水曜日：改善を構築する
木曜日：テストして改善をデプロイ
金曜日：チェンジログ/アップデート投稿を書く
週末：  マーケティング — ブログ投稿1つ、ソーシャル投稿1つ、コミュニティでのやり取り1回

繰り返す。

キーワードは週に1つの改善だ。機能の大改修ではない。再設計でもない。既存顧客にとって製品をわずかに良くする1つのこと。12週間で、それは実際の使用データに基づいた12の改善になる。このサイクルの12週間後のあなたの製品は、孤独にデザインしたどんなものよりも劇的に良くなっている。

収益はアンケートより速く検証する

アンケートは嘘をつく。意図的にではない——人々は自分の行動を予測するのが苦手なだけだ。「これに$29払いますか？」は簡単に「はい」をもらえる。しかし「こちらがチェックアウトページです、クレジットカードを入力してください」は正直な答えをもらえる。

だから初日から決済ありでローンチするのだ：

検証方法 シグナルまでの時間 シグナルの質
アンケート / 投票 1-2週間 低い（人々は嘘をつく）
メール登録付きランディングページ 1-2週間 中程度（関心であり、コミットメントではない）
価格ありだがチェックアウトなしのランディングページ 1週間 中〜高（価格受容性）
実際のチェックアウト付きライブ製品 48時間 最高（実際の購買行動）

$0の価格は何も明らかにしない。$29の価格はすべてを明らかにする。

あなたの番

  1. 「不完全なローンチ」のコミットメントを書こう。 テキストファイルを開いて書く：「私は[製品名]を[日付]にローンチする、たとえ完璧でなくても。v0.1のスコープ：[3つの機能]。ローンチ前に機能4は追加しない。」署名しよう（比喩的に）。磨きたくなった時に参照しよう。

  2. 最初の10人の顧客メールを下書きしよう。 個人的なお礼メールテンプレートを今、顧客がいる前に書こう。最初の売上が来たら、1時間以内に送りたい。

  3. イテレーショントラッカーを設定しよう。 以下のカラムを持つシンプルなスプレッドシートまたはNotionページを作成しよう：週 | 行った改善 | メトリクスへの影響 | 顧客フィードバック。これが次に何を作るかの意思決定ログになる。

レッスン 3：開発者製品の価格心理学

「$0は価格ではない。罠だ。」

なぜ無料は高くつくのか

開発者製品の販売で最も直感に反する真実：無料ユーザーは有料顧客よりもコストがかかる。

無料ユーザー：

有料顧客：

無料プランを提供する唯一の理由は、有料プランへのリード獲得メカニズムとしてだ。無料プランが十分に良くて誰もアップグレードしないなら、無料プランではない——寄付ボタン付きの無料製品だ。

よくあるミス： 「まずユーザーを集めるために無料にして、後で課金しよう。」これはほとんどうまくいかない。$0で引き付けたユーザーは永遠に$0を期待する。価格を追加すると去っていく。初日から$29を支払ったであろうユーザーは、あなたの製品を無料ツールとして位置づけたから見つけなかった。間違ったオーディエンスを引き付けてしまった。

開発者製品の価格帯

何百もの成功した開発者製品を分析した結果、これらの価格帯が一貫して機能している。以下の価格はすべてUSD表記——your local currencyで価格設定する場合は、現地の購買力と市場の慣習に合わせて調整しよう。

プラン 1：$9-29 — 開発者ツールとユーティリティ

この価格帯の製品は、特定の狭い問題を解決する。一度の購入で、今日すぐ使える。

例：
- プレミアム機能付きVS Code拡張機能：$9-15
- プロ機能付きCLIツール：$15-19
- 単一目的のSaaSツール：$9-19/月
- 小規模コンポーネントライブラリ：$19-29
- ブラウザDevTools拡張機能：$9-15

購入者心理：衝動買いの領域。開発者がそれを見て、
問題を認識し、マネージャーに聞かずに買う。
予算承認は不要。クレジットカード → 完了。

重要な洞察：この価格帯では、ランディングページは
2分以内にコンバートしなければならない。購入者は長い機能リストを
読まない。問題を見せ、解決策を見せ、価格を見せる。

プラン 2：$49-99 — テンプレート、キット、包括的ツール

この価格帯の製品は、大幅な時間を節約する。連携する複数のコンポーネント。

例：
- フルUIテンプレートキット：$49-79
- 認証、課金、ダッシュボード付きSaaSボイラープレート：$79-99
- 包括的なアイコン/イラストセット：$49-69
- 多目的CLIツールキット：$49
- 充実したドキュメント付きAPIラッパーライブラリ：$49-79

購入者心理：慎重な購入。開発者は5-10分かけて
評価する。代替品と比較する。節約できる時間を計算する。
「これが10時間節約してくれて、自分の時間を$50/時間と
見積もるなら、$79は考えるまでもない。」

重要な洞察：比較対象が必要。これをゼロから構築する
時間/労力と、キットを購入する場合を示す。
推薦文があれば含める。

プラン 3：$149-499 — コース、包括的ソリューション、プレミアムテンプレート

この価格帯の製品は、スキルを変革するか、完全なシステムを提供する。

例：
- ビデオコース（10時間以上）：$149-299
- フルソース + ビデオウォークスルー付きSaaSスターターキット：$199-299
- エンタープライズコンポーネントライブラリ：$299-499
- 包括的な開発者ツールキット（複数ツール）：$199
- 「Xをゼロから構築」完全なコードベース + レッスン：$149-249

購入者心理：投資型の購入。購入者は支出を正当化する
必要がある（自分自身またはマネージャーに対して）。
ソーシャルプルーフ、詳細なプレビュー、明確なROIストーリーが必要。

重要な洞察：この価格帯では、返金保証を提供せよ。
購入の不安を減らし、コンバージョンを増加させる。
デジタル開発者製品の返金率は通常3-5%。
コンバージョンの増加は返金をはるかに上回る。

3プラン価格戦略

製品がそれをサポートするなら、3つの価格プランを提供しよう。これはランダムではない——「センターステージ効果」と呼ばれるよく文書化された認知バイアスを活用している。3つのオプションを提示されると、ほとんどの人は真ん中を選ぶ。

プラン構造：

BASIC          PRO（ハイライト）     TEAM/ENTERPRISE
$29             $59                   $149
コア機能        Basicのすべて          Proのすべて
                + プレミアム機能       + チーム機能
                + 優先サポート         + 商用ライセンス

コンバージョン分布（一般的）：
- Basic: 20-30%
- Pro: 50-60% ← これがあなたのターゲット
- Team: 10-20%

プランの設計方法：

  1. Proプランから始める。これがあなたが実際に売りたい製品で、その価値を反映した価格だ。これを最初にデザインする。

  2. BasicプランはProから機能を削って作る。BasicがProblemを解決するが、Proが問題をうまく解決するぐらいに十分な機能を削る。Basicはわずかにフラストレーションを感じるべき——使えるが、明らかに制限されている。

  3. TeamプランはProに機能を追加して作る。マルチシートライセンス、商用利用権、優先サポート、カスタムブランディング、ソースコードアクセス、Figmaファイルなど。

実際の料金ページ例：

DashKit

STARTER — $29                    PRO — $59                        TEAM — $149
                                 ★ 一番人気                       エージェンシーに最適

✓ 12のコアコンポーネント          ✓ Starterのすべて                 ✓ Proのすべて
✓ React + TypeScript             ✓ 8つのフルページテンプレート       ✓ 最大5チームメンバー
✓ ダークモード                    ✓ Figmaデザインファイル            ✓ 商用ライセンス
✓ npm install                    ✓ 高度なデータテーブル             （無制限のクライアントプロジェクト）
✓ 6ヶ月のアップデート             ✓ チャートライブラリ統合           ✓ 優先サポート
                                 ✓ 12ヶ月のアップデート            ✓ 永久アップデート
                                 ✓ 優先機能リクエスト               ✓ カスタムブランディングオプション

[Starterを入手]                  [Proを入手]                      [Teamを入手]

価格アンカリング

アンカリングとは、最初に見た数字がその後の数字の認知に影響を与えるという認知バイアスだ。倫理的に活用しよう：

  1. 高い選択肢を最初に表示（欧米のレイアウトでは右側）。$149を見ると$59が妥当に感じる。

  2. 「節約した時間」の計算を示す。

    「これらのコンポーネントをゼロから構築すると約40時間かかる。
$50/時間だと、それはあなたの時間の$2,000分。
DashKit Pro：$59。」

  3. サブスクリプションには「1日あたり」の言い換えを使う。

    "$19/月" → "1日$0.63未満"
"$99/年" → "$8.25/月" または "1日$0.27"

  4. 年払い割引。 年払いプランで2ヶ月無料を提供する。これは標準的で期待されている。年払いはチャーンを30-40%削減する。なぜなら、解約には継続的な月次判断ではなく、1つの更新ポイントでの意識的な判断が必要だからだ。

月払い: $19/月
年払い: $190/年（$38節約 — 2ヶ月無料）

表示方法：
月払い: $19/月
年払い: $15.83/月（年額$190で一括請求）

価格のA/Bテスト

価格テストは価値があるが、注意が必要だ。不誠実にならずに行う方法はこうだ：

許容されるアプローチ：

許容されないアプローチ：

いつ価格を上げるか

以下のいずれかが当てはまる場合、価格を上げよう：

  1. コンバージョン率が5%を超えている。 安すぎる。開発者製品のランディングページの健全なコンバージョン率は1-3%だ。5%を超えるということは、価格を見たほぼ全員がお得だと同意していることを意味する——つまり、テーブルにお金を残している。

  2. 誰も価格について文句を言わない。 100人中ゼロ人が高すぎると言うなら、安すぎる。健全な製品は、訪問者の約20%が高いと思う。つまり80%が妥当またはお得だと思っている。

  3. ローンチ以降に大幅な機能を追加した。 $29で3機能でローンチした。今は8機能とより良いドキュメントがある。製品の価値が上がった。もっと請求しよう。

  4. 推薦文とソーシャルプルーフがある。 ソーシャルプルーフにより知覚価値が増加する。5件以上の肯定的なレビューがあれば、あなたの製品は購入者の心の中でより価値がある。

価格を上げる方法：

本音： ほとんどの開発者は50-200%安すぎる価格をつけている。あなたの$29の製品はおそらく$49の価値がある。$49の製品はおそらく$79の価値がある。これは、開発者が自分の支払い意欲（低い——我々はツールに関してはケチだ）に固定してしまい、顧客の支払い意欲（より高い——彼らは時間がかかる問題への解決策を買っている）ではないからだ。あなたが思うよりも早く価格を上げよう。

あなたの番

  1. 製品の価格を決めよう。 上記のプラン分析に基づき、v0.1ローンチの価格帯を選べ。書き留めろ。「高すぎる」と感じて不快なら、おそらく正しい範囲にいる。快適に感じるなら、50%上乗せしよう。

  2. 料金ページをデザインしよう。 3プランテンプレートを使って、料金ページのコピーをデザインしよう。どの機能をどのプランに入れるか決めろ。「ハイライト」プラン（最も多くの人に買ってほしいもの）を決めろ。

  3. 計算しよう。 以下を埋めよう：

    • 1件あたりの売上：$___
    • 目標月間収益：$___
    • 月に必要な販売件数：___
    • 必要な推定ランディングページ訪問者数（コンバージョン率2%の場合）：___
    • その訪問者数はあなたの流通計画で達成可能か？（はい/いいえ）

レッスン 4：法的最小限のセットアップ

「今30分の法的セットアップが、後で30時間のパニックを節約する。」

法的セットアップに関する正直な真実

ほとんどの開発者は法的なことを完全に無視するか（リスキー）、麻痺してしまうか（無駄）だ。正しいアプローチは最小限の法的セットアップだ：$5を稼ぐ前に弁護士に$5,000を費やすことなく、正当に運営するための十分な保護。

最初の販売前に実際に必要なもの、100件目の販売前に必要なもの、そしてもっと後まで必要ないものを示す。

最初の販売前に（この週末にやること）

1. 雇用契約を確認する（30分）

フルタイムの仕事がある場合、何かを作る前に雇用契約のIP条項を読もう。具体的に以下を探す：

探しているもの：

安全：「会社の時間中または会社のリソースを使用して作成された発明は
会社に帰属する。」→ 自分のマシンでの週末プロジェクトはあなたのもの。

曖昧：「会社の現在または将来予定される事業に関連するすべての発明。」
→ 副業が雇用主と同じ領域にある場合、法的アドバイスを得よう。

制限的：「就業期間中に着想されたすべての発明は会社に帰属する。」
→ これは攻撃的だが一部の企業では一般的。製品をローンチする前に
法的アドバイスを得よう。

カリフォルニア、デラウェア、イリノイ、ミネソタ、ワシントンなどの州には、雇用主が個人の発明をどの程度広く請求できるかを制限する法律がある。しかし、契約の具体的な文言が重要だ。

よくあるミス： 「秘密にしておけばいい。」製品が重要になるほど成功すれば、誰かが気づく。雇用契約に違反していれば、製品と仕事の両方を失う可能性がある。今30分かけて契約を読めば、これを防げる。

2. プライバシーポリシー（15分）

製品が何らかのデータを収集する場合——購入のためのメールアドレスだけでも——プライバシーポリシーが必要だ。これはEU（GDPR）、カリフォルニア（CCPA）、そしてますます世界中で法的要件だ。

ゼロから書くな。ジェネレーターを使おう：

プライバシーポリシーがカバーすべき内容：

# [製品名]のプライバシーポリシー
最終更新日：[日付]

## 収集するもの
- メールアドレス（購入確認と製品アップデート用）
- 決済情報（[Lemon Squeezy/Stripe]で処理、
  カード情報を見ることも保存することもない）
- 基本的な利用分析（ページビュー、機能利用 —
  [Plausible/Fathom/Umami]経由、プライバシー重視、Cookieなし）

## 収集しないもの
- ウェブ全体にわたる追跡はしない
- データを誰にも販売しない
- 広告Cookieは使用しない

## データの利用方法
- 購入した製品を提供するため
- 製品アップデートと重要な通知を送信するため
- 集計された利用パターンに基づいて製品を改善するため

## データの保存
- データは[ホスティングプロバイダー]の[地域]のサーバーに保存
- 決済データは[Lemon Squeezy/Stripe]が完全に処理

## あなたの権利
- いつでもデータのコピーを要求できる
- いつでもデータの削除を要求できる
- 連絡先：[あなたのメール]

## 変更
- 重大な変更はメールで通知する

yourdomain.com/privacy に配置する。チェックアウトページのフッターからリンクする。

3. 利用規約（15分）

利用規約は不当な請求からあなたを保護する。デジタル製品の場合、シンプルだ。

# [製品名]の利用規約
最終更新日：[日付]

## ライセンス
[製品名]を購入すると、[個人/商用]目的で使用する
ライセンスが付与される。

- **シングルライセンス：** 自分のプロジェクトで使用（無制限）
- **チームライセンス：** 最大[N]人のチームメンバーが使用
- 再配布、再販売、アクセス資格の共有は不可

## 返金
- デジタル製品：[30日 / 14日]返金保証
- 満足いただけない場合、[あなたのメール]に連絡で全額返金
- 返金期間内は質問なし

## 責任
- [製品名]は「現状有姿」で保証なしに提供される
- 製品の使用に起因する損害について当方は責任を負わない
- 最大責任額は支払い済み金額に限定される

## サポート
- サポートは[あなたのメール]へのメールで提供
- [48時間 / 2営業日]以内の返信を目指す

## 変更
- 通知の上でこれらの規約を更新する場合がある
- 継続使用は更新された規約の承諾を意味する

yourdomain.com/terms に配置する。チェックアウトページのフッターからリンクする。

100件目の販売前に（最初の数ヶ月以内）

4. 事業体（1-3時間 + 処理時間）

個人事業主として運営する（事業体を設立せずに物を売る際のデフォルト）のは最初の販売では機能する。しかし収益が増えるにつれ、責任保護と税制上の利点が欲しくなる。

アメリカ合衆国 — LLC：

LLC（有限責任会社）はソロ開発者ビジネスの標準的な選択だ。

費用：州に応じて$50-500（申請料）
時間：処理に1-4週間
申請先：特別な理由がない限り、居住している州
デラウェア州やワイオミング州を使う理由が特にない限り

DIY申請（最安）：
1. あなたの州の州務長官ウェブサイトにアクセス
2. 「Articles of Organization」を申請（フォームは通常1-2ページ）
3. 申請料を支払う（州に応じて$50-250）
4. IRS.govからEIN（税ID）を取得 — 無料、オンラインで即時

ソロ開発者向け州比較：
- ワイオミング：申請$100、年次報告書$60/年。州所得税なし。
             プライバシーに良い（公開メンバー情報不要）。
- デラウェア：申請$90、年次税$300/年。人気だが
            ソロ開発者にとって必ずしも良いわけではない。
- ニューメキシコ：申請$50、年次報告書なし。維持費が最安。
- カリフォルニア：申請$70、最低フランチャイズ税$800/年。
              高い。$0の収益でもこれを支払う。

Stripe Atlas（誰かにやってもらいたい場合）：

Stripe Atlas (https://atlas.stripe.com) は$500で、デラウェアLLC、米国銀行口座（Mercury経由）、Stripeアカウントを設定し、税務・法務ガイドを提供する。米国外在住か、書類を他の人に任せたいなら、$500の価値はある。

イギリス — 有限会社（Ltd）：

費用：Companies House (https://www.gov.uk/set-up-limited-company) でGBP 12
時間：通常24-48時間
継続：年次確認書（GBP 13）、年次決算書の提出

ソロ開発者向け：有限会社は利益がGBP 50,000/年を超えると
責任保護と税効率を提供する。
それ以下なら個人事業主（sole trader）の方がシンプル。

欧州連合：

各国に独自の仕組みがある。一般的なオプション：

オーストラリア：

個人事業主：ABN申請 (https://www.abr.gov.au) で無料登録
会社（Pty Ltd）：ASICでAUD 538の登録
ソロ開発者向け：個人事業主として始める。収益が会計のオーバーヘッドを
正当化するレベル（約AUD 100K以上/年）になったら会社を登録する。

5. 税務義務

Lemon Squeezyを決済プラットフォームとして使用している場合、販売代行者として消費税とVATを処理してくれる。これは大幅な簡素化だ。

Stripeを直接使用している場合、以下の責任がある：

本音： ソロ開発者にとってLemon SqueezyのStripeに対する最大のメリットは、チェックアウトページや機能ではない。グローバルな税コンプライアンスを処理してくれることだ。国際的な消費税は悪夢だ。Lemon Squeezyは取引あたり5% + $0.50で悪夢を消してくれる。月$5,000以上を稼ぐまでは、5%は価値がある。その後、Stripe + TaxJarで自分で税金を管理する方がお金と精神衛生の面でメリットがあるか評価しよう。

6. 知的財産の基礎

知っておくべきこと：

# プロジェクトの依存関係ライセンスを確認 (Node.js)
npx license-checker --summary

# 問題のあるライセンスを具体的にチェック
npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

# Rustプロジェクトの場合
cargo install cargo-license
cargo license

7. 保険

$29のコンポーネントライブラリに保険は必要ない。以下の場合に保険が必要だ：

必要になったとき、専門家賠償責任保険（errors and omissions / E&O）はソロ開発者ビジネスで年間$500-1,500だ。

あなたの番

  1. 雇用契約を読もう。 雇用されている場合、IP条項と競業避止条項を見つけよう。分類する：安全 / 曖昧 / 制限的。曖昧または制限的なら、ローンチ前に労働弁護士に相談しよう（多くが無料の30分相談を提供している）。

  2. 法的文書を生成しよう。 TermlyまたはAvodocsにアクセスして、製品のプライバシーポリシーと利用規約を生成しよう。HTMLまたはMarkdownで保存する。製品ドメインの/privacyと/termsにデプロイしよう。

  3. 事業体の決断をしよう。 上記のガイダンスとyour countryでの居住地に基づき、決めよう：個人事業主としてローンチ（最速）か、先にLLC/Ltd/equivalentを設立（より多くの保護）か。決断とタイムラインを書き留めよう。

  4. 依存関係を確認しよう。 プロジェクトでライセンスチェッカーを実行しよう。商用製品を販売する前に、GPL/AGPLの依存関係を解決しよう。

レッスン 5：2026年に機能する流通チャネル

「作るのは仕事の20%。人の目に触れさせるのが残りの80%。」

流通の現実

ほとんどの開発者製品が失敗するのは悪いからではなく、誰もその存在を知らないからだ。流通——製品を潜在顧客の前に置くこと——は、ほとんどの開発者が最も弱いスキルだ。そしてそれが最も重要なスキルだ。

労力、タイムライン、期待リターンでランク付けした7つの流通チャネルを示す。7つ全ては必要ない。あなたの強みとオーディエンスに合った2-3つを選ぼう。

チャネル 1：Hacker News

労力： 高 | タイムライン： 即時（0-48時間） | 性質： 当たりハズレ

Hacker News (https://news.ycombinator.com) は、開発者製品にとって最もレバレッジの高い単一イベント流通チャネルだ。フロントページのShow HN投稿は24時間で5,000-30,000人の訪問者を送ることができる。しかし予測不能——ほとんどの投稿はゼロのトラクションだ。

HNで機能するもの：

HNで機能しないもの：

Show HNプレイブック：

投稿前：
1. あなたのカテゴリの最近の成功したShow HN投稿を研究する
   https://hn.algolia.com — "Show HN"でフィルタ、ポイント順にソート
2. 投稿タイトルを準備：「Show HN: [名前] – [何をするか、70文字未満]」
   良い例: "Show HN: ScrubLog – Strip PII from Log Files in One Command"
   悪い例: "Show HN: Introducing ScrubLog, the AI-Powered Log Anonymization Platform"
3. ライブデモを準備する（HN読者は読みたいのではなく試したい）
4. 予想される質問への回答を準備する（技術的判断、価格の根拠）

投稿時：
5. 火曜から木曜の米国東部時間午前7-9時に投稿する
   （最もトラフィックが多く、トラクションを得る確率が最高）
6. 投稿本文は4-6段落にすべき：
   - 何であるか（1段落）
   - なぜ作ったか（1段落）
   - 技術的詳細（1-2段落）
   - 何を求めているか（フィードバック、具体的な質問）

投稿後：
7. 投稿後4時間はオンラインでいろ。すべてのコメントに返信する。
8. 謙虚で技術的であれ。HNは限界についての正直さを報いる。
9. 誰かがバグを見つけたら、ライブで修正して「Fixed, thanks.」と返信する。
10. 友人にアップボートを頼むな。HNには投票リング検出がある。

期待される結果（現実的）：

労力で確率を上げられるくじだ。素晴らしい製品と素晴らしい投稿があれば、意味のあるトラクションを得る確率は約30%。保証はない。しかしアップサイドは莫大だ。

チャネル 2：Reddit

労力： 中 | タイムライン： 1-7日 | 性質： 持続的、再現可能

Redditは開発者製品にとって最も一貫した流通チャネルだ。HN（一発勝負）と違い、Redditにはあなたの製品が関連する数百のニッチなサブレディットがある。

サブレディットの選択：

一般的な開発者サブレディット：
- r/SideProject (140K+メンバー) — まさにこのために作られた
- r/webdev (2.4Mメンバー) — 巨大、競争的
- r/programming (6.3Mメンバー) — 非常に競争的、ニュース志向
- r/selfhosted (400K+メンバー) — セルフホスト可能な製品なら

フレームワーク/言語固有：
- r/reactjs, r/nextjs, r/sveltejs, r/vuejs — フロントエンドツール向け
- r/rust, r/golang, r/python — 言語固有のツール向け
- r/node — Node.jsツールとパッケージ向け

ドメイン固有：
- r/devops — インフラ/デプロイツール向け
- r/machinelearning — AI/MLツール向け
- r/datascience — データツール向け
- r/sysadmin — 管理/モニタリングツール向け

ロングテール：
- 特定のニッチに関連するサブレディットを検索
- 小さめのサブレディット（10K-50Kメンバー）は
  巨大なものよりコンバージョン率が良いことが多い

Redditエンゲージメントルール：

  1. 製品を投稿する前に実際のReddit履歴を持っておく。自己宣伝だけを投稿するアカウントはフラグが立てられシャドウバンされる。
  2. 自己宣伝に関する各サブレディットのルールに従う。ほとんどは貢献するメンバーである限り許可する。
  3. 本心でエンゲージする。 質問に答え、価値を提供し、他の投稿のコメントで役に立つ。それから製品をシェアする。
  4. 異なるサブレディットで異なる時間に投稿する。 ピーク活動時間にはhttps://later.com/redditまたは類似ツールをチェック。

期待される結果（現実的）：

チャネル 3：Twitter/X

労力： 中 | タイムライン： 勢いをつけるのに2-4週間 | 性質： 時間と共に複利効果

Twitterはゆっくり構築するチャネルだ。最初のローンチツイートは友人から5いいねをもらうだろう。しかし一貫してビルドプロセスをシェアすれば、オーディエンスは複利的に増える。

ビルドインパブリック戦略：

第1週：ビルドプロセスのシェアを始める（ローンチ前）
- 「[製品タイプ]に取り組んでいる。解決している問題はこれ：[スクリーンショット]」
- 「[製品]を構築して3日目。[機能]が動いた：[GIF/スクリーンショット]」

第2週：ビルドからの技術的洞察をシェア
- 「今日学んだこと：[製品タイプ]を構築するとき[技術的教訓]が必要」
- 「アーキテクチャの判断：[理由]で[X]を[Y]より選んだ」

第3週：ローンチ
- ローンチスレッド（レッスン1のフォーマット）
- 具体的なメトリクスをシェア：「1日目：X訪問者、Yサインアップ」

第4週以降：継続
- 顧客フィードバックをシェア（許可を得て）
- 収益マイルストーンをシェア（人々はリアルな数字を好む）
- 課題とその解決方法をシェア

誰にエンゲージするか：

期待される結果（現実的）：

Twitterは6ヶ月の投資であり、ローンチ当日の戦略ではない。製品の準備ができる前から今すぐ始めよう。

チャネル 4：Product Hunt

労力： 高 | タイムライン： 1日の集中的な活動 | 性質： 一回きりのブースト

Product Hunt (https://producthunt.com) は専用のローンチプラットフォームだ。デイリートップ5入りで3,000-15,000訪問者を送ることができる。ただし準備が必要だ。

Product Huntローンチチェックリスト：

2週間前：
- [ ] Product Huntのメーカープロフィールを作成
- [ ] PHリスティングを構築：タグライン、説明、画像、動画
- [ ] 4-5枚の高品質スクリーンショット/GIFを準備
- [ ] 動機を説明する「ファーストコメント」を書く
- [ ] ローンチ日にサポートしてくれる10-20人を集める（偽の投票ではなく——
      製品を試して真のコメントを残す本物の人々）
- [ ] 「ハンター」（PHのフォロワーが多い人に製品を提出してもらう）を見つける
      または自分で提出する

ローンチ日（太平洋時間午前0:01）：
- [ ] 太平洋時間の真夜中からオンラインでいる。PHは真夜中にリセットされる。
- [ ] すぐに「ファーストコメント」を投稿
- [ ] Twitter、LinkedIn、メール、DiscordでPHリンクをシェア
- [ ] PHリスティングのすべてのコメントに返信
- [ ] 1日を通じてアップデートを投稿（「[X]の修正を出荷しました！」）
- [ ] 太平洋時間の真夜中まで終日モニタリング

終了後：
- [ ] サポートしてくれた全員に感謝
- [ ] 「学んだ教訓」投稿を書く（Twitter/ブログコンテンツとして良い）
- [ ] ランディングページにPHバッジを埋め込む（ソーシャルプルーフ）

よくあるミス： 製品の準備ができる前にProduct Huntでローンチすること。PHは一発勝負だ。製品をローンチしたら、再ローンチはできない。製品が磨かれ、ランディングページがコンバートし、決済フローが機能するまで待とう。PHは「ビッグローンチ」であるべき——ソフトローンチではない。

期待される結果（現実的）：

チャネル 5：Dev.to / Hashnode / テクニカルブログ投稿

労力： 低〜中 | タイムライン： SEO結果は1-3ヶ月 | 性質： ロングテール、永遠に複利効果

製品に関連する問題を解決するテクニカルブログ投稿を書き、製品を解決策として言及する。

コンテンツ戦略：

各製品について3-5のブログ投稿を書く：

1. 「2026年に[あなたの製品が解決する問題]を解決する方法」
   - 手動アプローチを教え、あなたの製品をショートカットとして言及

2. 「[製品]を48時間で作った——学んだこと」
   - ビルドインパブリックコンテンツ。技術的詳細 + 正直な振り返り。

3. 「[競合] vs [あなたの製品]：正直な比較」
   - 本当にフェアに。競合が勝つ点にも言及する。
   - 比較検討中の検索トラフィックをキャプチャする。

4. 「[あなたの製品に関連する技術的概念]の解説」
   - 純粋な教育。最後に製品を1回だけ言及。

5. 「2026年に[あなたの製品のドメイン]で使っているツール」
   - リスト形式。他のツールと並べてあなたの製品を含める。

公開先：

投稿あたりの期待される結果：

よく書かれた1つのブログ投稿は、何年にもわたって月200人以上の訪問者を送ることができる。5つの投稿なら月1,000人以上。これが複利だ。

チャネル 6：ダイレクトアウトリーチ

労力： 高 | タイムライン： 即時 | 性質： 最高のコンバージョン率

コールドメールとDMは、どのチャネルよりも最高のコンバージョン率を持つ——しかし、リードあたりの労力も最高だ。高価格帯の製品（$99以上）またはB2B販売に使おう。

潜在顧客へのメールテンプレート：

件名: Quick question about [彼らの具体的なペインポイント]

Hi [名前],

I saw your [ツイート/投稿/コメント] about [彼らが言及した具体的な問題].

I built [製品名] specifically for this — it [何をするかの
1文説明].

Would you be open to trying it? Happy to give you free access
for feedback.

[あなたの名前]
[製品へのリンク]

コールドアウトリーチのルール：

期待される結果：

$99の製品の場合、100人にメール = 1-4件の売上 = $99-396。スケーラブルではないが、初期の顧客とフィードバックを得るには優れている。

チャネル 7：SEO

労力： 低い継続コスト | タイムライン： 結果まで3-6ヶ月 | 性質： 永遠に複利効果

SEOは最良の長期流通チャネルだ。スタートは遅いが、一度機能すれば無料のトラフィックを無期限に送る。

開発者向けSEO戦略：

1. ロングテールキーワードをターゲットにする（ランクインしやすい）：
   以下ではなく："dashboard components"
   ターゲット："tailwind dashboard components react typescript"

2. キーワードごとに1ページ作成：
   各ブログ投稿またはドキュメントページで1つの具体的な検索クエリをターゲット

3. 技術的実装：
   - 高速読み込みのための静的サイト生成を使用（Astro, Next.js SSG）
   - すべてのページにメタディスクリプションを追加
   - セマンティックHTML（h1, h2, h3の階層）を使用
   - すべての画像にalt テキストを追加
   - Google Search Consoleにサイトマップを送信

4. 開発者ツールでランクインするコンテンツ：
   - ドキュメントページ（意外とSEOに良い）
   - 比較ページ（「X vs Y」）
   - チュートリアルページ（「Yで Xをする方法」）
   - チェンジログページ（Googleへのフレッシュコンテンツシグナル）

# Google Search Consoleにサイトマップを送信
# 1. https://search.google.com/search-console にアクセス
# 2. プロパティを追加（ドメインまたはURLプレフィックス）
# 3. 所有権を確認（DNS TXTレコードまたはHTMLファイル）
# 4. サイトマップURLを送信：yourdomain.com/sitemap.xml

# Astroを使用している場合：
pnpm add @astrojs/sitemap
# サイトマップは /sitemap.xml に自動生成される

# Next.jsを使用している場合、next-sitemap.config.jsに追加：
# pnpm add next-sitemap

期待される結果：

チャネル選択フレームワーク

7つすべてをうまくやることはできない。このマトリクスに基づいて2-3を選ぼう：

あなたが... 優先すべき スキップすべき
今週末ローンチする Reddit + HN SEO, Twitter（遅すぎる）
まずオーディエンスを構築する Twitter + ブログ投稿 ダイレクトアウトリーチ, PH
$99+の製品を販売する ダイレクトアウトリーチ + HN Dev.to（オーディエンスが無料を期待）
長期戦を見据えている SEO + ブログ投稿 + Twitter PH（一発勝負、後で使う）
英語以外が母語 Dev.to + Reddit（グローバル） HN（米国中心）

あなたの番

  1. 2-3のチャネルを選ぼう。 上記のマトリクスと製品タイプに基づき、集中するチャネルを選べ。各チャネルの計画タイムラインとともに書き留めよう。

  2. Reddit投稿を書こう。 レッスン1のテンプレートを使って、r/SideProject投稿の下書きを今すぐ書こう。保存しよう。ローンチ当日に投稿する。

  3. 最初のブログ投稿を書こう。 「[あなたの製品が解決する問題]を解決する方法」投稿を下書きしよう。ローンチの最初の1週間以内にDev.toまたはブログに公開する。1,500-2,000語を目指そう。

  4. Google Search Consoleを設定しよう。 これは5分で完了し、初日からSEOデータが得られる。ベースラインデータを持つために、ローンチ前にやっておこう。

レッスン 6：ローンチチェックリスト

「希望はローンチ戦略ではない。チェックリストだ。」

プレローンチチェックリスト

すべてのアイテムを確認しよう。すべての「必須」アイテムにチェックが入るまでローンチするな。「推奨」アイテムは必要であれば第1週に行える。

製品（必須）：

- [ ] コア機能がランディングページの説明通りに動作する
- [ ] 購入 → 配信フローに致命的なバグがない
- [ ] Chrome、Firefox、Safari で動作する（Web製品の場合）
- [ ] モバイルレスポンシブなランディングページ（トラフィックの50%以上がモバイル）
- [ ] エラーメッセージが役に立つ、スタックトレースではない
- [ ] 非同期操作のローディング状態がある

ランディングページ（必須）：

- [ ] 明確な見出し：8語以下で何をするか
- [ ] 問題文：顧客の言葉で3つのペインポイント
- [ ] 解決策セクション：製品のスクリーンショットまたはデモ
- [ ] 料金：見える、明確、購入ボタン付き
- [ ] 行動喚起：1つの主要ボタン、ファーストビューに見える
- [ ] プライバシーポリシーがフッターにリンクされている
- [ ] 利用規約がフッターにリンクされている

決済（必須）：

- [ ] チェックアウトフローをテストモードでエンドツーエンドテスト済み
- [ ] チェックアウトフローをライブモードでエンドツーエンドテスト済み（$1テスト購入）
- [ ] Webhookが支払い確認を受信する
- [ ] 顧客が支払い後に製品アクセスを受け取る
- [ ] 返金プロセスが文書化されている（返金リクエストは必ず来る）
- [ ] 領収書/請求書が自動送信される

インフラ（必須）：

- [ ] カスタムドメインがライブサイトを指している
- [ ] HTTPSが動作している（緑の鍵マーク）
- [ ] アップタイムモニタリングがアクティブ
- [ ] アナリティクススクリプトがインストールされデータを受信中
- [ ] 連絡先メールが動作している（you@yourdomain.com）

流通（必須）：

- [ ] Reddit投稿が下書きされ準備完了
- [ ] Show HN投稿が下書きされ準備完了（該当する場合）
- [ ] Twitterローンチスレッドが下書き済み
- [ ] 共有用の2-3コミュニティが特定されている

推奨（第1週）：

- [ ] ソーシャルシェアプレビュー用のOpenGraphメタタグ
- [ ] カスタム404ページ
- [ ] FAQページまたはセクション
- [ ] 顧客オンボーディングメールシーケンス（ウェルカム + 使い方ガイド）
- [ ] チェンジログページ（空でも——アップデートへのコミットメントを示す）
- [ ] ブログ投稿：「[製品]を48時間で作った」
- [ ] Google Search Consoleが認証されサイトマップが送信済み

ローンチ後のアクションアイテム

1日目（ローンチ日）：

朝：
- [ ] Redditに投稿（r/SideProject + ニッチサブレディット1つ）
- [ ] Show HNに投稿（該当する場合）
- [ ] Twitterローンチスレッドを投稿

終日：
- [ ] Reddit、HN、Twitterのすべてのコメントに返信
- [ ] エラーログとアナリティクスをリアルタイムで監視
- [ ] ユーザーが発見したバグを即座に修正
- [ ] すべての顧客に個人的なお礼メールを送信

夜：
- [ ] メトリクスを確認：訪問者数、コンバージョン率、収益
- [ ] アナリティクスダッシュボードのスクリーンショットを撮る（後で欲しくなる）
- [ ] 最も多かったフィードバック3つを書き留める

第1週：

- [ ] すべてのフィードバックとサポートリクエストに24時間以内に返信
- [ ] ローンチ中に発見されたトップ3のバグ/問題を修正
- [ ] 最初のブログ投稿を書いて公開
- [ ] すべての顧客にフィードバックを求めるフォローアップメールを送信
- [ ] アナリティクスをレビュー：どのページの直帰率が最も高いか？
- [ ] シンプルなフィードバック収集方法を設定（メール、Typeform、またはCanny）

記録する週次メトリクス：
| メトリクス           | ターゲット | 実績 |
|---------------------|-----------|--------|
| ユニーク訪問者       | 500以上   |        |
| チェックアウトクリック率 | 2-5%    |        |
| 購入コンバージョン    | 1-3%     |        |
| 収益                | $50以上   |        |
| サポートリクエスト    | 10件未満  |        |
| 返金リクエスト       | 2件未満   |        |

1ヶ月目：

- [ ] 顧客フィードバックに基づいた4つの週次改善を出荷
- [ ] 2件以上のブログ投稿を公開（SEO構築）
- [ ] 顧客から3件以上の推薦文を収集
- [ ] 推薦文をランディングページに追加
- [ ] 価格を評価：高すぎる？安すぎる？（コンバージョンデータをレビュー）
- [ ] Product Huntでの「ビッグローンチ」を計画（該当する場合）
- [ ] 将来の製品ローンチ用メールリストの構築を始める
- [ ] 流通チャネル戦略をレビューし調整

月次財務レビュー：
| カテゴリ            | 金額      |
|--------------------|-----------|
| 粗収益             | $         |
| 決済プロセッサー手数料 | $       |
| ホスティング/インフラ費用 | $     |
| API費用            | $         |
| 純利益             | $         |
| 投資した時間        |           |
| 実効時給            | $         |

メトリクスダッシュボード

毎日チェックするシンプルなメトリクスダッシュボードを設定しよう。派手である必要はない——スプレッドシートで十分。

=== 日次メトリクス（毎朝チェック）===

日付: ___
昨日の訪問者数: ___
昨日の新規顧客数: ___
昨日の収益: $___
サポートリクエスト: ___
アップタイム: ___%

=== 週次メトリクス（毎週月曜にチェック）===

対象週: ___
合計訪問者数: ___
合計顧客数: ___
合計収益: $___
コンバージョン率: ___% （顧客数 / 訪問者数）
最も訪問されたページ: ___
トップトラフィックソース: ___
トップフィードバックテーマ: ___

=== 月次メトリクス（毎月1日にチェック）===

月: ___
合計収益: $___
合計費用: $___
純利益: $___
合計顧客数: ___
返金: ___
チャーン率（サブスクリプション）: ___%
MRR（月間定期収益）: $___
前月比成長率: ___%

プライバシー重視のアナリティクス設定：

// Plausibleを使用している場合、ほとんどはダッシュボードで取得できる。
// カスタムイベントトラッキング用：

// チェックアウトクリックを追跡
document.querySelector('#buy-button').addEventListener('click', () => {
  plausible('Checkout Click', {
    props: { tier: 'pro', price: '59' }
  });
});

// 購入成功を追跡（Webhook成功ハンドラーから呼び出す）
plausible('Purchase', {
  props: { tier: 'pro', revenue: '59' }
});

いつ加速、方向転換、撤退するか

30日間のデータがあれば、判断を下すのに十分なシグナルがある：

加速（継続、さらに投資）：

シグナル：
- 収益が週ごとに成長している（ゆっくりでも）
- 顧客が具体的な機能リクエストを提供している（もっと欲しがっている）
- コンバージョン率が安定または改善
- オーガニックトラフィックが来ている（自分の投稿なしで見つけてくれている）
- 少なくとも1人の顧客が「これで[時間/お金]を節約できた」と言った

アクション：
- 流通努力を増やす（チャネルを追加）
- 最もリクエストの多い機能を出荷
- 価格をわずかに引き上げ
- 将来のローンチ用メールリストの構築を始める

方向転換（角度を変え、コアを維持）：

シグナル：
- 訪問者はいるが売上がない（関心はあるが購入しない）
- 予想外のオーディエンスからの売上（ターゲットと異なる人が買っている）
- 顧客が予想と異なる方法で製品を使っている
- フィードバックが一貫して、解決しているのとは異なる問題を指摘

アクション：
- 実際のオーディエンス/ユースケースに合わせてランディングページを書き直す
- 実際のオーディエンスの支払い意欲に合わせて価格を調整
- 人々が実際に使っているものに向けて機能の優先順位を変更
- コードは残す、ポジショニングを変える

撤退（止める、学ぶ、別のものを作る）：

シグナル：
- 流通努力にもかかわらず訪問者がいない（需要の問題）
- 訪問者はいるがチェックアウトクリックがゼロ（調整後も
  持続するポジショニング/価格の問題）
- 4週間以上収益が停滞し成長トレンドなし
- 作業を嫌がっている（ソロ製品にはモチベーションが重要）
- 市場が変化した（競合がローンチ、技術が変わった）

アクション：
- ポストモーテムを書く：何がうまくいき、何がうまくいかず、何を学んだか
- コードを保存——次の製品で部品が役に立つかもしれない
- 1週間ビルドを休む
- 新しいアイデアの検証プロセスを始める
- これは失敗ではない。これはデータだ。ほとんどの製品はうまくいかない。
  お金を稼ぐ開発者は、1つの製品に1年費やす人ではなく、
  5つの製品を出荷する人だ。

ローンチドキュメントテンプレート

これがモジュール E の成果物だ。このドキュメントを作成し、ローンチを実行しながら記入しよう。

# ローンチドキュメント：[製品名]

## プレローンチ

### 検証サマリー
- **検索ボリューム：** [Google Trends/Ahrefsからの数値]
- **スレッドの証拠：** [需要を示す5つ以上のスレッドへのリンク]
- **競合調査：** [強み/弱みを含む3つ以上の競合]
- **「10人が支払う」の証拠：** [どう検証したか]

### 製品
- **URL：** [ライブ製品URL]
- **ドメイン：** [購入したドメイン]
- **ホスティング：** [プラットフォーム]
- **コア機能（v0.1）：**
  1. [機能 1]
  2. [機能 2]
  3. [機能 3]

### 料金
- **価格：** $[金額]
- **プラン構造：** [Basic/Pro/Team または単一プラン]
- **決済プラットフォーム：** [Lemon Squeezy/Stripe]
- **チェックアウトURL：** [リンク]

### 法的
- **プライバシーポリシー：** [URL]
- **利用規約：** [URL]
- **事業体：** [種類 または "個人事業主"]

## ローンチ

### 流通チャネル
| チャネル | 投稿URL | 投稿日 | 結果 |
|---------|----------|-------------|---------|
| Reddit  | [リンク] | [日付]      | [訪問者数, アップボート] |
| HN      | [リンク] | [日付]      | [訪問者数, ポイント] |
| Twitter | [リンク] | [日付]      | [インプレッション, クリック] |

### 1日目のメトリクス
- 訪問者数: ___
- チェックアウトクリック数: ___
- 購入数: ___
- 収益: $___

### 第1週のメトリクス
- 合計訪問者数: ___
- 合計購入数: ___
- 合計収益: $___
- コンバージョン率: ___%
- トップフィードバック: ___

### 1ヶ月目のメトリクス
- 合計収益: $___
- 合計費用: $___
- 純利益: $___
- 合計顧客数: ___
- 判断: [ ] 加速 [ ] 方向転換 [ ] 撤退

## ローンチ後ロードマップ
- 第2週: [計画した改善]
- 第3週: [計画した改善]
- 第4週: [計画した改善]
- 2ヶ月目: [計画した機能/拡張]

## 学んだ教訓
- うまくいったこと: ___
- うまくいかなかったこと: ___
- 次回は変えること: ___

4DA統合

4DA統合： 4DAのアクション可能シグナルは、コンテンツを緊急度で分類する。人気パッケージの脆弱性に関する「クリティカル」シグナルは、修正ツールか移行ツールを今すぐ、誰よりも先に作れということだ。新しいフレームワークに関する「上昇トレンド」シグナルは、競合がほぼゼロの今週末にスターターキットを作れということだ。レッスン1の48時間スプリントは、アイデアが時間に敏感なシグナルから来るときに最もうまく機能する。4DAのインテリジェンスフィードをスプリントカレンダーに接続しよう——高緊急度の機会が現れたら、次の週末をブロックして実行する。機会を捉える開発者とそうでない開発者の違いは才能ではない。スピードだ。4DAがレーダーを与えてくれる。このモジュールがローンチシーケンスを与えてくれる。合わせれば、シグナルを収益に変換する。

あなたの番

  1. プレローンチチェックリストを完了しよう。 すべてのアイテムを確認する。各アイテムに完了マークを付けるか、いつやるかスケジュールしよう。「必須」アイテムはスキップするな。

  2. ローンチドキュメントを作成しよう。 上記のテンプレートを好きなドキュメントツールにコピーする。今わかっているすべてを記入する。ローンチ中および後に記入するメトリクスは空欄のままにする。

  3. ローンチ日を設定しよう。 カレンダーを開こう。今後2週間以内の特定の土曜日を選ぼう。書き留めよう。誰かに伝えよう——友人、パートナー、Twitterのフォロワー。説明責任がそれを現実にする。

  4. 撤退基準を設定しよう。 ローンチ前に決める：「30日間で[Y]の流通努力にもかかわらず[X]件未満の売上なら、[方向転換/撤退]する。」これをローンチドキュメントに書こう。事前にコミットされた基準があれば、サンクコストの誤謬で死んだ製品に何ヶ月も注ぎ込むのを防げる。

  5. 出荷しよう。 プレイブックがある。ツールがある。知識がある。残るのは行動だけだ。インターネットが待っている。

モジュール E：完了

2週間で構築したもの

このモジュールを始めた時にはなかったもので、今あなたが持っているものを見よう：

  1. 48時間実行フレームワーク これはあなたが作るすべての製品で繰り返せる——検証済みアイデアからライブ製品まで1週末で。
  2. 出荷マインドセット 完璧よりも存在を、推測よりもデータを、計画よりもイテレーションを優先する。
  3. 価格戦略 希望や過少請求ではなく、実際の心理学と実際の数字に基づいている。
  4. 法的基盤 麻痺させずに保護する——プライバシーポリシー、利用規約、事業体計画。
  5. 流通プレイブック 7つのチャネルの具体的なテンプレート、タイミング、期待される結果。
  6. ローンチチェックリストと追跡システム カオスをプロセスに変える——再現可能、測定可能、改善可能。
  7. ライブ製品、決済受付中、実際の人間が訪問している。

最後のものが重要だ。他のすべては準備だ。製品が証拠だ。

次のステップ：モジュール E2 — 進化するエッジ

モジュール E1はあなたをローンチまで導いた。モジュール E2はあなたを先頭に留める。

モジュール E2が扱う内容：

一貫した収入を得る開発者は、一度ローンチして終わる人ではない。ローンチし、イテレーションし、市場の先を行き続ける人だ。モジュール E2は先を行くためのシステムを提供する。

STREETSフルロードマップ

モジュール タイトル フォーカス 期間
S ソブリンセットアップ インフラ、法的、予算 第1-2週
T テクニカルモート 防御可能な優位性、独自資産 第3-4週
R レベニューエンジン コード付きの具体的なマネタイズプレイブック 第5-8週
E 実行プレイブック ローンチシーケンス、価格設定、最初の顧客 第9-10週（完了）
E 進化するエッジ 先を行く、トレンド検出、適応 第11-12週
T タクティカルオートメーション パッシブインカムのための運用自動化 第13-14週
S ストリームスタッキング 複数の収入源、ポートフォリオ戦略 第15-16週

あなたは折り返し地点を過ぎた。ライブ製品がある。それは独立した収入を築きたいと思いながらここまでたどり着けない95%の開発者より先にいるということだ。

STREETS進捗： 0 / 7 モジュール完了。

さあ、成長させよう。

あなたの製品はライブだ。チェックアウトは機能する。人間があなたにお金を支払える。

これ以降のすべては最適化だ。そして最適化こそが楽しい部分だ。

あなたのマシン。あなたのルール。あなたの収益。

← 前へ モジュール R: 収益エンジン 次へ → モジュール E: 進化の最前線