Any project involving public institutions that includes outsourced intellectual property—commonly speaking, code that is written by one party and then sold off—tends to be of notoriously poor quality, riddled with vulnerabilities and lacking essential features. After the vendor (Party B) completes the acceptance process and the client (Party A) finishes installation and sign-off, the vendor typically collects payment and immediately moves on to their next project. This low-quality software severely hinders enterprise scalability and user experience, potentially even impacting the overall health of the industry. From the perspective of the general public, the online service experience provided by non-internet companies is often very poor.

On the surface, this may be attributed to the relatively low skill level of the programmers building the software. However, if this has become a widespread phenomenon, the root cause must lie in the rules and incentives. The accountability for software quality becomes significantly diluted after multiple layers of contracting, leading developers to pay little attention to code quality. This is a direct result of the prevalent commercial procurement models. To address this issue, adopting a software subscription model is an excellent solution.

For the client (Party A), procuring software through a subscription model means paying based on time and usage rather than purchasing the full intellectual property rights to the source code. In other words, they are buying the right to use the software along with a service that guarantees its availability. Subscribed services typically offer better cost-effectiveness and higher software quality, and they also help improve the vendor’s (Party B) development processes. For service providers, it is well understood that poor, hard-to-maintain code creates massive technical debt during subsequent iterations, which can block business expansion. Service interruptions or performance degradation can easily lead to customer churn and project failure.

A real-world case: A university previously purchased a perpetual-licensed academic administration management system. Initially, they submitted their requirements to the developer. The developer allocated resources to build the software and delivered it to the university’s academic affairs office for installation and acceptance. Once acceptance was passed, the contract effectively terminated. The university settled the payment and began using the system. The vendor then moved on to their next project.

In this type of collaboration, the software often works stably and well in the initial phase. However, as business needs evolve and time passes, the application may crash, the environment may require upgrades, hacker groups may discover vulnerabilities, performance bottlenecks may emerge, large volumes of logs may accumulate requiring analysis, or migrations may be necessary… We can summarize these tasks as software maintenance and evolution. The vendor (Party B) is not responsible for this, and the client (Party A) lacks the expertise to handle it, often leaving the entire software in a state of complete neglect.

In such situations, the university’s academic affairs office is likely to have to purchase additional security assurance, technical consulting, and operations & maintenance services. Their staff must spend daily work hours organizing resources to maintain system health, including managing the environment, scaling performance, and implementing feature changes. Hard drives may fail, and new vulnerabilities emerge every day. The client may even discover that the initially accepted software contained significant amounts of shoddy work, with many features merely being empty shells implemented to meet contractual obligations. When they try to contact the vendor, they find the company no longer exists. They are left to go through great lengths to contact a few former programmers from that company and offer high fees to request their services.

The university recognized the problem and decided to change this collaboration model. They decided to subscribe to an academic administration system. They contacted another academic administration software provider, who proposed the following collaboration model: they would provide a SaaS service for an annual fee of 1 million RMB, granting the client usage rights and guaranteeing 99% system availability, while not providing any additional code or programs. The final contract was agreed upon; the academic affairs office paid 1 million RMB and signed a one-year contract.

After the contract was finalized, the service provider set up the service in their own data center, maintained by professional personnel. In the event of any failure, the university had no responsibilities or concerns; they simply waited for the service provider to fix the issue. The service provider had an in-house team and sufficient technical capability. Moreover, due to contractual requirements, they were obligated to ensure 99% availability. Therefore, they monitored performance daily, scaled resources appropriately, improved code, fixed vulnerabilities, and upgraded the system. To avoid breaching the contract, the system would never experience prolonged downtime.

The academic affairs office was completely freed from maintenance tasks and the daily anxiety of managing system stability; meanwhile, the software provider gained long-term revenue and produced high-quality code and services.

From a cost perspective, purchasing software requires the university to allocate at least one person’s effort for maintenance. In contrast, a subscribed service is maintained by a specialized team that can manage hundreds of online services with only 5–10 people. To reduce costs, such providers will certainly build advanced automated data centers, featuring sophisticated build processes, beta testing, canary releases, automated deployment, load balancing, and so on. The concept of DevOps becomes widespread, all to maintain scalability and availability while minimizing costs.

For the academic affairs office, this significantly reduces risk. Purchasing software for 5 million RMB with lifetime usage rights may appear cheaper than subscribing to a service at 1 million RMB per year, but in reality, they assume substantial risk: if serious defects are discovered in the software, they could face a loss of 5 million RMB. In contrast, with an annual subscription of 1 million RMB, they can simply switch to another service provider if needed.

In the scenario described above, the service provider is clearly aware of this as well. They will go to great lengths to maintain the system and provide the highest quality of service to ensure that the client continues to subscribe in the following year. From either party’s perspective, this is a healthier collaboration model.

Pricing can also be more flexible in practice. For example, the management system could be priced at 1 RMB per user per day. This keeps the client’s initial trial cost very low. They can first roll it out internally at a rate of 10 RMB per day, and once they deem the system sufficiently excellent, they can expand its usage across the entire organization. The additional amount they pay can then be used by the provider to fund system expansion. This model also helps the provider expand their market, as sales personnel only need to convince decision-makers to pay 10 RMB for a few days of trial use, rather than several million RMB upfront.

For Party B, it is essential to rely on precise pricing to ensure a guaranteed profit, regardless of the procurement model chosen by the other party. As long as the return on investment exceeds costs, the enterprise remains financially healthy.

For example, in the past, Microsoft sold Office under a perpetual license model at a price of over 900 yuan per copy, allowing users to use it for life. However, market practice showed that most users were unwilling to accept this pricing. Instead, they preferred pirated versions, which often came with bugs, viruses, security vulnerabilities, advertisements, and a lack of updates. Microsoft recognized this issue and shifted to a subscription-based model for Office 365. The average daily cost is less than one yuan, with a free trial available for the first month. This pricing is entirely acceptable to ordinary users. Moreover, if users encounter any issues, they can immediately submit a support ticket to receive excellent, professional technical assistance, ensuring high software availability.

Although this model offers significant advantages from both macro and micro perspectives, with greater efficiency and benefits, it still presents serious challenges. Since subscription-based software is not fully autonomous or controllable, and data is often not stored locally, there are also concerns regarding financial asset declaration. As a result, many enterprises are reluctant to procure SaaS software. For Party B, this model can significantly extend project timelines and increase maintenance debt. Nevertheless, this approach will become the mainstream and the future of the software customization industry. It has not yet been widely adopted in many sectors domestically, but this is merely a matter of corporate awareness and understanding. In Beijing and Shanghai, a large number of software development companies have already begun transitioning to service-oriented models and have achieved highly successful results. As a programmer, I believe this shift will significantly improve IT service quality across all industries.