EXIT
2026-08-24
Flusk — ノーコードの死角を突いて、18 ヶ月でプラットフォーム本体に買われた 2 人組
事業
Flusk
Bubble 製アプリのセキュリティ監査・脆弱性検出・監視を自動化する、ノーコードエコシステム特化の SaaS
01 WHAT
Flusk は、ノーコード開発プラットフォーム Bubble で作られたアプリのセキュリティを自動監査する SaaS だ。Bubble のアプリはコードを書かずに作れる反面、データベースの公開設定やプライバシールールの設定ミスが起きやすく、開発者本人が脆弱性に気づけないことが多い。Flusk はアプリをスキャンして脆弱性を検出し、修正方法を提示し、継続的に監視する。
フランスの Victor Nihoul と Wesley Wasielewski が創業した。2 人とも創業時 21 歳、外部資金は入れていない。売却先は他ならぬ Bubble 本体で、2 人はそのままセキュリティチームの一員として合流した。エコシステムの隙間を埋めるツールが、プラットフォーム自身に「標準機能」として取り込まれた事例だ。
02 NUMBERS
Metrics
| As of | Type | Value | Reliability | Source |
|---|---|---|---|---|
| 2024-09-01 | Employees | 2 | 自己申告 | They Got Acquired |
| 2024-09-01 | Users | 1,000 | 自己申告 | They Got Acquired |
| 2024-09-01 | MRR | $20,000 | 自己申告 | They Got Acquired |
| 2024-09-01 | ARR | $240,000 | 自己申告 | They Got Acquired |
Exits
| Date | Type | Buyer | Price | Source |
|---|---|---|---|---|
| 2024-09-01 | acquihire | Bubble | $1,000,000–$9,999,999 | They Got Acquired |
03 STORY
始まりはセキュリティツールではない。2 人は当初、Bubble 開発者向けの 24 時間サポートサービスを構想していたが、契約はほとんど取れず、早々にピボットを決める。サポート業務の中で繰り返し目にした「Bubble アプリのセキュリティ設定ミス」に商機を見て、監査ツールとして Flusk を作り直した。
最初の課金モデルは年間ライセンスだったが、これは失敗だった。ユーザーは監査で脆弱性を見つけて直すと解約してしまう。「検出して終わり」のツールは構造的にチャーンが高い。2 人はユーザーヒアリングを重ね、ダッシュボード・継続監視・アラート・ユーザー分析を足して「直したら終わり」から「守り続ける」への転換を図り、料金も月額制に切り替えた。
転機は Flusk 2.0 のローンチ直後に来た。ノーコード界隈の著名 YouTuber が Flusk を推奨する動画を公開し、その 2 週間後に Bubble から買収の打診が届いた。Bubble 社内に Flusk のユーザーがいて、経営陣に推していたことが後から分かっている。交渉は長引き、何度も浮き沈みがあったが、最終的に 2 人の入社を含む acquihire として成立した。
04 WHY IT WORKED
第一に、プラットフォームの「必須だが未整備」な領域を突いたことだ。セキュリティは Bubble エコシステムの信頼性に直結するのに、公式の解が存在しなかった。エコシステムの穴のうち、プラットフォーム本体が「いずれ自分で解かなければならない」種類の穴を選んだことが、買収という出口に直結した。
第二に、チャーンの原因を機能追加ではなく事業構造の転換で解決したこと。「脆弱性を見つけるツール」から「セキュリティを維持するサービス」への再定義は、収益の継続性だけでなく、買い手から見た事業価値も変えた。
第三に、無料コンテンツによるポジショニング。2 人は Bubble セキュリティに関する情報発信を大量に行い、後発でも「この分野の標準」という認知を作った。買収の引き金になった YouTube 動画も、この認知の延長線上にある。社内にユーザー(チャンピオン)がいたことが最後の一押しになった。
05 HOW THEY BUILT
Flusk 自体も Bubble で作られている。自分たちが監査対象とする環境の上で自社製品を動かすドッグフーディングで、対象プラットフォームの制約と挙動を誰よりも深く理解していた。
チームは最後まで共同創業者 2 人だけで、採用も外部資金もなし。収益は月額サブスクリプションと単発の監査サービスの併売で、単発監査が初期のキャッシュフローを支え、サブスクリプションが事業価値を作るという分担になっていた。構想からローンチまでの助走期間を含めても、事業としての実質稼働は 1 年半に満たない。
06 JAPAN
この型は「プラットフォームのエコシステムの穴を埋め、本体に買われる」という再現可能な戦略として読める。日本での適用を考えるなら、対象になるのは国内で開発者・制作者のエコシステムを持つプラットフォームだ。kintone(サイボウズ)、STUDIO、ノーコード受託の周辺、Shopify 日本市場、freee・マネーフォワードのアプリストアなどが候補になる。
鍵はプラットフォーム選びにある。(1) エコシステムが成長中で、(2) セキュリティ・品質・運用のような「本体がいずれ標準化したい」領域が未整備で、(3) 本体に買収の前例か外部ツールの公認文化があること。この 3 条件が揃う場所でツールを作れば、SaaS としての売上と「本体への売却」という出口の両方を狙える。
注意点はプラットフォーム依存リスクそのものだ。本体が同機能を内製すれば市場は消える。Flusk のケースは「内製される前に、内製の担い手として買われる」ことに成功した例であり、スピードと本体との関係構築(公式コミュニティでの露出、社内ユーザーの獲得)が防御になっている。