BaseでポストSaaSのアプリ・カタログを作っているので、その「実際に意味すること」を話します

ここ数か月、私は QuackBuilds というサイトに向けて、こっそりとWebアプリを配信してきました。表向きにはシンプルなカタログに見えます——ヘルス、ファイナンス、生産性、AI にまたがる小さなツールが10個前後、すべてブラウザ上で動作し、インストールは不要です。ですが、その内側は「アプリを作るための限界コストがゼロに近づいたとき、ソフトウェア配布がどのような姿になりうるか」を試す実験です。なぜなら、あなたが今日使えるのは表側の部分で、私が本当に面白いと思っているのはその下の部分だからです。表側と内側の両方を順を追って説明します。
見えている部分は至って単純です。各アプリは Next.js のフロントエンドで、Vercel にデプロイされています。モバイルファーストなのは、私自身のトラフィック（たぶんあなたのトラフィックも）ほとんどがスマホから来るためです。アプリに永続化が必要な場合は Supabase と通信します。サーバーレスに置けない長時間稼働が必要なもの——スケジューラ、トレーディングボット、完了まで90秒かかるAIパイプライン——そういったものは、Oracle Cloud の ARM インスタンス上で Coolify を動かしている環境にオフロードしています。ここでは、無料枠のハードウェアで Heroku のようなデプロイ体験が得られます。このインフラ選定は、後で経済性の議論に効いてくるので、先に強調しておきます。システムの長時間稼働側のホスティングコストは、実質的にゼロです。一方でサーバーレス側は、用意したキャパシティではなく実際の利用に比例してスケールします。
あまり見えていない部分は、決済とアイデンティティのレイヤーです。QuackBuilds は Coinbase の Ethereum L2 である Base に接続されており、最終的にマネタイズが必要になったアプリは、私が Stripe の連携を作ったり、チャージバック対応を管理したり、サブスクリプションで機能を制限したりすることなく、USDC で決済できます。もしあなたが小さなツールをマネタイズしようとしたことがあるなら、この問題の絶望的な形——支払いインフラは多くの場合、アプリそのものより複雑で、1回あたりの取引経済が数ドル以下の何かを不可能にしてしまう——を知っているはずです。オンチェーンのレールは、その問題を崩します。5セントのマイクロペイメントは、可能なだけではなく日常的です。これは従来のSaaS製品よりも、「捨てられる小さなアプリのカタログ」にとって重要であり、そのためアーキテクチャもこの方向に寄っています。
ここからは、もう少し野心的な話に入ります。そして最初に言っておくと、ここで触れる部分のいくつかは「出荷済み」ではなく「制作中」です。私が目指しているのは、私の中で「自律的な生成（autonomic generation）レイヤー」と呼んでいるものです。狙いは、アプリを作ること自体を、人間の活動というより“パイプライン”として扱うことです。私が QuackRouter と名付けたコンポーネントが、複数の言語モデル——Claude、GPT、Gemini、そしてその他——の前に位置し、タスクの種類、コスト、利用可能性に基づいてリクエストをルーティングします。また、提供元の品質が落ちたときには自動的にフェイルオーバーします。このルータに接続されるのが、私が「Hatchery Engine」と呼んでいるビルドループです。これは仕様を受け取り、アプリをスキャフォールドし、出力を複数エージェントによるレビュー用のスウォームに通して正確性とセキュリティを確認し、最終的に“候補となるアプリ”をカタログへデプロイします。さらに Agent-to-Device ブリッジは、同じロジックを IoT とローカルのハードウェアへ拡張します。これにより、エージェントはブラウザの中だけでなく、物理世界で行動できます。
これがかなり大がかりに聞こえるのはその通りで、私は現時点で「作られている部分」と「理想として描いている部分」の境界がどこにあるのか、率直に説明したいと思っています。ルーティングレイヤーは存在していて動作しています。ビルドループは部分的に組み込まれており、スキャフォールドはできますが、レビューとデプロイの手順は多くの場合まだ手作業です。スウォームは設計段階です。私は現在カタログを埋めているアプリを手作業で作っていますが、そのプロセスを、いずれ自動版が最終的に扱う必要があるものを計測するために使っています。未完成であるにもかかわらず、野心的な部分について公に語っても大丈夫だと感じる理由は、今まさに行っているアーキテクチャ上の意思決定——エージェント間の支払いに Base を選んだこと、長時間稼働するエージェント処理に Coolify を選んだこと、すべてのアプリをステートレスにしてブラウザネイティブにすることを選んだこと——が、そのより大きな構想の文脈でのみ意味を持つからです。もし小さなツールのカタログだけを出荷しているだけなら、もっと単純なスタックを選んでいたはずです。
私が繰り返し考え、他の開発者と特にぜひ議論したい問いは、「新しいアプリの製作コストが十分に低くなり、アプリが使い捨て可能になるようになったとき、ソフトウェアカタログは実際にどのような形になるべきか？」です。SaaSモデルでは、各製品は作るのに高いコストがかかるため、そのコストを回収するために強くマネタイズする必要がある、という前提が置かれています。その前提が成り立たなくなった場合、価格設定、オンボーディングの摩擦、アカウント作成、機能のゲーティング、ロックインといった多くの下流の判断は、ユーザーの本当のニーズというより、昔の経済モデルの“遺物”のように見えてくるようになります。QuackBuilds は、古いモデルに後付けで適合させるのではなく、新しい経済性を最初から設計し直すための私の試みです。そして、今日あなたがブラウズできるカタログは、そのシステムの初期の、手作りの種（シード）です。
もしこの中の何かに共感してくれるなら——ブラウザファーストのアプリ配信、オンチェーンの決済レールによる小さなツールのマネタイズ、多エージェントによるコード生成、あるいは「使い捨てソフトウェア」という設計上の問い——コメント欄であなたの考えをぜひ聞かせてください。カタログは quackbuilds.com/apps にあります。多くのプラットフォームで私は @itsevilduck として見つけられます。各レイヤーのアーキテクチャ解説は、私がそれを安定化させるにつれてサイトに掲載していく予定で、デモできるほど現実になった各パーツについては、dev.to でも追記を投稿することが多分あります。この仕組みを分解して、前提に突っ込み、気まずい質問を投げかけてください。私はそのためにこの半分（ここ）に本当にいるのです。