I’m building a post-SaaS app catalog on Base, and here’s what that actually means

For the last several months I’ve been quietly shipping web apps to a site called QuackBuilds. On the surface it looks like a simple catalog — ten or so small tools spanning health, finance, productivity, and AI, all running in the browser with nothing to install. Under the surface, it’s an experiment in what software distribution might look like when the marginal cost of producing an app approaches zero. I want to walk through both layers, because the surface is what you can use today and the underneath is what I think is actually interesting.
The visible part is straightforward. Every app is a Next.js frontend deployed on Vercel, designed mobile-first because most of my own traffic (and probably yours) comes from a phone. Where an app needs persistence, it talks to Supabase. Where an app needs something long-running that can’t live on serverless — a scheduler, a trading bot, an AI pipeline that takes ninety seconds to complete — I offload to an Oracle Cloud ARM instance running Coolify, which gives me a Heroku-like deploy experience on free-tier hardware. That infrastructure choice matters to the economic argument later, so it’s worth flagging now: my hosting cost for the long-running half of the system is essentially zero, and the serverless half scales linearly with actual usage rather than with provisioned capacity.
The less visible part is the payments and identity layer. QuackBuilds is wired into Base, Coinbase’s Ethereum L2, which means any app that eventually needs monetization can settle in USDC without me building a Stripe integration, managing chargebacks, or gating features behind a subscription. If you’ve ever tried to monetize a small tool, you know the depressing shape of that problem: the payment infrastructure is often more complex than the app itself, and the per-transaction economics make anything under a few dollars infeasible. Onchain rails collapse that problem. A five-cent micropayment is not only possible, it’s routine. That matters for a catalog of small, disposable apps more than it matters for a traditional SaaS product, which is part of why the architecture leans this way.
Here’s where it gets more ambitious, and I’ll flag upfront that parts of this are still being built rather than shipped. The goal I’m working toward is what I’ve been calling an autonomic generation layer. The idea is to treat app creation itself as a pipeline rather than as a human activity. A component I’ve named QuackRouter sits in front of multiple language models — Claude, GPT, Gemini, and others — and routes requests based on task type, cost, and availability, with automatic failover when one provider degrades. Feeding into that router is a build loop I’ve been calling the Hatchery Engine, which takes a specification, scaffolds an app, runs the output through a multi-agent review swarm for correctness and security, and ultimately deploys a candidate app into the catalog. An Agent-to-Device bridge extends the same logic to IoT and local hardware, so agents can act in the physical world and not just the browser.
If that sounds like a lot, it is, and I want to be honest about where the line between built and aspirational currently sits. The routing layer exists and works. The build loop is partially wired up — it can scaffold, but the review and deploy steps are still manual in most cases. The swarm is in design. I’m hand-building the apps that currently populate the catalog, and I’m using that process to instrument what the automated version will eventually need to handle. The reason I’m comfortable talking about the ambitious piece publicly, despite it being incomplete, is that the architecture decisions being made right now — the choice of Base for agent-to-agent payments, the choice of Coolify for long-running agent processes, the choice to make every app stateless and browser-native — only make sense in the context of that larger design. If I were only shipping a catalog of small tools, I would have chosen a simpler stack.
The design question I keep returning to, and the one I’d most like to discuss with other developers, is what a software catalog should actually look like when the cost of producing a new app drops low enough that apps become disposable. The SaaS model assumes each product is expensive to build and therefore needs to be monetized aggressively to recoup that cost. If that assumption no longer holds, a lot of downstream decisions — pricing, onboarding friction, account creation, feature gating, lock-in — start to look like artifacts of the old economics rather than genuine user needs. QuackBuilds is my attempt to design for the new economics from scratch rather than retrofit them onto the old model, and the catalog you can browse today is the early, hand-built seed of that system.
If any of this resonates — browser-first app delivery, onchain payment rails for small tools, multi-agent code generation, or the design question about disposable software — I’d genuinely value your thoughts in the comments. The catalog is at quackbuilds.com/apps and you can find me on most platforms as @itsevilduck. Architecture writeups for each layer will land on the site as I stabilize them, and I’ll probably post follow-ups here on dev.to as each piece becomes real enough to demo. Tear it apart, poke at the assumptions, ask the uncomfortable questions. That’s the half of this I’m actually here for.