.png)
If you build engineering software, you've had this conversation:
Customer: Does your tool integrate with [Excel/ETABS/Revit/etc.]?
You: We have an API.
Customer: ...
The honest version of the answer is usually: "Sort of, if your team has someone with the developer skills to wire it up, and you're willing to maintain that wiring, and your team's specific use case happens to match what our API was designed for."
For most engineering customers, that's not really yes.
This post is about a model for fixing that — without you having to build bilateral integrations against every other tool in your customers' stacks.
The bilateral-integration trap
The default model for software-to-software integration in engineering is bilateral. Tool A and Tool B agree they want to work together. One of them (usually whoever has the smaller engineering team) builds a plugin or connector. It works for the version of Tool A and Tool B that exist when it's built. Both products evolve. The connector ages. Eventually it breaks, gets quietly deprecated, or the customers who relied on it migrate.
Repeat this for every pair of tools in a customer's workflow. The effort scales as N×N — every new tool that joins the mix increases the integration burden quadratically. By the time a customer has six tools, twenty bilateral integrations are theoretically possible and maybe four exist in practice.
This is why your customers' workflows are still held together with Python scripts and copy-paste.
It's also why most software vendors quietly accept that "integration" is a marketing answer rather than a real one. The economics don't justify building twenty bilateral connectors. So you build one or two with the biggest neighbours, ship a generic API for everything else, and tell customers their developers can wire up the rest.
The platform-mediated alternative
A different model has been emerging over the last few years. Instead of N×N bilateral integrations, tools plug into a shared platform layer. The platform handles the connective work — data routing, type translation, units, change propagation, dependency tracking — and your tool gets to be a clean node in customers' workflows without you having to know about every other tool they use.
This is what CalcTree is becoming for engineering calculations. ETABS and Excel are connected at launch, with several more tools in pilot. Customers wire up workflows that move data between them, with the connection layer doing the heavy lifting.
For software vendors, the model is straightforward: build one integration with the platform, get usable connectivity to everything else the platform connects to. Maintenance is one connector, not twenty.
What a partnership looks like
Practically, integrating with CalcTree as a partner involves four things.
1. A defined integration surface. We document what data your tool can expose to CalcTree, what data it can receive, and what type/unit conventions apply. For most software this is a relatively small surface — the parameters and outputs that matter for engineering calcs, not your full internal data model.
2. A native runtime hookup. Most engineering software is desktop-resident. The CalcTree desktop app provides the runtime that hosts the connection. Your tool either runs alongside the desktop app, exposes a local API the desktop app can call, or vice versa. We provide the SDK and reference implementations.
3. Joint go-to-market. Your tool gets featured in CalcTree's connection-node directory. Customers searching for "how does X work with Y" find your integration. Both companies amplify the launch.
4. Optional revenue share. For tools where customers are paying for premium features that the integration enables, we can structure a revenue share. For tools where the integration is a competitive feature you'd build anyway, there's no charge — the partnership is value-aligned without commercial terms.
What partners get out of it
Three things, in rough order of size.
Distribution through workflow templates. This is the bit most vendors don't expect. CalcTree workflows save as templates that customers share with their teams and across their firms. Every template that incorporates your tool exposes it to engineers who didn't necessarily know they needed it. Your tool gets distribution inside every workflow that depends on it. The acquisition cost on those leads is essentially zero for you.
Stickiness. Customers using your tool inside an integrated workflow churn less than customers using it standalone. Your tool becomes part of their workflow rather than a destination they have to choose to use.
A maintenance partner. When CalcTree adds support for a new neighbouring tool, your customers get that connectivity for free. You didn't have to build it. You're not on the hook to maintain it.
What we don't do
Worth being explicit about, because some "platform partnership" pitches conflate things they shouldn't.
- We don't compete with you. We're not building Excel. We're not building ETABS. We're not building Revit. CalcTree is for engineering calculations and the connections around them, full stop.
- We don't take your customers. Your users in CalcTree workflows are still your users. Your branding, your account ownership, your renewal motion — all yours.
- We don't train on your data. Customer data passing through CalcTree's connection layer is workspace-scoped and not used for any training. Same policy as Knowledge Base.
- We don't lock you in. Standard exit terms. If the partnership stops working, customers can migrate off without us as a chokepoint.
Who this fits
The model fits software vendors who:
- Build engineering software (broadly — design, analysis, modelling, calculation, drawing, project management)
- Have customers whose workflows touch other engineering tools
- Are willing to commit to a single, well-maintained integration with CalcTree rather than ten half-finished bilateral ones
- Want to be a clean node in their customers' connected stack rather than an island
It doesn't fit everyone. If your tool is general-purpose, your audience is broader than engineering, or your strategic position depends on being a workflow island — there are better partners for you than us.
How to start the conversation
If any of this is interesting, the right next step is small. A 30-minute call to look at your tool's existing integration surface, talk about what your customers are asking for, and figure out whether a pilot makes sense. No commitment beyond the call.
