AI is making PLM software easier to build, customize, and compete with. Yet manufacturers still need reliable product records, engineering change control, regulatory compliance, and supplier coordination. PLM remains essential while its business model comes under pressure. Which competitive advantages will continue to matter? Eight moats offer a practical way to examine the future of product lifecycle management.
The recent wave of AI-built application clones has given this debate much more energy. Adobe alternatives, an AutoCAD-style application, and other projects have triggered declarations that SaaS is dead and software is becoming free. For engineering software vendors, it raises a practical question: what will customers continue paying us to provide?
The cloning stories deserve careful reading. PhotoCraft’s own documentation describes it as early alpha and says it is not yet a replacement for daily professional Photoshop work. CADCraft’s roadmap identifies it as pre-alpha and describes gaps in core workflows and file preservation. These are ambitious projects with substantial work ahead of them. You can read the projects’ assessments in the PhotoCraft repository and CADCraft roadmap.
Still, their current limitations should give established vendors little comfort. A competitor does not need to reproduce every capability of a mature platform. It needs enough functionality to solve a particular customer’s problem. That is a much smaller target.
Earlier this year, in Can We Vibe Code the Next PLM?, I explored building PLM applications with AI. My thinking centered on the relationship between generated applications and the persistent product knowledge supporting them. I later examined AI-native PLM implementation and Product Memory. Now I want to consider the business implications. If building applications becomes easier, where does defensible value remain?
Two MicroConf talks helped me organize these thoughts: Rob Walling’s The Only SaaS Moats Left in 2026 and the follow-on talk, SaaS Moats in the AI Era: Sell the Outcome, Not the Tool. Together, they offer a useful way to examine both the threats and the opportunities for PLM.
How AI changes competition in PLM software
Everyone gets access to AI. Customers get it. Competitors get it. Open-source developers get it. Agencies, implementation partners, and the platforms surrounding your product get it too.
This broadens the threat considerably. Customers building their own applications are only one possibility. A competitor can close a feature gap. An ERP or CAD platform can absorb adjacent functionality. An integration partner can offer a tailored service. An agent can perform work that previously required someone to operate several applications.
The demand side matters as well. A manufacturer may continue using its PLM system while needing fewer people to search for information, prepare reports, reconcile BOMs, or coordinate routine handoffs. The product record remains important, but software consumption changes.
For PLM vendors, this means faster development is necessary without being sufficient. Everyone accelerating at the same time puts pressure on the advantage of having more features. Rob’s framework directs attention toward trust, authoritative records, permission to act, reliable outputs, approvals, coordination, learning, and the responsibility of keeping a service running.
These advantages deserve a specific interpretation for engineering and manufacturing.
Will AI replace PLM software—or change its business model?
A physical product still needs an applicable configuration. Someone must know which revision was approved, what suppliers received, which components were purchased, and what was manufactured. Engineering decisions have consequences across time, organizations, and systems.
Those responsibilities remain even when AI can generate applications around them. However, the organizations fulfilling them, the interfaces people use, and the way customers pay could change substantially.
A PLM platform might remain the authoritative record while an external agent becomes the main way people interact with it. A generated workspace might replace a module. A service might complete work previously performed by several licensed users.
This is the central tension: PLM can become more important while established PLM business models come under pressure. SaaS delivery alone provides no protection, and the same questions apply to on-premises software.
Free CAD and PLM software are not new
Before we conclude that free software will eliminate the engineering software business, it is worth remembering that our industry has already explored free distribution.
AutoCAD-compatible alternatives have existed for years, including products offered at no license cost. DraftSight provides a useful example. Dassault Systèmes offered a free DWG-based CAD application while also providing commercial services around it. Its Bobst customer story describes the company adopting the free application and selecting a Premium Service Pack for support, licensing capabilities, and API access.
PLM has its own example. Aras Innovator’s enterprise open-source model made the software available as a free download while building a subscription business around support and upgrades. I discussed the relationship between its free license, community, platform, and services in my earlier article, Aras PLM: The Good, the Bad and the Open Source.
These examples demonstrate that eliminating the initial license fee does not eliminate the work required to make engineering software useful and dependable. Companies still need implementation, integration, maintained information, upgrades, support, and confidence that their operations will continue working.
AI changes the economics further. It can reduce the effort required to create applications, adapt workflows, build integrations, and move information. Some services that previously justified substantial fees will face pressure too.
History therefore gives us a useful starting point, rather than a guarantee that existing vendors are safe. Free software has already challenged the industry. The next question is which responsibilities and advantages remain valuable as AI makes more of the surrounding work easier.
8 moats that can defend PLM software from AI
A PLM moat is a competitive advantage that remains valuable even when another company can reproduce the application’s visible features.
Here are eight areas where I think PLM vendors can build a more defensible position. They translate Rob’s framework into the specific responsibilities of engineering and manufacturing software.
1. Industry trust and the PLM community
Engineering and manufacturing software is purchased within communities of practice. People ask colleagues, suppliers, consultants, and peers what worked, what failed, and who helped when something went wrong.
A vendor can strengthen its position by becoming a reliable participant in those communities. Responsive support, useful education, successful implementations, honest references, and users helping other users all contribute. Industry expertise becomes especially valuable when it reflects the buyer’s actual products and operating environment.
A new application may arrive with impressive functionality. It still needs people willing to recommend it, partners able to implement it, and customers prepared to trust it with consequential work.
The practical recommendation is to invest in the community surrounding the product as deliberately as in the product itself. Recommendations are earned through repeated experience. They become more valuable when they come from people whose judgment the buyer already trusts.
2. Systems of record and Product Memory
Systems of record have weight because operations depend on them. In PLM, that can include product definitions, revisions, configurations, approvals, relationships, and the connections to downstream systems.
Product Memory connects product structures, revisions, decisions, relationships, and outcomes so that people and AI agents can understand how a product evolved.
It captures why a component was selected, what alternative was rejected, which exception was accepted, how a change affected manufacturing, and what happened afterward. It connects formal records with the context needed to understand them.
A replacement application must therefore do more than import rows and files. It must preserve relationships, interpretation, and continuity so the organization can keep working with confidence.
There is an essential principle here: Product Memory belongs to the customer. Data ownership and portability should remain clear. A vendor’s defensibility should come from the continuing value of maintaining that memory—its integrity, accessibility, consistency, and usefulness.
This gives customers a reason to stay even when they are free to leave. It also creates a foundation on which customers and partners can build their own AI-generated applications.
3. AI agents that act on the customer’s behalf
A platform that prepares a report occupies a different position from one trusted to execute an agreed process.
Consider an engineering change involving a contractor. The platform could prepare the revised package, perform agreed checks, obtain the required approval, distribute the applicable revision, collect acknowledgments, follow up on missing responses, and route exceptions to the responsible people.
This involves delegated responsibility. The customer must trust the platform’s permissions, timing, records, and handling of exceptions. Contractors must recognize the process and understand what its communications mean.
Technical access is only one part of that relationship. A newcomer also needs to establish confidence that it can carry the work through reliably.
For PLM vendors, the recommendation is to identify specific activities customers are prepared to delegate and make them dependable. Keep the scope and authority clear, with the necessary engineering decisions and approvals assigned to accountable people.
4. Trusted BOM cost and quantity calculations
Rob describes a moat built around outputs customers no longer routinely double-check. In PLM, cost calculations provide a useful example.
The arithmetic of a cost roll-up can be straightforward. The operational challenge is knowing which configuration applies, whether quantities and units are consistent, which supplier prices are valid, and how agreed assumptions affect the result.
When a platform repeatedly handles these details correctly, its outputs can become part of quoting, planning, purchasing, and engineering decisions. The same principle applies to quantity calculations and configuration resolution.
The recommendation is to make important outputs reliable and explainable. Users should be able to trace the inputs, applicable revision, rules, and assumptions. Repeated correctness builds confidence; hidden logic makes that confidence fragile.
Customers may stop independently recalculating every result while continuing the reviews their processes require. A replacement must establish comparable confidence before its outputs become operationally interchangeable.
5. Regulation and compliance in PLM
Regulation and compliance deserve explicit attention because the consequences of failure can extend well beyond inconvenience.
Depending on the industry and intended use, a manufacturer may need controlled records, approvals, traceability, audit evidence, and confidence that its software supports the required process. Relevant vendor qualifications or external approvals can add another barrier where they apply.
The work involves establishing evidence and maintaining dependable controls over time. For example, the FDA’s February 2026 software assurance guidance for medical-device production and quality management systems describes a risk-based approach to establishing confidence in automation.
For a PLM vendor, this creates an opportunity to support customers with appropriate controls, documentation, testing evidence, and validation activities. Where a manufacturer depends on those controls to release work or continue production, replacement requires careful assessment. An unproven transition could put operations or compliance evidence at risk.
Serving a regulated customer does not itself make a vendor approved or its software suitable for every regulated use. The advantage comes from the specific qualifications, evidence, validated use, and continuing assurance surrounding the service.
A challenger can build similar screens. It must also establish the confidence and evidence necessary for the customer’s intended use.
6. Data collaboration across OEMs and suppliers
PLM becomes more difficult to replace when it connects engineering, procurement, manufacturers, contractors, and suppliers in their daily work.
The experience matters. People need to find applicable information, understand requests, respond easily, and see what has changed. Communication becomes more useful when it stays connected to the relevant item, revision, requirement, or decision.
Replacing an individual tool can be relatively simple. Moving an established working community requires coordination. Participants must change habits, responsibilities, shared references, and expectations together.
That advantage should be built through usefulness. A collaboration portal with many dormant accounts provides little protection. A place people prefer to use—and invite others into—has a stronger position.
For a network effect to develop, additional relevant participants must make the environment more valuable to existing participants. A growing user count alone does not establish that.
7. Learning from engineering and manufacturing outcomes
This is where Product Memory and the second MicroConf talk connect most directly.
A snapshot can show the current BOM and its approved revision. It cannot by itself explain how the organization arrived there, which suppliers requested clarification, what corrections were necessary, or what the resulting production experience revealed.
A platform can capture that progression: perform defined work, observe the result, evaluate what happened, and improve subsequent behavior. The value grows when it can demonstrate that experience makes future work more effective.
Imagine a platform connecting the Product Memory of participating OEMs and suppliers. Consider a hypothetical engineering change to a machined housing: the OEM revises the drawing, a supplier asks for clarification, and the approved package eventually reaches production. Each step can add context to the next.
| Step in the OEM–supplier process | What the platform records | How the experience can improve later work |
|---|---|---|
| Engineering revises the housing | The applicable revision, drawing, affected BOM items, and reason for the change | Makes the scope and context of the handoff available for subsequent checks |
| The supplier requests clarification | A missing inspection criterion or ambiguous surface-finish requirement | Identifies information that deserves attention in comparable future packages |
| The OEM resolves and approves the clarification | The decision, responsible approver, and applicable package | Preserves the accepted interpretation and its limits |
| The supplier acknowledges the package | The revision received, response, and any remaining exceptions | Distinguishes a completed handoff from one still requiring follow-up |
| Production provides feedback | Reported rework, acceptance results, or other relevant observations | Provides evidence for evaluating whether revised checks actually improved preparation |
If the same clarification recurs across comparable packages, the platform could begin checking for it earlier. That would be a useful learning advantage: accumulated experience improving the next interaction. A supplier acknowledgment alone would not establish technical correctness; later manufacturing feedback provides additional evidence.
This learning must respect ownership, confidentiality, and agreed rights. Connecting companies does not mean exposing one OEM’s proprietary design or negotiated prices to another. Some lessons may be reusable; others must remain specific to a customer.
There is also a time dimension. Qualification, production, and field performance take time to observe. A better foundation model cannot instantly recreate those experiences. Customers should be able to transfer their history, while the platform earns an advantage through its ability to interpret experience and turn it into better results across permitted interactions.
8. Maintained BOM and service information
Another opportunity is to provide a reliable place to obtain information people repeatedly need: current BOMs, approved component and supplier attributes, or maintenance and service records.
The ongoing work can be substantial. Sources change. New revisions appear. Attributes become inconsistent. Integrations need attention. Permissions evolve. Someone must keep the information current, preserve its relationships, and make it available when needed.
A shared resource becomes valuable when participants can depend on that service. Copying the interface or importing yesterday’s dataset does not reproduce its continuing maintenance.
This differs from the system-of-record advantage. An authoritative record establishes what is official and preserves continuity. A maintained resource stays useful through the work of reconciliation, updating, access, and operation.
Providing a single place to work does not require putting every source in one database. The practical goal is dependable access to applicable information, supported by a service willing and able to keep it working.
From PLM tools to completed work: how AI changes SaaS business models
The second talk adds an important commercial dimension. It describes three options: develop faster, support and charge for agent use, and move into work previously performed by people using the software.
For PLM, these approaches can coexist. A vendor can provide stable data services for customer-built applications while also delivering defined services of its own.
Consider the difference between giving someone a supplier-package preparation tool and taking responsibility for preparing the agreed package, running checks, routing exceptions, distributing it after approval, and tracking responses. The latter addresses the effort required to get the work done.
The value proposition can therefore expand to engineering and manufacturing capacity. Teams may handle more products and suppliers with less reconciliation and follow-up. The vendor can capture some of the value of completed work while continuing to provide the underlying platform.
This does not prescribe charging per outcome. Subscriptions, usage allowances, transaction fees, and hybrid arrangements could all support the model. The deliverable needs clear boundaries and acceptance criteria. A completed handoff is much easier to define than responsibility for an entire successful product launch.
It also strengthens the learning opportunity. Executing work gives the platform a chance to observe results, address exceptions, and improve. The advantage must be supported by performance, including the cost of handling difficult cases.
What is my conclusion?
I don’t expect the need for PLM to disappear. Product development and manufacturing still require persistent knowledge, coordination, traceability, and accountable decisions. AI can help fulfill these responsibilities in different ways, and that puts pressure on the products and business models surrounding them.
For PLM vendors, defending a feature list will become more difficult. A stronger position comes from earning an industry’s recommendation, maintaining trusted Product Memory, carrying consequential responsibilities, connecting participants, and learning from the work performed across that network.
Existing vendors have useful starting advantages in records, relationships, expertise, and operational experience. New entrants have an opportunity to organize those responsibilities differently. Neither position guarantees success.
The question I would ask is what customers continue to entrust to the platform when building an alternative application becomes easier. Their answer will reveal much more about the business than the size of its codebase.
Just my thoughts…
Best, Oleg
Disclosure: I am the co-founder and CEO of OpenBOM. These are my thoughts about the direction of PLM and the software business.
