After a long parametric study or transient simulation, a project folder on a CAE engineer's machine looks like a disaster: hundreds of result files named by time step, duplicate mesh files from iterations that went nowhere, log files from crashed runs mixed in with logs from successful ones, and no reliable way to know which .cas file corresponds to which geometry version. The specific complaint — 'saves an excessively large number of files at each time step, making file management challenging' — understates how bad this gets at scale. Engineers doing design-of-experiments runs across 20 parameter combinations have folders in the tens of thousands of files and hundreds of gigabytes, with no metadata linking a result file back to its boundary conditions.
This problem is invisible to vendors because it lives entirely outside their software. The solver finishes, writes its files to disk, and its job is done. What happens to those files is the user's problem. IT doesn't care because storage is cheap. Managers don't see it because the engineer handles it manually. Nobody complains to the vendor because there's nothing to complain about — the software technically did what it was asked.
The real cost shows up when an engineer needs to reproduce a result from three months ago, or when a project gets handed off and the receiving engineer has no idea which of 400 .cas files is the final approved one. Reconstruction from scratch, re-running simulations to recover a known-good result, and time spent manually auditing folders are all real recurring costs that nobody is counting.
This is structurally awkward to fix inside a CAE solver because it requires observing file system activity across multiple solvers, correlating it with project metadata, and presenting a UI that lives outside any single vendor's application. No one vendor covers the full stack an engineer actually uses.
What to build
Build a Windows desktop app that watches designated CAE project directories, automatically tags result files with the solver name, run timestamp, parameter values parsed from solver input files, and pass/fail status inferred from log output, then presents a filterable run history with storage size per run and one-click archival or deletion of superseded results.
Where to start
Start with Ansys Fluent .cas/.dat file pairs, where the run log structure is consistent enough to reliably parse completion status and iteration count, giving engineers an immediate win on identifying failed runs and cleaning up storage before expanding to multi-solver support.
The hard part
Parsing solver input files to extract meaningful parameter values (mesh size, material properties, boundary conditions) requires format-specific parsers for each solver — Fluent journal files look nothing like MAPDL input decks — so the early version will only cover one or two solvers credibly, and expanding coverage is a long tail of engineering work.
How it makes money
One-time purchase per engineer seat with an optional annual update subscription, since the core value is immediate and doesn't require ongoing cloud infrastructure — price around $200 one-time plus $80/year for updates.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Simulation & CAE.
More ideas in Simulation & CAE