元記事
記事タイトル：Grinding to $1,000,000 in revenue over 6 years
掲載サイト：Jason McCreary氏個人ブログ（jasonmccreary.me）
著者・創業者：Jason McCreary氏
公開日：2021年11月23日
URL：https://jasonmccreary.me/articles/grinding-to-million-dollar-revenue-saas/
記事タイトル：Turning a developer tool into a $50k MRR lifestyle business
掲載サイト：Indie Hackers
著者：James Fleischmann氏（インタビュアー）／創業者：Jason McCreary氏
公開日：2026年6月30日
URL：https://www.indiehackers.com/post/tech/turning-a-developer-tool-into-a-50k-mrr-lifestyle-business-9GL6b2gcc31LXjx7g3yC
Shiftは、PHPフレームワーク「Laravel」のメジャーバージョン間のアップグレード作業を自動化するサービスです。リポジトリを接続すると、変更点をまとめたプルリクエストが自動生成される仕組みで、創業者のJason McCreary氏が一人で10年以上運営しています。
売上や実行回数、継続率などの数字は創業者本人の申告に基づくもので、第三者による監査を受けた数値ではありません。両記事とも第三者からのスポンサー関係は明記されていません。
3分で要約
McCreary氏は長年PHPを書いてきたプログラマーです。2015年のカンファレンスでLaravelの作者Taylor Otwell氏に「アップグレード用のスクリプトはあるか」と聞かれて「ない」と答えたところ、「あったら使う」と返されたことが開発のきっかけになりました。
最初の商品は、カンファレンス会場のハッカソン一晩で書いたPHPとシェルスクリプトです。GitHubと連携し、Stripeで決済すると、バージョン間の差分を反映したプルリクエストが自動で届く仕組みで、2015年12月23日にローンチしました。
価格は1回のアップグレードにつき3〜7ドルという極めて低い設定で、初月の売上は80ドル・約20回の実行にとどまりました。その後もカンファレンス登壇のたびに売上が跳ねる一方、2017年前後は本業のコンサル契約を優先したため、月3,000〜5,000ドルで足踏みが続きました。
転換点は2018年のカンファレンス登壇後に月間最高6,315ドルを記録し、専業化を決めたことです。2019年に価格を「新しいバージョンほど安く、古いバージョンほど高い」段階制に変えたところ収益が大きく伸び、同時にサブスクリプションも導入しました。2020年に年商26.7万ドル、2021年11月には創業からの累計売上100万ドルに到達しています。
10年目にあたる時点では、月次経常収益(MRR)は5万ドル、累計の実行回数は17.5万回に達しています。「1回いくらの単発アップグレード代行」から始まり、そこにサブスクリプションを足しながらも、単発課金と定額課金が併存する構造に落ち着いた点が特徴です。
主要な収益モデル
収益＝(単発アップグレードの実行回数×バージョンごとの単価)＋(サブスクリプション契約者数×月額)－サーバー・インフラ費－外部協力者への時間契約費－本人のサポート対応時間
単価は最新バージョンほど安く(9ドル)、古いバージョンほど高く(29ドル)なる設計です。これは需要の強さではなく供給側のコスト構造を反映したもので、古いバージョンほど差分が大きく、自動化ルールも複雑になるためです。
顧客が増えても増えるコストは、新しい変更に対応するルールの追加開発と、サポートメールへの返信くらいで、サーバー費用の限界費用はごくわずかです。運営コストは月100ドル程度と本人が明言しており、粗利益率は極めて高い構造になっています。
単発課金とストック収益の両方を持つ点が特徴で、Laravelが年1回メジャーリリースを出すたびに単発売上が跳ね、契約者からは月額が積み上がります。蓄積する資産は、10年・17.5万回の実行から得た「どこでエラーが起きやすいか」というエッジケースの知識であり、これが後発の参入者に対する見えにくい参入障壁になっています。
開始コスト
現金の投資はほぼゼロで、開発費もカンファレンス会場での一晩のハッカソンで書いたコードだけでした。サーバー、店舗、在庫、車両、保険といった固定費が発生しない構造です。
唯一の支出は、友人のデザイナーに依頼したウェブサイトのデザイン代と、GitHubやStripeという既存インフラの利用料程度でした。費用として消える支出はほとんどなく、代わりに開発した自動化ルール自体が将来の売上を生み続ける資産になっています。
必要スキル
一般的なプログラミング能力に加えて、フレームワークの変更履歴を読み解き、どの変更なら機械的に自動化でき、どの変更が人間の判断を必要とするかを切り分ける「変更の分類眼」が最も重要です。
価格設定を一律料金から「古いバージョンほど高い」段階制に変えた判断も収益を大きく押し上げた決め手であり、技術力以上に値付けの設計力が効いています。10年間、実行のたびに同じ2つの質問を送るフィードバックメールを、返信率が1割程度でも欠かさず続けた継続力も、地味だが差がつくスキルです。
他人が見落としていたポイント
他人は、Laravelというフレームワーク自体や、その使い方を教える学習コンテンツに目を向けていました。しかしこの事業者は、新しいバージョンが出るたびに開発者が数時間から数日かけてこなす「移行作業」という、フレームワークの外側にある摩擦に目を向けました。
顧客が本当にお金を払っていたのは、コードそのものではなく、移行作業に費やすはずだった時間を取り戻すことです。価格が「ランチ1回分」程度に抑えられているのも、金額の大きさではなく時間を買っているという感覚を壊さないための設計だと読み取れます。
さらに、AIによる自動化が広がった後も、この事業者は競合ではなく補完という立場を取りました。決定論的なルール処理の部分は自分が持ち、AIには最後の細かい調整だけを任せるという役割分担です。「AIに仕事を奪われる」ではなく「AIが片付けにくい部分を先に押さえておく」という、見落とされがちな発想の転換です。
日本ならどう応用できるか
米国のLaravelバージョンアップ代行という構造は、日本では「制度改正やシステム更新のたびに毎回発生する、地味だが確実な反復業務」に置き換えて考えられます。会計ソフトやECカートの大型アップデート、インボイス制度や電子帳簿保存法のような法改正対応、特定のCMSやプラグインのメジャーバージョンアップなどが候補です。
重要なのは、対象を一つのプラットフォームや制度に絞り込み、そのバージョン間の差分だけを扱う専門特化を貫くことです。この事例でもPHP全体への拡張は実行回数の1%未満に終わっており、対象を広げすぎるとかえって強みが薄まります。
税務・会計・建築などの資格が必要な領域に踏み込む場合は、税理士法や社会保険労務士法などの資格業務規制に抵触しないか、代行できる作業の範囲を事前に確認する必要があります。これは制度上の事実確認であり、実際にどの業種で需要があるかは個別に検証すべき事業仮説です。
7つの勝ち筋フィルター
① 他人が見落としている切り口があるか
評価：★★★★☆
フレームワーク本体ではなく「バージョン間の移行」という一過性の摩擦だけを商品にした点は独自性が高いですが、発想自体は既存のアップグレードスクリプト文化の延長でもあります。
② 古くからある市場か
評価：★★★☆☆
Laravelは2015年時点で既に主要なPHPフレームワークとして広く使われており、需要を教育する必要はありませんでした。ただし市場規模は特定フレームワークの人気に強く依存します。
③ 小さく始められるか
評価：★★★★★
初期投資はカンファレンス一晩のハッカソンで書いたコードのみで、検証には数週間もかかりませんでした。
④ 在庫を持たずに済むか
評価：★★★★★
物理的な在庫は一切なく、コードという資産のみで完結します。
⑤ ストック収益になるか
評価：★★★☆☆
サブスクリプションはあるものの、収益の柱は今もリリースサイクルに連動した単発課金です。ただし17.5万回分の自動化ルールという蓄積資産と、90%の高いリピート率はストック性を支えています。
⑥ 粗利益率は高いか
評価：★★★★★
月間運営コストが100ドル程度と本人が明言しており、人件費もほぼ本人の時間のみです。ソフトウェア自動化ビジネスとして極めて高い粗利構造を持ちます。
⑦ 再現性はあるか
評価：★★☆☆☆
Taylor Otwell氏個人の後押しやカンファレンスでの偶然の出会いに初期成長の多くを依存しており、創業者個人の人脈と技術コミュニティでの信頼構築力に負う部分が大きい構造です。
どうなったら失敗するのか
この事業の生命線は、Laravelというフレームワーク単体への依存です。メジャーリリースの頻度が下がったり、長期サポート(LTS)の対象が広がって「上げなくても困らない」開発者が増えたりすると、単発課金の柱が細ります。
創業者自身も「ここ1年はほぼ横ばいで、今年は2割減を見込んでいる」と述べており、AIによる自動化がこの事業の核心である決定論的な差分処理を代替し始めていることが一因です。PHP全体への横展開を試みて実行回数の1%未満に終わったように、対象プラットフォームの拡張判断を誤ると開発リソースが分散するだけに終わります。
一人運営を貫いているため、本人が対応できる問合せ件数とサポート品質そのものが事業の天井になっている点も、この事業固有の限界です。
早期に確認したいKPI
最も重要なKPI＝同一顧客のリピート実行率
継続率、リリース後の実行回数の伸び率、サブスクリプション比率など複数の指標が考えられますが、最も重要なのは同じ顧客が次のバージョンアップでも戻ってくるかどうかです。この事業では90%という高いリピート率が、単発課金型でありながらストック的な収益基盤を築く土台になってきました。
最初に取り組むアクション
最初に売る最小の商品
いきなり全バージョン・全機能に対応するのではなく、直近1回分のバージョンアップだけに対応した最小限の自動化スクリプトに絞ります。
最初の顧客候補
対象プラットフォームの開発者コミュニティで積極的に発言している中堅〜上級エンジニアや、そのプラットフォームの作者に近い立場の人物です。影響力のある個人ユーザーの支持が、その後の口コミの起点になります。
最初の集客方法
広告は使わず、対象コミュニティのカンファレンスやSNSでの発言、開発者インフルエンサーとの接点を優先します。利用後は必ず「何が自動化できなかったか」「どこで知ったか」を聞くフォローアップを続けます。
投入する費用と時間の上限
最初のメジャーリリース1回分(数週間〜1ヶ月)、外部支出は数万円以内。需要が確認できるまで、専用のチームや大がかりな開発体制は作りません。
継続または撤退を判断する基準
最初のリリースサイクルで実行回数が数十件に達し、かつ同じ顧客が次のバージョンアップでも戻ってくるかを確認します。戻ってこない、あるいはフィードバックメールの返信からエッジケースの傾向がつかめない場合は、対象プラットフォームの選定自体を見直します。
まとめ
Shiftは、Laravelのバージョンアップという一過性の摩擦だけを商品にし、10年かけてその摩擦の中に眠るエッジケースの知識を積み上げてきました。売上は伸びてもサーバー費用はほとんど増えず、蓄積したノウハウが新規参入者に対する参入障壁になっています。
この事業の本質は、Laravelのバージョンアップを代行することではありません。多くの開発者が「面倒だが自分でもできる」と思っている反復作業を先回りして引き受け、そこで積み上げた失敗パターンの知識を、価格ではなく参入障壁として蓄積し続けることです。
コメント