The distinction that matters
Ask one question about your project: would a wrong answer be obvious? If yes, most competent development teams can build it well. If a wrong answer would look entirely plausible, you need a different kind of team — and the difference is practice, not talent.
This is not a criticism of web and app agencies. It is an explanation of why a particular category of software sits outside what their practice is built to handle, and how to tell which category you are in.
Why agency practice works — and where it stops
Good agency process is genuinely effective. It is built on a reasonable assumption: that software defects are observable.
| Agency practice | Assumes | Holds for engineering software? |
|---|---|---|
| QA by testing behaviour | Bugs are visible | No |
| User feedback loops | Users notice problems | No — they cannot judge |
| Rapid iteration | Fast feedback exists | No — feedback is slow |
| Staffing flexibility | Knowledge is transferable quickly | No — domain depth takes years |
| Feature-based estimation | Effort scales with features | No — it scales with edge cases |
Every one of those assumptions is reasonable for application software and false for numerical and geometric software. The result is not incompetence — it is a well-run process applied where its foundations do not hold, producing software that passes QA and cannot be trusted.
What the different practice looks like
- Correctness proven, not observed. Manufactured solutions, order-of-accuracy verification, benchmark validation with documented error metrics.
- Degenerate cases as the design target. Tangency, slivers, singularities and shocks planned for from the start, not patched later.
- Fuzz testing near degeneracy. Perturbing input by nanometres, because clean tests prove nothing.
- Stable small teams. Domain knowledge lives in people and cannot be staffed flexibly.
- Slow, deliberate iteration. Some defects only appear under mesh refinement or on specific geometry classes.
- Regression suites that assert numerical results, not just that the program ran.
Telling which category your project is in
Any good team can build
- Web and mobile applications
- Dashboards and reporting
- Integrations and data pipelines
- Licensing, accounts, deployment
- Most user interfaces
Needs a different practice
- Geometry kernels and modelling
- Numerical solvers
- Toolpath generation
- Real-time motion control
- Physics engines and simulation cores
- Storage engines
Most engineering products need both columns. The mistake is assuming one team's process covers both — or that the right-hand column is just the left-hand column with harder maths.
How to split the work sensibly
The domain-critical part is usually a minority of the codebase and the entirety of the risk. That suggests a specific allocation:
- Identify the correctness-critical components — where a wrong answer would not be obvious.
- Give those to a team whose practice is built around proving correctness.
- Give the surrounding infrastructure to whoever is cost-effective — web, mobile, integrations, deployment.
- Define the boundary precisely — data formats, units, coordinate conventions, error behaviour. This is where multi-vendor products fail.
- Make one party accountable for the boundary, or nobody will be.
The boundary is the most common failure point in split projects. The solver is correct, the application is polished, and they disagree about units or about whether a long computation may block the interface. Both parties consider it the other's responsibility. Name an owner in the contract.
Questions that reveal which practice a team has
- "How would you prove this is correct?" — methodology, or a description of QA.
- "What happens on degenerate input?" — specifics, or reassurance.
- "How would you estimate this?" — by edge cases and verification effort, or by feature count.
- "Who specifically would write it?" — named engineers, or a resourcing answer.
- "When would you tell us to buy instead of build?" — named conditions, or none.
You do not need to be technical to evaluate the answers. You are listening for whether correctness is treated as something to be established, or as something that follows from testing the interface.
Where we sit, plainly
We build both columns — most of our work is still websites, applications and business systems. The reason we say so rather than positioning purely as specialists is that pretending otherwise would fail the same honesty test this article applies to everyone else. What we would claim is narrower: the engineering work sets the standard, and we will tell you when your project only needs the left-hand column.
Not sure which category your project falls into? Describe what a wrong answer would look like — that usually settles it in one exchange. See our services, what foundational software means, and the buyer's guide.