Enovia Was the Right Answer in 2015. That's Exactly the Problem.

Article 2 of 3: Buying engineering tools for the company you're becoming

There's a moment in almost every PLM conversation I have with scaling hardware companies. Someone on the buying side — usually the person pushing for modernization — lowers their voice slightly and says some version of:

"The engineers here want Enovia. They came from aerospace, they know it, they trust it. And I can't tell them they're wrong, because on paper they're not."

They're not wrong on paper. That's what makes this decision genuinely hard, and I want to treat it honestly rather than pretend the incumbents have nothing.

What forty years actually buys you

Let's give the incumbents their due, because a modernization argument that ignores their strengths gets shredded in the first procurement meeting.

Teamcenter, Enovia, Windchill — these systems encode four decades of edge cases. Every weird revision scenario, every regulatory workflow, every "what happens when a supplier obsoletes a part mid-certification" — someone at Dassault or Siemens hit that case in 1997 and wrote a feature for it. If you're building a Rafale, that accumulated scar tissue is worth an enormous amount. An engineer who spent ten years at Airbus will sit down in Enovia and feel at home.

That maturity is real. Anyone selling against it by calling it "legacy bloat" is selling you spin.

What forty years costs you

Here's the honest other side. Those systems were architected for a world where the unit of work was a human clicking through a workflow. Their data models, their permission systems, their entire interaction paradigm assumes that a person opens the tool, does a thing, and closes it.

The world that's arriving — fast — has a different unit of work: an agent that reads your design data, runs checks, simulates a change's downstream impact, and drafts the ECO before the humans meet. That's not speculative anymore. It's the difference between a four-hour design review and a forty-five-minute one, and teams are seeing it today.

Can you bolt agents onto an incumbent PLM? Technically, sometimes. In practice it means writing custom Python piping against APIs that were designed as an afterthought, maintained by a vendor whose revenue depends on services engagements, on top of a data model that doesn't know what "design intent" means. You become the systems integrator. Every AI capability you want is a project, not a feature.

The question the tooling lead at that drone company asked me was the sharpest version of this I've heard: "I'm sure they have all the features. But will they have the engineers, in five years, to adapt to this new world?"

That's the real bet. Not features today — trajectory.

Vertical vaults in a horizontal world

There's a second structural issue that predates AI entirely. The incumbent PLMs grew up inside CAD ecosystems — Enovia with CATIA, Teamcenter with NX. Inside their home vertical, they're excellent. The moment your stack crosses vendors — SolidWorks for mechanical, Altium or KiCad for electrical, GitHub for firmware — you're in integration hell, because the PLM was never designed to treat other vendors' artifacts as first-class citizens.

And every modern hardware company crosses vendors. Multi-discipline is the default now, not the exception. So the incumbent's greatest strength — deep vertical integration — is aimed at a topology that fewer and fewer companies actually have.

How to make this decision without a crystal ball

I don't think the answer is "always pick the startup." I run one; I'm biased; discount accordingly. Here's the framework I'd actually use:

Weight domain depth by how much of it you'll use. If your products are 100-line BOMs, you will use perhaps 5% of Enovia's accumulated edge-case handling — and pay, in complexity and rigidity, for the other 95%. Aerospace scar tissue is only valuable if you have aerospace wounds.

Weight adaptability by how fast your requirements are changing. If you expect your engineering workflow to look the same in 2031 as it does today, buy the mature thing. If you expect agents to be doing your impact analysis, your DFM checks, and your first-pass design reviews — buy the thing that was architected for that, or at minimum the thing with real APIs and an MCP surface, so you can build what the vendor doesn't.

Interrogate the API before the demo. The demo shows you the past — features built for previous customers. The API shows you the future — what you'll be able to do when your needs diverge from the roadmap. Ask to see the documentation before the sales deck. A vendor who hesitates is telling you something.

The uncomfortable truth for buyers is that there's no zero-risk option anymore. The startup might fold. The incumbent might fossilize. You're choosing which risk you'd rather manage — and the third article in this series is about exactly that: how to buy from a young company without betting your career on its survival.

---

I'm Serge Kadjo, founder of ProductFlo — a coordination layer that connects mechanical, electrical, and firmware engineering so changes propagate instead of getting lost. I've spent 10+ years building hardware, from consumer robotics to medical wearables, and I write about the intersection of AI and hardware engineering.