私が構築したすべての製品は何らかの不便から始まった - そしてここに15個の問題すべてがあります

誰もが朝起きて15個のソフトウェア製品を構築することにしません。これはそのようには機能しません。実際に起こることは、スタートアップの起源物語が示唆するよりも遅く、より混乱していて、はるかに華やかではありません。問題が現れます。それは醗酵します。既存のソリューションは過度に高価か、不十分なパフォーマンスか、またはサブスクリプション モデルにそれほど固定されているため、小さなタスクにそれらを使用することは、ランプを運ぶためにムービングトラックを借りるような感じです。最終的に、不満は閾値を超え、唯一の合理的な反応はより良いものを構築することです。その後、別の問題が現れます。そしてもう1つ。15個の問題の後、ここに完全なプラットフォームがあり、すべての製品は、特定の不満の瞬間にまで遡ることができます。

これは、起業家精神を恋愛的に見せるために慎重に作られた物語ではありません。これらの不満のいくつかは些細なものでした。いくつかは高価でした。いくつかは週末全体を台無しにするのに十分なほどイライラしていました。しかし、すべてが同じパターンに従いました:問題に直面する、解決策を検索する、解決策が不十分であることを発見する、より良いものを構築する。このパターンは何年も繰り返されましたが、その結果はyeb.toで、41個のAPI、18個のSaaS アプリケーション、68個のオンライン ツールを提供しています。

すべてを始めた最初の5つの不満

キャプション ツールは最初に来て、最も単純な刺激から来ました。AI生成音楽を再生するYouTubeチャネルを実行することは、焼きたての字幕をインベストしたリリックビデオを製造することを意味します。Captions.aiはこの特権に対して月額10ユーロを請求しました。これは2〜3個のビデオのみを持つ月が蓄積され始めるまでは適切に見えていました。ほとんどの週で未使用のツールの月額サブスクリプション料金は、静かに複合する廃棄物の一種でした。代替案は明白でした:月ごとに処理されたビデオ数に基づいて料金を請求するツールを構築します。クレジットはサブスクリプションを置き換え、節約はすぐに明白になりました。

翻訳 ツールは異なる問題から成長しました。機械翻訳サービスは主要言語を十分に処理しますが、ブルガリア語またはセルビア語が必要になるとすぐに、品質が低下します。性別の契約エラー。間違った動詞の活用。技術的には翻訳されていますが、辞書から言語を学んだので、話された形式で聞いたことのない人によってアセンブルされたように聞こえる文。既存のツールは、英語、スペイン語、フランス語に最適化されたエンジンに付属する側面として、より小さな言語を扱いました。すべての言語を一級市民として扱う翻訳サービスを構築することは、ビジネス上の決定ではありませんでした。これは、完全に通常の文の多くの見当違いの翻訳を受け取ることに対する反応でした。

透かし ツール出版から来ました。本を書いて、PDFに変換し、公開の数日以内に海賊版サイトに表示されるのを見て、ユニークな違反の種類です。DRM ソリューションは保護を約束しましたが、正当な読者に不便をもたらし、決定的な海賊船に対してゼロ障害をもたらしました。著者が実際に必要とするコピー防止ではなく、コピーの追跡であるという実現は、すべての配布コピーを個別に識別できる透かし システムにつながりました。問題は個人的でした:本が海賊版になっていました。ソリューションは製品になりました。

通貨コンバーターは、宣伝されている為替レートと実際に受け取った金額の間のギャップから生まれました。すべての国際的な転送には、中間市場レートをチェックし、隠された手数料、マークアップパーセンテージ、およびプラットフォームが事前に表示したことのない変換スプレッドのために、受け取った金額がかなり低くなるのを観察するというリチュアルが伴いました。実際のレートを、Wise、Revolut、PayPal、Western Unionが実際に請求するものと並べて示す通貨ツールを構築することは、「手数料なし」の約束が3パーセントのスプレッドに蒸発したときに、多くの転送を受け取ることに対する直接的な反応でした。

リンク管理 プラットフォームは、2026年に存在しないはずの問題に対応しました。Bitlyは、ブランド化された短いリンクに対して月額35ドルを請求しています。35ドル。その主な機能が長いURLを短いURLに置き換えることであるサービスの場合。URLの短縮の技術的な複雑さは最小限です。インフラストラクチャのコストは無視できます。しかし、市場は、すべてのユーザーがコーポレート予算を持つマーケティング部門であると想定する価格設定に何らかの方法で収束しました。LinkHubをクレジットベースの代替手段として構築することは、短いリンクの作成がセントの分数で費用がかかり、月額請求書が実際の使用に正確に比例することを意味しました。

技術的になった問題

スクリーンショット APIは、稼働時間の監視から始まりました。Webサイトがアップかダウンかをチェックすることはごく簡単に見えますが、JavaScriptレンダリング、遅延ロード、またはシングルページアプリケーション アーキテクチャを使用する場合、それは簡単です。従来のHTTPリクエストは空のページまたはローディングスピナーを表示し、すべて良好であると報告しますが、実際の訪問者は壊れた体験を見ます。レンダリングされたページのリアルブラウザスクリーンショットは、HTTPステータスコードが決してできない方法で真実を伝えます。この視覚的検証の必要性は、スケジュール設定されたキャプチャ、ビジュアル差分検出、OCRテキスト抽出を備えた完全なスクリーンショットAPIに進化しました。クライアントプロジェクトで5時間の検出されないダウンタイムは、すべてを開始した特定のインシデントでした。

ボット検出は、より不安な発見から成長しました。Webプロジェクトの分析をチェックし、ゼロ変換、ゼロ関与、ゼロスクロール深度を生成する1000万の訪問を見つけること。実際のブラウザのように見せかけているボットからの1000万の訪問、メトリックを膨らませ、データを歪め、その交通に基づくすべてのビジネス上の決定を基本的に間違ったものにします。既存のボット検出ソリューションは、セキュリティ予算を持つ企業向けに価格設定されたエンタープライズ製品でした。リクエスト レベルでボット トラフィックを識別でき、デバイス フィンガープリント と行動分析を使用する検出APIを構築することは、Webトラフィックの重要な割合が架空のものであるという実現に対する直接的な反応でした。

稼働時間 監視 ツールスクリーンショットAPIが明らかにしたギャップを埋めました。サイトが視覚的に壊れていることを知ることは有用ですが、それが壊れた瞬間を知ることは重要です。既存の稼働時間モニターはエンドポイントをチェックし、HTTPコードを報告しました。これは、サーバーが200ステータスコードで応答するがページのコンテンツが間違っているか、欠落しているか、破損している障害の全体的なカテゴリーを逃します。稼働時間チェックを定期的なスクリーンショットと組み合わせることで、従来のツールに見えない障害をキャッチする監視システムが作成されました。

小さく見えたが、そうではなかった問題

QR コード生成は、解決された問題である必要があります。オンラインに数千の無料生成器があります。しかし、特定の配色、埋め込みロゴ、カスタムエラー訂正レベル、および分析追跡を使用してQRコードを生成しようとすると、無料のツールはほぼ即座に制限を明らかにします。yeb.toのQRコードジェネレーターは、すべての無料の代替手段がカスタマイズなしでプレーンなブラック・アンド・ホワイト・スクエアを生成するか、生成されたコードごとにペニーのコストがかかる機能の月額サブスクリプションを要求するためです。

PDFツールは、ドキュメント ワークフロー摩擦から来ました。3つのPDFをマージするには、デスクトップソフトウェアをダウンロードするか、不明瞭なプライバシーポリシーで見知らぬ人にセンシティブなドキュメントをアップロードする必要はありません。PDFを分割したり、圧縮したり、画像に変換したり、テキストを抽出したりすることは、ボタンをクリックするのと同じくらい簡単な操作です。プラットフォーム上のすべてのPDFツールは、特定のドキュメントタスクが必要であった、利用可能なオプションが不十分であった、ツールの構築が不十分の周りで働き続けるよりも時間がかかったためです。

GeoIP検索サービスは分析コンポーネントとして開始されましたが、異なるプロジェクト全体で訪問者の場所を識別する必要性が繰り返し生じた場合、独自の製品になりました。商用GeoIPデータベースは年間ライセンス料を請求します。APIは、自由に利用可能なデータを即座にクエリできる形式にパッケージ化し、検索クレジットコストは、高いボリュームアプリケーションでも企業契約を交渉することなく自分自身に余裕がある程度です。

WordPressアナリティクス プラグインは、これらの不満のいくつかを結びつけました。WordPressサイトを実行することは、実際の訪問者をボットから区別し、地理的な起源を識別し、デバイスの種類を検出できる分析が必要であることを意味しました。Googleアナリティクスはそのうちのいくつかを処理しますが、有用なデータをインターフェースの複雑さと、ますます積極的なデータサンプリングの下に隠します。WordPressプラグインは、内部でyeb.toAPIを使用します。これは、本物の必要性から構築された製品が、どの個別のツールよりも大きいものに自然にどのように接続するかの実証です。

すべてを接続するパターン

製品の完全なリストを見て、それぞれを原点に遡ると、非常に一貫性のあるパターンが現れ、ほぼ処方的に見えます。すべての製品は、問題とのスポーク的な遭遇から始まりました。市場調査の調査結果ではなく、競合分析ではなく、トレンドレポートではなく。実際の、具体的な、不快な問題が解決を求めていました。キャプションツールは存在します。なぜなら、月額10ユーロで3つのビデオは間違っていると感じたからです。翻訳者が存在するのは、ブルガリア語が焼かれ続けたためです。透かしツールが存在するのは、本が海賊版になったためです。通貨コンバーターは、隠された手数料が国際的な転送を食べ続けたため存在します。リンクマネージャーが存在するのは、URLの短縮に対して35ドルは不合理だからです。

個人的な欲求不満から構築された製品は、市場の機会から構築された製品よりも構造的な利点があります。創設者は、彼らがそれで生きたので、セルラーレベルで問題を理解しています。どの機能が重要で、どの機能が装飾であるかを知っています。既存のソリューションが失敗する瞬間を正確に知っています。彼らは、彼らが想像する使用例ではなく、彼らが知っている使用例のために構築しています。

不利な点は、このアプローチが予測不可能なスケジュールで製品を生成することです。四半期計画に基づくロードマップはありません。新しい製品は、新しい不満が閾値を超えたときに現れます。1つの四半期で3つの製品が出現することもあります。既存のツールの改善で6か月が経つこともあります。開発タイムラインは、ビジネス計画の形状ではなく、実際の問題の形状に従います。

15個の欲求不満は15個の製品ラインになり、41個のAPIと68個のツールに拡張されました。クレジットシステムはすべてをまとめていますので、キャプションから始まるユーザーは、新しいアカウントや新しいサブスクリプションを作成することなく、透かし、リンク追跡、翻訳、および通貨換算を発見できます。エコシステムは有機的に成長しました。なぜなら、それが解決する問題は有機的に接続されているからです。ビデオを作成するクリエイターもキャプションが必要です。本を書く著者も透かしが必要です。リンクを短縮するビジネスもQRコードが必要です。接続は計画されていません。それらは一度に1つの不満の時点で発見されました。

よくある質問

15個の製品はすべて1人で構築されていますか?

はい。yeb.toのすべてのAPI、SaaSアプリケーション、およびオンラインツールは、単一の開発者によって設計、開発、および保守されてきました。テクノロジースタックは、アプリケーションフレームワーク、レンダリング用のブラウザオートメーション、およびオーディオ転写用のAIモデルです。

なぜ、単一の焦点を当てたツールの代わりに、これほど多くの異なる製品があるのですか?

各製品は、個人的に遭遇した特定の不満に対応しています。多様性は、働く開発者とコンテンツクリエイターが異なるドメイン全体で直面する問題の幅を反映しています。共有されたクレジットシステムとインフラストラクチャは、複数の製品を維持することは、それぞれが独立したインフラストラクチャで実行される場合よりもはるかに効率的であることを意味します。

すべての製品は同じクレジットシステムを使用していますか?

はい。1つのクレジットバランスは、41個のAPI、18個のSaaS アプリケーション、68個のツール全体で機能します。10ドルで100クレジットを購入すると、一括購入によってクレジットあたりのコストが削減されます。クレジットは失効しておらず、サービスが実際に使用されている場合のみ控除されます。

どの製品が構築が最も難しかったですか?

スクリーンショット APIは、コンテナー内でヘッドレスChromiumブラウザを実行しているため、最も複雑なインフラストラクチャが必要でした。ブラウザインスタンスの管理、JavaScriptの重いページの処理、OCRの実装、ビジュアル差分検出の構築には、テキスト処理またはAPIラッパーツールよりも多くのムービングパーツが含まれていました。

他の誰かがいなくても、誰かが1つの製品だけを使用できますか?

絶対に。すべての製品は独立して機能します。クレジットシステムは共有されていますが、複数のサービスを使用する必要はありません。キャプションのみが必要な人は、彼らが選択しない限り、透かしまたは通貨ツールと相互作用することはありません。

新しい不満が現れたときはどうなりますか?

それは新しい製品になります。開発プロセスは最初のツール以来変わっていません。問題は特定され、既存のソリューションが評価され、それらが不足している場合は、新しいツールが構築されます。プラットフォームは、計画的な製品の立ち上げのペースではなく、実際の問題のペースで成長します。