21,000票の熱狂をコードゼロで生み出した男
21,000+
Product Hunt アップボート
数百万
ユニークユーザー
40
ツールカテゴリー数
2件
売却したプロジェクト数
출처: Startup Stash 実績
数ヶ月かけてデータベースを設計し、APIを繋ぎ、認証機能を実装したあげく、公開初日に誰一人として訪れない。多くの個人開発者が一度は味わうこの絶望を、Bram Kansteinは最初から回避していた。プログラミングの知識を持たない非エンジニアだったからではない。非エンジニアの創業者がノーコードで収益性の高いSaaSを構築した事例が示す通り、むしろ「コードを書ける状態」こそが、初期検証において最大のバイアスを生むと見抜いていたからである。
彼が2015年に世に送り出した『Startup Stash』は、起業家やクリエイター向けに厳選されたツールを40のカテゴリーに分類したディレクトリだ。公開されるやいなやProduct Huntで爆発的な支持を集め、歴代最多級となる21,000以上のアップボートを獲得した。数百万のユニークユーザーを集めたこのプロダクトは、のちに外部企業へ買収される。さらに彼はその後も同様の軽量なアプローチで複数のプロジェクトを立ち上げ、そのうち2つを売却した。
なぜ、自らコードを一行も書かないプロダクトが、膨大なコードで組み上げられたSaaSを差し置いてこれほどの熱狂を生み、価値ある資産へと育ったのか。彼の「No-Code MVP」の設計思想を紐解くと、開発者が陥りがちな「ビルド優先の罠」から抜け出すための合理的なアプローチが見えてくる。
「何が作れるか」ではなく「作るべきか」という分岐点
何が作れるか（Could I build this?）
- 誰も欲しがらない完璧なシステムを追求する
- タグ付けやレコメンドなど機能の洗練に走る
- アーキテクチャの完成度に時間と資金を溶かす
作るべきか（Should I build this?）
- 相手の課題を最短で解決する答えを重視する
- 日常で繰り返される具体的な不便から着想する
- 裏側の仕組みを問わず提供価値の実在を問う
Kansteinの出発点は、初期スタートアップのメンターやアクセラレーターでのアドバイザー経験にあった。そこで彼が日常的に目撃したのは、優れた技術力を持つ創業者が「誰も欲しがらない完璧なシステム」を作り上げ、資金と時間を溶かしていく姿だった。
彼自身がStartup Stashを構想したきっかけは、きわめて個人的な日常の不便さだった。スタートアップ創業者たちから「ランディングページを作るなら何がいいか」「初期のメール配信ツールは何を選ぶべきか」と同じ質問を何度も繰り返され、自分のブラウザのブックマークがツールのリンクで埋め尽くされていたのである。
このとき彼が下した判断は象徴的だ。多くのエンジニアであれば「タグ付け可能で、ユーザーが投票でき、レコメンド機能がついたWebサービス」を作ろうと考えただろう。しかしKansteinはそうしなかった。
「本当に価値を提供し、相手の課題を解決しているなら、ユーザーは裏側の仕組みなど気にしていない。」
この原則が、彼のあらゆる意思決定の軸となっている。ユーザーが求めているのは「自分の課題を最短で解決してくれる答え」であり、開発者の洗練されたアーキテクチャではない。彼は「自分は何を作れるか（Could I build this?）」ではなく、「これは作る価値があるか（Should I build this?）」を徹底的に自問した。
実際に彼が組んだ「道具の生態系」
Startup Stashの初期バージョンは、拍子抜けするほど簡素なツール構成で構築されていた。彼が選んだのは、ゼロからのスクラッチ開発ではなく、既存のWeb制作基盤の徹底的な流用である。
- 初期の公開基盤：必要最小限のWordPressインスタンスと、既存のグリッドレイアウト用テーマ
- コンテンツ管理：スプレッドシートによるツールの分類・キュレーション（40カテゴリ、数百のリソース）
- その後のMVP検証スタック：Carrd（高速なLP構築）、Airtable（構造化データベース）、Zapier（ツール間の自動連携）、Typeform（ユーザー課題のヒアリング）、GumroadまたはStripe（決済導線）
Kansteinが後年、自身のコース『No-Code MVP』で体系化した検証スタックも、この極限まで削ぎ落とされた道具立てが基本となっている。プログラミングを行わない最大の利点は、作業時間の短縮そのものよりも「修正コストがゼロに近いこと」にある。
コードで組まれたシステムは、一度作ってしまうと仕様変更に心理的・技術的な抵抗が生まれる。いわゆるサンクコスト効果だ。一方で、Airtableのフィールドを増やし、Carrdのテキストを書き換え、Zapierのトリガーを繋ぎ変えるだけの構造なら、朝に得たユーザーフィードバックを昼にはプロダクトへ反映できる。彼にとってノーコードツールとは、単なる開発の代用品ではなく、仮説検証のサイクルを最速で回すための仕組みだった。
4週間の制約：意思決定のプロトコル
Kansteinの検証手法において、ツール以上に重要なのが「時間枠（タイムボックス）」の厳密な設定だ。彼はアイデアを思いついた際、自分自身に次の問いを投げかける。
「今から4週間後、このアイデアを本格的に追求すべきかどうかを判断するには、何を確かめれば十分か？」
この問いを立てた瞬間、無駄な機能開発はすべて視界から消える。Bram Kansteinが説く検証手法によれば、4週間という短い期間で確かめられるのは、「課題の実在」と「提供価値への反応」だけであり、それ以外の機能はすべて不要な装飾となる。
検証は、次のような流れで行う。
- 価値提案の極小化：解決したい課題を1文で定義し、提供する解決策を1つに絞る。
- 手動プロトタイプの提示：裏側の処理を自動化せず、スプレッドシートや手動連絡（コンシェルジュ型）で成立する形を作る。
- 痛みの深度測定：単なる「いいね」やメール登録ではなく、時間や金銭といった実質的なコストをユーザーが支払う意思があるかを確認する。
もし4週間経っても確かな手応えが得られなければ、そのアイデアは静かに破棄される。コードを一切書いていないため、心理的な痛みも金銭的な損失もほとんど発生しない。
この手法が孕む構造的リスク
ただ、このアプローチをそのまま鵜呑みにすることには、無視できないリスクもある。
もっとも大きな懸念は、「初期トラフィックの獲得」と「持続的な事業性」の混同である。Startup StashがProduct Huntで21,000票を獲得できた背景には、当時のProduct Hunt自体の急速な成長期と、「スタートアップ向けツール集」という同プラットフォームのユーザー層に完璧に一致したコンテンツ選定があった。
キュレーション型やノーコードのディレクトリは、参入障壁が極めて低い。実際にStartup Stashの成功以降、類似のまとめサイトがネット上に乱立した。独自のアルゴリズムや技術的な壁が存在しない場合、初期のバイラルが沈静化した後のリテンション維持や、競合による模倣への対策は極めて難しくなる。
また、ノーコードによる検証は「初期の関心」を測るのには適しているが、高単価なエンタープライズSaaSや複雑なデータ処理を要するプロダクトでは、MVPの段階で一定の技術的実現性を示さなければ顧客が納得しないケースも多い。Kansteinの成功パターンを、あらゆるアイデアに効く万能薬と考えるのは早計だ。
個人開発者が直ちに盗むべき公式と、真似できない前提条件
Kansteinの軌跡から、現代のインディーハッカーが取り入れるべき要素と、安易に真似すべきでない要素を明確に切り分けて考える必要がある。
直ちに再現可能な要素
- 「Should > Could」の判定基準：コードを書く前に「そもそも作る価値があるか」を検証する姿勢を徹底する。開発を始める前に、AirtableとCarrdだけで最小の価値提供ができないかを考える。
- 4週間の強制終了ルール：ダラダラと開発を続けず、4週間で一定の検証データ（事前登録数、有料予約数、直接のインタビュー結果）が集まらなければ撤退する規律を持つ。マーク・ルーのShipFast式のような超短期間での開発手法も、このスピード感による検証を重視している。
- 裏側の手動化（コンシェルジュMVP）：複雑なバックエンド処理を組む前に、最初の10人のユーザーに対しては自分が手作業でデータを集め、メールで結果を送る。それで価値を感じてもらえないなら、自動化しても誰も使わない。
そのまま真似できない前提条件
- 2015年当時のProduct Huntの拡散力：当時は優れたキュレーションというだけでプラットフォーム全体を席巻できたが、現在のProduct Huntは競争が激化し、単なるリンク集で同様のトラフィックを得ることは不可能に近い。
- Kanstein個人のネットワーク：彼は当時すでにスタートアップエコシステム内部に身を置いており、何がコミュニティに刺さるかの感覚を持っていた。オーディエンスも文脈もない状態から単にツールだけを並べても、初期の流通チャネルを確保できずに頓挫する可能性が高い。こここそが、Arvid Kahlが説くオーディエンスファースト戦略が必要となる点である。
コードを書く能力は、課題が特定されたあとの「スケール手段」であり、「課題の発見器」ではない。Kansteinが証明したのは、開発リソースを持たないことこそが、無駄な機能を作らずにユーザーの痛みに直結する最短ルートを歩むための武器になるということだ。
参考資料
よくある質問 (FAQ)
Q. プログラミングが全くできなくても、本当にノーコードだけで売却可能な事業を作れるのか？
可能だが、買収対象となるのは高度な技術資産ではなく「検証されたトラフィック」「熱量の高いオーディエンス」「整理された独自データベース」である。KansteinのStartup Stashも、複雑なプログラムではなくスタートアップ関係者が毎日訪れるリソース基盤としての実態が評価され売却に至った。
Q. 需要検証のための「4週間」という枠組みは、どのように配分すべきか？
第1週で解決すべき中核課題の特定と最小スコープの定義、第2週でCarrdやAirtableを用いたプロトタイプ実装、第3週でターゲット層への配布と直接ヒアリング、第4週で予約注文や事前決済などの実数値に基づく撤退または継続判断を行う配分が実用的である。
Q. ランディングページを作ってメールアドレスを集めるだけで十分な検証と言えるのか？
単なるメール登録は無料の好奇心を測る指標に過ぎず、真の支払意欲の検証には不十分になりやすい。Kansteinが指摘するように、StripeやGumroadを通じた事前決済を設けるか、手動でサービスを提供するコンシェルジュ型アプローチを併用し、身銭を切る覚悟があるかを確かめる必要がある。
Q. 現在のようにノーコードツールが溢れる環境でも、同じ検証アプローチは通用するか？
ツールの操作難易度は下がったが、単なるリンク集やキュレーションサイトは模倣されやすく埋もれやすい。現在再現するなら、単なるまとめにとどまらず、特定ニッチの痛烈なペインを解消する独自データや、Zapierなどを駆使した自動化ワークフローを組み込む差別化が不可欠である。