個人開発のDogfooding戦略 — 自分のSaaSを自分で使い倒す理由

自分のSaaSスターターキットを使って、別の新しいアプリを作った。

recipe-ai というYouTube料理動画からレシピを抽出するアプリの開発に、自作のSaaS基盤（Supabase + Next.js + Stripe構成）をそのまま流用した。いわゆる「Dogfooding（ドッグフーディング）」だ。

結果、プロダクトの改善点が見つかり、ブログのネタが生まれ、「自分で使っている」という最強の信頼材料を手に入れた。この記事では、個人開発者がDogfoodingを戦略として活用する方法を、実体験ベースで解説する。

この記事でわかること:

• Dogfoodingの定義と、個人開発での意味
• recipe-ai の開発で実際に再利用できたもの・足りなかったもの
• Dogfoodingが同時に回す3つのメリット（製品改善・コンテンツ・信頼）
• 個人開発でDogfoodingを始める具体的な手順

Dogfooding とは何か

Dogfoodingとは、自分が作った製品を自分自身で日常的に使うことを指す。語源は「自社のドッグフードを自分で食べる」という英語の慣用句だ。

有名な例を挙げると、MicrosoftはWindowsの開発中に社内で未リリース版を使い続けた。Slackは自社のコミュニケーションツールとしてSlack自身を使って開発された。どちらも「自分で使うからこそ、ユーザーが感じる摩擦を先に発見できた」という共通点がある。

では個人開発者にとってのDogfoodingとは何か。

自分のプロダクト（テンプレート、ライブラリ、SaaS基盤）を使って、別のプロジェクトを実際に構築すること。

ここが大企業のDogfoodingとの違いだ。大企業は同じ製品を社内で使う。個人開発者は、自分の「基盤」を使って「別のもの」を作る。この構造の違いが、個人開発ならではの3つのメリットを生む。

recipe-ai x SaaS基盤: 実際のDogfooding体験

何を再利用できたか

recipe-ai の開発では、自作のSaaS基盤から以下をそのまま流用した。

Supabase設定一式 -- プロジェクト共用で認証・データベース・RLSポリシーの設計パターンをそのまま転用。新規でSupabaseプロジェクトを立てる必要がなく、既存の知見がそのまま使えた。

Auth認証パターン -- Supabaseの認証フローは一度書けばプロジェクト間で使い回せる。ログイン・サインアップ・セッション管理のコードがほぼコピペで動いた。

Tailwind + shadcn/ui のデザインシステム -- Editorial（角丸なし）のデザイン方針をそのまま適用。コンポーネントの見た目を一から考える時間がゼロになった。

デプロイフロー -- Vercelへのデプロイ設定、環境変数の管理パターン、CI/CDの構成。これらは一度確立すれば、新規プロジェクトでもほぼ同じ手順で動く。

何が足りなかったか

一方で、Dogfoodingだからこそ見えた「足りないもの」もあった。

AI連携テンプレートの不在 -- recipe-ai はAnthropic APIを使ってレシピを抽出する。しかし基盤にはAI連携のテンプレートがなかった。APIキーの管理、ストリーミングレスポンスの処理、エラーハンドリングのパターンを一から書く必要があった。

長時間タスクの処理パターン -- YouTube動画からの文字起こしやレシピ抽出は数十秒かかる。この「待ち時間のあるタスク」をどうUIに反映するかのパターンが基盤に含まれていなかった。ローディング状態の管理、タイムアウト処理、リトライロジックなど。

これらは「足りない」のではなく「まだ必要とされていなかった」というのが正確だ。Dogfoodingをしなければ、この2つの不足に気づくのは、外部のユーザーからクレームが来たときだっただろう。

Dogfooding の3つのメリット

1. 製品改善 -- ユーザーより先にバグと摩擦を見つける

自分で使えば、ドキュメントに書いていない前提知識や、微妙に使いにくい設定フローに気づく。recipe-ai の開発中に見つけた改善点は以下だ。

• 環境変数のセットアップ手順が暗黙知になっていた
• Supabase RLSポリシーのテンプレートが汎用性に欠けていた
• AI連携・長時間タスクという「よくあるユースケース」のテンプレートが未整備

これらは全て、外部ユーザーが「使いにくい」と感じる前に、自分で発見して修正できるポイントだ。

2. コンテンツ生成 -- 開発過程がそのまま記事になる

Dogfoodingの過程は、そのままBuild in Publicのコンテンツになる。

recipe-ai の開発では、着工日からMVP完成まで、すべての工程を記録した。「Claude Codeで0からMVPを1日で作った」という記事、「フィードバックループをTallyとSlackで設計した」という記事。これらは全て、Dogfoodingの副産物として自然に生まれたものだ。

個人開発で一番難しいのは「何を書けばいいかわからない」というコンテンツの壁だ。Dogfoodingはこの壁を完全に取り払う。作る過程が、そのまま書く素材になる。

3. 信頼構築 -- 「自分で使っている」は最強の社会的証明

「このSaaSスターターキットは便利です」と言うのと、「このスターターキットで実際にアプリを作って公開しました」と言うのでは、説得力がまったく違う。

recipe-ai は単なるサイドプロジェクトではない。SaaS基盤が実用に耐えることの「動く証拠」だ。ソースコードも開発過程も公開されているから、誰でも検証できる。

特に個人開発の世界では、実績が全てだ。テンプレートやツールを売る人は多いが、「それを自分で使って別のプロダクトを作った」と言える人は少ない。これは圧倒的な差別化になる。

で、どう稼ぐ？ -- Dogfoodingはマネタイズ戦略でもある

ここが核心だ。Dogfoodingは単なる品質管理手法ではなく、マネタイズの仕組みそのものになる。

収益への直接経路:

1. 基盤の改善 → 基盤の価値向上 -- Dogfoodingで見つけた不足を埋めるたびに、SaaS基盤の完成度が上がる。完成度が上がれば、その基盤自体の商品価値も上がる。

2. 開発記録 → 有料コンテンツの素材 -- 開発過程で書いた記事が蓄積されると、それ自体が「個人開発の実践ガイド」という有料コンテンツの素材になる。ノウハウ記事を単品で販売することも、体系化してまとめることもできる。

3. 信頼の蓄積 → 高単価商品への導線 -- 「自分で使って検証した」という信頼が積み重なると、より高単価な商品（有料記事、サブスク型サービス）への転換率が上がる。

つまりDogfoodingは、1つの行動（自分で使う）から3つの資産（改善された製品・コンテンツ・信頼）が生まれ、それぞれが別の収益チャネルに接続する構造だ。個人開発者がリソースの少なさを補うには、こういった「1アクション3アウトプット」の戦略が不可欠になる。

個人開発でDogfoodingを始める方法

ステップ1: 自分のツールで小さなプロジェクトを作る

大きなものを作る必要はない。自分のテンプレート、ライブラリ、SaaS基盤で「1日で動くMVP」を作れるかを試す。recipe-ai のように、技術的に新しい要素（AI連携など）を1つだけ加えると、基盤のどこが足りないかが明確になる。

重要なのは「売れるかどうか」ではなく「自分の基盤で実際に動くものを作れるか」だ。

ステップ2: 開発過程を記録する

コードを書く前に「何をするか」、書いた後に「何がうまくいって何が駄目だったか」を記録する。この記録がそのままブログ記事やSNS投稿の素材になる。

特に記録すべきは以下の3点だ。

• 再利用できたもの -- 基盤の価値を証明する素材になる
• 足りなかったもの -- 基盤の改善ロードマップになる
• かかった時間 -- 「スターターキットを使えばN時間でMVPが作れる」という定量的な証拠になる

ステップ3: フィードバックをプロダクトに反映する

Dogfoodingで見つけた改善点を、実際に基盤へ反映する。recipe-ai で見つけた「AI連携テンプレートの不在」は、そのまま次のアップデートの優先タスクになる。

この「使う → 発見する → 改善する → また使う」のサイクルが回り始めると、製品は加速度的に良くなる。外部のフィードバックを待つよりも遥かに速い。

まとめ

Dogfoodingは、個人開発者が限られたリソースで「製品改善・コンテンツ生成・信頼構築」を同時に回す戦略だ。自分のSaaS基盤で別のアプリを作るという1つの行動が、3つの資産を生む。「作れるけど売れない」を突破する鍵は、作る行為自体を売る仕組みに変えることにある。

関連記事

Claude Code で 0→MVP を1日で作る全記録

recipe-ai Build in Public の全工程を公開

→

個人開発者よ、作るのをやめて売ることを始めよう

「作れるけど売れない」から脱出するための思考転換

→

個人開発AIアプリのフィードバックループ設計

Tally x Slack x Build in Public の実装

→