For the past few years, there has been an ongoing assumption in hardware that the massive software incumbents - companies like Dassault Systèmes, Autodesk, and Ansys - sit on unbreakable moats. If you wanted to run high-end computational fluid dynamics or finite element analysis, you had no real alternative. You bought their enterprise licenses, learned their Byzantine interfaces, and accepted their pricing because writing that kind of simulation software historically required an entire army of PhD-level mathematics and physics engineers. But I've come to the conclusion that this defensibility is quietly evaporating.
What is actually driving this shift? Two distinct technical developments have collided at the exact same time. First, AI has made it dramatically easier to write complex numerical software and reverse-engineer legacy codebases. Second, the modern graphics stack has opened way up. Modern tools like Rust and WebGPU (via WGSL) have radically lowered the barrier to writing high-performance compute shaders that run anywhere. Taken together, the software layer surrounding physical engineering is starting to dissolve, and that has massive consequences for how physical products get built.
Solvers without the PhD army
Historically, if you wanted to build a serious engineering simulation product, you were forced to recruit dozens of specialized researchers and spend five years building a proprietary solver from scratch. Today, that simply isn't the case anymore. Just the other day, I was talking with the team at Solid SF (https://solidsf.com/), who built their own high-fidelity CFD and FEA solver from the ground up in Rust.
At the same time, nimble newcomers like Nullspace (https://www.nullspaceinc.com/) are entering the market with solvers that run simulations at very high fidelity, move fast, and natively accept open-source file formats. So how are small teams pulling this off? Part of the answer lies in modern graphics abstractions. In the past, writing GPU-accelerated code meant getting bogged down in platform-specific CUDA dialects and writing brittle translation layers to shuttle binary data between the GPU and the CPU.
With WGSL, you learn a single language to express your compute workload, and that same code can execute across GPUs, CPUs, FPGAs, in the browser, or on a remote server cluster. When you make graphics hardware that accessible, you instantly expand the pool of software engineers capable of building simulation engines from a tiny priesthood to the broader developer community.
The end of file format lock-in
Beyond the difficulty of writing solvers, the older CAD and CAE giants have relied on dirty little tricks to keep customers trapped inside their ecosystems. The standard playbook was simple: you created a proprietary file format, obfuscated the internal structure, and made it nearly impossible for third-party tools to read or export the underlying geometric and simulation data. If an engineering firm tried to switch tools, they faced the terrifying prospect of losing access to a decade's worth of legacy parts and simulation runs.
That tactic is now falling apart completely. With modern AI tools, reverse-engineering opaque formats and scripts has become remarkably straightforward. I know several companies that have already reverse-engineered complex, closed solid part formats and proprietary scripting languages to turn them into open data structures. Once you strip away the artificial barrier of format obfuscation, customers are no longer held hostage by their file history.
Why enterprise teams still pay for legacy seats
There is, of course, a very fair counter-argument to all of this. If lightweight Rust solvers and open CAD tools are so capable, why do enterprise engineering teams at aerospace and automotive suppliers still happily cut six-figure checks for CATIA and Ansys seats every year? Some people argue it comes down to safety certification and decades of validated edge cases, but I disagree with that framing. You don't get an AS9100 or FAA part certification simply because you ran the numbers through a specific commercial brand's simulation package; physical validation on real hardware is and always will be the ultimate requirement.
The real reason enterprise engineers stick with legacy suites is friction. An engineering team has spent fifteen years building customized simulation scenarios, macros, and standard operating procedures directly on top of CATIA's or Ansys's specific scripting environments. Migrating an entire organization's embedded workflow and retraining hundreds of engineers off a familiar user interface is a massive organizational cost. In practice, that switching cost only buys legacy vendors time while the tooling around newer solvers catches up. As newer entrants build better integrations, drop-in workflow translators, and modern tooling around their solvers, that friction will steadily drop to zero.
The rise of the solo hardware founder
When simulation solvers commoditize and CAD formats become entirely fluid, where does the defensible value actually go? It collapses down into what I think of as the manufacturing knowledge worker. This is the individual engineer who understands the entire value chain from top to bottom - they understand the core problem, they know how to design the CAD model, they run their own high-fidelity simulations on their workstation, and they understand the physical machining and fabrication constraints needed to get the thing made.
Instead of needing a twenty-person engineering department divided into CAD drafters, simulation specialists, and production planners, a single engineer sitting at a desk can design a complex physical assembly, validate it numerically in minutes, and send it straight out to a CNC shop or 3D printer. The entire software stack around hardware development is becoming a solo founder sport.
If the software barriers to designing complex mechanical systems are effectively collapsing to zero, what happens to the physical supply chain that has to build them?