What Cascadia Is Built To Do (And What It Isn't)

I want to write about Cascadia PLM’s AI-assisted Design Engine workflow, because it's exciting, and “AI for hardware” is all the rage right now, but I have to establish some context first. What are the choices I've made in designing Cascadia that makes the Design Engine possible, in its current state and direction, and how those choices provide both distinct advantages and disadvantages. All of this informs what's possible with Cascadia (and the Design Engine), and how Cascadia positions itself in the market.

Every PLM (every enterprise software!) is built on a series of bets about what to prioritize and what to ignore or postpone. The established PLM gameplan is to bet on flexibility. Be configurable enough to serve any industry, any size, any workflow, and you can sell to anyone. And the big monsters (Siemens, PTC, Dassault) won that game (though I might argue they won in part despite that approach, instead of because of it, at least in some cases), but it's resulted in a class of software that's expensive to license, slow to deploy, and dependent on ongoing consulting engagements to stay healthy in any given environment.

Cascadia bets the other way. Pick a target audience, close to my heart, build for them specifically, and accept the constraints that come from that choice. So let’s lay out what those choices, advantages, and constraints actually are, because the Design Engine isn't a bolted-on AI feature. It's a direct consequence of a handful of foundational decisions, and without that context the workflow doesn’t have the same impact.

The Audience

Cascadia is built for small-to-mid-size discrete manufacturers doing high-mix/low-volume work: engineer-to-order shops, prototyping teams, custom equipment builders, that whole segment. And because I wanted something to support my own projects, I can attest to the fact that there’s also a real angle for hobbyists and personal use (remember, it’s free!).

Who we’re not built for: Cascadia is not built for process manufacturing (chemicals, food, pharma), not built for retail PLM use cases, and not optimized for the Fortune 500 enterprise customer with tens of thousands of users and every aspect of the software set in stone. You could probably make Cascadia work in some of those environments (it's open source, fork away) but the model wasn’t designed with those in mind.

That target informs every decision we’ll address below. Each one makes Cascadia worse for someone, and (I believe) much better for the people and teams it's built for.

The First Decision: Design-centric, not Part-centric

Most PLMs treat parts and documents as the atomic unit. That's the most flexible model (you can configure everything around the central “Part” concept) but it leaves the system without a natural container for "this project" or "this product."

Cascadia is Design-centric. A Design is the container; parts, documents, requirements, and so on belong to Designs. There are several categories of Designs — Engineering (your EBOM for a given project), Manufacturing (your MBOM), Family (family-of-assembly collections), and Library (standard parts collections).

This is what enables the entire git-inspired change management workflow we talked about last time (link). Branches need a clear scope to branch from, and Designs provide that scope.

However, if your work doesn't naturally decompose into something you can think of as Designs, Cascadia is going to feel awkward. For example, if you have one “thing” you design and manufacture, but you manufacture hundreds of thousands of that thing every year, then yes, you could track that as a Design in Cascadia, but the “overhead” of thinking of your single top-level-assembly, or individual part, or whatever it is as a “Design” and tracking all of your active changes as branches from that design feels unnecessary. In that case, Excel might still be your best bet.

The Second Decision: An Integrated Engineering+Manufacturing Platform

PLM grew out of PDM, simple data management for CAD, so it’s not a surprise the standard use of it stops with Engineering. It usually goes something like this: PLM handles your EBOM, MES or ERP handles your MBOM, you author your work instructions in Word or PowerPoint (maybe in your MES), and you pay two or three different teams of consultants and contractors to architect and implement the integrations between those systems. At the large enterprise scale that’s fine. The money’s there to burn, and anyway, entirely different organizations own the different stages, the systems are specialized for their domains, and integration teams are (hopefully) funded.

For HMLV/ETO at SMB scales, that separation can break companies. Most often, responsibilities are shared across engineering and manufacturing planning (sometimes they’re the same person). The same data feeds both silos.

We’ve built Cascadia to be an integrated engineering and manufacturing platform. EBOM and MBOM live in the same system, linked by traceability rather than separated by integration. Work instructions are first-class items, linkable to parts and BOM nodes. Work orders are directly in the system, with the same workflow management system as an engineering change order.

Additionally, we built in a Tools item type for manufacturing capabilities — what equipment you have, what materials it can work in, what tolerances it can hold. Right now, that data’s static, and (importantly for our next post) gives the AI-assisted Design Engine context to design for manufacturability with the user's actual equipment.

So skip the expensive software integration project to connect your workflows from engineering to manufacturing. Everything is together, on one platform, with one data model, already tightly coupled.

But the drawback is twofold: Cascadia isn't a full MES (and won’t be for a long time), and again, Cascadia is opinionated towards manufacturing organizations. If you need detailed shop floor execution, multi-site production scheduling, sophisticated scrap and rework tracking, real-time machine integration — the kind of thing companies eventually grow into and buy a dedicated MES for — Cascadia won't scale to that today. And if you just want PLM for engineering design, and someone else somewhere else will always be doing everything past the engineering handoff, then you’re getting a lot of stuff OOTB with Cascadia that you just don’t need.

But for the target audience, having everything in one place beats having best-of-breed in many places, until the company is big enough that the calculation flips.

The Third Decision: Code-First, Not Low-Code

The industry trend for the last decade has been toward low-code. Every modern enterprise platform pitches "configure without programming." The marketing argument is appealing; you don't need expensive developers, business analysts who cost half as much can do it, the system is more accessible.

The reality in PLM specifically has been less appealing. I've seen too many low-code configurations metastasize into unmaintainable bloat that no current employee can fully explain, with a consulting bill arriving every quarter to patch around the latest accumulated mess. The low-code abstraction layer doesn't actually eliminate complexity — it just hides it in a place where you need a specialist to access it, and that specialist works at the vendor or a consulting firm, not at your company.

Cascadia goes the other direction. The data model is in code. The (default) workflows are in code. The integrations are in code. There's no admin interface for adding a field to a part or changing how a form looks; you open your editor (or Claude Code in the root folder) and you make the change.

Two firm beliefs I hold provoking this approach:

First, any organization that genuinely needs a PLM should have a technical owner for it. Not necessarily a full-time developer, but someone who can read code, run tests, deploy changes, and own the platform's evolution. Companies that try to avoid this role consistently end up with PLM deployments that decay until they're abandoned or replaced.

Second, the technical-owner role has gotten dramatically lighter in the last eighteen months. With today’s AI-assisted coding tools, someone who knows the business and can read code (but couldn't have built the system from scratch) can effectively own a code-first platform. You still need that full-time technical owner, but that role can now be done an existing mechanical engineer or technically-inclined operations person who plays around with coding projects on their spare time at home.

There's a third aspect, too, come to think of it: a code-first data model is something AI can reason about natively and reliably. The Design Engine works using the same code the platform itself is built on, not against a custom abstraction layer called “configuration” by the software publisher. To be more concrete, while a LLM could reason about the low-code customizations any modern enterprise system might contain, it would have to do so by first consuming and holding in context all the structure, architecture, and boilerplate that allows that low-code customization to work in the first place, much of which might not even be publicly available information for it. Cascadia avoids that problem entirely.

So we natively get long-term maintainability, AI-assisted customization, no configuration drift, and full version control of every change to the platform.

And all it costs us is that Cascadia is not for organizations that want a pure no-code admin experience. If your manufacturing operations director needs to add a custom field to a part without at least opening up Codex, you're going to want a different platform. Honestly, though, this is the one decision that I think sacrifices the least; your manufacturing operations director probably shouldn’t be making changes directly to your PLM platform without some other involvement anyway.

A… Decision? CAD-Agnostic Architecture

The biggest PLM players are also the biggest CAD vendors. Siemens has NX and Solid Edge. Dassault has CATIA and SolidWorks. PTC has Creo. Their PLMs offer first-class integration with their own CAD systems, and that integration is one of the main reasons large customers stay with them at the top tier. Truly CAD-agnostic PLM platforms exist, but they’re relegated to Tier 2 or below precisely because they can't match the first-party integration depth.

Cascadia is CAD-agnostic, mainly because building your own CAD system is an even bigger undertaking than building your own PLM. Even building “first-party” CAD support requires resources an unfunded open-source project doesn't have. What we'll do instead is provide working integrations to the most common CAD applications for our audience (coming soon, expect Solidworks, Solid Edge, and Fusion 360 in the coming month, and Onshape to follow). But also, our target audience sometimes uses a mix of CAD tools — a small ETO shop might have five SolidWorks licenses in Engineering, and two Fusion 360 licenses in Manufacturing, or subcontract with an even smaller shop that only uses Solid Edge. The interoperability layer there is STEP files, so that’s what our expectation is for actually working with natively.

So for organizations whose entire value chain runs through one vendor's CAD ecosystem (hey, NX is best, I get it), the integrated story those vendors offer is real, and Cascadia can't match it.

But if you’re more interested in not being locked down…

A Brief Note on AGPL

I've covered this in earlier posts, so I won't re-litigate it. The short version: Cascadia is AGPL-3.0, free to self-host with unlimited users and all features included. No open-core gating, no premium tier. The constraint that comes with this is that there's no enterprise support contract by default and no SLA-backed hosted offering. We may eventually offer that for organizations that want it, but the base platform stays open and free.

Audience First, Everything Else Follows

Notice that none of those decisions started with a feature or a technology. They started with the audience. Small-to-mid manufacturers doing high-mix, low-volume work, with shared engineering and manufacturing responsibilities, no consulting budget to burn on multi-system integrations, and a need to move quickly on every project. Every choice above is a consequence of trying to serve that specific group well.

And the decisions reinforce each other, more than I think any of them stand alone. Design-centric organization is what makes the git-inspired change management workflow possible, and that workflow is what lets small teams iterate fast on engineer-to-order work without tripping over themselves. An integrated engineering+manufacturing platform is what removes the integration tax that SMBs can least afford to pay, and the Tools item type only exists because manufacturing is in scope. Code-first is what keeps a platform with this much built-in functionality maintainable, because trying to wrap all of it in a low-code abstraction layer would have collapsed the project under its own weight. And CAD-agnostic is what keeps the platform from forcing a CAD purchasing decision on an audience that often uses a mix of tools across engineering and manufacturing.

Pull any one of those out and the others get weaker. A Part-centric Cascadia couldn't have branch-based change management. A code-first Cascadia that wasn't integrated engineering+manufacturing would be missing most of what makes the code-first decision pay off, because the platform would be doing less. A flexible, low-code, enterprise-targeted Cascadia couldn't have built the Design Engine (sorry for continuing to tease this, but I’m legitimately excited about it).

So that's the bet. Pick an audience, build for them sincerely, let the constraints compound into something that no flexible platform could replicate without giving up its flexibility, and accept that you're probably going to be wrong for everyone outside that audience.