Why New Defense Builds Its Own Enterprise Software

How are the New Space/New Defense companies winning? There's been much written about their contract vehicles (generalized as "build the product first, then sell it to the government"), their ability to pay like tech companies instead of like the archaic primes, and their willingness to break things on the way to novel solutions. Those are all very valid pieces, but I'm interested in a different aspect they share.

The software they built for themselves

I'm sure it's not completely universal, but it does seem anecdotally like all the major defense tech players have invested in an in-house enterprise platform. I'm not just talking some customizations on SAP and Teamcenter, but truly boutique solutions centered around making all the right data available to everyone at the right time. SpaceX famously has Warp Drive, Anduril has ArsenalOS, Stoke Space's Fusion was so good they spun it out as a software product (it's now called Boltline). These systems might be built on top of or integrate with standard enterprise solutions to greater or lesser degrees, but there's no arguing that these companies are working hard to own their own data and processes across the enterprise in a way that the legacy primes never attempted.

Legacy primes had (and have) very traditionally separate engineering and manufacturing disciplines, while in the New Defense space those lines are often much more flexible. Enterprise engineering and manufacturing software was designed for the old primes, which is a large part of why the new ones have had to build their own. The very idea of PLM vs MES vs ERP is a legacy of the disconnected world of old-school product development.

Tearing down the walls

What do you get when you throw those ideas out and rethink what's possible? Or in other words, what's the value proposition this cohort of new defense tech companies used to justify building their custom solutions? To start with, you get to tear down the walls between program management, manufacturing, engineering, and supply chain. Even the Boeings and Northrops of the world aren't so broken as to think they can make major engineering decisions without manufacturing in the room to sign off on manufacturing schedule, or supply chain to confirm procurability. But how do they bring those disciplines together? PowerPoint. And I'm not just speaking theoretically. I've been in the room, personally facilitating multi-hour Change Review Boards (CRBs) over PowerPoint week after week for billion dollar defense contracts (yes, it's as painful as it sounds).

Now picture that same meeting when the change, the BOM it touches, the build schedule and the parts already on order all live in one system. The board looks at the change itself: what's different, what it hits downstream, who still has to sign. The traceability walk can be done in the meeting, it doesn't have to be prepared separately beforehand. The meeting gets shorter, sure, but the bigger win is that the decision gets made against what's true today, not what was true when somebody took the screenshots. Live data, not stale.

That's the first thing you get.

Design changes reach the floor as fast as they're made. Stoke's CEO has said Fusion came out of "a history of pain all of us have felt in the industry" (Payload). Anduril's COO says his manufacturing engineers have two jobs at the same time: keeping pace with design teams that never stop iterating, and scaling production while they do it (I-Connect007). When engineering and manufacturing work from one record, a design change shows up where the work is being done. It doesn't wait for next week's change board to be announced.

Every part has a history you can pull up. When a Stoke engine has an anomaly, the team can go from the bad part to who made it, what it's made of, and which other parts might share the problem. In a disconnected stack, that's a research project across three systems and a shared drive.

The process is yours to change. One of Stoke's design rules for the software is that the people closest to the work configure it themselves, with no waiting on IT or an outside vendor. If you've ever waited a quarter for a consultant to add one field to a form, you already understand the value.

Where that leaves everyone else

But what if you can't afford to build and support your own multi-million dollar custom software to run your manufacturing business? Well, Cascadia is built on the idea that you shouldn't just be out of luck if that's the case.

The gaps that those other applications addressed for their companies are linking the decisions made in Engineering to those made in Supply Chain, Production, Shipping, Deployment Ops, etc.

Cascadia starts with the link that hurts most when it's missing: the one between an engineering change and everything that change touches. Here's what that looks like in the product today.

The change board reviews the change, not a deck about it. Every change order in Cascadia opens its own branch of the design, the way a software team would use Git. Reviewers see exactly what differs from the released design, a where-used tree that follows the change up the BOM and into other designs, and any conflict with another change in work on the same parts. Approvers vote in the same place, and nothing reaches released data until the change is approved and merged. (This is the CRB I wish I'd been running.)

Engineering and the floor share one record. Work instructions attach to the parts they build, so when one of those parts is revised or made obsolete, the instruction gets flagged. A work order turns those instructions into a traveler and records every run, every sign-off, and the serial numbers and lots it consumed.

Every unit carries its history. Cascadia can compare what was built against what was designed. When a lot goes bad, it can answer the recall question directly: what shipped with this material?

Requirements stay attached to evidence. A requirement links to the part that satisfies it, the test that verifies it, the work order that built it and the serial number that shipped. If either end of a link gets revised, the link is marked suspect until someone confirms it still holds.

We're still building Cascadia, and we're building the core experience open source, so let's be clear about where we're at. It isn't Warp Drive OOTB. It doesn't keep inventory balances, it doesn't do costing or purchasing, and its MBOM tools are still early (a refinement of the MBOM tools, including work instructions, is coming). For those functionalities, you keep the ERP you have and connect it through Cascadia's REST API and webhooks. What you get is the connected product record and the change process that sit in the middle of all those systems. That's the piece the in-house platforms were built to get right.

You shouldn't need to be a software company in order to be a successful hardware company

SpaceX, Anduril and Stoke wrote their own enterprise software because nothing they could buy let engineering, manufacturing and supply chain work from one record. Most hardware companies have the same problem and nowhere near the budget to solve it the same way.

That's who Cascadia is for. The core is free and open source, and you can click through a working instance loaded with sample programs at cascadiaplm.com/demo. The code is on GitHub.