3年で失敗に終わった私のスタートアップのコードを公開

 (dylanhuang.com)
3 ポイント 投稿者 GN⁺ 2024-12-18 | 1件のコメント | WhatsAppで共有
  • KonfigはAPI統合を容易にする開発者向けツールのスタートアップとして始まったが、3年後に終了し、製品コードと運用成果物を含むコードベースを公開した
  • 中核製品はOpenAPI仕様からクライアントライブラリを生成するSDK Generatorで、その後ドキュメント化や対話型APIテスト環境へと拡張された
  • 一部のスタートアップ顧客から反応はあったものの、契約の難しさと低い価格帯のため、超高速成長ビジネスへ育てるのは難しかった
  • その後、バーティカルB2B SaaSのAI製品へピボットしたが、複数のインタビューや営業活動を通じても、大きな事業になると確信できるだけの**市場の反応（トラクション）**は見つからなかった
  • 公開リポジトリは終了時点の状態そのままで、整理・修正なしに製品コード、ピボット実験、営業スクリプト、デプロイ設定、マーケティングWebサイトを含んでいる

Konfigが作っていたAPI開発者ツール

  • Konfigは2022年末に始まったAPI開発者ツールのスタートアップで、開発者がAPIを扱う方法を単純化することに注力していた
  • 目標は、SDK生成、ドキュメント化、テスト周辺ツールを改善することだった
  • 主力製品はSDK Generatorだった
    • OpenAPI仕様を入力として受け取り、複数のプログラミング言語向けクライアントライブラリを生成する
    • その後、APIドキュメントツールと対話型APIテスト環境へと拡張された

成長の限界とAIピボット

  • 一部のスタートアップ顧客ではトラクションがあったものの、超高速成長ビジネスにはつながらなかった
  • 見込み顧客との契約締結は難しく、証明可能なROIがあっても価格帯が低すぎた
  • 生成AIの発展後、以前は解決が難しかった問題を解決できると考え、バーティカルB2B SaaSのAI製品へピボットした
  • 複数のアイデアについてユーザーインタビューや営業を進めたが、巨大な事業につながる方向だと確信できるほどのトラクションは見つからなかった

終了時点のまま公開されたリポジトリ

  • 公開リポジトリは konfig-dev/konfig である
  • リポジトリは会社終了時点の状態そのままで公開された
    • 整理なし
    • 磨き込みなし
    • 修正なし
    • コードベースは、フィルタリングされていない実際のスタートアップコードの状態を示している

3年間で作った主な製品

あわせて公開された運用コードと実験

創業者が残した回顧

  • Dylan Huangは2022年3月に仕事を辞めてスタートアップに専念し、失敗の可能性を理解しながらも挑戦した
  • 今回の失敗を、成功以上に多くを教えてくれた経験として受け止めている
  • 次の段階として、新しい機会を探り、採用市場で自分に合う場を探しつつ、学びと成長を続ける計画だ
  • いつか再び自ら何かを作る挑戦にも前向きである

関連記事

1件のコメント

 
GN⁺ 2024-12-18
Hacker News のコメント

  • 「超高速成長」する「巨大な事業」ではなく、小さな事業を目指していたら、今ごろ優れたニッチ製品がどれだけ残っていただろうと思う

    • そう言うのは簡単だけど、実際にやってみると、3〜5年間ほぼ無給で耐えながら、投資を受けた事業と似たような結果を期待しなければならないので本当に難しい
      先進国で2〜3人規模のスタートアップが生き残るには、月額10ドルのライセンスをものすごい数売らなければならず、機会費用も考慮する必要がある
    • 毎月必要な費用を賄うために投資を受けるなら、投資家の立場では超高速成長の可能性がなければポートフォリオの計算が合わない
      小さく持続可能な事業を最初から目標にして成功すれば投資を避けられるが、会社の中盤から後半でまったく新しい方向へピボットしたのなら、すでに準備金の大半を燃やしている可能性が高い
    • そういう結果なら、大企業に就職してリスクなしで似たような報酬を得るほうが理にかなっている
    • 自分もこの点が気になっていた。生活費の低い地域でコンサルティングをしているブートストラップ企業の共同創業者3人のうちの1人だが、ここ数年、創業者に年5万ドルずつ給与を支払ってきたし、特別に運が良かったわけでも事業判断がものすごく優れていたわけでもないのに、かなりうまくいっている
      今年の売上は40万ドル、利益は15万ドル、成長率は40%で、営業見通しも年初よりずっと良くなった。来年も力強い成長を期待しており、市場飽和にはほど遠いので、今後数年間は成長の余地が大きい
      給与と利益の3分の1を合わせると今年ベースで10万ドルで、40%成長なら会社は2年ごとに倍になる。うまくいけば給与と利益だけでもかなり良くなり、そこに創業者たちが数百万ドルを得られる売却機会も加わる
    • ここには「ほら、難しいと言っただろ！」という含みを感じる
      Googleのような会社を作ろうとすることと、Basecampのような会社を作ろうとすることは、どちらも問題なく、単に異なる種類の会社というだけだ
      むしろ「低リスク事業」を作るリスクは過小評価されがちで、どんな事業も難しい。Konfigに拍手を送りたい

  • Konfigの顧客として本当に残念だ。私たちはおそらく最初の顧客だったかもしれないし、初期のコミットにも言及されていたように思う
    DylanとAnh-Tuanは、私たちの実際の問題をいくつも非常に見事に解決してくれた。生成されたSDKと見栄えのよいホスティングされたドキュメント／チュートリアルを1か所で提供し、私たちのAPIを呼び出してユーザーがすぐに実データで試せるようにしてくれた
    Konfig以前は、APIをラップするSDKを手作業でばらばらに作っており、ドキュメントはReadMeでホスティングしていたが、私たちのAPIのリクエスト署名要件のせいでインタラクティブにはうまく動かなかった
    Konfigがオープンソースとして公開してくれたおかげで、今はドキュメントを自前でホスティングしている: https://docs.snaptrade.com/
    このチームを本当に尊敬しているし、どうにか続ける方法を見つけられたらよかったのにと思う
    Konfigのように顧客には好かれているが、必要なほど売上が伸びない製品を運営しているなら、価格をもっと上げることも検討する価値がある。私たちはKonfigが請求していた金額の2〜3倍でも払っただろうし、成長に伴ってさらに払ったはずだが、彼らは求めもしなかったし、SDKごとの月額料金やデモごとの月額料金のような利用量ベースの課金も作らなかった

    • あなたの製品を通じてKonfigを知った。ドキュメントがあまりに良かったので、裏で何を使っているのか調べずにはいられなかったし、SwaggerやRedocより本当に優れている
    • https://github.com/OpenAPITools/openapi-generatorを直接試してみなかったのか気になる
    • 軽量なAPIドキュメントの代替が欲しいならScalarをおすすめする。シンプルで使いやすいのに、Swaggerドキュメントよりずっと良い

  • 米国のスタートアップ文化は本当に奇妙。すべてが超高速でスケールする必要はないし、すべてが巨大である必要もない
    事業は持続可能性にもっと集中すべきで、2〜3年の間に3回ピボットした末に店じまいするようなやり方であってはならない

    • 一方ではその通りだが、他方では「超大型スケールでなければ失敗」という執拗な集中こそが、米国のスタートアップ・エコシステムを今の位置まで押し上げ、世界の他地域を大きく引き離した理由である可能性も高い
      欧州のスタートアップ創業者の多くに「5年後に従業員15〜20人で頭打ちになり、安定したキャッシュフローがあり、自分に年20万〜25万ドルを支払っている」と言えば、大成功だと考えるだろう。米国では、特にベンチャー投資を受けていれば、失敗と見なされるかもしれない
      シリコンバレーのベンチャー投資家が「会社を5,000万ドルで売ることを成功だと思うなら、マインドセットが間違っているし、一緒に仕事をしたくない」と公然と言うのを聞いたことがある
      大きな挑戦と大きなリスクを取らず、小さな成功と安定成長で満足していれば、大きな報酬は絶対に得られない。個人にとってはそのほうが健全かもしれないが、経済全体には悪いかもしれない
    • 収益性のある小さな事業、つまり小さなチームと長期目標を持つ、退屈に見えるかもしれない会社は、非現実的に大きな目標を掲げないため、HNのトップページにはあまり上がってこないように思う
      この文化が「素早く動いて壊せ」的な考え方を受け入れているのは興味深いが、主にテック業界にだけ当てはまるようだ。何度も失敗した事業家が「連続起業家」と呼ばれるのもそうだし、持続不可能な会社を売ることを成功と見るのは難しい
      いくつものスポーツで失敗した人が自分を「連続アスリート」と呼んだらどんな感じかを考えると笑える
    • 問題は、ベンチャー投資を受けた瞬間に超大型スケールの方向へ押しやられる点だ
      ベンチャー投資を受けなければ、コンサルティングのような形で自力で資金を賄える場合を除き、自走可能な状態に至る道のりははるかに難しく、長くなる。ここでのモデルは37 Signalsだが、彼らはRailsを作った会社なので非常に例外的だ
      そしてその地点に到達しても、ベンチャー投資を受けた競合が、より良い人脈と資金で押し寄せて踏みつぶす可能性がある
    • 欧州にいて、まさに同じ困難を抱える会社で働いている
      大企業向けB2Bの営業サイクルはばかげたほど長く、中小企業に売れる価格帯では十分ではない
      自分たちが価値を提供し、顧客の時間を節約していても、その価値を説明するのは常に難しい
      隣の芝は青く見えるものだが、B2B事業をやりながら数年間明かりを灯し続けるために同じ苦労を繰り返し、毎月似たような会話を別の顧客としながら、年に10回もなぜ価値があるのかを同じように説明しなければならないなら、人々がそこに閉じ込められたくないと思うのも理解できる。燃え尽きも早く来うる
      だから、価値が明確で、人々が「お金を持っていってくれ」と叫ぶような事業アイデアを見つけたいと思う気持ちも理解できる
    • 西側企業が水平ではなく垂直拡張を好むのには、いくつかの要因がある
      第一は投資収益率だ。他人のお金を引き込むなら、その人たちは当然リターンを期待するし、賢明な投資家はポートフォリオを分散するため、多くの投資が失敗することを知っている。だから損失を相殺するため、すべての投資先に可能な限り大きく成長するよう圧力をかけ、少数の超高パフォーマンス企業に失敗を埋めさせる
      こうした垂直成長はスタートアップだけでなく大企業にも見られる。これには形式主義、過剰規制、官僚制が大きく作用していると思う。許認可、税務や給与アカウントの設定など数多くの手続きを経なければならず、上場するにはさらに多くの手続きを踏まなければならないなら、新会社を分離して作るより、すでに確立された会社の活動範囲を広げるほうが、はるかに安くリスクも低い場合がある

  • 競合だったように思う。ReadMe.comの創業者で、私たちはAPIドキュメントやSDKなどを提供している
    具体的になぜ私たちが成功したのかはよく分からないが、私自身も数多くの誤った出発を経験し、人々が目に見えて興奮する地点に到達するまで、核となるアイデアを少しずつ反復改善してきた
    この市場が難しいことは分かっていたので、エンジニアリング以外のことにも多くの時間と労力を注いだし、特により率直にさらけ出したとき、Hacker Newsはいつも私たちに好意的だった
    もっと聞いてみたくて、個人的に連絡してみようと思う
    全体としては、注ぎ込んだすべての努力に祝意を送りたい。会社を始め、自分を信じるのはものすごく難しいことであり、誇りに思っていい

    • ReadMeがKonfigより成功した理由は、8年早く始めたことかもしれない。Konfigは良いアイデアで、実行もよかったが、単にタイミングが合わなかった可能性がある
    • せっかくなので言うと、ReadMeのログイン画面のCSSトランジション効果は、私の記憶に残る最も強いブランディング要素のままだ。誰が考えたにせよ、本当に素晴らしい

  • この結果は近い将来たくさん見ることになりそうだ。AIバブルがしぼむにつれて、似たようなことが繰り返されるだろう

    • むしろこう書いていたなら、その努力をもっと尊重できたと思う
      「私たちは生成AIを垂直型B2B SaaS製品に活用し、以前は解けなかった問題を解決できると考えて試みた。複数のアイデアを作って提案したが、ユーザーの反応は、巨大な事業を作る正しい方向だと確信できるほど肯定的ではなかった。」
      原文のままだと、「この記事を書いた人は一時的で狭い流行文化に深く埋め込まれていて、本能的に拒否感を覚えるし、完全に失敗した直後でさえ心理的にそこから抜け出せていないのだな」という第一印象を与える
    • コードをオープンソースで公開して諦めるのは、究極のAIピボットだ。新しいモデルたちがあなたのやったことを学習して、いつかもっと上手にできるようになるだろうから

  • ぴったり合わない製品がピボットの方向を探す中でAIを答えにして失敗した、という話は初めてではない
    前にも言ったが、繰り返す価値がある。AIが得意なことと不得意なことを見極めれば、私たちはAIを目標ではなく道具として扱い始め、製品アイデアの発想も安定するだろう

    • 私たちはすでに知っている。AIはもっともらしい内容をでっち上げることが得意で、事実や検証に耐える成果物を作るのは苦手だ
    • 製品自体は悪くなかった。OpenAPI仕様からSDKを作るその製品に喜んでお金を払い、多くの価値を得ていたスタートアップにいた
      だから、ここでの問題はプロダクトマーケットフィットではなかったと思う
    • AIが何かを自動化しても、悪い製品アイデアを救うことはできないという意味か？ 誰も望んでいないことをより効率的に行うのは事業ではない、というように
    • APIという概念は消えるべきで、単にAI同士が自然言語で会話するようにすべきだ

  • これをどう見ればいいのか、正直よく分からない。一方では、自己省察、不都合な真実に向き合ったこと、そしてかなり幅広いツールセットを作ったことには拍手を送りたい。
    ただ中身を見ると、ツールを包んだツールになっている。API分類ツールは、重い作業のかなりの部分をOpenAIに投げているように見える。
    「あなたは世界最高レベルの分類器です。これらのAPIを、このグループのいずれかに分類してください。」
    残りのファイルは配線コードと、モデル・ビュー・コントローラーの境界が少し曖昧になっている程度だった。テストも見えたし、外部の制御外での変更が多いツールのラッピングでは重要だろうと思ったが、実際にはIntelliJがデフォルトで用意するcontextLoads()の関数テストのように、依存関係があり、コンパイルが失敗しないことを確認する程度だった。
    ビジョンはあり、パレートの法則にも沿っているが、市場は自分たちのものを保守することに関心がない、という仮説を検証している間に、肝心の社内では自分たちの保守問題も解決できていなかったように感じる。
    まず自分たちでその理由を解決できていれば、他人にも解決できたはずだが、そのためには実際に使われるプロダクトがあってこそ痛みを感じ、エンドユーザーに共感できるというジレンマのように見える。

  • 失敗したスタートアップは恥じることではない。私たちのほとんどは、挑戦する勇気すら持っていない。
    コードに大きな関心を期待するのは難しい。ビジネスと人が抜け落ちた会社のコードの価値は、特別な技術的秘密兵器でもない限り、かなり否定的だ。
    たとえ技術的にすごい部分があったとしても、人々はその一部分がどう動くのかを理解しようとするだけで、コード自体を使う可能性は低い。

    • Konfigの創業者です。100%同意します。誰かにKonfigを自力で解読してデプロイしてみることは勧めません。
      ただし、ある顧客はKonfig終了の影響に対処する方法を探す間に、私たちのドキュメントプラットフォームを自社でデプロイすることに成功しました。
    • だんだん失敗の少ないスタートアップを何度かやってきて、苦労して学んだことはこうだ。
      すぐに売上を出せる事業計画か、巨額の投資資金がないなら、テックスタートアップを作るべきではない。通常、事業がどこへ向かうのかについて最低限の感覚すらなければ投資も受けにくく、技術者はたいていビジネス面を十分に理解していない。
      ほとんどの会社はスタートアップではなく、ただの会社だ。売上があり、請求書を払う会社である。スタートアップとは、売上なしに借りた時間とお金で生きる会社であり、特にそのお金が自分のお金なら計画が必要だ。
      ベンチャー投資を受けた会社の大半は失敗する。ベンチャーキャピタルの仕事は、失敗する会社を早く失敗させることであり、失敗せず爆発的に成功する少数の会社で自分たちの事業を成り立たせている。「アクセラレーティング」や「資金調達」は成功ルートにいるという意味ではなく、確率に勝たなければならない場所に乗せられ、残された時間は多くないという意味だ。
      売上のある成功した会社なら、ベンチャーキャピタルは必要ない。ならば、なぜ彼らと話しているのかを問うべきだ。売上を作るのが難しいなら、ベンチャーキャピタルはそれを直してはくれない。
      多くのベンチャーキャピタルは怠惰で、すでに成功した後でようやく関心を示す。だから、初期に投資を受けた会社は失敗し、投資を受けられなかった会社が成功するという奇妙な力学が生まれる。
      今の会社は4年目に入り、完全にブートストラップで運営している。売上に苦労し、使える時間に仕事を詰め込み、私は主に副業のコンサルティングで生活している。会社は3年連続で過去最高の年を迎え、もうすぐコンサルタントをやめて事業に集中できるところまで近づいているが、長い道のりだった。
      オープンソースについては、事業特化のコードや中核的な知的財産でないものは公開している。次の会社を始めるときに同じ雑用をまた作りたくない、というのも大きな理由だ。そういうものが速度を落とすことを経験してきた。
      スタートアップでは知的財産に執着する人が多いが、現実的にはほとんどのソフトウェアはそれほど価値がない。それでも、それを作るには時間、お金、エネルギーがかかる。
      だから、自分が主なユーザーになるツールやフレームワークなどを多く公開している。次のプロジェクトでも使い続けるためだ。

  • コードのダンプ自体は興味深いかもしれないが、ライセンスが付いていないように見える。きちんとオープンソースライセンスを付ければ、ずっと有用になるはずだ。

    • コメントから約1時間後にMIT LICENSEファイルが追加された。

  • 開発者ツール市場は本当に難しい。
    ほぼすべてのアーキテクチャ上の判断が「この問題を解決するには、どのオープンソースツールを使えるだろうか」になる。
    誰もお金を払いたがらないし、それで構わない。

    • そうではあるが、ほとんどの開発者は自分が直面している問題以外の問題をほとんど認識しておらず、それらの問題はたいてい開発者ツールの問題だ。
      だから、ほかの領域に非常に大きなニーズがあるにもかかわらず、開発者ツールのスタートアップを作る会社が多くなる。
      何かを始めようとしている熟練開発者が、問題とドメイン専門性、起業意欲を持つ人たちを、偶然やネットワーキング以外の方法でも見つけられるなら、多くの価値が解き放たれると思う。
    • 開発者にツールを売るのは難しい。常に適応し変化し続ける大量のオープンソースツールと競争しなければならず、良いアイデアはすぐに吸収され、複製される。
      そのため、ほとんどの商用ツールは有用性という面で寿命が限られており、だいたいは「あれば便利」程度にとどまる。
      さらに、多くの開発者は雇用されていて、個人のツール予算を持っていない。市場は実質的に、フリーランス開発者か、開発者を雇っているマネージャーに狭まる。
      チームのマネージャーはこうした支出を細かく精査し、たいてい予算も多くない。ほとんどの会社には、開発者向けの個人ツール予算というものがない。
      フリーランスも一般に、自分にお金を払っている会社が使うツールを使い、それはほとんどの場合無料ツールだ。有料ツールは契約者ライセンスまで気にする必要があり、フリーランスを使うことをさらに複雑にする。だから単純に保つために、そうしたツールを避ける傾向がある。
    • さらに言えば、開発者ツールは誤解されるほど難しい。開発者ツールを作ることが、会社やスタートアップの勝ち筋のように見えやすい。自分も開発者であり、過去に自分で経験した問題を見つけた可能性が高いからだ。
      開発者がどこに集まり、何が刺さるのかも分かっているので、すべてうまく見える。
      しかし言われているように、多くの開発者はお金を払いたがらず、少し不便でも必要なことをやってくれるオープンソースの解法を探す。しかも相手は、仕事も人生もソフトウェアを作る人たちなので、答えが「自分で作ればいいか」になることもある。
    • 完全にその通りというわけではない。ただ、10ドルの請求書50枚を処理するのに時間を無駄にしたくはない。
      複数のサービスを1つの請求書にまとめてくれるビジネスはないのだろうか？ それとも、やはりAWS、Azure、GCloudを使うしかないのか？