Hakeema
Hakeema は social-sector market で demand と retention を見つけましたが、nonprofit ごとの implementation requirements が scalable SaaS ではなく custom platforms and service work へ delivery を引き寄せました。
元のストーリーを見るプロダクト概要
何だったか
Hakeema は nonprofit marketing、stakeholder engagement、knowledge-asset communities を支える small-team platform でした。
誰のためか
課題 / 価値
cloud docs、knowledge bases、content marketing を partner and prospect communities に変えること。
中核ワークフロー
organizations が content、knowledge assets、stakeholder engagement を組み合わせ、partners や prospects の community を運営する。
プロダクト形態
価格モデル
business は 100% bootstrapped and client-funded と説明され、2.5 years に almost $600k revenue を得ましたが、repeatable SaaS pricing の詳細は確認 source では明示されていません。
競合または代替手段
何が起きたか
概要
Hakeema の founder は、social sector 向け software を 3 年 building した後、team が shut down を決めたと発表しました。
結果
real revenue と retention はありましたが、customer requirements は repeatable SaaS より custom platform work に寄っていました。
中核リスク
Service Gravity In Vertical Saas
終了理由
nonprofit customers の funded-program and grant-specific requirements が custom delivery を生み、scalable SaaS として repeatable にしづらかったこと。
タイムライン
- LinkedIn は Hakeema を 2017 年 founded、2-10 employees と記載しています。
- founder は 2.5 years に almost $600k revenue を報告しました。
- founder は 3 年後に Hakeema の shutdown を発表しました。
作る前に確認すること
なぜ重要か
Hakeema は revenue、profitability、retention があっても SaaS fit が保証されない例です。pre-build question は、nonprofit customers が同じ workflow と package を使えるのか、それとも毎回 grant-specific custom work になるのかです。
主な確認事項
grant-funded buyers へ売る前に、同じ設定で3団体以上が使える標準機能と有料更新条件を確認してください。
チェックリスト
- second customer は first customer と同じ workflow を custom build なしで使えるか。
- nonprofit が value を得るまでに何時間の staff time が必要か。
- buyer は software access に払っているのか、funded program delivery や bespoke stakeholder engagement に払っているのか。
- custom platform work をすべて別料金にしても business は成り立つか。
- product revenue と custom implementation revenue を分ける。
- new nonprofit customer ごとに product や delivery process がどれだけ変わるか記録する。
- SaaS と呼ぶ前に、self-serve にすべき workflow 部分を定義する。
- custom work を product plans に隠さず、明示的に price する。
参考になる場合
- nonprofits や social-sector organizations 向け vertical SaaS を作っている。
- client-funded revenue はあるが、implementation が毎回変わる。
- customer success や custom platform work が product margin を食っている。
参考になりにくい場合
- 同じ package を複数 customers に scope change なしで導入できている。
- custom work を明確に separate priced service として扱い、product gross margin が守られている。
開発前テスト
- first workflow を manual で届け、clients 間で繰り返せる部分を document する。
- scope を変えず、同じ package を 3 つの similar organizations に売る。
- features を増やす前に onboarding and custom work hours per customer を測る。
- fixed implementation menu を作り、custom request を 1 つ断って product boundary を試す。
応用できる学び
- willingness to pay だけでなく repeatability を検証する。
- grant や program-specific requirements がある vertical markets は custom-service gravity を生みやすい。
- strong retention があっても、team が運営したくない business model かもしれない。
今作るなら
nonprofit demand を SaaS demand と見なす前に、repeatable product workflow と custom funded-program work を分離し、同じ package を複数 client に売れるか確認してください。