Systems that fail to become platforms will die

TL;DR

The current debate about the future of Software as a Service is framed too narrowly. The important question is not whether software will continue to be hosted in the cloud, delivered through a browser or sold through recurring agreements. Those models are likely to remain. The more consequential question is whether the fixed application will continue to be the primary unit of software.

The software market has been organized around applications for decades. A vendor builds a CRM system, a project management system or an HR system, then distributes the same product to thousands of customers. Customers configure the application, connect it to other products and adapt their processes to the boundaries imposed by the software.

That model was economically rational when software was expensive to produce. It was far cheaper to purchase a standardized application than to build a system around the exact requirements of one organization.

AI changes that calculation.

As the cost of translating requirements into working software falls, organizations no longer need to choose as often between standardized SaaS and expensive custom development. A new category of platform can combine the economic advantages of reusable software with the adaptability of a tailored system.

Under this model, AI does not primarily act as an unconstrained programmer. It acts as an assembler. The platform provides proven components, architecture, infrastructure and operating rules, while AI interprets requirements and combines those capabilities into a system that fits the organization.

The application does not disappear. It remains the interface through which people perform their work. What changes is its role. Instead of being the enduring technical product, the application becomes the current configuration produced by the platform.

This shift will begin with administrative software because much of it is built from recurring technical patterns. Customer management, project delivery, recruitment, invoicing and internal operations use different terminology, but they rely on similar combinations of data, permissions, workflows, notifications and reporting.

More specialized software will move later. The transition will be gradual, and it will not eliminate SaaS companies, software developers or consultancies. It will change what they build, how they create value and where they compete.

The next software market will not simply offer better applications.

It will offer better ways to produce them.

The application has defined the software market

The modern software market is organized around the application. Vendors define a category, build a product around it and sell access to that product. Customers then choose between competing applications based on features, price, usability and reputation.

This structure is so familiar that it appears permanent. CRM is treated as a type of application. Project management is another. Recruitment, invoicing, support and analytics each occupy their own categories, with vendors competing to build the strongest product within each one.

The application is therefore more than a technical artifact. It determines the product boundary, the commercial model, the sales organization and often the identity of the company that created it.

That model has produced an enormous amount of useful software. It has also encouraged the market to treat every business problem as a separate application category, even when the underlying processes are closely connected.

A company does not experience its work as a collection of software categories. It experiences a continuous operation in which leads become customers, customers become projects, projects create invoices and completed work creates support obligations.

The application market divides that operation into products.

The organization then carries the burden of putting it back together.

Why SaaS was the right model

Best-of-breed SaaS emerged because software was costly to build, maintain and operate. A custom system required developers, project management, infrastructure and an ongoing commitment to upgrades and support. For most organizations, that level of investment was difficult to justify for routine administrative functions.

A specialized vendor could solve the same problem once and distribute the result to thousands of customers. The development cost was shared, the product improved over time, and each customer gained access to capabilities that would have been expensive to create internally.

The customer accepted a degree of compromise in exchange for those economics. The terminology might not perfectly match the organization. The workflow might contain unnecessary steps. Important processes might require workarounds or external integrations.

Even so, buying the application remained far cheaper than building an equivalent system from scratch.

This allowed specialization to flourish. A vendor focused entirely on one category could develop deeper functionality than most internal teams could justify. That focus improved product quality and created strong commercial markets around increasingly narrow business functions.

SaaS was not a mistake that AI now needs to correct. It was the optimal response to the production economics of its time.

The market changes when those economics change.

The cost of a fragmented software environment

Individual SaaS products can be excellent while the combined software environment remains inefficient.

A company may use one application to generate leads, another to manage customer relationships, another to deliver projects and another to issue invoices. Each product may be highly capable within its category, but the organization's actual process crosses all of them.

Every application introduces its own concepts, data model, permissions and operating assumptions. The same business entity may be represented differently in several systems, while employees must understand which product owns which part of the process.

Integrations reduce some of the friction, but they rarely create true coherence. An API can transfer a customer record from one application to another, yet the two products still maintain separate interpretations of that customer. Changes must be synchronized, failures must be handled and conflicting states must be resolved.

As more applications are added, the cost does not grow only through additional subscriptions. It also appears through implementation, administration, training, reconciliation and manual coordination.

Employees learn where information belongs. Managers learn which reports can be trusted. Administrators learn which integrations fail silently. The organization gradually develops a layer of operational knowledge dedicated to compensating for the boundaries between its software products.

This is the fragmentation tax created by best-of-breed software.

The problem is not that each application performs poorly. The problem is that every application optimizes itself while the organization needs the entire system to be optimized.

AI changes software production

Most AI features in software currently focus on interaction. They summarize information, generate text, answer questions or automate individual actions inside an existing application.

Those features are useful, but they do not change the fundamental structure of the market. A CRM system with an AI assistant remains a CRM system. The application still defines the product boundary, and the customer still adapts to that boundary.

The more significant change occurs when AI is applied to software production itself.

AI can increasingly translate natural-language requirements into interfaces, workflows, data structures and executable logic. The results are still imperfect, particularly as systems become larger, but the direction is clear: less manual effort is required to move from an expressed need to a working implementation.

This reduces one of the main advantages of standardized applications. If adapting software to an organization becomes inexpensive, the customer no longer needs to accept as much mismatch between the application and the business.

The relevant comparison is not between SaaS and fully custom software as they exist today. It is between a collection of fixed applications and a tailored system assembled from a reusable platform.

Once the second option becomes faster and less expensive than licensing and integrating several products, the center of the market begins to move.

AI is a better assembler than an inventor

Imagine a car mechanic replacing a worn component. The replacement part already exists, its connection points are known and it was designed to work within the vehicle. The mechanic still needs judgment and skill, but much of the surrounding engineering has already been solved.

Now imagine asking the same mechanic to design and manufacture an entirely new engine. The task requires thousands of interconnected decisions involving materials, geometry, cooling, lubrication, manufacturing and safety. A mistake in one area can create failures somewhere else.

The difference is not merely that one task is larger. One task is constrained by a proven system, while the other requires the system itself to be invented.

Software follows the same pattern.

When AI creates software from scratch, it must make decisions about architecture, data models, permissions, validation, deployment, testing, security and maintenance. Those decisions are not independent. A reasonable choice in one part of the system may create complexity or inconsistency in another.

As the system grows, the number of interactions grows with it. The AI must remember earlier assumptions, understand the effects of new requirements and preserve coherence across changes made over time.

A platform narrows that problem. It supplies a known architecture, compatible components, established deployment procedures and predictable operating rules. The AI can focus on selecting, connecting and adapting existing capabilities rather than inventing every technical layer.

The result is not simply faster development. It is a more controlled production process.

AI becomes the assembler of the system rather than the sole author of its code.

What makes a system-generating platform

The word platform is already used by almost every large software vendor, so it requires a more specific meaning in this context.

An application becomes extensible when it supports plugins, integrations or configurable workflows. Those capabilities can make the product more flexible, but they do not necessarily change its fundamental nature. The application still remains the predefined object around which everything else is organized.

A system-generating platform begins from a different premise. Its primary purpose is not to deliver one predefined application. Its purpose is to produce and evolve multiple systems from a shared technical foundation.

That foundation includes the capabilities required across the full lifecycle of the system. It manages data, identity, permissions, interfaces, workflows, deployment, monitoring and change. These are not optional services attached after generation. They are part of the environment in which generation occurs.

The platform also contains reusable components that are designed around common conventions. They share technical assumptions, can be combined predictably and can be improved without requiring every system to be rebuilt independently.

AI operates inside those boundaries. It interprets requirements, selects suitable components and adapts their configuration to the organization. Where specialized behavior is needed, the platform may generate extensions, but those extensions remain connected to the same architecture and lifecycle.

The platform proves its value by producing useful systems repeatedly. It is not merely a toolkit handed to developers. It is the production environment through which requirements become operational software.

The application becomes a configuration

Consider a company that needs customer management, project delivery and invoicing.

Under the current model, the company typically selects three applications. It configures each one, creates integrations between them and adapts its internal processes to the boundaries of the products.

A platform-based model starts with the process rather than the categories. The company describes how a lead becomes a customer, how a completed sale creates a project and how delivered work becomes an invoice. The platform then assembles the records, interfaces, workflows and permissions required to support that process.

Employees still use an application. They see dashboards, forms, reports and task views designed for their work.

The difference is that the application was not developed as an independent product and later adjusted to fit the company. It was generated as one expression of the underlying platform.

If the company later introduces booking, support or contract management, the system can evolve without adding another isolated product. The platform extends the existing data, processes and interfaces while preserving the relationships between them.

The application therefore becomes a configuration of the platform rather than the final product of the software company.

This does not make the application disposable in the sense that its data and history are unimportant. The organization still accumulates users, permissions, workflows, records and operational knowledge. Those assets remain durable.

What becomes replaceable is the fixed application boundary.

Better AI strengthens the platform model

A common argument against platforms is that future AI may become capable enough to create any software directly. If unrestricted generation becomes effortless and reliable, why would a constrained platform still be necessary?

The argument assumes that AI improves while platforms remain unchanged.

In practice, every improvement in AI capability also improves what the platform can do. A stronger model can interpret more complex requirements, select components more accurately and create more sophisticated adaptations within the same controlled environment.

The comparison therefore remains between two approaches using the same level of intelligence. One generates a system with few constraints, while the other works from proven architecture, compatible components and an established production process.

The constrained approach retains an advantage because the problem remains smaller.

This pattern already exists throughout software development. Better programming languages did not remove the need for libraries. More capable developers did not remove the value of frameworks. Improved cloud infrastructure did not make operating systems irrelevant.

Greater capability usually allows the industry to build more ambitious systems. It does not create a reason to discard useful abstractions.

As software production becomes cheaper, demand for software is also likely to grow. Organizations will request more specialized processes, more frequent changes and closer alignment with their own operations. Efficiency will not simply reduce the amount of software being created. It will make previously uneconomical software practical.

Platforms allow that increased ambition to be directed toward business-specific requirements rather than repeatedly recreating common technical foundations.

From best-of-breed to best-fit

The current software market rewards best-of-breed products. Buyers compare CRM systems with other CRM systems, project management systems with other project management systems and HR systems with other HR systems.

This assumes that the quality of each individual application determines the quality of the overall software environment.

In practice, the strongest individual products do not always create the strongest combined system. A sophisticated CRM application may still be a poor fit if its data model conflicts with the rest of the organization, its workflow cannot be adapted or its integrations create significant manual work.

A less elaborate CRM capability may produce a better operational result when it is part of one coherent system that connects customer management, delivery and invoicing without artificial boundaries.

The platform model therefore moves competition from best-of-breed toward best-fit.

This does not eliminate specialized software. Some products contain deep domain knowledge, proprietary data or technically difficult capabilities that a general platform cannot easily reproduce. Those capabilities may remain independent, or they may eventually become services and components consumed by broader platforms.

The transition does not require every specialized application to disappear. It only requires enough administrative functionality to move into shared platforms for the economic center of the market to change.

Why administrative software moves first

Administrative applications cover many different departments, but their underlying technical structures are often similar.

A CRM system stores entities and relationships, assigns responsibility and moves records through a process. A recruitment system performs similar operations with candidates and positions. Project management, support and procurement systems also rely on ownership, status, deadlines, permissions, notifications and reporting.

The business meaning differs, but much of the technical machinery is reusable.

This makes administrative software particularly suitable for platform generation. Common structures can be standardized while terminology, rules and workflows remain adaptable to the organization.

The platform does not need to know every business in advance. It needs a sufficiently general set of components and a reliable method for configuring them around different requirements.

Highly specialized engineering, scientific and creative software will move more slowly because its complexity often lies deeper in the technical domain. A CAD system, an industrial simulation environment or a professional media tool may depend on advanced algorithms, specialized hardware and decades of domain-specific engineering.

Those systems are not permanently excluded from the shift. They simply offer a less practical starting point.

Administrative software will move first because its recurring patterns are easier to generalize and its current fragmentation costs are already substantial.

Platforms improve through use

An application improves its own product. A platform can improve the production of every system built on it.

A component created for one implementation may later become reusable across many others. A workflow that originally required custom work may become configurable. An ambiguous requirement encountered in one project may lead to better interpretation and validation in future projects.

Testing, deployment and security improvements can also flow through the shared foundation. The next generated system begins from a stronger technical base than the previous one.

This compounding effect is one of the most important differences between applications and platforms.

It is not automatic. A poorly designed platform can become a collection of customer-specific exceptions and accumulated code. At that point, it loses the advantages of standardization and becomes another difficult software estate.

Successful platforms must continuously separate what is general from what is specific. Common capabilities belong in the shared foundation, while organization-specific behavior belongs in configuration or controlled extensions.

When that boundary is managed well, every implementation expands the platform without forcing every customer into the same process.

The platform becomes more capable while the resulting systems remain different.

Software becomes self-renewing

Traditional applications evolve through changes to one product codebase. Over time, they accumulate features, compatibility requirements and historical decisions. Large architectural changes become difficult because the vendor must preserve behavior expected by existing customers.

A platform creates the possibility of a different lifecycle.

Generated systems remain connected to a shared technical foundation. When the platform improves its permission model, deployment process or data layer, those improvements can be made available across many systems.

The organization's data, workflows and history do not disappear. The system is not recreated from nothing. Instead, its implementation can continue to inherit improvements from the platform on which it was built.

This makes the software self-renewing in a practical rather than autonomous sense.

Human governance is still required. Changes must be tested, compatibility must be managed and organizations must decide when new behavior should be introduced.

The difference is that the system is not technically isolated from the machinery that created it. It remains connected to a foundation that continues to evolve.

A standalone custom application must finance and manage that evolution by itself.

SaaS becomes a delivery model for platforms

The transition from applications to platforms does not necessarily end SaaS.

Software can still be hosted by a vendor, accessed through a browser and sold through a subscription. Those characteristics describe distribution and commercial structure rather than the nature of the underlying product.

A system-generating platform can therefore be delivered as SaaS.

What changes is what the customer receives. Instead of subscribing to one predefined application, the customer gains access to an environment capable of producing and evolving a system around its requirements.

The commercial relationship may look familiar, but the technical model is different.

Existing SaaS vendors can participate in this transition. Many already possess valuable components, domain expertise, customer relationships and operational infrastructure.

The challenge is that the fixed application model is usually embedded in the entire company. Architecture, pricing, sales, support and product management are organized around one predefined product. Becoming a platform therefore requires more than adding an AI assistant or exposing additional settings.

It can require the vendor to reconsider what it sells.

Some companies will make that transition successfully. Others will continue improving their existing applications without changing the underlying model. Those products may remain valuable for years, particularly in categories where migration is difficult and customer relationships are strong.

The broader direction will nevertheless favor vendors that can produce systems rather than only distribute applications.

Consultancies move up the value chain

Software consultancies exist because organizations often need systems that standard products cannot provide.

Platforms do not eliminate that need. They change the nature of the work required to meet it.

A consultancy may currently spend much of a project creating interfaces, implementing permissions, writing integrations and configuring infrastructure. Those tasks are necessary, but they are usually not the source of the customer's competitive advantage.

A platform can absorb more of that implementation work. The consultancy can then focus on understanding the business, clarifying requirements and designing processes.

This work is difficult to automate completely because organizations rarely describe themselves accurately. Important exceptions may be undocumented, different departments may follow conflicting processes, and management may describe an ideal operation that differs from daily reality.

Someone must investigate those conditions and help the organization decide how the system should work.

Consultancies are therefore likely to become significant users of system-generating platforms. They can combine domain expertise with a production environment that turns their recommendations into working software quickly.

The amount of routine coding declines, while the value of business understanding increases.

The consultancy moves from building every component to shaping the system that the platform produces.

Platforms will not become one universal system

The move toward platforms does not imply that every company will use one global platform or that all software will collapse into a single enterprise suite.

There will be many platforms serving different markets, industries and operational models. Some will be broad, while others will focus on domains with specialized requirements. Some will be proprietary managed services, while others will be open source and operated by customers or consultancies.

The number of platforms is still likely to be lower than the number of applications they produce. Reuse is the economic basis of the model, so one platform must support many systems.

That does not require every resulting system to be identical.

The platform standardizes production rather than standardizing the organization. Shared architecture, components and deployment processes create efficiency, while the generated system can still reflect different workflows and terminology.

This is an important distinction because large enterprise suites have historically created coherence by forcing organizations into one product model.

System-generating platforms can create coherence without requiring uniformity.

The role of open source

Open-source platforms are likely to play an important role because they separate the technical foundation from the service used to operate it.

Some organizations will prefer a managed platform that handles infrastructure, upgrades and support. Others will want control over deployment, source code and data. Consultancies may offer managed services around open platforms, just as they currently do around databases, cloud infrastructure and web frameworks.

These models can coexist.

The existence of an open-source implementation does not remove the value of the platform. It gives customers more choice over ownership and operation.

Open platforms may also influence standards around component interfaces, workflows and system definitions. Greater portability would reduce the risk of dependence on one provider and make it easier for organizations to move between managed and self-hosted environments.

The market has followed similar patterns before. Open-source frameworks did not eliminate commercial hosting, and managed cloud services did not eliminate internal infrastructure.

The same foundation can support several commercial models.

The transition will be gradual

Software markets rarely change all at once.

Existing applications contain years of customer data, integrations and operational habits. Replacing them creates technical and organizational risk, even when a better model becomes available.

Large vendors also possess distribution, trust and financial resources that allow them to adapt. Some will transform their products into platforms over time, while others will maintain fixed applications for established customers and introduce platform capabilities alongside them.

New entrants will have the advantage of designing around AI and generation from the beginning. They will not need to preserve older architectures or business models, but they will lack the customer relationships and domain maturity of established vendors.

The market will therefore contain several models at once. Traditional SaaS applications, AI-enhanced applications, low-code tools, open platforms and fully managed system-generating platforms will coexist for years.

The important shift will not be visible through a single product launch. It will appear through a gradual change in what customers expect.

They will become less willing to adapt their organizations to rigid product boundaries. They will expect systems to reflect their processes, terminology and data without the cost of conventional custom development.

As that expectation becomes normal, the fixed application will become more difficult to defend.

What the change means for software buyers

Software buyers have historically chosen between buying and building. Buying was faster and cheaper but required compromise, while building offered greater control at a significantly higher cost.

Platforms blur that distinction.

The organization may purchase access to a managed service while receiving a system configured around its own requirements. It gains some of the adaptability of custom development without taking responsibility for every layer of the implementation.

This changes how software should be evaluated. Feature lists become less decisive when the system can be assembled and extended around the organization. The more important questions concern the platform's component depth, adaptability, operational reliability and ability to evolve without accumulating fragile custom code.

Buyers will also need to examine ownership and portability. A platform may offer greater flexibility inside its environment while still creating dependence on its runtime, component model and commercial terms.

The strongest providers will therefore need to combine adaptability with credible governance, export and long-term stability.

The platform cannot merely generate a system quickly. It must remain a dependable foundation after the initial excitement has passed.

What the change means for software companies

For software companies, the transition changes the object of competition.

Application vendors currently compete through features, usability, distribution and category expertise. Platform companies must also compete through the quality of the systems they can produce.

Their advantage comes from the breadth and reliability of their components, the consistency of their architecture and the accuracy with which they can translate requirements into working software.

This creates a different product discipline. A feature is no longer valuable only because it improves one application. It becomes more valuable when it can be generalized and reused across many systems.

Product development moves closer to platform engineering. Customer implementations become sources of reusable knowledge, but only when they are designed in a way that strengthens the shared foundation.

Companies that fail to maintain that discipline may call themselves platforms while operating as custom development shops. Their implementations will become expensive, inconsistent and difficult to upgrade.

The strongest platforms will balance generalization with adaptability. They will make common needs inexpensive without assuming that every organization should operate in the same way.

The next unit of software

The transition from systems to platforms is not simply another feature cycle. It changes the unit through which software is produced and sold.

The application remains visible. Users still need interfaces designed around specific work, and organizations still depend on the systems through which their data and processes operate.

What changes is the layer that endures.

In the application model, the vendor's durable asset is the application itself. In the platform model, the durable asset is the capability to produce and continuously evolve many applications.

That capability compounds through reusable components, shared infrastructure and accumulated implementation knowledge.

The customer receives a system that fits more closely, while the provider retains the economic advantages of reuse.

This is what makes the platform model more than custom development with AI. Custom development creates one system at a time. A platform creates systems through a repeatable production process that becomes stronger with use.

Conclusion

SaaS became dominant because it provided the most effective response to the economics of software production. Vendors could build one application, distribute it widely and share the development cost across thousands of customers. Organizations accepted a degree of mismatch because the alternative was expensive custom development.

AI changes those economics by reducing the cost of translating requirements into implementation. This makes it possible to preserve the advantages of reusable software while allowing the resulting system to reflect the organization more closely.

The market will not move away from applications because applications remain the way people use software. It will move away from treating every application as an independent, permanent product.

More applications will become configurations generated by platforms that provide the architecture, components, infrastructure and operating rules underneath them.

Administrative software will move first because its recurring patterns are already suitable for generalization. Existing SaaS vendors will adapt, new platform providers will emerge, and consultancies will shift more of their value toward business understanding and process design.

The transition will be gradual, and no single company will define it. Proprietary services, open-source platforms and industry-specific providers will all contribute to the market.

What unifies them is a different view of software production. Instead of repeatedly building and integrating fixed applications, they create shared foundations capable of producing systems around the needs of each organization.

The system remains what the organization uses. The platform becomes the durable machinery through which that system is created, maintained and renewed.