There's a measurement that ought to be more famous than it is.
By CalcTree's own count, and we built a company around this number, engineers spend something like 40% of their working week searching through past projects, rebuilding calculations, and moving data between tools that don't talk to each other.
Forty percent. Of every project. Of every engineer.
If a piece of physical equipment in your office wasted 40% of its capacity on plumbing between other equipment, you'd replace it the same week. Engineers have been doing it for thirty years.
This post is about why, and about what's finally starting to change.
How we got here
Engineering software hasn't always been like this. In the early days, the 1980s and 90s, most engineering work happened inside one or two big monolithic packages. AutoCAD did your drawings. Excel did your calcs. Mathcad did your reports. The integrations were trivial because there wasn't much to integrate.
The unbundling started in the late 90s and accelerated through the 2010s. Each engineering discipline got specialised tools that were dramatically better than the monoliths at one specific job: Grasshopper for parametric geometry, ETABS for structural analysis, Revit for BIM, Plaxis for geotechnical, Bluebeam for markups, and dozens of others. Each tool was a step forward.
The catch was that nobody was responsible for what happened between them.
Your geometry lives in one tool. Your loads live in a second. Your structural calcs live in a third. Your reports live in a fourth. Your project documentation lives in a fifth. The "integration" is you, an engineer, opening a tool, exporting a CSV, importing it somewhere else, and doing it again every time something changes upstream.
Software vendors had little incentive to fix this. Each one was busy being best-in-class at its own job. Helping competitors' tools work better with theirs was, at best, a low priority. Often it was an explicit anti-priority.
So the integration burden landed on engineers, where it has stayed.
What engineers have tried
Worth running through the workarounds, because they're the reason the problem feels intractable.
Manual export/import. The default. Run an analysis in ETABS, export results, open Excel, paste, run calcs, export again, paste into Word. It works. It falls apart the moment something upstream changes, because every change requires re-running the whole pipeline by hand. The error rate over a project is non-trivial.
Custom Python scripts. A senior engineer with coding skills writes a script that pulls from Tool A and pushes to Tool B. It works for that team, that project, that combination of tool versions. It stops working when anything changes: Tool A updates its API, Tool B updates its export format, or the senior engineer leaves the firm. Most engineering teams have a graveyard of these.
Vendor APIs and SDKs. Officially supported but rarely used. Engineers aren't software developers. Writing against a SOAP API or learning a new SDK isn't time well spent when the deadline is Friday.
File-based exchange formats. IFC for BIM, STEP for geometry, IGES for older CAD. These work for what they were designed for, usually structural geometry handoff, but they're snapshots, not live connections, and they only cover a narrow band of what engineers actually need to share.
Vendor-bundled integrations. Sometimes Tool A's vendor builds a plugin into Tool B because both are owned by the same parent company. Sometimes useful. Usually limited to the specific bundling the vendor chose to support, which is rarely the bundling you actually need.
No-code automation tools (Zapier, Make). Mostly aimed at SaaS-to-SaaS workflows. They don't reach into desktop engineering software in any real way.
The pattern is consistent. Every workaround is either narrow (works for one specific case), brittle (breaks when anything changes), or technical (requires skills engineers don't have time to maintain).
What's actually changing now
Four things are shifting in 2026 that didn't used to be true.
Cloud-resident hubs. A new generation of engineering tools, including ours, is built cloud-first, which means they're designed from day one to be the place data passes through, not just the place data lives. The integration surface is the product, not an afterthought.
Programmable connection layers. No-code and low-code tooling has become genuinely good. Engineers can wire up data flows without writing scripts, and the wiring stays stable across version updates of the underlying tools. The "junior engineer with a senior's Python script that nobody understands" pattern is finally getting a viable alternative.
AI-assisted integration. Schema-matching, type translation, unit conversion, dependency tracking: the bits of integration work that used to require manual tweaking are increasingly automatable. The engineer states what they want connected, and the tool figures out how.
Workflows as portable artefacts. This is the one that compounds. Once tools talk to each other, the natural next step is making the workflows themselves transferable. The connection graph an engineer wires up, pulling data from Tool A, running a calc, writing back to Tool B, becomes saveable, versionable, and shareable. Your firm's clever processes stop being held in one engineer's head. They become documented templates that survive turnover, tool updates, and reorganisation.
Together, these add up to a different model. Tools stay best-in-class at their own jobs. The integration burden moves off the engineer's shoulders and onto a layer that's actually responsible for it. And the workflow itself, what used to be lost when the senior engineer changed jobs, becomes a firm asset.
This is the direction we're building toward at CalcTree, and we're now deploying the first version of it with enterprise teams. (More on that across the rest of this series.)
What this means for the next few years
If you're a practising engineer, the practical question is which of your current workflows would benefit from being live-connected rather than manually shuffled. Usually it's the loops you run most often: design checks, scenario comparison, code-compliance iteration. Anywhere "I need to change one thing and see what happens" turns into a 20-minute manual update across three tools.
If you run engineering operations at a firm, the practical question is whether the integration burden across your team is a tax worth paying. Most firms don't measure it. The ones that do find it's larger than they expected, usually a meaningful fraction of total billable hours, depending on the discipline. The follow-on question is whether the firm's best workflows are captured anywhere, or whether they evaporate every time a senior engineer leaves.
If you build engineering software, the practical question is what your integration story is, because by the late 2020s "we don't really play with other tools" is going to read the way "we don't have a mobile app" read in 2015.
The "best individual tool" era of engineering software ran from roughly 2000 to 2020. The "best connected tool" era is starting now.
If you'd like to see what a connected workflow looks like inside your own firm's stack, book a call with our team. We're deploying this with enterprise teams now.
