India has one of the largest software industries in the world and comparatively little capability in the software engineering depends on. That gap is real, it has understandable causes, and it is the reason we work where we do.
The shape of the Indian software industry
The industry grew around delivering business software at scale for global clients — enterprise systems, applications, integrations, maintenance. That is genuinely valuable work, and the operating model that makes it succeed is specific:
- Staffing flexibility — teams scaled up and down against demand.
- Process standardisation — so quality does not depend on individuals.
- Throughput — features delivered per sprint as the measure.
- Breadth over depth — engineers who can work across many domains.
Foundational engineering software rewards nearly the opposite of all four. It needs small stable teams, deep domain knowledge accumulated over years, correctness verified rather than demonstrated, and depth in one narrow field. An industry optimised for the first list does not accidentally produce the second.
What this means for buyers
An Indian manufacturer, machine builder or engineering firm with a genuinely hard software problem has limited options:
- Commercial software — capable, but licensed on terms that may not fit, and not extensible where you need it.
- Global specialists — expensive, and often uninterested in projects below a certain size.
- A local IT firm — willing, and frequently not equipped for the specific discipline.
- Build in-house — requires hiring people who are scarce and expensive.
The most common outcome we see is the fourth option abandoned and the first accepted — a company working around software limitations for years because there was nowhere to take the problem.
Why the gap persists
The feedback loop is slow
You cannot tell whether a solver is correct by looking at it. Building capability means building verification discipline, which takes years and produces nothing demonstrable early. That is difficult to justify inside a business measured quarterly.
Domain knowledge cannot be hired quickly
Understanding machining, aerodynamics or geometric modelling well enough to build software for it takes years of exposure. It cannot be added to a team by recruiting for a keyword.
The market is small and hard to reach
The buyers exist but are dispersed — a machine builder here, a design software startup there. That is not a market you address with a sales team; it is one you reach by being findable when someone searches for a specific problem.
It is not glamorous
Most of this work is tolerance handling, degenerate cases and verification. It attracts people who find that satisfying, and there are not many of them anywhere.
Why we chose it anyway
Three reasons, stated plainly:
- The problems are genuinely interesting. Robustness, numerics and real-time constraints are the kind of engineering that rewards care, which is the kind we want to do.
- There is very little competition for it locally. A firm willing to do slow, verification-driven work has few rivals, because the work is unattractive to organisations optimised for throughput.
- It raises the standard of everything else. The discipline a solver demands does not switch off when we build a business application — and clients on ordinary projects benefit from it.
The third reason is the one that matters commercially. Most of our work is still websites, applications and business systems. The engineering work is not a separate business — it is where the standard comes from. A team accustomed to proving correctness writes better ordinary software too.
What we would tell a buyer
If you have one of these problems, the important thing is not that we exist. It is that you evaluate anyone — including us — on the right criteria:
- Ask how they would prove the software is correct, and listen for methodology.
- Ask what happens on degenerate input.
- Ask what they have not done before.
- Ask when they would tell you to licence commercial software instead.
- Ask which named engineers would do the work.
A partner who answers those well is worth talking to regardless of where they are. One who cannot is worth avoiding regardless of size or reputation.
Have an engineering software problem with nowhere obvious to take it? Describe it in your own terms. See our services, what foundational software means, and the buyer's guide.