From 71% External SaaS to 72% Self-Built Apps: How AI Coding Is Reshaping Software Consumption

The Flip of a Single Number

A developer shared on social media how his browser-based software usage time had changed: last August, 71% of his browser software screen time went to external SaaS products; in the most recent week, that proportion became 72%—only in the completely opposite direction, with 72% of his time spent on applications he had built himself.

This data comes from a personal perspective and an extremely small sample, yet it acts like a probe striking at a structural change now underway: when AI coding tools become powerful enough, the boundary between software producers and consumers begins to melt.

Why the Barrier to Self-Built Apps Suddenly Disappeared

Traditionally, building internal tools yourself has been a luxury. Behind a single CRUD application lies a whole burden of scaffolding setup, dependency management, database design, and deployment and operations. Small teams often choose to subscribe to SaaS directly to avoid these costs.

What AI coding tools change is the distance "from idea to runnable code." Describing requirements in natural language is enough to generate usable interfaces and logic, and debugging and modification become conversational. A prototype that once took days to build may take shape within a single round of conversational iteration. This directly lowers the startup cost of "building a tool that is just good enough for yourself."

It should be noted that this is an individual observation from one developer, not industry statistics. But it aligns with a trend being repeatedly discussed in the AI coding field: as the barrier to coding falls, more people begin to treat software as a daily item they can build with their own hands.

CRUD is an acronym for Create, Read, Update, and Delete—the four basic operations around data records. Internal enterprise tools such as customer management, task tracking, and inventory registration are overwhelmingly CRUD applications in essence. The technical difficulty of such applications lies not in the business logic itself but in the accompanying engineering burden: database table structure design, API endpoint writing, front-end form and list page rendering, permission control, and deployment and monitoring. The reason AI coding tools have the greatest impact on CRUD scenarios is precisely that these steps are highly patterned. After describing fields and operations in natural language, the model can generate front-end and back-end code plus table creation statements in one go, compressing days of setup into a single round of conversational iteration. Understanding this layer of meaning in CRUD makes it clear why "building a tool that is just good enough" first becomes reality in internal management applications.

SaaS's "Generality Tax" Is Being Recalculated

The pricing logic of external SaaS is built on economies of scale: vendors sell one set of general features to many customers, spreading R&D and operations costs. But when the cost of self-building drops sharply, this calculation deserves to be redone.

The hidden costs of SaaS have always existed—paying for complex features you do not use, difficulty migrating data out, integration friction, and workflows forced to accommodate product design. When building a lightweight tool that fits your own processes becomes feasible, the weight of these frictions is amplified.

But this does not mean SaaS will be replaced. In areas requiring extremely high reliability and compliance investment, such as identity authentication, payments, and collaboration, the advantages of specialized vendors remain solid. A more likely picture is stratification: general, highly complex capabilities continue to be provided by SaaS, while long-tail, highly personalized internal tool needs shift toward self-building.

SaaS (Software as a Service) refers to vendors delivering software via the cloud on a subscription basis, so users do not need to install and maintain servers themselves and pay by account or usage. The core of its business model is economies of scale: the same product is sold to a large number of customers, R&D and operations costs are spread thin, and the fee paid by each customer is therefore lower than self-building. But this model also embeds a "generality tax"—the product must cover as many customer scenarios as possible, leading to increasingly bloated features, with individual users paying for a large number of capabilities they do not use, and workflows having to accommodate the product's general design. When AI coding pushes the cost of self-building low enough, this premium paid for generality becomes conspicuous, and users begin to use "building a lightweight tool that fits their own processes" as an alternative option for repricing.

The Real Boundaries of AI Coding Tools

Amid the enthusiasm, calm is needed: AI coding excels at rapidly producing runnable prototypes, but production-grade applications still require security auditing, error handling, and maintainability design. These are precisely the areas where AI tends to leave blind spots.

Another hidden bill for self-built applications is maintenance. When subscribing to SaaS, maintenance costs are packaged into the price; after self-building, dependency upgrades, troubleshooting, and security patches all fall on your own shoulders. As the number of self-built applications grows, this "shadow operations cost" will gradually emerge.

Therefore, a more rational judgment is not that "SaaS is dead," but that the decision matrix for software consumption has gained a competitive option. For scenarios with unique processes, high usage frequency, and general products that are hard to fit, self-building becomes worthwhile; for capabilities that are highly standardized, strongly compliance-driven, and require continuous evolution, subscription remains the better solution.

Shadow operations cost refers to the ongoing investment that only gradually emerges after self-built software is developed, including dependency library upgrades, security patch follow-up, troubleshooting, data backup and migration, and feature adjustments made as the business changes. When subscribing to SaaS, this work is undertaken by the vendor and packaged into the subscription fee, so users do not perceive it; once switched to self-building, it all falls on the builder. The operations burden of a single small tool may be slight, but when the number of self-built applications grows and they are scattered across different technology stacks, the fragmentation of maintenance can significantly erode the costs initially saved. This is also an item easily underestimated when judging "whether self-building is worthwhile": the decision cannot compare only development cost and subscription fee, but must also include the shadow operations cost over the application lifecycle in the total account.

What It Means for Developers and Product Teams

For individual developers, this is an amplification of capability leverage: those who can identify needs, describe problems clearly, and judge the quality of generated code can independently deliver things that once required team collaboration.

For SaaS vendors, this creates gentle but real pressure. When users have the ability to self-build, a product's value must land more clearly on "irreplaceable complexity"—data network effects, compliance qualifications, deep integration, and continuous operations—rather than merely providing a usable interface.

For technical teams, it is worth re-examining the list of internal tools: which processes are making compromises for general software, and which high-frequency small pain points are suitable for quickly filling with AI coding. Starting with one small tool may be the lowest-cost way to validate.

Final Thoughts

The proportional flip in one individual's screen time is not enough to prove any macro conclusion. But the sense of direction it captures is worth recording: AI coding is turning "building software" from an exclusive capability of professional teams into a daily skill that more people can call upon. The structure of software consumption may be slowly sliding from "subscribe to everything" toward "self-build part of it on demand."