TABLE OF CONTENTS
Key takeaways
- AI can produce a convincing PLM prototype surprisingly quickly.
- Building the first version is only a small part of the actual cost.
- Scale, integrations, security, and data integrity turn an internal tool into an ongoing software operation.
- Building an internal PLM means accepting responsibility for an entire software product.
- Hardware companies should focus their engineering resources on their products, not on becoming PLM experts.
We’re fans of LLMs and AI agents. Duro’s Product Lifecycle Management (PLM) platform is AI native, we actively encourage partners to build AI tools on top of our API (see what Circuitly did here), and our dev team heavily leverages Claude to get things done faster and at scale.
So when a potential new customer quipped “why can’t I just vibe code a PLM?” we didn’t get defensive. After all, there would be clear benefits to creating your own personalized PLM to use for just your engineering team. An internal PLM could be customized around the company’s exact workflow. The business could control the interface, data model, hosting environment, and product roadmap. It could avoid a lengthy procurement process and eliminate recurring subscription fees.
So yes, vibe coding has genuinely made software prototypes faster and less expensive to produce. But a prototype is not the same thing as a production quality infrastructure.
We know because we tried it.
Duro vibe coded a PLM from scratch… and it worked
Using our favorite flavor of LLM today, a few members of the Duro team started a skunkworks project to literally vibe code a functional PLM prototype from scratch. We instructed our AI to create something with a recognizable interface, product data, components, BOMs, and other elements someone would expect to find in a basic PLM.
And wouldn’t you know it, it worked.
We could enter in component parts, do status changes, and even upload a BOM. Our LLM even gave the PLM a name and the UX was simple, but surprisingly easy to navigate. “Keel” was live and it was a homegrown PLM competitor to… ourselves!
But getting the first version to work was the easy part. Making it something we would trust with the product record of a real hardware company was an entirely different problem. After all, a prototype can demonstrate a workflow under controlled conditions. But a true production PLM must support that workflow reliably for years, across changing products, growing teams, complicated permissions, third-party systems, and enormous volumes of interconnected data.
And as we continued to test Keel and tried to improve it, the limitations quickly became obvious.
Problem #1: The cheap vibe coded PLM isn’t cheap
Vibe coding makes generating code less expensive, but doesn’t eliminate or even drastically reduce the cost of owning software. And when you build it in-house, you do indeed own it.
First, even the initial build has unavoidable costs such as employee time, AI tokens (an increasingly expensive factor), infrastructure (ie. server space), testing sprints, and review cycles. Every generated feature has to be checked to ensure it does what the company intended, in both best and worst case scenarios. When it does not, someone must understand whatever the AI generated code is well enough to diagnose and correct it. Who was that someone? The dev that vibe coded it? The head of engineering? Is that the best use of their time?
When the vibe coded PLM is launched internally, someone has to respond when a BOM does not load properly, a permission rule blocks the wrong user, or a revision behaves unexpectedly. Someone must patch dependencies, monitor infrastructure, manage databases, test upgrades, review security vulnerabilities, maintain documentation, and respond to feature requests from engineering, operations, sourcing, quality, and manufacturing.
In our experiment, it quickly became apparent that an internal PLM would need a dedicated developer simply to troubleshoot issues and keep up with requests. That means a full-time engineering salary in addition to AI usage, hosting, storage, monitoring, and other infrastructure costs.
The company also needs someone who understands PLM best practices, which was easy for us of course, but not so easy for any engineering team who might vibe code a PLM themselves. The LLM can generate a working change-order screen, but it can’t independently decide how lifecycle states should work, which data should become immutable after release, or how a proposed revision should affect downstream assemblies. Those are product and process decisions. If the company does not already have that expertise, someone must develop it.
This is why software costs should be evaluated based on total cost of ownership rather than the price of producing the initial version. As we explain in our guide to calculating the total cost of ownership of PLM software, the real calculation includes implementation, infrastructure, integrations, support, maintenance, upgrades, training, and staffing.
For an internal system, the equation looks something like this:
Internal PLM cost = development + AI usage + infrastructure + integrations + maintenance + security + support + domain expertise + opportunity cost.
The code may be cheap, but everything else isn’t.
Problem #2: Scaling a vibe coded PLM is arduous
Our vibe coded PLM worked within the narrow scope of the experiment. But anything looks good as a prototype running off a laptop working with fake data. So how would it behave when managing larger, busier, and more complicated products?
Scaling a PLM is not simply a matter of paying for additional database capacity. PLM data is relational. A component can appear in several assemblies, each of which can appear in several products with its own revision and lifecycle state. A single change may affect drawings, sourcing decisions, compliance documentation, manufacturing instructions, and products already in the field.
A production-quality PLM has to manage thousands of component parts, deeply nested BOMs, multiple configurations, large CAD files, years of revision history, and where-used relationships across many different products.
It also has to scale organizationally so it can accommodate multiple users who bring more permissions, perform simultaneous edits, do approval requirements, and manage exceptions. Suppliers and contract manufacturers may also need access to one set of files without gaining access to the rest of the company’s intellectual property. Different programs may need different workflows or isolated environments.
The prototype could handle a representative product. But continuing to extend it for thousands of parts, multiple teams, complex assemblies, and years of accumulated history was going to require continuous development.
That should sound familiar. Companies often adopt PLM because they have already outgrown spreadsheets and homegrown processes. As we discuss in our comparison of Excel and dedicated PLM software, spreadsheets work well early because they are inexpensive and flexible. Problems appear as more products, revisions, and stakeholders become involved.
A vibe coded PLM risks recreating the same growth ceiling behind a better-looking interface. And if the argument is that you just need something simple and basic in the first place, then why even push past Excel at all?
Problem #3: Vibe coding PLM integrations is yet another giant project
Hardware product data moves through ECAD, MCAD, ERP, MES, procurement, quality, project management, and a whole lot more. A PLM becomes valuable when it connects those tools and keeps product information consistent as it moves between them.
That means every internal PLM eventually needs integrations to be actually useful for the team. We here at Duro know that integrations are fundamentally important to PLM, which is why we have a dedicated team of developers actively maintaining and upgrading our various integrations.
For starters, connecting two APIs is just the beginning. Your PLM team (that’s right, you have to have an in-house PLM team now) must decide which system owns each field, how attributes are mapped, what happens when the systems disagree, and how failed transactions are detected and retried. It must account for authentication, permissions, rate limits, outages, schema changes, and conflicting revisions.
For example, let’s consider an ECAD integration. Synchronizing a component isn’t just copying its name and part number. The integration may need to map manufacturer parts or sourcing attributes or lifecycle states or schematic data; honestly, a host of different data and data sources. Not to mention it has to also prevent one system from accidentally overwriting approved data in another.
That is why a production integration such as the connection between Altium 365 and Duro requires much more than a one-time coding effort. Our team is constantly working on this integration to account for edge cases and to make it work faster and better.
Some integrations may also require partnership agreements, commercial contracts, certifications, or ongoing technical communication with the provider. If an external API changes, your team is on the hook to update its connector. In essence, each connector effectively becomes another software product that must be monitored, documented, tested, and supported.
(By the way, this was one reason Duro rebuilt its platform around an open, API-first architecture. Stable APIs make it easier to connect specialized applications without requiring a company to recreate its underlying product-data system.)
All this also creates a key-person problem. The person who vibe coded the application and its integrations may become the only person who understands why the system behaves the way it does. If that developer leaves or changes roles, the company inherits a business-critical application that may no longer have a knowledgeable owner.
Problem #4: PLM security is a headache you don’t want
Your internally built PLM can’t run on your local servers for long, which means they will most likely use the cloud. Congratulations, you’re now responsible for configuring, monitoring, and protecting that infrastructure.
By its nature, a PLM contains some of a hardware company’s most sensitive information: CAD files, product architecture, component selections, manufacturing documentation, supplier details, pricing, and unreleased designs. Protecting that information requires more than putting the application behind a login screen. Now we’re talking identity and access controls, multifactor authentication, encryption, activity logging, backup processes, and more.
According to Justin Gatewood | Security @ Duro:
- Authorization is harder than authentication. AI-generated code nails the login page and misses the ownership check behind it. It’s possible that your contract manufacturer’s buyer changes one ID in a URL and reads a competitor’s BOM.
- Your PLM is supposed to be the single source of truth for what gets built. If a dimension can be changed without a reliable record of who changed it, or the released package can be altered on its way to your supplier. The first time you learn the truth is when the wrong parts arrive on the dock.
- Stolen data is a bad week; changed data is a bad quarter. You can’t tell a typo from tampering without a trustworthy edit history, and you can’t tell which other parts are wrong, so the cost isn’t one scrapped build. It’s no longer trusting anything in the database.
- You can’t prove what you don’t log. Trade secret protection requires demonstrable measures to keep it secret; with no access logs, the departing engineer’s download is unprovable and the asset may not legally be a secret at all.
- Export control follows the data, not your intent. A default region, a backup replica, a foreign-national contractor, or a controlled drawing pasted into a coding assistant are each a potential deemed export, assessed per violation, criminally.
- Backups you’ve never restored aren’t backups. Same account and credentials means ransomware takes production and recovery in one motion, and you find out how long you’re actually down on the worst possible day.
- Your PLM holds credentials to CAD, ERP, MES, and every contact manufacturer you work with. Compromise travels outward, which makes you the incident your customers have to disclose.
- Bus factor of one, and nobody reviewed the code. When the next Log4j lands you can’t answer “are we affected?”
- Compliance can’t be produced retroactively. SOC 2 Type 2 needs an observation window, so the day a customer’s security review arrives you’re months from an answer, not weeks, and the deal doesn’t wait.
Regulated industries add another layer. Aerospace, defense, medical device, and other hardware companies may need to demonstrate compliance with SOC 2, NIST, ITAR, export controls, or industry-specific requirements. And these are ongoing operational programs, not something that can be generated once and marked complete.
Duro’s own journey to SOC 2 Type 1 and Type 2 compliance required dedicated processes, controls, monitoring, and independent audits. A cloud account under your company’s name does not provide those protections automatically.
Is your team ready to take on the responsibility of securing your vibe coded PLM? If so, well, we’re hiring.
Problem #5: The real-world consequences of bad PLM
A bug in a typical internal application might produce an incorrect report or a broken page. A bug in a PLM can escape the software and enter the factory.
Here are some PLM nightmares that can happen:
- An incorrect revision can cause a supplier to manufacture from an outdated drawing.
- A broken lifecycle rule can release an unapproved component.
- A failed synchronization can leave purchasing with stale availability data.
- A damaged BOM relationship can cause the wrong quantity or part to be ordered across an entire production run.
These issues keep us up at night because they can consume physical materials, manufacturing capacity, engineering time, and weeks of schedule. Your vibe coded PLM, like all good PLMs, should be rigorously tested to prevent errors creeping into the real world with real dollars at stake.
For example, this is why part traceability is such an important capability in hardware development. Teams need to know what changed, who changed it, which products were affected, and which version went to manufacturing. That history cannot depend on the assumption that generated code probably handled every edge case correctly.
A company that builds its own PLM takes on the responsibility for preserving that record for the entire product lifecycle.
The real cost: You started a PLM company inside your hardware company
To turn our vibe-coded PLM prototype into a dependable product, we would need people responsible for engineering, product management, design, security, infrastructure, integrations, testing, support, documentation, and PLM domain expertise.
In other words, we would need to operate a PLM company. Luckily, we already do. But you don’t.
Duro has more than 40 people working to make sure our PLM just works. Our team is always building as new CAD tools emerge, APIs change, security threats evolve, and as customers develop more complicated products that require upgraded features.
The question isn’t whether you can vibe code a basic PLM. Rather, the question to ask yourself is:
Do we want to operate a PLM company for the next five to ten years?
Build your product, not your PLM
Our experiment proved that AI can generate a working PLM prototype. It also demonstrated why vibe coding a PLM is just the tip of the iceberg. The hard part is sustaining the system as products become more complicated, teams grow, integrations change, security requirements evolve, and years of product history accumulate.
Every hour your team spends debugging BOM logic, repairing a CAD integration, or investigating a failed backup is an hour not spent on the product that your company actually produces. Your engineering team should focus on becoming the best in the world at building that product, not on becoming experts in maintaining PLM software.
