1本に5年、次は10ヶ月で30本。月商$22,000に届いたアプリ量産への方針転換

「1本に5年」と「10ヶ月で30本」。同じ開発者が、同じスキルで出した2つの結果である。iOSエンジニアとして8年のキャリアを持つMax Artemov氏は、最初のアプリであるカロリー計算アプリを5年以上かけて伸ばそうとしたが、成果は出なかった。2025年2月に方針を変え、単一プロジェクトからポートフォリオ型へ切り替える。2025年12月10日公開のIndie Hackersのインタビュー時点で、30本超のアプリ群が合計MRR $22,000を生んでいる。

この事例で検証したいのは「たくさん作れば当たる」という粗い教訓ではない。作る順番そのものを反転させたことが、なぜ数字を動かしたのかである。

公開されている数字

なお「1本あたり平均$730」は合計を本数で割っただけの数字で、実際の分布は語られていない。本人が「初速の後に消えるアプリが大半」と述べている以上、収益は上位の数本に偏っていると考えるのが自然だが、その内訳は公開されていない。

何を作っているのか

作っているのはFlutter製の小さなアプリ群である。1本のアプリに詰め込む機能は、特定のユーザー課題を解く「コア機能ひとつ」。バックエンドはFirebaseで済ませ、収益はサブスクリプションではなく広告で回収する。有料化の設計、課金導線の最適化、価格テストといった重い仕事を最初から外している構成だ。

サポート体制も自分で全部抱えていない。ユーザーフィードバックとレビュー対応はパブリッシャー側に任せ、本人のところには実際の不具合だけが上がってくる形にしている。30本を1人で回すには、運用の固定費を下げる設計が前提になる。

潮目が変わった瞬間

転機は明確である。2025年2月、Adam Lyttle氏のYouTube動画を見たことだ。単一プロジェクトに集中するのではなく、複数アプリのポートフォリオを組むべきだという主張で、本人は「モバイルアプリに対する自分の理解が完全に変わった」と表現している。

前後の落差は極端だ。転換前は、1本のアプリに5年以上を投じて成果ゼロ。転換後は、10ヶ月で30本超を出し、合計MRR $22,000に届いた。投じたスキルも人数も変わっていない。変わったのは、何に時間を配るかの割り振りだけである。

もうひとつ、数字が動いた地点としてASOの習得がある。学習後に「インプレッション、ダウンロード、収益が50%増えた」と明言しており、量産という枠組みの中で個々の弾の当たり方を底上げしたのがこの部分だ。転機が「量産への転換」、増幅装置が「ASO」という二段構えになっている。

なぜ効いたのか、構造で分解する

表面的には「たくさん出したから当たった」に見える。だが効いているメカニズムはもう少し具体的だ。

第一に、作る順番の反転である。従来は「作りたいアプリを作る→後から集客を考える」だった。転換後は「App Store内で人気度20超・難易度60未満のキーワードを見つける→そのキーワードを中心にアプリを設計する→タイトル・サブタイトル・説明文に使う」という順序になる。需要の存在を確認してから着手するので、需要ゼロの領域に5年を溶かす事故が構造的に起きにくい。検索キーワードは、すでに人が探しに来ている場所の地図だからである。

第二に、App Storeの初速ブーストを無料の検証装置として使っている点だ。リリース直後の数日、App Storeは新作にある程度の露出を与える。多くのアプリはその後に週10〜50ダウンロードまで落ちて消える。本人はここを合否ラインとして扱う。ピークを維持しなくてもよい、急落せず一定水準で安定するなら見込みあり、という判定である。特定のダウンロード数で機械的に切るのではなく、ブースト後の挙動を1本ずつ見て判断すると述べている。つまり広告費を払う前に、プラットフォームが配ってくれる露出で需要の有無を測っている。

第三に、感情的な固着を設計で外していることだ。「ユーザーがそのアプリをどう思うかは、自分が次のアプリを作っている間に語らせればいい」「作って出して、実際のユーザーの反応次第で沈むか浮くかに任せる」と述べている。1本しか持っていない開発者は、そのアプリを諦めることが事業の終了を意味するため、撤退判断が歪む。30本あれば1本の失敗は統計上の1件でしかない。5年の固着を生んだのは技術力の不足ではなく、選択肢が1つしかない構造だった、と読める。

第四に、過剰設計をやめたことである。かつてはSOLID原則や理想的なアーキテクチャに時間を使っていたが、いまは「コア機能に必要なものだけ」に絞る。本人の助言も端的だ。「出すことを恐れるな。磨き込んだり、もう1つキラー機能を足そうと考えたりして時間を無駄にするな。バグのない状態で機能ひとつ載せて、出せ」。

うまくいっていない部分と、抱えているリスク

まず前提として、この事例は失敗期間のほうが長い。8年のキャリアのうち5年以上が、結果の出なかった1本に費やされている。カロリー計算という飽和カテゴリを選び、機能を膨らませ、設計に凝った。量産戦略はその反省の裏返しであり、最初から正解として選ばれたわけではない。

現在のモデルにも弱点がある。収益源が広告に集中しており、集客はApp Storeのアルゴリズムにほぼ全面依存している。ASOが機能する前提が変われば、30本すべてが同時に影響を受ける構造だ。本人もこのリスクを認識しており、2026年は収入を分散させるためSaaSを数本作る計画だと述べている。ポートフォリオの分散は「アプリの本数」ではなく「依存先の種類」で測るべきだ、という自己評価に読める。

また、大半のアプリは初速のブーストを超えられない前提で運用されている。30本という数字は成功の証というより、生存率が低いことを織り込んだ必要量に近い。

どこまで真似できるか

再現しやすいのは判断のルールの部分だ。キーワードの人気度・難易度に閾値を置いて着手を決めること、リリース後の挙動で継続か放置かを決めること、機能をひとつに絞って出すこと。これらは特別な資産を必要としない。ASOツールも一般に入手できる。

一方、そのまま真似できない条件もある。8年分のiOS開発経験があるため、1本あたりの開発コストが他人より圧倒的に低い。Flutterによるクロスプラットフォーム開発とFirebaseの組み合わせに習熟していることも前提だ。サポートとレビュー対応をパブリッシャーに委ねられる体制も、誰でもすぐ用意できるものではない。開発速度が半分なら、同じ10ヶ月で出せるのは15本になり、上位数本に偏る収益分布を踏まえると結果は比例しない可能性が高い。

さらに、この方法は「深く刺さる1本」を作る戦略とは相性が悪い。数を出すために機能を削り、広告で回収する設計は、単価の高いプロダクトや長期の顧客関係を前提とする事業には転用しにくい。量産は目的ではなく、需要の所在を安く探すための手段として機能している。そう読むのが、この事例の妥当な解釈だろう。

あわせて読みたい

• 1人で$100K/月に到達したPhoto AI、Pieter Levels氏の作り方
• Kindle本24冊を積み上げた個人出版の収益構造