長文コンテンツをソーシャル投稿に変換する、1人で開発されたAIツールが、年間経常収益（ARR、継続課金の年間換算額）$100万に達したと伝えられています。ほかの創業者にとってより参考になるのは、製品がどのように形づくられたかです。創業者はコードを書く前に関心の有無を確かめ、広すぎる構想を中核となる1つの作業に絞り込み、その後は顧客が実際にどう使うかを観察しました。収益の数字はこの事業のものであり、ほかの人が同じ結果を期待できるものではありません。
製品より先に関心を確かめた
出発点は、ブログ記事やYouTube動画などの素材を、ほかのプラットフォーム向けの短い投稿に変換するというアイデアでした。2024年8月1日、創業者はこの作業の流れをTikTokの投稿で説明し、実際に困っている課題かどうかを問いかけました。関心を示すコメントは200件を超えました。
こうしたコメントは調べを進める理由にはなっても、人々がお金を払う証拠にはなりません。創業者はダイレクトメッセージで追加の質問を送り、聞き取りのための通話やチャットを20件未満行いました。質問の内容は、現在どのようにコンテンツを再利用しているか、どのツールを使っているか、いくら支出しているか、どのプラットフォームを重視しているかです。これにより、創業者自身の必要性だけに頼るよりも具体的な出発点が得られました。
最初の版を小さくして構想を検証可能にした
当初の製品計画は大がかりなもので、コンテンツの取得元との連携、顧客のブランドの語り口に関する情報、AIによる選別、多数のプラットフォームへの配信が含まれていました。開発に入る前に、創業者は紙のワイヤーフレーム上で副次的な機能に線を引いて消しました。こうしてできたMVP（Minimum Viable Product、中核となる作業を検証するための最小限の版）は、1つのテキストを受け取り、FacebookとTwitter向けの投稿を、OpenAIのDALL-E 2で作った画像とともに生成するものでした。画像の出来は粗かったものの、最初の版で作業の流れは検証できました。
▲ 絞り込んだ最初の製品のワイヤーフレーム
創業者はAIコードエディターのCursorを使い、最初の版のコードを生成しました。これは「バイブコーディング」の一例です。綿密に設計したコードベースから始めるのではなく、AIを使ってプロトタイプの大部分を素早く作る手法を指します。最初のランディングページには$60のWebflowテンプレートを使いました。範囲を絞り、安価な構成にしたことで、構想全体を作り込む前に動く製品を人々に試してもらえました。
アーリーアダプター向けのプログラムは、この計画を複雑にしました。2024年10月1日、創業者はGoogleフォームを通じて、先着50人の応募者に生涯割引と優先サポートを提供しました。アンケートでは投稿先のプラットフォームや作業上のボトルネックを尋ねましたが、申告されたニーズが実際に見える行動と食い違うことがありました。ある例では、InstagramとLinkedInの間で投稿を使い回していると答えた人の実際の活動はTikTokが中心で、再利用された投稿は見当たりませんでした。グループ全体の要望も、ポッドキャストの切り抜きや顔出しなしの自動化など、別々の製品の方向へ引っ張り合いました。
この経験は、待機リストを1つの顧客像として扱うことの限界を示しています。創業者は、グループ内で競合する要望を長々と調整するよりも、一般公開を優先する考えに至りました。これはアンケートの回答がすべて間違っていたという意味ではありません。申告された好みだけでは、この製品が何をすべきかを決められなかったということです。
シンプルなローンチで支払い意思を確かめた
2024年10月20日の一般公開では、5分間のYouTubeでの製品紹介、既存のニュースレター読者へのメール、TikTokの投稿、LinkedInの投稿を使いました。この既存の読者層は、この事例の重要な要素でした。読者層を持たずに始める創業者には得られない露出を、製品にすぐもたらしたからです。
ローンチは洗練されたものとはほど遠い状態でした。メール内のリンクが壊れていたため、読者は予定していた製品紹介を開けませんでした。モバイルでは表示が崩れ、Apple PayとAmazon Payの決済手段は機能せず、カレンダーの招待には会議のリンクがありませんでした。こうした問題は余分な手間と摩擦を生みました。一方で、リンクをたどる、登録を試みる、支払いを試みるといった顧客の行動は、フォームで示された関心よりも多くのことを教えてくれました。
一般公開から10日以内に、製品の月間経常収益（MRR、継続課金の月額換算）は$1万に達したと伝えられています。当初の価格は月$49で、その後、海外の顧客や自己資金で事業を営む創業者を念頭に引き下げられました。初期のMRRも、その後の$100万のARRも、この製品の読者層、顧客の需要、継続的なマーケティングがなくても同じようにシンプルなローンチが成功することを裏付けるものではありません。
利用状況が作り直しを導いた
ローンチ後、創業者はPostHogのセッション録画（利用者が製品内をどう動いたかを再生する機能）を使い、オンボーディングの各段階の間で利用者がどこで止まっているかを探りました。最初の2か月間、開発の中心はこの流れを滑らかにすることでした。サポートはIntercomのチャットウィジェットで対応しましたが、個別のオンボーディング通話は時間がかかりすぎて続けられないと感じていました。
▲ オンボーディングの摩擦の確認
有料ユーザーの登場で、コードへの向き合い方が変わりました。AIが生成した最初の版は需要を確かめる役割を果たしましたが、その構造は長期的に通用するものではありませんでした。創業者はNext.js、Fastify、Supabase、Herokuでバックエンドを作り直し、意図的なアーキテクチャ設計、テスト、分かりやすい命名、ドキュメントを加えました。費用が月$600まで膨らんでいたWebflowのサイトは、Claudeで設計しVercelにデプロイしたAstroのサイトに置き換えました。サポートをIntercomからn8nによる自動化ワークフローに移したことで、この事業では月におよそ$1,300を節約できました。
ここで区別すべきなのは、検証できる製品を世に出すためにAIを使うことと、顧客がその製品に頼るようになった後、より管理された開発プロセスの中でAIを使うことです。後の作り直しは、需要を最初に証明する段階の一部ではなく、その証明を受けて行われたものでした。
成長には継続的な取り組みが必要だった
伝えられている収益の推移は、急激に跳ね上がるのではなく着実に伸びました。12月下旬から1月にかけては横ばいの時期があり、この間、創業者はスキーのためにマーケティング活動を止めていました。創業者は顧客を集めるため、チュートリアルやソーシャル向けコンテンツも作り続けていました。この事例では、経常収益があるからといって顧客獲得が自然に回っていたわけではありません。
実践的な順序は、見込み客と一緒に具体的な課題を検証し、中核となる作業を試せるだけのものを作り、ローンチ後に人々が実際に何をするかを観察することです。顧客がお金を払うなら、その証拠をもとに、より良い開発体制や運用コストの削減がどこで重要になるかを判断します。節目の数字は、新しいAI事業の収益目標としてではなく、それを生んだ条件、特に既存の読者層と継続的なコンテンツ制作と合わせて読むべきです。