HeadReach
HeadReach は early traction が本物だった一方、lead-discovery value が fragile third-party search/data infrastructure に依存していました。Google Site Search が変わると、自前の durable data layer なしでは product を維持しにくくなりました。
元のストーリーを見るプロダクト概要
何だったか
HeadReach は targeted leads、email addresses、social profiles を見つける micro-SaaS sales prospecting tool でした。
誰のためか
課題 / 価値
right people and contact data をより速く見つけ、manual prospecting work を減らすことを目指しました。
中核ワークフロー
users が target market を指定し、relevant leads、email addresses、social profiles を発見して outreach に使う。
中核依存
Google Site Search and third-party data access が core lead discovery workflow に大きく関わっていました。
プロダクト形態
価格モデル
創業者 postmortem は nearly $2,000 MRR within roughly three months and $18,453 total product revenue を報告しています。
競合または代替手段
何が起きたか
概要
HeadReach は early organic traction を持つ micro-SaaS でしたが、critical third-party API and data-indexing dependency が変わった後、投資継続が難しくなりました。
結果
product は sunset mode に入り、後に user base and marketing assets が sold されました。
中核リスク
Core dependency risk
終了理由
core lead-discovery workflow が Google Site Search に大きく依存し、その dependency change 後に sustain しにくくなりました。
タイムライン
- founders は 2016年11月頃に publicly launched しました。
- roughly three months で few thousand users and nearly $2,000 MRR を創業者は報告しました。
- 2017年に Google Site Search API closure が major technical dependency shock になりました。
- 2017年8月、team は HeadReach を sunset mode にしました。
- 2018年夏、user base and marketing assets は LeadFuze に sold されました。
作る前に確認すること
なぜ重要か
HeadReach には real users、revenue、registrations、early MRR がありました。しかし主要な価値は builder が control できない search/data infrastructure に依存していました。これは no-demand story ではなく technical and data dependency risk です。
主な確認事項
prospecting automation を売る前に、lead-data access、enrichment quality、platform terms を検証してください。
チェックリスト
- product に本当に core な API or data source は何か。
- その API が close、rate-limit、pricing change、block したら何が残るか。
- backup path の cost and operational burden はいくらか。
- broad data coverage なしでも customers は狭い version を欲しがるか。
- core API、data source、platform を特定する。
- API closure、rate limits、pricing change、blocking が起きた場合の impact を見積もる。
- backup data source、proprietary data layer、narrower workflow を作れるか確認する。
- users が product に払っているのか、temporary access to someone else infrastructure に払っているのか分けて考える。
参考になる場合
- lead-generation、email-finder、sales prospecting、data enrichment、search、scraping、API-wrapper product を作っている。
- 主要な価値が third-party API、index、search endpoint、platform workflow、external data source に依存している。
- shortcut で launch はできるが、long-term data access or indexing economics が不明である。
参考になりにくい場合
- core data source を own している、または legally and economically build できる。
- third-party source が変わっても manual service、proprietary workflow、narrow niche で value を届けられる。
- third-party platform は convenience layer で、主要価値そのものではない。
開発前テスト
- alternate APIs、proprietary index、manual enrichment、narrower data source の backup path を先に price する。
- most fragile dependency なしで useful results が出るか small data coverage test を行う。
- third-party source が rate-limit、pricing change、blocking した場合の cost and burden を見積もる。
- broad third-party search coverage に依存しない narrower version でも customers が関心を持つか test する。
応用できる学び
- initial product demand だけでなく、technical substrate の defensibility を validate する。
- third-party APIs and data access を implementation detail ではなく business risk と扱う。
- revenue and users があっても、core infrastructure が fragile なら long-term fit は悪くなり得ます。
- maintenance risk が upside を超えるなら sunset mode or asset sale は合理的な closure path です。
今作るなら
prospecting automation を売る前に、lead-data access、enrichment quality、platform terms、backup data source の economics を確認してください。