Disposable by default: when software costs almost nothing to change

Summary

For fifty years the advice to small businesses was the same: buy software, don't build it, because whatever you build you have to maintain. That advice was right when maintenance was most of the cost. We argue it is becoming wrong for most of the tools a small business needs. When an AI system can change, rebuild or replace a tool in an afternoon, a custom tool is closer to a paper cup than a building: you use it, you change it when your needs change, and you throw it away when it stops being useful. What does not get cheaper is knowing exactly what you want. That is where the rigor goes now: into the problem definition, the user stories and the tests, written before the first line of code.

The old math

The case against custom software was always a case about maintenance. In the best-known early study of the subject, Lientz and Swanson surveyed 487 data processing organizations and found that staff spent about half their time maintaining existing systems, not building new ones [1]. Most of that maintenance was not fixing bugs. It was adapting software to new needs: enhancements requested by users, changes to data and file formats, changes to the systems around it.

For a business with ten or twenty people and no engineers, that math made custom software a trap. You paid once to build the tool and then paid forever to keep it fitting a business that kept changing. An off-the-shelf product that fit 70% of your needs was the safer choice, because someone else carried the upkeep.

The new math

The cost of making a change is falling fast. METR, which measures what AI systems can do on real software tasks, found that the length of task frontier models can complete on their own has been doubling roughly every seven months, and stood at about an hour of skilled human work in early 2025 [2]. Most changes a small business asks of its tools are well inside that window: a new field on a form, a new report, a different approval step, a new integration.

When a change costs minutes instead of weeks, the old reasons for caution change too. Maintainability indexes, long-term architecture reviews and five-year total cost of ownership models were tools for rationing expensive changes. If changes are cheap, you don't ration them. You make the change. And when a tool stops being useful, you retire it, keep the data if you want it, and move on.

When changing software costs almost nothing, stop owning it and start specifying it.

What you still own

Disposable does not mean free of consequences. Four things around the code do not get cheaper at the same rate, and they are where a disposable tool can quietly become a permanent one.

• Data that has to outlive the tool. Customer records, invoices and decisions are the asset. The tool is the cup; the data is the coffee you still need tomorrow.
• Other systems that depend on it. Once your bookkeeping, your calendar or a partner reads from a tool, changing it is no longer a private decision.
• Security. A tool that touches customer data or money carries the same obligations however quickly it was built.
• People. Every change to a tool your team uses daily costs them a little relearning.

That gives a simple test for which tools can be treated as disposable: the tool doesn't hold the only copy of important data, nothing else depends on it, and it doesn't touch sensitive data. Most internal tools in a small business pass. The ones that don't need a different kind of care, which we cover in a companion paper on mission-critical software.

Rigor moves upstream

If writing the code is cheap, the expensive part is deciding what the code should do. Natural language is ambiguous, and the gaps are where businesses lose money: the refund rule nobody wrote down, the customer who is both a vendor and a client, the approval that only applies above a certain amount. A system that writes code fluently will fill those gaps with confident guesses unless something stops it.

Software engineering already has the tools for this, refined over decades. Domain-driven design asks you to agree on the words for the business before writing anything. User stories describe what each person needs to get done. Test-driven development turns each story into a test that fails until the software does what was asked. None of these is new. What is new is that they used to be overhead on top of the expensive part, and now they are the expensive part.

Test-driven development matters most of all for AI-written code. In a controlled comparison, Mathews and Nagappan gave models the tests along with the problem description and measured how many problems they solved. Including the tests raised the share of problems solved by between 9 and 30 percentage points across models and benchmarks [3]. Kent Beck, who popularized test-driven development, describes the same discipline as the difference between directing an AI to write tested code and accepting whatever it produces, and he names the failure to watch for: an agent that disables a test or adds features nobody asked for [4].

"The tests only check what the AI understood"

The strongest objection to this approach is that if the same AI writes the code and the tests, the tests prove only that the code matches the AI's understanding, not yours. That is true, and it is the reason for the order of operations. The tests come from the user stories, before any code exists, and the person who owns the outcome reads and approves them. The AI then writes code to pass tests it did not write and cannot change without asking. An adversarial review, by a second model or a person whose only job is to find what the tests miss, closes the remaining gap.

Done this way, the tests encode what you meant. They may not cover everything your domain contains, but they cover everything you want from this tool, which is the only standard a disposable tool has to meet.

How Supersafe Forge works this way

1. 01Define the problem first. Forge asks the questions an engineer would and writes down the terms, the people involved and what success looks like.
2. 02Turn each user story into acceptance tests, and have the owner approve them before any code is written.
3. 03Build to the tests. The tests are fixed; changing one needs the owner's approval.
4. 04Review adversarially: a separate review looks for the cases the tests miss, and new tests are added for anything it finds.
5. 05Keep the data portable, so a tool can be retired or replaced without losing what it held.

When a project fails the disposable test, because it holds sensitive data, moves money or other systems depend on it, Forge hands it to our engineers, and the human gates described in our companion paper apply.

Starting this week

1. 01List the spreadsheets and manual steps your team repeats every week. Each is a candidate for a disposable tool.
2. 02For one of them, write three user stories in plain language: who does what, and how you'll know it worked.
3. 03For each story, write one example with real numbers: the input, and the exact output you expect.
4. 04Check it against the disposable test: no only copy of important data, no system depending on it, no sensitive data. If it passes, build it and plan to throw it away.

Where we might be wrong

• Cheap changes are not the same as fast work. In a randomized trial, experienced open-source developers using early-2025 AI tools took 19% longer on tasks in their own codebases, while believing they had been 20% faster [5]. Familiar, complex codebases may behave differently from small new tools.
• Benchmark gains from tests come from function-sized problems. Whole systems with many moving parts may see smaller gains.
• Cheap change can become cheap churn. GitClear's analysis of 211 million changed lines found duplicated code blocks rising sharply and refactoring falling as AI assistants spread [6]. Disposable tools still need someone to say no.

What we're measuring

• Time from a written user story to a tool in use, for Forge projects.
• How often an approved acceptance test turns out to be wrong or missing once the tool is in use.
• How many tools are retired or replaced each quarter, and whether their data moved cleanly.