A temporary app starts as a convenient way to compare supplier quotes. A second department begins using it. Then an export from the app becomes the input to a weekly purchasing meeting. Six months later, a change breaks the export and several people cannot do their work.
The application did not become business-critical because its code grew sophisticated. It became critical because a business process came to depend on it. That can happen to a spreadsheet, an AI-built utility, or a conventional internal application.
Watch for changes in consequence, not just usage
User counts are an incomplete signal. A tool used by three people can determine payments or production schedules. A tool used by hundreds may only display information already available elsewhere.
More useful questions are: what stops if the tool fails, what decision relies on its output, and what happens if its output is wrong? Ask whether it has become the only place where a record is stored. Check whether people have stopped maintaining the original fallback.
New data and permissions can change the answer quickly. A read-only comparison tool that gains the ability to update an ERP record has crossed an important boundary. So has a planning app that starts storing confidential employee information. Neither change should be treated as a routine interface enhancement.
Stabilize the situation before adding features
Start by naming an owner and describing the application’s actual use. List its users, data stores, integrations, credentials, paid resources, and outputs. Include any manual steps on which its apparent reliability depends.
If the tool now has consequential write access that nobody has reviewed, restrict or suspend that path while the team assesses it. Preserve the records and evidence needed to understand what happened. Do not delete the system reflexively if people depend on its data or retention obligations apply.
Pause new features until the critical workflow is understood. Expanding an application during an assessment can move the target faster than the team can evaluate it. Agree on temporary limits and a fallback that users can actually follow.
Choose between hardening, replacing, and retiring
Harden it when the application fits the continuing requirement and its implementation can support appropriate controls. That may mean adding independent tests, correcting authorization, documenting operations, improving recovery, and assigning maintenance responsibility.
Replace it when the use case now belongs in an existing enterprise system, when an established product fits better, or when the implementation cannot meet mandatory requirements economically. Replacement can preserve a useful workflow without preserving the original code.
Retire it when the original task is finished or the application no longer offers enough value to justify its obligations. Retirement requires a transition for users and records, not merely switching off a server.
Avoid making the choice based on the tool’s origin. AI-generated code is not automatically disposable, and traditionally written code is not automatically maintainable. Evaluate observable behavior, architectural fit, operating cost, and the people available to own it.
Define what continued operation requires
For an application that will remain in use, document who grants access, reviews changes, responds to incidents, and handles requests involving data. Establish a deployment path that does not depend on somebody’s personal account or an unrecorded conversation with a builder.
Check backups by restoring them into a separate environment. Check permission boundaries with denied actions as well as normal requests. Check integrations when the remote service is unavailable. The evidence should match the consequences of failure, not the application’s original “temporary” label.
Decide how changes are approved. A prompt that adds a new report can also change data access, dependencies, or schema. Review the complete change and keep the critical acceptance tests in the normal delivery process.
Operational responsibility also includes mundane costs: renewing credentials, reviewing unused accounts, updating libraries, and responding when a vendor changes an interface. If nobody has capacity for those activities, continued operation is not yet a complete plan.
Make the transition reversible where possible
Before replacing the app, reconcile its data with the destination and decide how users will confirm that the transition worked. A parallel period may help, provided the team knows which system is authoritative and avoids conflicting updates.
Keep an appropriate record of assumptions and decisions. For a planning model, that might include inputs and formulas. For an approval workflow, it might include authorization and business history. Exporting a flat file does not necessarily preserve the meaning of the records.
When retirement is complete, revoke access and credentials, stop unnecessary resources, and handle databases, files, logs, and backups according to the retention policy. Confirm that no scheduled integration still depends on the application.
Disposable software is useful precisely because not every business task needs a permanent product. The discipline is to notice when that premise changes. A small review at the moment people begin depending on a tool is usually more useful than debating whether the tool should have been built in the first place.
Related reading
- Disposable Software: When a Business App Should Work Like an Excel Model
- AI Changes the Developer’s Job—But Reviewing the Code Is Not Enough
- Vibe coding: platforms, B2B risks, and delivery choices
Put the right guardrails in place
SaM Solutions can assess your project, review its architecture, and help decide where AI-assisted development fits.