Founder Background and Market Context

The market scope and viability of FEA Sidekick is grounded in first-hand industry and research experience rather than desk research. This note records that foundation explicitly.

Founder Profile

Sundar Gurumurthy — CV and full profile at sundar.guru.

• Automotive industry background: direct experience with the production engineering and simulation workflows that FEA Sidekick targets.
• Academic role at Cranfield University: active research on FEA of Wire Arc Additive Manufacturing (WAAM) for aerospace applications, including thermo-mechanical simulation and residual stress analysis on additively manufactured components.
• Industry partners engaged through Cranfield: GE Aerospace and Airbus — two of the most demanding consumers of validated FEA in the world.

Why This Background Is the Market Signal

The viability of FEA Sidekick does not rest on a market report. It rests on direct observation of how simulation workflows fail at scale in practice:

• Engineers in regulated industries (aerospace, automotive) cannot accept black-box AI predictions as final validation. This is a regulatory and contractual constraint, not a preference. It is why end-to-end AI solvers will not displace validated FEA in the near term.
• Meshing is the most labour-intensive and error-prone step in a typical FEA workflow. Poor mesh quality is the single most common cause of inaccurate results and wasted compute.
• The gap between what a solver needs (a mesh that reflects the physics) and what an engineer can produce manually (a mesh that reflects geometry) is well understood by practitioners but poorly addressed by existing tools.
• Industry partners at the tier of GE Aerospace and Airbus represent the top of the target market: long simulation cycles, high compute costs, and strict accuracy requirements. If the tool demonstrably accelerates workflows at this level, the commercial case is self-evident.

Market Wedge Rationale

The initial target is aerospace and automotive OEMs and their Tier 1 suppliers — organisations that run large numbers of non-linear or contact-heavy FEA models and are already investing heavily in simulation. The wedge is not a new solver; it is a productivity tool that sits alongside existing validated solvers (CalculiX, Abaqus, Nastran) and reduces the time and expertise required to produce an accurate mesh.

Crucially, the tool does not compete with existing solvers — it interoperates with them. The commercial FEA solver market is saturated and dominated by entrenched vendors (Ansys, Dassault, Siemens). Entering that market as a new solver would require displacing decades of validated workflows, certification history, and institutional familiarity. FEA Sidekick instead wraps around the solver the engineer already uses, requiring no change to the validated simulation chain. This dramatically lowers the barrier to adoption inside large organisations where procurement, IT security, and validation processes make introducing new solvers slow and costly.

This positioning also means the sales conversation is with simulation teams and CAE managers, not with IT procurement or C-suite — shortening the sales cycle for early contracts.

Product Philosophy: Engineer First

FEA Sidekick is explicitly engineer first, not AI first. The engineer defines and owns the model; the sidekick improves what the engineer has created and accelerates the simulation — it does not generate models autonomously or replace engineering judgement.

This distinction is not cosmetic. In regulated industries, the engineer is accountable for the simulation and its conclusions. Any tool that positions AI as the primary author of a model creates an accountability gap that safety and certification processes cannot tolerate. By contrast, a tool that helps an engineer produce a better mesh, catch errors earlier, or reduce iteration time fits naturally into existing review and sign-off workflows.

The practical implication is that every output from FEA Sidekick must be interpretable and auditable: refinement recommendations should be traceable to specific model features (load introduction points, contact interfaces, material boundaries), not to opaque model weights. This is a design constraint, not a limitation.

Long-Term Vision: Physics-Informed LLM Integration

The long-term product includes an LLM integration via MCP (Model Context Protocol), enabling conversational interaction with the pre-processor. An engineer would be able to describe intended changes to model definition — mesh density, boundary condition placement, contact definitions — in natural language, and have those changes applied directly.

However, this must be driven by a physics-informed backbone, not a bare LLM. Large language models operate on token probability rather than physical reasoning; they have no inherent understanding of stress concentrations, convergence behaviour, or load paths. A bare LLM integration would require engineers to write precise, lengthy technical descriptions to constrain the output — and even then, misinterpretation could produce models with silent, major errors: wrong boundary conditions, incorrect material assignments, or mesh that is refined in the wrong regions.

The physics-informed backbone solves this: the LLM handles the natural language interface while the underlying model graph (mesh connectivity, semantic model features, load paths) constrains what changes are physically and mechanically valid. The engineer speaks naturally; the backbone enforces correctness.

This architecture also directly addresses a known failure mode of current AI coding and modelling assistants when applied to FEA: the generation of syntactically valid but physically nonsensical input decks. The experience of encountering this failure mode in practice is part of the foundation for this design decision.

Credibility for Pre-Seed

The combination of automotive production experience, active aerospace FEA research at Cranfield, and working relationships with GE Aerospace and Airbus provides the three signals early investors look for in deep tech:

1. Domain expertise — the founder understands the problem at a practitioner level.
2. Access — existing relationships with target customers reduce the cold-start problem.
3. Timing — the convergence of GNN-based mesh learning, open-source solver ecosystems, and rising compute costs makes this the right moment for the product.

Next Steps

These must be completed in order. Steps 1–3 are prerequisites for any development work.

1. Read the employment contract IP clause — confirm whether FEA-related work developed in personal time with personal resources is assigned to Cranfield. This determines whether an external company or a university spinout is the correct vehicle.
2. Consult an immigration solicitor — confirm that the Global Talent Visa permits company directorship. This is likely, but needs written confirmation before registering anything.
3. Meet with Cranfield’s Technology Transfer Office — they handle exactly this situation. If the work is adjacent to existing research, a spinout route may be cleaner than an external company and removes the IP ambiguity. Obtain a written NoC before any development begins.
4. Initiate customer discovery — contact simulation leads at GE Aerospace and Airbus through existing Cranfield relationships. The goal is not to pitch; it is to produce concrete, quotable evidence of the pain point: what does a typical meshing cycle cost in engineer-hours, how often do mesh quality issues cause re-runs, and what would a 30% reduction in that cycle be worth. This evidence is the single most important thing to have before the pre-seed raise.
5. Define and lock the demo benchmark — choose the specific WAAM geometry, BCs, and success metrics before writing any code. See the PoC plan for the benchmark definition. The demo problem should be chosen in consultation with at least one industry contact from step 4 so that the benchmark is recognisable as real to the target audience.