Honest framing
The cost advantage is real. The capability is much rarer than the marketing suggests — India has enormous IT capacity and comparatively little CAx and numerical software depth. The entire risk in this decision is partner selection, not geography.
We are an Indian engineering studio writing about outsourcing to India, so read this with appropriate scepticism. We have tried to write the version we would want if we were the buyer.
Why firms look offshore for this work
- Cost. Engineering rates in India are substantially below US and Western European equivalents, and for multi-year software programmes that difference is material.
- Scarcity at home. Engineers who can write a geometry kernel or a CFD solver are rare everywhere. Firms often cannot hire them locally at any price.
- Programme shape. Foundational software is often a defined project rather than an ongoing need, which suits an external team better than a permanent hire.
- Timezone for Europe. Working hours overlap usefully with EU teams.
The risk nobody states plainly
Most Indian software firms cannot do this work, and some will accept it anyway. The industry is structured around enterprise IT, web and mobile delivery — optimised for throughput and feature velocity. Numerical and geometric software needs the opposite: slow, verification-driven engineering by people with domain knowledge. A firm that staffs your solver project with capable generalists will produce something that runs and cannot be trusted.
This is the failure mode to design your evaluation around. Not fraud — genuine effort producing plausible, unverified output.
Due diligence that actually discriminates
Standard vendor evaluation — company size, years in business, client logos — tells you almost nothing here. These questions do:
- "How will you prove this is correct?" Listen for specific methodology: manufactured solutions, benchmark validation, convergence studies, fuzz testing against degenerate geometry. Vagueness here is disqualifying.
- "Show me error convergence from previous work." A plot of error decreasing at the expected rate under refinement is the single most informative artefact a numerical software team can produce.
- "What happens on degenerate input?" For geometry work, a capable team discusses tolerance models and exact predicates unprompted.
- "Who specifically will write this, and what have they built?" Ask about the individuals, not the company. This work is done by people, and the named engineers matter.
- "What would make you tell us not to build this?" A partner who cannot name conditions under which you should licence commercial software instead is selling rather than advising.
Ask any partner to explain how they prove correctness. Teams who build foundational software answer fluently because it is the core of the job. Teams who do not, describe testing the user interface.
What travels well and what does not
| Work type | Suits offshore? | Why |
|---|---|---|
| Well-specified solver or kernel module | Yes | Clear acceptance criteria; verifiable |
| Productionising research code | Yes | Behaviour to preserve is defined |
| Post-processor development | Partly | Needs access to the physical machine |
| Exploratory R&D | Harder | Needs tight iteration with domain experts |
| Export-controlled work | Often no | May be legally impermissible |
| Work needing shop-floor commissioning | Partly | Requires on-site presence somewhere |
Check export control before scoping, not after. Defence, aerospace and some dual-use engineering software carries restrictions on who may access the technical data. This can rule out offshore development entirely, and finding out late is expensive. Involve your compliance function early.
Structuring the engagement
- Start with a paid feasibility study. Time-boxed, ending in a benchmark and a recommendation. It costs little and reveals capability far better than any interview.
- Agree validation cases and acceptance criteria before development. This is your contractual definition of "correct".
- Own the repository from day one. Not delivered at the end — pushed to your infrastructure continuously.
- Milestone payments tied to verifiable deliverables, including validation evidence.
- Insist on a knowledge-transfer milestone before final payment. Numerical software concentrates knowledge dangerously.
- Written IP assignment covering source, build scripts and documentation.
Signals of a serious partner
- They ask about your governing equations, mesh types or geometry classes before quoting.
- They propose a feasibility phase rather than a fixed price for uncertain work.
- They discuss verification unprompted.
- They tell you when commercial software would serve you better.
- They name the engineers who will do the work.
- They are specific about what they have not done before.
That last one is worth weighting heavily. In a field this specialised, a partner who claims experience across every discipline is describing a sales position rather than a team.
Evaluating partners for engineering software work? Tell us what you are building — and ask us the questions above. See the full buyer's guide and our engineering services.