The Story of InStandart: Why We Only Do CAD Automation

Most company stories are lists of things added. This one is about what we removed – and what removing it cost. The short version: InStandart was founded in 2014 as a general s...

The Story of InStandart: Why We Only Do CAD Automation

Most company stories are lists of things added. This one is about what we removed – and what removing it cost.

The short version: InStandart was founded in 2014 as a general software company. Over the following decade we grew the way software companies grow – bespoke development, e-commerce, managed services, dedicated teams, analytics. In 2026 we stopped offering almost all of it. We now do one thing: automation for the engineering workflows that off-the-shelf CAD software doesn’t cover.

About Us covers what that looks like in practice – the platforms, the products, the industries, the people. This page is about the other half of the decision: why only this, and what it took.

What we stopped

We don’t take on new work outside CAD and BIM automation. Not bespoke software, not e-commerce, not team augmentation, not analytics – regardless of whether we could do it well.

Existing commitments are a different matter. Some engagements from the earlier lines are still running, and we see them through, because that is what a commitment is. But nothing new is added outside the focus, and the service pages for those lines have been taken down rather than left up to collect enquiries we intend to decline.

What it cost

This is the part that usually gets left out of positioning statements, so here it is.

Turning down work we’re good at. The hard no isn’t to the project you’d botch. It’s to the one you’d deliver well, for a client you’d like, at a price that works. Those arrive regularly. We decline them.

Losing the diversification that makes a pipeline feel safe. Several service lines meant several sources of demand, moving independently of each other. One focus means one market’s weather. If demand for CAD automation softens, there is no second leg to stand on. We knew that and took the trade.

Writing off capability that took years to build. Competence in e-commerce or general application development doesn’t transfer to formwork optimisation or Plant 3D SDK work. A meaningful part of what this company spent a decade learning is simply no longer in use.

Accepting a narrower ceiling on what we can say yes to. A generalist can follow a client wherever they go next. We can’t. When a good client needs something adjacent to our focus, we refer it out rather than stretch to cover it.

Why we did it anyway

Because the competence we sell can’t be bought quickly or hired reliably, and it only compounds if you concentrate.

CAD automation sits at the intersection of three skill sets that rarely coexist in one person: platform APIs (AutoCAD, Revit, Plant 3D SDK, AVEVA PML), engineering domain knowledge (formwork systems, piping design, structural calculation, plant workflows), and enterprise integration (SAP, Oracle). A developer with the first is straightforward to find. One with all three is close to unhireable – that combination has to be built over years, inside real projects, and it decays if it isn’t used.

A team that does five things adequately builds that combination in none of them. The only way to have solved a client’s specific problem several times before is to have spent years turning down the problems that weren’t it.

That’s the entire argument. It isn’t a claim about being better than anyone. It’s an observation about where this particular kind of expertise comes from, and what you have to give up to accumulate it.

What it means if you’re the one reading this

Two practical consequences, and they cut both ways.

If your problem sits inside the focus – a calculation redone from scratch every project, a Bill of Materials retyped between CAD and ERP, clashes tracked in a spreadsheet, drawing data that has to reach procurement – the odds are we have built something close to it already. The conversation starts from known patterns rather than from a blank page, and that is most of the difference between a three-month project and a nine-month one.

If it doesn’t, we will say so on the first call instead of scoping it. That isn’t modesty. It’s the same decision as the one above, applied to your project instead of to our service list.

Share this post:

Not sure whether your problem is in the focus?

Book a 30-minute call. Bring the workflow that costs your engineers the most time and the platform it runs on. You'll leave with a straight answer about whether it's something we've built before, something we'd be building for the first time, or something you shouldn't automate at all – and if it's the last one, that's where the call ends.