Lemon Squeezy、ソフトウェア販売の税務と決済をMerchant of Recordに集約した設計

冒頭でLemon Squeezyは、ソフトウェア販売者が避けたい決済・税務・請求を一つのサービスにまとめた。

公式サイトはMerchant of Recordとしての価値を前面に出している。出典

創業

JR Farrらは、ソフトウェアを作る人が各国の販売実務まで抱える問題に向き合った。

Lemon Squeezyは決済API単体ではなく、販売主体と税務を含む運用サービスとして始まった。出典

転機・苦労

決済事業は、成功すればするほど返金、チャージバック、税率、請求書などの例外が増える。

公式docsがCheckoutだけでなくSubscriptionsやTaxesを分けて説明するのは、この複雑さをプロダクトへ取り込んだ結果だ。出典

「開発者がソフトウェアを販売するためのより簡単な方法を作る」という発想を、JR Farrは事業の中心に置いた。出典

成長・成功

AffiliateやLicense Keysまで同じ面で扱い、販売者の獲得から継続課金までを広げた。

2023年にはStripeによる買収が発表され、MoRというポジションが大手決済企業にも戦略的価値を持つことを示した。出典

結び

Lemon Squeezyの示唆は、複雑なバックオフィスを機能一覧ではなく責任の引き受けとして商品化したことにある。

Lemon Squeezyは、ソフトウェアを売りたいが、各国のVAT/GST、チャージバック、請求書、定期課金を自前で持ちたくない小規模チームに刺さる。

Merchant of Recordとして販売主体を引き受けるため、開発者はプロダクトと顧客獲得に集中できる。出典

決済APIだけでなく税務と請求まで束ねることで、決済導入後に発生する運用負債を先回りしている。

各国税務、決済リスク、返金、請求を運用として蓄積することが障壁になる。

API自体は模倣できても、Merchant of Recordの実務と信頼は短期に複製しにくい。

ネットワーク効果は中程度。

販売者が増えるほど決済・税務のデータと運用知見は増えるが、購入者同士が直接つながる構造ではない。

個人開発者、小規模SaaS、デジタル商品の販売者。

自前の法人・税務体制を持つ前に海外販売を始めたいチームに向く。

大企業の複雑な請求統合には要確認。

課題を決済画面ではなく販売責任全体として定義した点が強い。

公式docsでCheckout、Subscriptions、Taxes、License Keysを一つの運用として提示し、導入後の手作業を減らす。出典

Affiliate機能を内蔵したことで、販売者の成長チャネルも同じ管理面に置いた。

決済と税務を外部事業者へ依存するため、料金改定、審査、規約変更が販売者の事業に波及する。

買収後のプロダクト方針とサポート範囲も、独立企業時代と同じとは限らない。出典

公式docsと開発者向けAPIで導入を低くし、コンテンツとaffiliateで販売者を獲得する。

セルフサーブを入口にしつつ、税務や請求に困る成長中SaaSへ広げる戦略だ。出典

主要チャネル: content, affiliate, developer community

決済の機能競争ではなく、売り手が避けたい責任を引き受けると価値が上がる。

開発者向けSaaSでは、APIの数より導入後の面倒をどこまで消せるかが差別化になる。

日本の個人開発者向けには、インボイス制度、消費税、海外販売の請求書を日本語で説明する導線が重要になる。

MoRの利便性と、販売者側に残る申告責任を明確に分けるべきだ。