- パリ拠点のLagoは、正式リリースとともに開発者向けオープンソース請求プラットフォームへ転換した成果を公開し、2回のラウンドで約**2,200万ドル（$22m）**を調達した
- 最新のシリーズA 1,500万ドルはFirstMarkが、前回のシード 700万ドルはSignalFireが主導し、Y Combinator、New Wave、Scriptと個人投資家が参加した
- もともとマーケティングチーム向けの「Zapier」を作ろうとしていたチームは、Hacker Newsの開発者の請求課題に関する投稿が大きな反響を呼んだことを受け、請求プラットフォームへとピボットした
- Mistral.ai、Together.ai、Juniがクローズドベータの初期顧客として参加し、Lagoはサブスクリプション・従量課金・ハイブリッド価格設定を扱うスタートアップを狙う
- Stripe、Adyen、Salesforce、Zoho、Paddleなどがいる市場で、Lagoはスケーラビリティとカスタム請求実装を差別化要因に据える
正式リリースと資金調達の構成
- パリ拠点のスタートアップLagoは、オープンソース請求プラットフォームの正式リリースとともに、総額2,200万ドルの資金調達を公表した
- 調達は2つのラウンドで構成される
- 最新のシリーズA 1,500万ドルはFirstMarkが主導
- それ以前のシード 700万ドルはSignalFireが主導
- Y Combinator、New Wave、Scriptも投資家として参加
- 個人投資家には、MongoDBの収益化責任者Meghan Gill、元StripeでOpenAIのデベロッパーリレーションズ担当のRomain Huet、Hugging Face CEOのClément Delangueが含まれる
- 関係者情報によれば、Lagoの企業価値は約1億ドル規模とされる
クローズドベータと初期顧客
- Lagoは正式リリース前、クローズドベータとして運営されていた
- 初期顧客にはMistral.ai、Together.ai、Juniのようなスタートアップが含まれる
- 開発者が新しいサービスに合わせて請求体系を自ら調整できるよう支援することに焦点を当てる
- 利用量データを計測し、サブスクリプションやその他の価格設定を処理できるよう支援する
マーケティングツールから請求プラットフォームへピボット
- Lagoは当初から請求プラットフォームを作ろうとしていた会社ではなかった
- 共同創業者のAnh-Tho ChuongとRaffi SarkissianはQontoで働いた後に起業し、Y Combinator Summer 2021のコホートに参加した
- YC参加時点では製品はなく、その後マーケティングチーム向けの「Zapier」というアイデアを選んだ
- 競争の激しいマーケティングテック市場で、初期製品はほとんど traction を得られなかった
- Sarkissianは注目を集めるため、Hacker Newsに開発者の請求課題を扱った投稿を掲載した
- タイトルは「Billing systems are a nightmare for engineers」だった
- これはQontoで請求課題を解決する製品を作っていた経験とつながっていた
- 多くのユーザーが自らの請求課題を共有したことで、Lagoは開発者向けの請求課題解決へと方向転換した
複雑な請求を狙うオープンソース戦略
- 単純な価格設定や請求にはすでに多くのソリューションがあるが、複雑な請求には十分な解決策がないと見ている
- AIベースの製品を作る企業は実行可能なビジネスモデルを模索しており、定額サブスクリプションと従量課金を組み合わせるハイブリッド方式を検討するケースが多い
- この方式には、開発者が作る製品と統合され、利用量データを識別して適用できるツールが必要になる
- 多くの企業はQontoのように独自の請求システムを構築するが、エンジニアはそれを嫌い、専任エンジニアを雇うコストも大きい
- Mistral.aiの共同創業者兼CTOであるTimothée Lacroixは、Lagoを選んだ理由としてオープンソースエコシステムへの信頼を挙げ、Lagoのおかげでリリース速度に追随しながら本業に集中できたと述べた
競争環境と次の拡張領域
- 請求市場には、Stripe、Adyen、Salesforce、Zoho、Paddleなど大手テック企業のソリューションがすでに存在する
- オープンソースのアプローチを取る既存プロバイダーもある
- FOSSBilling
- ChargeBee
- Kill Bill
- AppDirectのjBilling
- Open Source Billing
- Lagoは競争の激しい市場でも、スケーラビリティとスタートアップごとのカスタム請求実装に機会があると見ている
- 今後は既存事業を拡大しつつ、2つの領域を検討する
- もともとのマーケティング構想につながるデータ分析: 顧客が何を消費し、何に支払い、支払いパターンがどうなっているかを提供すること
- 請求の反対側にある決済領域
- 決済スタックそのものを作る可能性は低く、ユーザーが望む決済ツールを使いながら請求プラットフォームと適切に統合できるようにする決済オーケストレーションに焦点を当てる可能性が高い
2件のコメント
Lago は Stripe との比較をかなり前面に出していましたが……やはり多くの投資を受けましたね。
Stripeの実際の価格: 入門ガイド のような記事も公開していましたし。
ただ、請求 API がオープンソースというのは、どこかしっくりこない感じもします。
Hacker Newsの意見
新しいSaaS製品で使ってみようとしたが、料金プランが月額3,000ドルから始まっていて面食らった
方向性が逆のように思える。自分のような小さなチームはセルフホスティングを望んでおらず、マネージドソリューションを求めている。大企業のほうが規模があるので、むしろセルフホスティングする余力がある
数年後に取引量が増えて契約の再交渉をしたくなったが、そのときLagoに再連携できていれば、Stripe契約更新時の交渉材料になった気がする。Stripe手数料として月3万ドルを払っていたので、月3,000ドルの代替案には十分な価値があったかもしれない。自分たちのケースはSaaS請求ではなく小売だったので少し違うが、財務的に筋が通る場面はありそうだ
従量課金APIの会社5社ほどと話したが、現実的に自分たちが来年の成長期のあいだ滞在する月1,000ドル未満の市場には、ほとんど誰も関心を示さなかった。しかもLagoや他社は「レベニューシェアなし」と宣伝しながら、いつも売上比率ベースで価格を提示してきた。技術的にはレベニューシェアではないが、コストが売上にほぼ線形に追随して増えていく
小規模でサポートコストが高く、収益性の低い顧客は避け、そうした顧客はStripeに赤字で抱えさせたまま、Stripeですでに成長した優良顧客だけを選んで奪いにいく価格戦略だとしたら賢い
開発者に売るのは難しいと思う。開発者はお金を使わず、機会費用が10倍かかっても自分で作ろうとする
そして何らかの形で収益化を試みた瞬間、Redisのときのように「裏切りだ」と言われて大規模な離脱が起きるだろう。自分もそういう開発者だから分かる
顧客ポータルが絶対に必要だったがプレミアム機能で、プレミアムは最低でも月1,500ドルだった。自分の売上では正当化しにくかった。ただ、Lagoは意図的に売上比率課金を避けているため、基本料金を高く取らざるを得ない。Stripe Billingは比率で課金するので、成長するビジネスならStripeの請求額が1.5千ドルを超えるのは時間の問題だ
Stripe Billingの従量課金も検討したが、自分の要件は満たせなかった。定額課金にはStripe Billingを使っている
正確な要件は、APIクレジットをサブスクリプションに含まれる前払いで売りたかったということだ。たとえばユーザーが月10ドル分のクレジットに加入したら、最初に10ドルを払い、その分のクレジットを使う方式だ。Stripe Billingは従量課金で前払い請求をサポートしておらず、請求期間が終わった後にしか請求しない。一部のユーザーがキャンセルして支払わない形でシステムを悪用できるので、自分には合わなかった。Lagoは前払い請求をサポートしていたと記憶している
サブスククレジットと前払いクレジットも自由に混在させたかった。ユーザーが1か月の割当量を超えたとき、最上位プランにアップグレードするより、ワンタイムのチャージを好む。どのクレジットから先に消費されるかも制御する必要があるが、Stripe BillingもLagoもここで問題があった
決済手段もできるだけ多く、特に前払いクレジットについてAlipayやWeChatのような中国系ウォレットをサポートしたかった。Lagoにはそれを実装する計画がなく、自分でLagoの中に実装することまで半ば考えていた。B2BではWeChatとAlipayはそれほど重要でないかもしれない
また、自分は回帰テストが非常に手厚いコードを好むが、Stripe Billingはテストクロック機能のおかげで、この点ではLagoよりはるかに先を行っている。Lagoにはサブスクリプションのライフサイクルをテストするために時間を先送りする機能がない。製品を信頼するなら、適切なタイミングで正しいコールバックを受け取れると期待すればよいので、それほど重要でないのかもしれない
それでも、Lagoの開発者たちがSlackでかなり深い技術的質問にまで時間をかけて答えているのは見た。B2Bスタートアップを運営しているなら、特にStripeアカウント停止の事例が多く見られるこの時期であれば、どうにかしてLagoを自分たちに合う形ではめ込もうとしたと思う
そしてこれこそがLagoの中核仮説なのではないかと思う。開発者はStripeのような独占的な提供者に依存するより、必要なら自分で修正できるオープンソースの請求ソフトウェアを求めている、ということだ。そこまで突飛な考えではない
隣のコメントのように、価値を生み時間を節約してくれるものには喜んでお金を払う。そもそも自前の請求システムを作ろうと考えたことすらない
年を取ったせいで、オープンソースの意味に対する感覚が現実の変化に適応できていないのかもしれないが、オープンソースと「$22Mの投資」が同じ文に入っていると、すぐに「何がオープンソースだよ」と思ってしまう
こういう感情はよく見かけるし、特に rich harris のようなオープンソースのベテランからも見てきた。皮肉なことに、彼はいまVCの金で給料をもらっている。一方で、私も文句を言いたくなるし、人は作って共有する楽しさだけで開かれたソフトウェアを作るべきだと言いたくもなる。だが現実世界で生きていくには金がかかるし、私が便利に使い、おそらく自分でも収益を上げるソフトウェアを、誰かが夜と週末に作って GitHub Star だけもらっていればいいと期待するのは非生産的で不公平に思える
Lago の文脈でのオープンソースの利点は、宣伝と開発者からの好感以上にはあまり分からない。今どきオープンソースで作るのは板挟みで、これがより長い寿命とサポートをもたらす未来なら、受け入れるしかないと思う
1970年代半ばにオープンソースが始まったときの精神は、ソフトウェアを無料で共有することだった。資金は大学や企業の研究助成という形で出ており、ビジネスモデルはなかった。1998年に RedHat や MySQL などが自由ソフトウェアの上に有料サポートとサービスを載せ、そこで本格的に金が入るようになった。2000年代半ば以降はクラウドコンピューティングのせいで、オープンソースで稼ぐという発想が一般的になった。SaaS では、ユーザーは中身がオープンソースかプロプライエタリソフトウェアかを知らないか、気にしないので、オープンソースも同じ土俵に上がることになった。
VCがオープンソースを好む理由はいくつかある。私は機械学習エンジニア出身の投資家だが、個人的には大学時代に spaCy のような素晴らしいオープンソースを使っていた懐かしさもあるし、コミュニティ・透明性・還元といった価値にも共感している。同時に、VCの仕事は金を稼ぐことでもある。
クローズドソースの会社は営業とマーケティングに多額の金を使う。開発者はたいてい売り込まれるのを嫌い、説得されるより自分で選びたがる。会社が開発者の心をつかめば、数百万ドルを営業やマーケティングに使わなくても、ソフトウェアは購買検討の段階に引き込まれるので、ビジネスモデルはより効率的になる。防御力も強い。大企業はスーツを着た営業人員に金を注ぎ込んで製品を売れるが、開発者の愛は買えない。そこには優れた開発者体験と良いデベロッパーリレーションが必要だ。
ただし、オープンソースで稼ぐのは SaaS よりはるかに難しい。SaaS ではプロダクト・マーケット・フィットを語る。同じように使い、同じように買い、同じ価値を得る顧客を5社以上見つけて予測可能性を作れれば、VCは金を出して営業を拡大する。オープンソースではこの問題が3倍になる。プロジェクト・コミュニティ・フィットは GitHub Stars で見て、プロダクト・マーケット・フィットはダウンロードで見て、バリュー・マーケット・フィットは売上で見なければならない。しかも買い手が開発者やユーザーとは限らない。優れたオープンソース製品の大半は、バリュー・マーケット・フィットで失敗する。
オープンソース企業の創業者の大半は、価値の回収に失敗する。難しすぎるか、あるいはオープンソースは「無料ソフトウェア」であるべきだという感覚のせいで、収益化を先延ばしにするからだ。そして収益化を始める頃には手遅れになっている。何年も無料で牛乳をもらってきたなら、牛を買うだろうか？ もう一つの理由は、やり方を知らないことだ。オープンソースで稼ぐ典型的な方法は、サポートとサービスの販売、独自機能を売るオープンコア、ホスティングやツールを売る SaaS である。例としては RedHat、Confluent、Elastic、Databricks がある。
成功したオープンソース企業を基準に単純化して言えば、無料版は1人の開発者が仕事を完了するのに必要な機能をすべて備えているべきだ。有料製品は、チームで仕事を完了するのに必要な追加機能を提供すべきだ。
私はオープンソースが好きだし、とても賢い創業者や数多くの貢献者が情熱を注いで作ったのに、拡大もできず報われもしないのを見るのはつらい。商業化はその助けになるが、本当に難しい。オープンソースに貢献し作る人はコミュニティを重視し、無料で提供したがるので、金を稼ぐという発想そのものに居心地の悪さを覚える。居心地が悪くなると、人は慣れた場所に戻り、たいていのエンジニアにとってそれはコーディングだ。だから多くの素晴らしい機能を持つ優れたオープンソースソフトウェアと、収益化をあまりにも長く先延ばしにした創業者が生まれる。ある時点で引き返せない地点を過ぎると、また1社、有望だった会社が死に、どれだけ製品が素晴らしくても、投資家は金を回収できないなら投資しない
それでも処理手数料を払う必要があるなら、ここでの利点は何なのか？
独自の決済スタックと PCI準拠 を維持しなければならないなら、ものすごく気が散る要因になりそうだ
定期課金、請求書、日割り精算される料金プラン変更、従量課金のエッジケースを追跡するのは難しい。そして Stripe Billing API も多くの場合それほど洗練されていない。この領域に新しいレイヤーが出てくるのは歓迎だ
参考までに、私は Very Good Security を創業し、8年間 CEO を務めていた
同様にRustで書かれたオープンソースの https://hyperswitch.io がある。
LagoはRubyで書かれていて、Javaで書かれた別のオープンソース請求システムもいくつか見つけた。Node.js製のものを知っている人はいる？
Parisは新しいフィンテックスタートアップを生み出す場所として本当に熱いように見える
一方で、Franceには善意から生まれた優れた反例もある。たとえばSemmle [1] はリポジトリ静的解析のためにGitHubに買収された。Inria [2] も素晴らしいが、問題は研究ではなく、米国流の企業と事業レベルでどう競争するかだ。
[1] https://en.wikipedia.org/wiki/Semmle
[2] https://www.inria.fr/en
GitHub READMEでDrakeミームを使っている
https://github.com/getlago/lago
https://imgur.com/a/gsrhUXm
技術文書のミーム化を見る日が来るとは思わなかった……なんてこった
実際のStripe Paymentsの代替を知っている人はいる？ Stripeは私たちとは仕事をしたがらず、クローズドソースの競合としか組もうとしないので、PayPalに縛られている
ちなみにそこで働いている
これはStripeの代替ではない。
請求、請求書、決済、権限、サブスクリプションはそれぞれ別物だ
つまり、RevOps全体に対するオープンな代替を提供したいということだ。Stripeのようなクローズドソースのエコシステムに入るのではなく、カスタムスタックを構築し、「ベストオブブリード」方式でロングテールのツール、ユースケース、自社システムを接続できるようにしたい。Stripeには21の製品があり、多くの創業者は自分が「Stripe payments」だけを使っているのではなく、そのうち3〜6個を使っていて、それぞれが通常は売上の一部を取っていることをよく知らない
Series Aで15Mを調達し、バリュエーションは公表されていないが100Mだという噂がある。
Crunchbaseによれば、7Mは2023年に受けたシード投資だった。リンク先の記事の最後の段落を見ると、Stripe全体を置き換えようとしているわけではないようだ。いずれにせよ、情熱的なHN投稿から始まった成功したスタートアップのピボット物語として興味深い