Buying engineering software development is unlike buying a web application, and the difference is not complexity — it is verifiability. A booking system either books or it does not. A CFD solver produces numbers that look entirely reasonable whether or not they are correct.
This guide is for product and engineering leads commissioning CAD, CAM, CFD, or simulation software from an external partner.
Why the usual evaluation fails
| Normal software | Engineering software |
|---|---|
| Bugs are visible in behaviour | Bugs produce plausible wrong numbers |
| Users report problems | Users may never know |
| Portfolio screenshots are informative | Screenshots prove almost nothing |
| Testing = does it do the thing | Testing = is the maths right |
| Wrong output annoys | Wrong output scraps parts or misinforms design |
Anyone can produce a colourful contour plot. The question is whether the numbers behind it would survive a design review.
The questions that separate partners
1. "How will you prove this is correct?"
The answer you want references specific practice: method of manufactured solutions to confirm observed order of accuracy, comparison against analytical solutions, validation against published benchmarks or experimental data, with documented error metrics.
The answer that should worry you is "we'll test it thoroughly" with no methodology named.
2. "What are the validation cases, and what is the acceptance criterion?"
These should be agreed before development starts and written into the contract. Deciding what "correct" means after delivery is how disputes begin.
3. "Show me error convergence from previous work"
For numerical software, a plot showing error decreasing at the expected rate under mesh refinement is the single most informative artefact a partner can show. It demonstrates they actually verify rather than assert.
4. "What happens on degenerate input?"
For geometric software especially: tangent faces, near-zero-area slivers, imported files with gaps. A partner who has built geometry kernels will discuss tolerance models and exact predicates. One who has not will say "we'll handle edge cases."
5. "How will you demonstrate parallel scaling?"
For HPC work, strong and weak scaling measured on your hardware — not a claim about theoretical efficiency.
6. "Who else understands this code?"
Numerical software concentrates knowledge dangerously. Ask about documentation and whether at least two engineers can maintain it.
The strongest single filter: ask a partner to explain, in plain language, how they would prove the software is correct. Genuine engineering teams answer this fluently because it is the core of their work. Generalist shops struggle, because in ordinary software correctness is judged by observing behaviour.
Scoping it properly
- State the governing physics or geometry precisely. Equations, assumptions, ranges. Ambiguity here becomes cost later.
- Define the input and output formats — mesh types, CAD formats, result files. Interop is real work.
- Specify the target hardware. Workstation, cluster, embedded, browser. It changes the architecture.
- Agree validation cases with tolerances. This is your acceptance test.
- Decide the performance requirement in measurable terms, on named hardware.
- Separate research from engineering. If part of the work is genuinely uncertain, contract it as a time-boxed study, not a fixed deliverable.
That last point prevents most disputes. Engineering software often contains genuine unknowns. Pretending they are fixed-scope leads to either a padded quote or a failed project. A short paid feasibility study that produces a benchmark and a recommendation de-risks the main engagement enormously.
Contract terms that matter here
- Full IP assignment on final payment, covering source, build scripts and documentation.
- Validation evidence as a deliverable, not a claim — reports with error metrics.
- Documented numerical methods and assumptions, so results can be defended later.
- Your repository from day one, so you always hold the current state.
- Knowledge-transfer milestone with your engineers, before final payment.
- Third-party licence inventory — critical if you will ship the software commercially.
Why India, and what to check
India has enormous software capacity and comparatively little CAx and numerical-software capability — most firms are staffed for enterprise IT and web work. That means cost advantages are real, but so is the risk of engaging a team that has never built a solver or a kernel.
The due diligence that matters is therefore not about geography but about evidence: can they explain verification practice, show convergence results, discuss tolerance models, and name the failure modes of the specific domain? Those questions filter far more effectively than company size or years in business.
Realistic engagement shapes
| Shape | Best for | Watch for |
|---|---|---|
| Feasibility study (time-boxed) | Uncertain requirements | Ensure it ends with a decision, not a document |
| Fixed-scope module | Well-defined component | Scope must genuinely be well-defined |
| Dedicated team | Long programmes | Continuity and knowledge retention |
| Productionising research code | Working scripts needing rigour | Agree what behaviour must be preserved exactly |
Commissioning CAD, CAM, CFD or simulation software and want the scope and validation defined properly before you commit? Tell us what you are building. See our engineering services.