The core argument
In ordinary software, a specification is mostly sufficient — the developer builds what it says and you can see whether it works. In engineering software, the specification is always incomplete, and the gaps can only be filled by someone who understands the domain. That is why generic teams produce output that runs and cannot be trusted.
This is not an argument that domain specialists are better engineers. It is an argument that engineering software has a property ordinary software does not, and that property changes what you need from a team.
Why specifications are always incomplete here
Write a specification for a booking system and a competent developer can build it. Write one for a CAD boolean operation and you will have described the intended behaviour, not the hundred degenerate cases that determine whether it works.
| The spec says | The spec cannot say |
|---|---|
| "Subtract solid B from solid A" | What to do when faces are tangent |
| "Generate a roughing toolpath" | What engagement angle protects tool life |
| "Solve the flow field" | Which turbulence model suits this regime |
| "Control the axis to position" | What following error indicates a crash |
| "Fit a surface to these points" | How much smoothing before detail is lost |
Every one of those gaps gets filled by someone. The only question is whether they fill it with knowledge or with a guess — and a guess produces software that runs.
The failure mode is silence
This is what makes the risk unusual. A generic team does not fail loudly. They deliver working software that produces plausible output. The boolean succeeds and yields subtly invalid topology. The solver converges to a wrong answer. The toolpath is geometrically valid and destroys tool life. Nobody reports a bug, because nothing looks broken.
In ordinary software your users are your test suite. In engineering software they are not — they cannot tell a right number from a wrong one by looking, which is the entire reason they commissioned the software.
What domain knowledge actually contributes
- Knowing which cases matter. Someone who has worked with CAD geometry knows that tangency and slivers are common, not exotic — and tests for them from the start.
- Recognising a wrong answer. The ability to look at output and think "that pressure distribution is not physical" is what catches errors before customers do.
- Knowing what to verify against. Which benchmarks are meaningful for which physics, and what accuracy is achievable.
- Spotting an incomplete specification. Asking "what should happen when the tool cannot reach?" before writing code, rather than discovering it in production.
- Judging when to stop. Knowing that a general kernel is not needed, or that commercial software would serve better — advice a team without domain grounding cannot give.
Where generic teams genuinely do fine
It would be dishonest to overstate this. A great deal of software around an engineering product does not need domain depth:
- The web application, licensing backend and user management.
- Data pipelines, reporting and dashboards.
- Integrations with ERP, PDM or CRM systems.
- Installers, update mechanisms and deployment.
- Most of the user interface, once behaviour is specified.
The domain-critical part is usually a minority of the codebase — and the entirety of the risk. Recognising which is which is how you allocate a budget sensibly.
How to test for it
Ask about failure modes, not capabilities. "Can you build a CAD kernel?" invites a yes. "What goes wrong when a boolean meets tangent faces?" cannot be answered without exposure. The second question is far more informative and takes thirty seconds.
Questions that discriminate:
- "What are the common failure modes in this kind of software?"
- "How would you prove the output is correct?"
- "What would you need from our engineers that we have not offered?"
- "What part of this are you least confident about?"
- "When would you tell us not to build this?"
That last pair matters most. A partner who names their uncertainty and names conditions for walking away is describing genuine engagement with the problem. Uniform confidence across every question is a sales posture.
What this means for how you engage
- Expect to supply domain expertise. Even a specialist partner needs your practitioners — your machining rules, your validation data, your operating conditions.
- Split the work deliberately. Domain-critical components to specialists; surrounding infrastructure wherever is cost-effective.
- Insist on verification evidence as a deliverable, because it is the only protection against silent wrongness.
- Start with a small piece that reveals whether the understanding is real, before committing to the whole.
Weighing a partner for engineering software? Ask us the questions above — including what we are least confident about. See our services and the CAx buyer's guide.