The Disposable Tools Manifesto

I built 20+ developer tools in six months. All of them work. None of them matter.

Not because they’re bad. Because the world changed underneath them while I was shipping. A friend put it bluntly: “I don’t work on the tool. The tool is a means to an end, not the end. Disposable tooling.”

He doesn’t build polished tool repositories. He builds what he needs, uses it, and moves on. The tool is scaffolding, not the building.

20+ products. 0 revenue.

In the past six months, I’ve shipped roughly 8,000 GitHub contributions across 20+ projects. MCP servers, browser extensions, CLI plugins, observation libraries, desktop apps. Here’s a partial list:

• claudebin (write-up): a session-sharing tool for Claude Code.
• agentprobe (write-up): an observation library for AI coding agents. Four provider integrations, published on npm.
• micode (write-up): a structured AI coding workflow plugin for OpenCode. Version 0.9.1.
• octto (write-up): an interactive browser-based brainstorming tool. Version 0.3.1.
• claude-notes (write-up): a CLI tool to transform Claude Code JSONL transcripts into readable, searchable HTML.
• wunderlabs: Lovable for existing codebases.
• cursouls (write-up): a pixel-art agent visualization extension for VS Code.

Every single one of these works. They’re tested, documented, published. And every single one of them generates zero revenue.

Here’s the part that stings: I built most of these with AI agents. They didn’t take months. They took days. I wasn’t slowly hand-crafting artisan software. I was shipping fast, with modern tools, into a void.

Take agentprobe. It gives you real-time observability for AI coding agents. Four provider integrations, clean API, published on npm. And here’s the thing: if you actually need real-time notifications from your agents, you don’t install agentprobe. You just ask Claude to implement that specific piece for your specific setup. It takes 20 minutes. Why would you add a dependency when the solution tailored to your exact problem is just as fast to build?

That’s the uncomfortable realization. The problem isn’t build speed. The problem is that generic solutions lose to specific ones when specific is just as cheap. I wasn’t competing with other developers. I was competing with the user’s own Claude session.

The IDE is now Claude

Here’s what changed. A year ago, if you wanted a script to parse your bank statements into a spreadsheet, you had two options: find a SaaS that does it (and pay $15/month), or spend an evening writing a parser. Today, you open Claude, paste a sample statement, and have a working parser in 10 minutes. Not a prototype. A working tool, tailored to your exact bank format.

That’s a trivial example, but the pattern scales. Every tool I built solves a real problem. The issue is that the user can now solve their exact version of that problem, with their exact constraints, faster than they can evaluate whether my generic version fits. If your tool survives longer than the problem it solves, you over-engineered it.

Software became so cheap to produce that paying a monthly subscription for a simple tool makes less and less sense. Andrej Karpathy called it “vibe coding”: you describe what you want, the AI builds it, and you move on. Why subscribe to a SaaS that sort-of does what you need when you can generate exactly what you need, tailored to your specific problem, in minutes?

I did the research. I went looking for new SaaS products built with Lovable, Base44, or Bolt that have meaningful revenue at scale. I found micro-wins (a few paying customers here, a handful of lifetime deals there), but nothing approaching a real SaaS business. Yet the platforms themselves are printing money: Lovable hit $300M ARR and a $6.6B valuation. Bolt.new reached $40M ARR in its first six months. The platforms that help you build disposable tools are thriving. The disposable tools themselves are not businesses.

From dev tools to agent-ready tools

But something else is happening that’s more interesting than “SaaS is dead.”

The value isn’t gone. It moved. It shifted from developer tools (things humans use directly) to agent-ready tools (things AI agents use on behalf of humans).

The difference is subtle but important. A developer tool has a UI, documentation, onboarding. An agent-ready tool has an API, clear inputs and outputs, and can be called programmatically. The user never touches it. They say “Claude, deploy this” or “Claude, use this style” and the agent figures out which tools to invoke.

MCP is one implementation of this, and it’s growing fast: 97 million monthly SDK downloads, 10,000+ public servers, and governance under the Linux Foundation with backing from Anthropic, OpenAI, Google, Microsoft, and AWS. Projects like OpenClaw are attempting to be distribution layers for agent tools, routing MCP-compatible skills to millions of users across WhatsApp, Telegram, and Slack. But the pattern is broader than any single protocol or runtime. Any tool that an AI agent can discover, understand, and call autonomously is an agent-ready tool. The value proposition changed: you’re not selling to a human who evaluates your landing page. You’re making your capability available to an agent that evaluates your interface programmatically.

The real opportunity: the environment

If disposable tools are the new normal, then the opportunity isn’t in building better tools. It’s in building the environment where disposable tools thrive.

Think about it. You generate a tool in Claude in 20 minutes. Great. Now what?

• Where do you run it? Your laptop? A server?
• How do you connect it to your other tools?
• How do you share it with your team?
• How do you preview what it does before trusting it?
• How do you keep costs down when you’re spinning up tools daily?

Hosting, integrations, previews, cost reduction. The infrastructure layer for disposable tools. Some companies are starting to build pieces of this. E2B raised $35M to build secure sandboxes for AI-generated code, using Firecracker microVMs that spin up in under 200ms. They’re used by 88% of Fortune 100 companies. Val Town lets you deploy small functions without worrying about infrastructure. But nobody has put the full picture together yet.

The analogy: containers didn’t win because Docker was a great tool. Containers won because Kubernetes, AWS ECS, and the entire ecosystem around them made it trivial to run containers at scale. The container itself is disposable. The orchestration layer is the business. Docker popularized containers but failed to capture the orchestration layer, had to sell its enterprise business, and nearly died. The value accrued to the platform, not the tool.

Disposable tools need their Kubernetes.

I don’t have the answer

I’m not going to wrap this up with a neat conclusion, because I don’t have one. I spent six months building tools that the world no longer needs in their polished, permanent form. That’s a hard thing to admit when you’ve poured real effort into them.

But here’s what I keep coming back to:

The cost of producing software is approaching zero. Google reported that 25% of its new code is now AI-generated. GitHub’s research showed developers complete tasks 55% faster with Copilot. That changes everything about how we think about tools, products, and what’s worth paying for. The SaaS model built on “we’ll maintain this tool so you don’t have to” loses its value when maintaining it yourself takes minutes, not months.

Something new is forming. Agent-ready tools, disposable by design, running on infrastructure that doesn’t exist yet. I don’t know exactly what it looks like. But I know that building another polished developer tool isn’t it.

Reusable tools are a tax on speed. My friend was right. The tool is not the end. It never was.