個人開発で何を作る？ゲーム・便利アプリ・Webツールの需要を作る前に調べる方法

自分には面白く見えない商品が売れる理由を整理し、ゲーム、便利アプリ、Webツール、記事、テンプレートごとに、検索・競合・訴求・利用・課金を検証する手順をまとめます。

読書機能の使い方

聴く：本文を読み上げます。速読：語句を順に表示し、速さを調整できます。語学練習：別の言語版と対訳を読み比べます。保存：このブラウザーにブックマークし、プレイヤーの保存済み一覧から開けます。

この記事をシェア

LINEで共有（新しいタブで開きます）Xで共有（新しいタブで開きます）

自分が「面白くなさそう」と感じても、その商品が売れないとは限りません。

ゲームは面白さと継続、便利アプリは手間の削減、Webツールは検索される問題、テンプレートはすぐ使える完成物が買われます。商品ごとに売れる理由が違うため、自分の好みだけで需要を判断すると外れます。

個人開発で確認すべきなのは、市場が大きいかだけではありません。

誰が使うのか。
その人へ一人で届くのか。
実際に使い続けるのか。
お金が残るのか。
保守で自分の時間を食い潰さないか。

ここまで確認して、初めて「個人開発として需要がある」と判断できます。

この記事を検索する人

個人開発で次に何を作るか決められない人
アイデアは多いが、売れるか分からない人
アプリを公開したが、ほとんど使われなかった人
ゲームと便利アプリを同じ基準で評価している人
日本向けと英語圏向けを分けて検証したい人

検索直前に起きていること

自分には退屈に見える商品が売れていて、判断基準が分からなくなった
作りたいものと、売れそうなものが一致しない
競合調査をしても「競合がいる」以上のことが分からない
作る前にどこまで調査すればよいか知りたい
アンケート以外の強い需要証拠が欲しい

この記事が答える一つの問い

個人開発では、何をどの順番で調べれば、作る前に需要と採算を判断できるのか。

AIは記事の主題ではなく、調査、集計、試作を速める補助手段として扱います。

1. 「自分には刺さらない」と「市場に需要がない」は別

開発者は、アイデアを次のような基準で見やすくなります。

新しいか
技術的に難しいか
自分が使いたいか
作っていて楽しいか
発想が賢く見えるか
画面が格好いいか

しかし、利用者は別の基準で選びます。

今すぐ面倒を減らせる
退屈な時間を潰せる
好きなものを集められる
短時間で完成物を作れる
同じ失敗を防げる
不安な状態を抜けられる
他人と遊べる
無料の方法より少し楽になる

たとえば、画像を一括で小さくするツールに、技術的な驚きはほとんどありません。

それでも、毎週50枚の画像を処理する人には価値があります。ゲームも同じです。自分には単調に見える育成や収集が、別の利用者には毎日起動する理由になります。

したがって、自分の感度は次のように使います。

自分の感度は、候補を見つけるために使う。
作るかどうかは、他人の行動で決める。

2. 個人開発では「需要」だけでは足りない

企業なら、大きな市場へ営業、広告、ブランド、既存顧客を使って入れます。

個人開発者には、その手段がないことが多いです。そのため、需要があっても次のどこかで止まります。

発見されない
商品を必要とする人はいるが、自分の商品ページまで来ない。
使われない
インストールや登録はされたが、価値が分かる前に離脱する。
払われない
便利だが、無料の代替で十分と思われる。
残らない
売上より、広告費、API費、サーバー費、問い合わせ時間の方が大きい。

個人開発としての価値は、次の掛け算で考えます。

個人開発としての価値
= 需要
× 到達可能性
× 利用継続
× 収益性
× 維持可能性

どれかがほぼゼロなら、他が強くても事業になりません。

巨大市場に入ることよりも、一人で届く小さな市場を、低い固定費で取ることの方が重要です。

3. 最初に商品を分類する

ゲーム、便利アプリ、記事、SNSを同じ基準で調べてはいけません。

まず、その商品が何を売るのかを決めます。

種類	利用者が買うもの	作る前の強い証拠	公開後の重要指標
ゲーム	面白さ、成長、収集、競争、交流	動画反応、体験版、ウィッシュリスト	プレイ時間、完了率、D1・D7継続
便利アプリ	時間短縮、操作削減、失敗防止	検索語、競合レビュー、既存の代替行動	主機能完了、再利用、課金
Webツール	検索した瞬間の問題解決	Google検索、関連語、上位サイトの弱点	検索流入、処理完了、再訪
記事・メディア	答え、比較、体験、読み物	検索意図、SNS反応、既存記事の不足	読了、内部リンク移動、再訪
テンプレート	すぐ使える完成物	同じ作業の反復、配布物への登録	購入、利用、追加購入
制作アプリ	作った画像、動画、文章、音声	作例への反応、保存、共有	完成率、書き出し、共有、課金
習慣・生活改善	継続による変化	課題の反復、既存の記録行動	D7・D30、記録回数、更新
拡張機能	特定画面での操作削減	コミュニティの不満、反復作業	有効化、週次利用、権限離脱
SNS・マッチング	他人がいること	初期参加者の事前確保	投稿、返信、成立率、健全性

分類できないアイデアは、価値が混ざりすぎています。

たとえば「AIで学習も相談もSNSもできるアプリ」は、何を検証すればよいか分かりません。最初は「試験問題を1問撮ると、間違えた理由だけ説明する」のように、利用場面を一つに絞ります。

4. 需要証拠には強さの順番がある

需要調査では、意見と行動を同じ重さで扱いません。

レベル1：言葉だけ

面白そう
欲しい
使ってみたい
あれば便利
応援する

候補を残す材料にはなりますが、開発決定の証拠には弱いです。

レベル2：他人がすでに困っている

同じ質問が繰り返し検索されている
競合アプリにレビューが付いている
無料のExcel、メモ、手作業で代用している
SNSや掲示板で方法を聞いている
競合の低評価レビューに同じ不満が並ぶ

ここで初めて、問題が自分の頭の中だけではないと分かります。

レベル3：少し手間を払った

広告や投稿をクリックした
LPを読んだ
メールを登録した
事前登録した
ウィッシュリストへ入れた
無料サンプルを受け取った
テスターへ応募した

「欲しい」と言うだけでなく、行動が発生しています。

レベル4：時間を使った

体験版を遊んだ
主機能を完了した
テンプレートを実際に使った
翌日も戻った
1週間後も利用した
他人へ共有した

商品に価値がなければ、利用者は戻りません。

レベル5：お金を払った

買い切りを購入した
有料予約した
サブスクを開始した
更新した
追加商品を買った
値上げ後も残った

最も強い証拠です。

需要調査の目的は「褒めてもらうこと」ではありません。証拠を一段ずつ強くすることです。

5. ガチガチに調べる手順

Step 0：先に合格条件を決める

調査を始める前に、何をもって作るかを決めます。

例：

調査期間：7日
候補：3案
開発上限：初版14日
月額固定費上限：3,000円
問い合わせ上限：週1時間
合格条件：
- 検索またはコミュニティで同じ課題を20件以上確認
- 競合の同種不満を30件以上確認
- LP訪問100人以上
- 登録またはテスター応募5%以上
- 価格表示後の登録2%以上

数字は商品の種類と流入量で変えます。

重要なのは、結果を見てから基準を下げないことです。作りたい気持ちが強いと、「3人が反応したから需要がある」と都合よく解釈しやすくなります。

Step 1：利用場面を一文で書く

悪い例：

写真を便利にするアプリ

良い例：

フリマ出品前に、スマホ写真20枚を同じ比率へ一括で切り抜く。

悪い例：

気軽に遊べるゲーム

良い例：

1回10分で終わり、負けるたびに新しい組み合わせを試せる一人用カードゲーム。

次の5項目を埋めます。

誰が：
いつ：
何をしようとして：
今は何を使っていて：
何が嫌なのか：

ここが書けなければ、検索語、競合、広告文、MVPを決められません。

Step 2：日本語と英語を別々に検索する

日本語を英訳しただけでは、米国の需要調査になりません。

同じ課題でも、検索される言葉、競合、料金、使われる端末、説明の順番が違う可能性があります。

日本向けに調べるもの

Googleの検索候補
Google Trendsの日本設定
日本語のApp Store・Google Play検索
Yahoo!知恵袋、教えて!goo、価格.com、専門掲示板
X、YouTube、ブログ
日本語レビュー
日本円の価格帯
日本語での具体的な困り方

米国・英語圏向けに調べるもの

Google TrendsのUnited States設定
英語のApp Store・Google Play検索
Reddit、YouTube、Discord、専門フォーラム
Chrome Web Store、Steam、Product Huntなど対象に合う販路
英語レビュー
米ドルの価格帯
英語利用者が使う問題名

たとえば、日本語で「写真容量小さくする」と検索されても、英語では compress photos、reduce photo file size、batch resize images が別の需要として存在します。

単語を直訳するのではなく、利用者が問題をどう呼んでいるかを調べます。

Google Keyword Plannerは関連キーワード、検索見込み、広告費の参考値を確認できます。[1] ただし、数字だけで採用せず、検索結果と実際の競合も見ます。

Step 3：競合表を作る

上位5件から10件を表にします。

項目	競合A	競合B	競合C
対象者
一番強い訴求
無料範囲
価格
課金方式
主な流入
レビュー数
最近の更新
高評価理由
低評価理由
標準機能との差
自分が埋められる穴

競合がいること自体は悪くありません。利用者がすでに商品を探し、場合によっては支払っている証拠です。

危険なのは、次の状態です。

強い無料サービスで完全に解決している
OS標準機能が急速に改善している
差を作るには大規模なデータや運営が必要
低価格なのに問い合わせが多い
広告以外の流入がほぼない
上位商品に不満はあるが、誰も乗り換えていない

Step 4：レビューを「不満」ではなく「乗り換える理由」で読む

低評価レビューを見つけただけで、需要があるとは限りません。

次の4種類に分けます。

直せば乗り換えそうな不満

操作が多い
一括処理できない
オフラインで動かない
日本語が分かりにくい
欲しい形式へ書き出せない
買い切りがない
データ移行ができない

直しても売上になりにくい不満

完全無料にしてほしい
広告を全部消してほしい
すべての機能を無料にしてほしい
一度しか使わないがサブスクは嫌
高価な外部APIを無料で使いたい

個人では重すぎる不満

24時間サポートしてほしい
全端末の同期を保証してほしい
大量の権利物を用意してほしい
不正ユーザーを常時監視してほしい
法的判断を自動で保証してほしい

本当の問題ではない不満

本人が説明を読んでいない
端末固有の問題
商品の対象外用途
一時的な障害
競合への攻撃目的と思われる投稿

数を集めた後で、自分が直せて、利用者が乗り換え、料金を取れる不満だけを残します。

Step 5：代替手段を調べる

競合はアプリだけではありません。

利用者は次の方法で済ませているかもしれません。

OS標準機能
Excel、Googleスプレッドシート
ChatGPTなどの汎用AI
メモ帳
手作業
無料Webサイト
家族や同僚へ頼む
何もしない
問題を我慢する

便利ツールの場合、最大の競合は「面倒だが今の方法で済ませる」です。

次を確認します。

今の方法に何分かかるか：
月に何回発生するか：
失敗した場合の損失：
新しいツールへ移る手間：
データ移行の必要：
無料で我慢できる程度か：

問題が大きくても、年に一度しか起きないならサブスクには向きません。反対に、1回2分の面倒でも毎日発生すれば、継続利用される可能性があります。

Step 6：作る前に商品ページだけ試す

アプリがなくても、訴求は試せます。

作るもの：

商品名
一文説明
利用前と利用後
画面モック3枚
無料範囲
価格案
登録、予約、テスター応募ボタン

複数の言い方を比べます。

便利アプリの例：

画像を高性能に処理
写真20枚を、同じ大きさへ一括変換
アップロードなし。スマホ内だけで写真を縮小

ゲームの例：

新感覚ローグライク
10分で終わる。一手ごとに敵の予定が見えるカードゲーム
負けたカードが、次の挑戦で武器になる

「高性能」「新感覚」では、何が起きるか分かりません。利用者が自分の場面を想像できる文を試します。

AppleのProduct Page Optimizationでは、アイコン、スクリーンショット、プレビューの代替案を最大3つ比較できます。[2] Google Playにも、国や流入元などに合わせたカスタムストア掲載情報があります。[3] つまり、商品そのものだけでなく、誰に何を見せるかも検証対象です。

Step 7：ゲームは「悩み」ではなく、遊んだ行動で判定する

ゲームでは、検索数や困り事の強さだけで採用しません。

作る前：

10秒から30秒のプレイ動画
画面モック
一文説明
小さなプロトタイプ
ストアページ
ウィッシュリスト

試作後：

起動率
チュートリアル完了率
最初の1ゲーム完了率
平均プレイ時間
2回目のプレイ率
D1継続
D7継続
難所ごとの離脱
感想ではなく、再起動した人数

Steam Playtestは、レビューやSteamキーの管理を本編と分けながらプレイテストデータを集めるための仕組みです。[4] Steamのウィッシュリストは、発売や値引き時の通知にも使われます。[5]

ただし、ウィッシュリストだけで成功とは判断しません。

見た → 欲しいと思った
欲しいと思った → 体験版を遊んだ
遊んだ → 最後まで続けた
続けた → 翌日も戻った
戻った → 購入した

この変換を一段ずつ見ます。

Step 8：便利アプリは「一回で消える問題」を見分ける

便利アプリは、問題が明確なのでインストールされやすい一方、解決した直後に消されやすいです。

次のどれに当たるか確認します。

一回利用型

引っ越し時の計算
一度だけのファイル変換
特定イベント用の画像作成
端末移行

向く収益：

買い切り
1回課金
広告
関連商品への送客

反復利用型

毎週の画像処理
日々の記録
定期的な請求管理
継続的な学習
仕事で使う変換

向く収益：

買い切り上位版
サブスク
チーム版
継続広告

データ蓄積型

家計
健康
日記
コレクション
学習履歴

継続理由は作りやすい一方、データ保護、バックアップ、移行、問い合わせが重くなります。

サブスクを付ければ成功するわけではありません。RevenueCatの2026年レポートは、11万5,000以上のサブスクリプションアプリを集計し、同じ市場でも成長や転換に大きな差があることを示しています。[6] 自分の商品は、自分のカテゴリ、価格、国、ストアに近い数字で比較します。

Step 9：記事とWebツールは「検索者の次の行動」を見る

記事のPVだけでは、事業として強いか分かりません。

記事の場合：

検索結果で表示
→ クリック
→ 冒頭で答えを得る
→ 必要な箇所まで読む
→ 関連記事へ移る
→ ツールやアプリを使う
→ 再訪する

Webツールの場合：

検索
→ ツール到達
→ 入力
→ 処理完了
→ 結果保存
→ 次回も直接訪問
→ 広告、課金、関連ツールへ移る

「検索される記事」と「ツールへ送客する記事」は役割が違います。

個人開発サイトでは、次のように分けると管理しやすくなります。

入口記事：検索される疑問に答える
比較記事：複数の解決方法を比べる
使い方記事：自分のツールの利用を助ける
実行ページ：アプリ、Webツール、テンプレート
回遊記事：近い悩みへ内部リンクする

記事数を増やすことを目的にしません。同じ検索者、同じ結論、同じチェックリストの記事は統合します。

Step 10：価格を隠した登録だけで合格にしない

無料なら登録する人は多くても、価格を出すと止まることがあります。

最低でも次の3案を比べます。

A：完全無料・広告あり
B：買い切り
C：月額または年額

価格を表示した状態で、次を測ります。

登録率
購入ボタン到達
購入開始
購入完了
返金
更新
解約理由

「欲しい」と「この価格で買う」は別です。

AI API、画像生成、音声処理など変動費がある場合は、利用回数が増えるほど赤字になることがあります。

1人当たり粗利益
= 1人当たり売上
- ストア・決済手数料
- API費
- ストレージ費
- サポート時間の原価

6. 日本向けと米国向けは、別の仮説として試す

日本語版と英語版を作るだけでは不十分です。

日米で次の項目を別々に記録します。

項目	日本	米国
問題を表す検索語
最も使われる競合
無料の代替
一番反応する説明
価格表示	円	ドル
買い切り・月額・年額の反応
主な流入元
端末・ストア
不安要素
継続理由

日本人は必ず買い切りを好む、米国人は必ずサブスクを受け入れる、といった決めつけはしません。

各国で次を独立して試します。

検索語
スクリーンショット
最初の一文
価格
無料範囲
プライバシー説明
CTA
継続率
返金、解約

Google Playのカスタムストア掲載情報は、国、特定キーワード、事前登録者などのユーザー区分に合わせた表示を作れます。[3] Appleのテストも、対応言語ごとに素材を検証できます。[2]

つまり、「英語へ翻訳して海外公開」ではなく、次の順番にします。

日本の問題仮説
→ 日本語の訴求
→ 日本の利用データ

米国の問題仮説
→ 英語の訴求
→ 米国の利用データ

両者の結果が違っても正常です。

7. なぜ「つまらなそうな商品」が売れるのか

自分には面白く見えないのに売れている商品は、次のどれかを持っています。

すでに検索されている

利用者が困った瞬間に、自分から商品を探します。

開発者が需要を教育する必要がありません。

小さい手間が何度も起きる

1回2分でも、毎日なら月1時間です。

面白さがなくても、反復が価値を作ります。

対象者には結果が分かりやすい

写真が小さくなった
PDFになった
アラームが鳴った
記録が残った
キャラクターが育った
テンプレートが完成した

利用前と利用後が明確です。

販路をすでに持っている

売れている理由が商品ではなく、SEO、SNS、YouTube、既存アプリ、メルマガかもしれません。

表からは見えない流通資産があります。

複数商品の合計で成立している

1本で大成功しているとは限りません。

小さな売上を出すツールが複数あり、合計で事業になっている場合があります。

開発者の人件費が表に出ていない

月1万円の売上でも、ほぼ放置なら残す意味があります。

逆に月10万円でも、毎日対応が必要なら割に合わないことがあります。

したがって、売上だけを見て真似しません。

利益
= 売上
- 現金費用
- 維持時間
- 集客時間
- 将来の修正負債

8. 個人開発向きかを100点で採点する

共通採点

項目	配点	確認すること
到達可能性	20	SEO、ストア検索、SNS、コミュニティなど、一人で届くか
実在する需要	15	検索、質問、競合利用、代替行動が確認できるか
行動証拠	15	クリック、登録、体験、再訪などが出ているか
収益導線	15	買い切り、広告、サブスク、送客のどれで回収するか
継続・再購入	10	反復利用、更新、追加購入が起きるか
開発負担	10	価値の核を短期間で公開できるか
維持負担	10	問い合わせ、API、法務、障害対応が軽いか
自分との相性	5	半年後も最低限の保守ができるか
合計	100

判定

80点以上：小さく販売・公開テストへ
65〜79点：弱い項目を一つ検証してから判断
50〜64点：実装せず、訴求または対象者を変更
49点以下：保留または終了

点数に関係なく止める条件

法律、医療、金融の判断を保証する必要がある
人が集まらないと価値がゼロになるが、初期集客手段がない
無料の標準機能と差がない
API原価を価格で回収できない
常時監視や即時サポートが必要
一つのプラットフォーム変更で全機能が止まる
個人情報や重要データを扱うのに、保護体制を持てない
初版の価値を出すまで数か月かかり、途中検証ができない

9. 商品別の追加合格条件

ゲーム

10秒動画だけで遊び方が分かる
体験版の最初の1ゲーム完了率を測れる
2回目を遊ぶ理由がある
一人で作れるコンテンツ量か
発売後の更新を止めても商品として残るか

便利アプリ・Webツール

問題を検索する言葉がある
標準機能より明確に速い
入力から結果まで短い
一回利用か反復利用か分かっている
保存するデータを最小化できる

記事・メディア

一記事一問になっている
冒頭200字以内に答えがある
検索上位と違う情報がある
関連記事またはツールへの次の導線がある
同じ結論の記事を増やしていない

テンプレート

購入直後に使える
説明なしでも入力箇所が分かる
無料サンプルで価値を見せられる
更新を頻繁に要求されない
アプリを作るより早く解決できる

拡張機能

対象サイトで操作が週1回以上発生する
必要権限を説明できる
対象サイトの変更に追従できる
ストア規約違反の危険が低い
対象サイトが機能を標準搭載しても別価値が残る

10. 7日間の需要調査スプリント

1日目：利用場面を3案作る

各案について、次を書く。

対象者：
発生する場面：
現在の代替：
一番嫌なこと：
約束する結果：
収益方法：
流入元：

2日目：日米の検索と競合を調べる

日本語キーワード10個
英語キーワード10個
日本の競合5件
米国・英語圏の競合5件
各競合の価格、レビュー、不満
無料代替

3日目：レビューを50件読む

最低でも次へ分類します。

乗り換え理由になる：
無料要求だけ：
個人では対応不能：
操作説明の問題：
新しい機能候補：

4日目：商品ページを3案作る

変えるもの：

一文説明
最初の画像
価格
無料範囲

一度に全部変えると原因が分からないため、比較する軸は一つか二つにします。

5日目：少額で反応を集める

既存サイト
SNS
コミュニティ
小額広告
テスター募集
ウィッシュリスト
無料サンプル

投稿禁止や宣伝禁止の場所へ無理に貼りません。

6日目：数字を比較する

表示：
クリック：
LP到達：
登録：
価格表示後の登録：
テスター応募：
離脱場所：
国：
端末：
流入元：

7日目：作る、変える、捨てる

感想ではなく、最初に決めた合格条件で判定します。

合格：核だけ実装
惜しい：訴求または対象者を1回だけ変更
不合格：終了
保留：将来の別商品と組み合わせる

「せっかく調べたから作る」は禁止です。

調査で捨てられたなら、開発時間を守れたということです。

11. 公開後は売上ではなく、詰まっている場所を見る

アプリ

ストア表示
→ 商品ページ閲覧
→ インストール
→ 初回起動
→ 主機能完了
→ 翌日再訪
→ 課金画面
→ 購入
→ 更新

Webツール

検索表示
→ クリック
→ 入力開始
→ 処理完了
→ 結果保存
→ 再訪
→ 広告・課金・関連ページ

ゲーム

動画視聴
→ ストア移動
→ ウィッシュリスト
→ 体験版
→ 最初のプレイ完了
→ 2回目
→ D1
→ 購入

たとえば、ダウンロードが少ないときでも原因は別々です。

表示されていない
説明が刺さらない
価格が怖い
初回操作が分からない
一度使えば終わる
使う場面を思い出せない

売上だけを見ると、どこを直すべきか分かりません。

12. 需要調査シート

以下をアイデアごとに埋めます。

# 個人開発需要調査シート

## 1. 商品の種類

- [ ] ゲーム
- [ ] 便利アプリ
- [ ] Webツール
- [ ] 記事・メディア
- [ ] テンプレート
- [ ] 制作アプリ
- [ ] 習慣・生活改善
- [ ] 拡張機能
- [ ] SNS・マッチング
- [ ] その他

## 2. 利用場面

誰が：
いつ：
何をしようとして：
現在の代替：
現在の方法で嫌なこと：
約束する結果：

## 3. 日本の需要

日本語検索語：
検索結果上位：
競合：
価格：
よくある不満：
無料代替：
主な流入元：

## 4. 米国・英語圏の需要

英語検索語：
検索結果上位：
競合：
価格：
よくある不満：
無料代替：
主な流入元：

## 5. 行動証拠

- [ ] 同じ質問を20件以上確認
- [ ] 競合レビューを50件以上確認
- [ ] LPを公開
- [ ] 価格を表示
- [ ] 登録が発生
- [ ] テスター応募が発生
- [ ] 体験利用が発生
- [ ] 翌日再訪が発生
- [ ] 支払いが発生

## 6. 収益

課金方式：
予定価格：
1人当たり変動費：
月額固定費：
必要購入者数：
返金・解約リスク：

## 7. 開発と運用

初版までの日数：
必要な外部API：
保存する個人データ：
問い合わせ想定：
プラットフォーム依存：
終了時のデータ処理：

## 8. 採点

到達可能性 /20：
実在する需要 /15：
行動証拠 /15：
収益導線 /15：
継続・再購入 /10：
開発負担 /10：
維持負担 /10：
自分との相性 /5：

合計 /100：

## 9. 判定

- [ ] 作る
- [ ] 訴求を変えて再試験
- [ ] 対象者を絞る
- [ ] テンプレートや記事として先に出す
- [ ] 終了

判定理由：
次に確認する数字：

13. 結論

自分が面白いと思うかは、個人開発の候補を出すには役立ちます。

しかし、採用判断には足りません。

ゲームは、遊んだ時間と再起動で判断する。
便利アプリは、検索される問題と反復利用で判断する。
Webツールは、処理完了と再訪で判断する。
記事は、検索者の疑問と次の導線で判断する。
テンプレートは、購入直後に使えるかで判断する。

日本向けと米国向けも、翻訳だけで一つにしません。検索語、競合、価格、訴求、利用データを別々に取ります。

個人開発で強いのは、最も面白い大作とは限りません。

自分一人でも利用者へ届く。
短期間で価値の核を出せる。
使った人が戻る。
お金が残る。
保守で自由時間を失わない。

この条件を満たす、小さくて具体的な商品です。

自分の感度で候補を作り、他人の行動で採否を決める。それが、個人開発の需要調査です。