Why are more and more software applications being "used and discarded"?

For a long time, the status of software in enterprises has rarely been questioned.

Once a system is launched, it means long - term operation. Core systems such as ERP, CRM, MES, and PLM are often planned with a cycle of five or even ten years. The development and implementation costs are high, but as long as the usage time is long enough, such investment is considered reasonable.

Therefore, software is implicitly regarded as a long - term asset that needs to "amortize costs".

However, in the past two or three years, a phenomenon that is clearly inconsistent with this logic has been occurring frequently. More and more software is not designed to exist in the long term.

Some people build an application for a single event and discard it after use; business departments quickly develop a system to meet emergency needs and rewrite the whole system after the task is completed; AI - generated tool versions are frequently replaced rather than continuously maintained.

These practices seem less serious in the traditional software concept, but they are becoming the real choices of many enterprises.

These changes point to an accelerating but still underestimated trend: Software is moving from "durable goods" to "fast - moving consumer goods." It no longer implicitly exists in the long term but is quickly produced and consumed around specific tasks.

What drives this shift is the simultaneous change in software production costs, organizational methods, and business models.

01

Starting from the counter - intuitive phenomenon:

Why is software starting to be "used and discarded"

If we go back ten years, many practices that are now common would have been almost impossible.

The founder of a16z once shared a case: someone used a no - code tool to develop a dedicated App for a friend's birthday party to display information and allow QR code check - in, and deleted it after the party; a mother developed News for Dinner, which only serves one family and is used to filter news topics suitable for dinner discussions.

These applications are extremely small in scale and have extremely short lifecycles, but they do exist.

On the enterprise side, the same phenomenon is occurring in large numbers.

Business departments quickly build internal systems to deal with a promotional event, a peak season cycle, a temporary production line, or a regulatory inspection. After the task is completed, these systems are directly abandoned or completely reconstructed in the next cycle, rather than entering a long - term maintenance state.

If we follow the traditional software logic, this behavior does not seem "economical."

However, the premise has changed. No - code platforms, AI code generation, and pay - as - you - go cloud resources have simultaneously reduced the time and capital costs of software development. When the cost of developing a system drops from "hundreds of thousands of yuan and several months" to "a few hundred yuan and a few days," a large number of requirements that were not worth systematizing before have emerged.

This change can be understood by the "Jevons Paradox." When the resource utilization efficiency is significantly improved, the total consumption often increases instead of decreasing. AI makes code production extremely cheap, which will not reduce software development but will instead promote software to enter more scenarios that it could not cover before.

As a result, the number of software is rapidly expanding, while the lifecycle of individual software is continuously shortening, gradually showing the characteristics of fast - moving consumer goods.

02

Four structural changes happening simultaneously

The "consumerization of software" has been implemented at multiple levels, occurring simultaneously in production methods, organizational structures, development tools, and business models.

First, software is shifting from a system form to a task form.

In a multi - agent platform, software no longer exists as a long - running system but as the ability to complete a single task.

The practices of Ant Tbox and 360 Agent Factory show that after users input their goals, the platform will automatically break down tasks and schedule different agents to complete them collaboratively. The deliverables are often a report, a video, or an execution result, rather than an application that needs continuous maintenance.

The practice in the manufacturing industry is more convincing.

The agent system deployed by Midea in its washing machine factory covers multiple links such as quality inspection, production scheduling, and mixed - line production. Multiple agents can complete tasks that originally required human - hour - level processing with second - level response and then enter the next call after completion.

The software here is essentially a production factor that is repeatedly consumed, rather than a fixed asset.

Second, business departments are starting to lead system construction.

The popularization of low - code and no - code platforms is changing the software power structure within enterprises.

Research by both Gartner and IBM points out that around 2025, about 70% of new applications will be completed through low - code or no - code methods. Domestic platforms such as Jiandaoyun and Qingliu have supported millions of enterprise users.

In practice, these systems often emphasize "usable in stages" rather than "perfect in the long term." Retail enterprises use no - code platforms to quickly build inventory systems to cope with periodic fluctuations, and manufacturing enterprises configure temporary management tools for specific production lines. These systems are taken offline and reconstructed directly after the promotion or peak season ends. They are not regarded as long - term assets but are a natural exit after a one - time investment.

Third, AI development tools are changing the cost comparison between maintenance and rewriting.

In an AI - assisted development environment, more and more teams find that overall rewriting is often more cost - effective than continuous maintenance. After an Internet company introduced AI development tools, it compressed the original development cycle of about 90 days to 30 days, and multiple internal systems were completely replaced several times within a year. This is a rational choice after the change in the cost structure.

Fourth, pay - for - results is providing commercial rationality for short - lifecycle software.

Charging by function or seat is based on the premise of long - term use.

When software itself may only serve one stage, enterprises are more willing to pay for quantifiable business results. AI customer service is divided according to sales improvement, and industrial equipment is charged according to output. In essence, they are all paying for "completing a single task." This model naturally matches the existence mode of one - time software.

03

The four - fold impact on the To B software industry

When the form of software changes, the operating logic and value consensus that the industry has followed for many years begin to loosen as a whole. This change affects product judgment, R & D organization, business model, and customer relationship simultaneously, forming a systematic impact on the entire To B software industry.

First, the traditional criteria for judging "good products" are becoming invalid.

In the past, the quality of To B software was often evaluated in terms of whether the architecture was elegant, whether the system had long - term scalability, and whether the code was easy to maintain. This set of criteria was based on the premise that software needed to run in the long term and continuously add functions.

However, in many application scenarios that are task - oriented and have a limited lifecycle, the focus of evaluation is shifting. Enterprises are more concerned about whether the delivery speed is fast enough, whether the results can be quantitatively verified, and whether the cost of abandonment and reconstruction is low enough when requirements change or business strategies are adjusted.

Stability and a perfect architecture are no longer pre - conditions but are factors that are reconsidered only in some scenarios.

Second, the R & D model is shifting from system construction to capability manufacturing.

In the traditional model, the core task of the R & D team is to continuously evolve around a unified system, emphasizing code reuse, version compatibility, and long - term maintenance.

Under the trend of software consumerization, the focus of R & D work is gradually shifting forward to the design of components, templates, workflows, and agent collaboration rules. The code does not necessarily need to be accumulated in the long term, but the capabilities must be able to be quickly combined, quickly replicated, and repeatedly called in different tasks. R & D is more like building an efficient production line rather than guarding an ever - expanding system.

Third, the pricing logic of software is starting to undergo a structural change.

The annual subscription and account - based charging models are based on the premise of long - term software use and high customer lock - in. When software is frequently rewritten and used in stages, the rationality of this pricing method naturally declines.

More and more manufacturers are starting to try pay - for - results, pay - per - task, or pay - per - call models to make the cost more directly correspond to the business value. This change is weakening the traditional SaaS's high dependence on ARR and forcing manufacturers to rethink how to measure growth, renewal, and customer value.

Fourth, the customer relationship is shifting from long - term binding to project - based collaboration.

In the new software form, manufacturers play the role of efficient executors and capability providers in more scenarios, rather than long - term system partners. The cooperation relationship is centered around clear goals and ends at the end of the project.

This does not necessarily mean a decrease in customer stickiness, but it requires manufacturers to continuously win the next cooperation through efficiency, results, and professionalism, rather than relying on system migration costs to form de facto lock - in.

04

Boundaries and costs:

Which software should not be consumerized

It should be emphasized that consumerization is not a universal solution. It solves the problems of efficiency and coverage but is not the optimal solution for all software forms.

Software suitable for this model usually includes personal micro - needs, department - level temporary projects, exploratory verifications, and task - oriented scenarios with relatively clear processes and quickly verifiable results. In these fields, the value of software is more reflected in whether the task is completed in time rather than whether it exists in the long term.

The boundaries of unsuitability are also clear.

Core business systems, security and compliance systems, financial transactions, medical care, aerospace, and other high - reliability fields must still adhere to the long - term maintainable software logic. These systems are directly related to organizational operations, safety responsibilities, or life and property risks. Once they fail, the cost will be much higher than the development and maintenance costs.

In such scenarios, stability, interpretability, traceability, and the ability to cover extreme situations always take precedence over delivery speed and flexibility.

It should be noted that blindly promoting consumerization in fields without the necessary conditions may bring new hidden costs.

Frequent rewriting will accumulate technical debt, short - lifecycle systems may weaken the organization's understanding of key processes, and over - reliance on instant - generation tools may also leave untraceable risks in terms of compliance and security. These costs are not easily visible in the short term but will be exposed when the system scale expands.

Therefore, the future software industry is likely to show a clearer differentiation pattern: on one end are fast - moving consumer goods software that emphasizes speed, low cost, and result - orientation, used to support high - frequency and fast - changing business needs; on the other end are high - quality systems that emphasize quality, stability, and long - term value, used to carry the most core and irreplaceable capabilities of the organization.

What enterprises really need is not to choose between the two but to have the ability to distinguish and match different software forms.

05

Conclusion

The consumerization of software is not a strategic choice of manufacturers. It is an inevitable result of the improvement of production efficiency in the AI era. When the cost of code generation approaches zero, the number of software will inevitably explode, and the lifecycle will inevitably shorten.

This brings both risks and releases creativity.

The risks of digital garbage and technical debt are real, but it is also irreversible that more people can build tools and verify ideas at low cost.

What is truly important is not to simply praise or resist this trend but to build judgment to determine which software should be developed quickly and which must be developed slowly; which can be used and discarded, and which is worth long - term investment.

This hierarchical ability will determine the position of enterprises and software manufacturers in the new cycle.

This article is from the WeChat public account "Neuters" (ID: Neuters). Author: Alex. Editor: Yanzi. Republished by 36Kr with permission.