YardPortal · ポストモーテム
どちらも報われる前の、二つのコールドスタート
私は Web アプリとモバイルアプリを作り、決済まで着手した — たった一本の通りが申し込むと証明する前に。YardPortal のポストモーテム。
アイデア
サブスクとしての芝生の手入れ。あなたの庭から自動で価格を出し、地元の業者が施工し、近所が加わるほど安くなる。売り文句はフライホイールだった — 通りでの密度がコストを下げ、低いコストがさらに近所を引き込む。
実際に最初に作ったもの
約 2 週間で、Web アプリと別立ての React Native モバイルアプリを作り、認証とデータを Supabase に立て、Stripe の配線まで進めた。git の履歴はどこで終わったかについて正直だ。最後のコミットは「Broken Supabase」と「stripe-start」。私は完全な入口を二つ作り、課金まで始めていた — どちらかを誰かがくぐるという証拠を持つ前に。
推論の誤り
近所割引は、通り全体が申し込んで初めて効いた — だからモデルを機能させるはずのものをどちらの側が得る前にも、住宅所有者と業者という二つのコールドスタートを越える必要があった。さらに悪いことに、需要を生むはずの割引は需要がすでに密になるまで存在せず、フライホイールの最初の一回転が、それが生むはずの結果を要求した。私は二面的で密度に依存する市場を、普通のアプリのように扱っていた — 製品を作り、それからユーザーを得る — 難しいのは決して製品ではなかったのに。
飛ばした、より安い検証
これを暴けたはずの最小の実験は、ほとんどコードを要さない。通りを一本選び、数軒の庭を自分で値付けし、業者を一人手配し、本物の割引が卓上にあるとき近所が実際に成約するかを見る。コンシェルジュ的で手作業の一区画版が跳ねないなら、Web もモバイルも Stripe も、どれだけ足してもフライホイールは回らない。私は区画を回す代わりにソフトウェアを書いた。
変わったこと
それ以来私が出してきた製品 — MassOutage、BlissGarden、LurePassion — が、コールドスタートに二つ目の側を必要としないデータアグリゲータであるのは偶然ではない。そのうちの一つは、プラットフォームに他の誰もいなくても、初日に、最初に訪れた人の役に立つ。YardPortal は、何かを書く前に、それが二つのグループが揃って初めて機能するものかどうかを問い、もしそうなら、まず安い方法でそれを検証することを教えてくれた。