Disposable Software

Build exactly what you need. Use it. Throw it away.

← All posts

The old way

You have a problem. You need a tool. So you go shopping.

You evaluate six products. You sign up for three trials. You watch demo videos. You configure settings. You map your workflow onto someone else's UI. You learn where they hid the feature you need behind two menus and a gear icon. You set configuration settings. You write integration code. You read documentation for an interface between programs (API) that changed since the docs were written.

Two weeks later, you have a tool that does forty things. You need it to do one thing. The other thirty-nine are in your way — tabs you'll never click, notifications you'll never read, preferences you'll never set. You pay monthly for all of them.

Or you build it yourself. You pick a framework. You set up the starting files for a project. You write algorithms. You handle edge cases (unusual situations the normal path doesn't cover). You build a UI. You debug the UI. You deploy it somewhere. You maintain it. You update dependencies (other software your tool relies on). Six months later the underlying tool releases an update that makes your program stop working.

Both paths have the same problem: the tool outlives the need. You built or bought something permanent to solve something temporary.

The new way

You describe what you need in English. In a markdown file. Claude reads it and becomes the tool.

Not a tool that gets installed. Not a tool with a UI. Not a tool with dependencies or a deployment pipeline or a monthly bill. A tool that exists for exactly as long as you need it, does exactly what you described, and disappears when you're done.

The "software" is a text file that says what to do. The runtime is Claude. When you need a new feature, you write a sentence. When you're finished with the whole thing, you close the conversation. The tool is gone. The output — the thing you actually cared about — remains.

The book is the example

The memoir I am bill? required a production system:

• 55 markdown files assembled in non-chronological reading order
• Three act breaks inserted at specific positions
• A map of which jokes depend on earlier setups — 183 cross-references tracked
• Five output formats: HTML, PDF, print-ready PDF, EPUB, DOCX
• Front matter with a half-title, title page, copyright, and dedication
• Print layout with 6×9 trim, gutter margins (extra space near the spine so text doesn't disappear into the binding), alternating page numbers
• A distribution system with temporary download links (presigned URLs) and identity tracking

If you went looking for software that does this, you wouldn't find it. This combination of requirements doesn't exist as a product. You'd end up stitching together Scrivener, InDesign, Pandoc (a document-conversion tool), a mail merge tool, and a custom script for the dependency graph. You'd spend weeks learning each one. You'd fight their UIs. You'd work around their assumptions about how a book should be structured.

Instead: markdown files and Claude. The "assembly system" is a Python script that Claude wrote in one session. The "distribution system" is 200 lines of Python. The "dependency tracker" is Claude reading the files and telling you what breaks when you move a scene. The "print layout engine" is page-layout instructions written in the same language that styles web pages.

Total setup time for the entire production pipeline: hours, not weeks. Total UI to learn: none. Total ongoing maintenance: none.

And here's the part that matters: Bill may never need this system again. He wrote one memoir. He might never write another. If he'd spent months learning InDesign, that knowledge would be dead weight. Instead, he described what he needed, Claude built it, the book exists, and the tool can be thrown away. The book is the artifact. The production system was disposable.

How it works in practice

Why this changes things

Traditional software has a fixed feature set. You adapt your workflow to the tool. You learn to think in the tool's categories. "Scrivener thinks about writing this way, so I have to think about writing this way." The tool imposes structure.

Disposable software has no feature set. It has your features and nothing else. There's no menu with forty options you don't use. There's no concept that doesn't map to your problem. The tool adapts to your workflow because the tool is your workflow, described in your words.

The tradeoff is that disposable software has no community, no support forum, no Stack Overflow answers. But it doesn't need them — because when something goes wrong, you describe the problem to the same system that built the tool, and it fixes it. The support channel and the development team are the same entity.

When to use this pattern

What you can steal from this

1. Start with markdown, not a product evaluation. Describe what you need in a text file. See how far that gets you before you open a browser to shop for tools.
2. Features are sentences. "Add a table of contents." "Email the report to these three people." "Flag anything over $100." Each sentence is a feature request with zero overhead.
3. The output is the artifact, not the tool. The PDF, the website, the dataset, the report — these are what matter. The scripts that produced them are disposable. Build accordingly.
4. Don't learn tools you'll use once. If you need InDesign for one book, you don't need InDesign. You need a book. There's a difference.
5. Disposable doesn't mean careless. Back up your outputs. Version your source files. The tool is disposable. The work is not. See the safety page.

← All posts