What does it take to scale software delivery across the federal government and defense tech ecosystem? In this insightful session from Prodacity 2025, D.J. Angelini, Sr. Architect - Federal at Palantir Technologies, shares how Palantir evolved its software delivery model, automated deployments, and built infrastructure that now powers both internal operations and external government programs.

From manual upgrade checklists to a fully automated, AI-driven deployment pipeline, Angelini walks through Palantir’s journey in scaling continuous delivery, mission-ready software, and multi-vendor ecosystems—while reflecting on what commercial software can teach federal buyers about build vs. buy decisions.

🔹 Key Topics Covered:

• The evolution of Palantir’s software delivery model from manual to automated
• How continuous deployment enables mission success in defense & federal tech
• The challenge of software interoperability in government ecosystems
• Why competitive pressure improves software quality & delivery speed
• The role of R&D in software development—and how it impacts end users
• Lessons for federal buyers navigating build vs. buy decisions

🕒 Key Highlights & Timestamps:
[00:03] - Introduction: How Palantir scaled software delivery across industries
[02:42] - The shift from manual deployments to fully automated pipelines
[06:03] - How Apollo & Rubix enable software delivery across multiple environments
[08:35] - The real challenge of interoperability in government IT
[10:28] - Why faster software delivery depends on collaboration, not just APIs
[12:25] - The power of honest product feedback from competitive markets
[14:13] - The role of R&D in driving continuous innovation
[16:55] - What’s happening beyond IL6 in secure cloud & edge computing
[18:53] - How AI & automation are transforming software deployment in defense
[22:25] - Final thoughts: Why software delivery must focus on mission, not infrastructure

🔗 Stay Connected:
Learn more about Prodacity: https://www.rise8.us/prodacity
Follow us on X: https://x.com/Rise8_Inc
Connect with us on LinkedIn: https://www.linkedin.com/company/rise8/

👍 Like, Subscribe, and Share:
If you’re tackling federal software delivery, DevSecOps, or multi-vendor integration, give this video a thumbs up, subscribe to our channel, and share it with your network. Mission success starts with modern software delivery.

‍

D.J. Angelini (00:03):

Awesome. Well thank you for that introduction and thank you to everyone for having me here today. So as Bryon mentioned, my name is DJ Angelini and I work at a company called Palantir Technologies, and I'm really excited to be here to pull back the curtain a little bit around how do we do software delivery, when did we make the decision to take our internal platforms external, but most importantly, some general reflections around the sorts of dynamics, the motivations that exist within a commercial enterprise, and how might those play out more broadly in broader build versus buy decision making? So those are the goals. We have help here on the screen. I'm going to quickly give you a bit of history on Palantir and how we've evolved our software development practices. It was an amazing presentation earlier talking about continuous delivery. I felt like I've lived that experience, so that was awesome.

(00:54):

I'm then going to shift to talking about the decision to take our internal tooling external and some of the frameworks that went into that, but I really want to spend most of the time reflecting on the dynamics that are at play as a commercial software provider. What does it mean in terms of how we prioritize and how do we deliver and how does that apply more broadly? So let's get started. For those of you that aren't familiar with Palantir, just a quick introduction. Palantir Technologies is a commercial software company and we're focused on building software that supports artificial intelligence, data transformation, data engineering, operational application building, and we work across our federal space. So the defense sector, the federal health sector, the civilian sector as was mentioned earlier, but we also have a really large commercial enterprise. So the same platforms that are being used on the federal side are driving oil and gas hospital operations and more.

(01:51):

We build a number of products in this suite. I'm not going to go into them, but we do a lot of data integration and AI operations in our foundry and a IP platforms. We have a defense domain specific platform, but the one platform I want to spend a little bit of time talking about today is called Apollo, and that's what's focused on software delivery and particularly relevant continuous delivery. A little bit about me, how did I get here? What am I doing here? I joined Palantir in 2016 when Palantir was a very small company. We were very small in terms of human scale and we had a few big customers. Over the past eight and a half years, we've stayed true in a lot of ways. We are still a very, very small company, but we just have more and more and more big customers, so we really had to invest in scale.

(02:42):

And throughout my time at Palantir, I've had to work across a variety of the business, whether it's the commercial business or our product development business. And most recently I've spent the vast majority of my time figuring out how do we accelerate delivery of tech for our federal practice. In prepping for this presentation, I really had to look up when I joined Palantir because 2016 felt both too long ago but also too soon. But I found this picture of my first day as an intern, and the only reason it's on this screen is at that point I had no gray hair. I now have a ton. So that should tell you a little bit about what it's like to work at Palantir.

(03:23):

But when I joined Palantir, the thing that I was most excited about was to solve mission problems. And as Bryon mentioned earlier, that's what the focus of software development should be. But I found my first year basically solving this problem. This is an actual screenshot from one of the documents that I had very early on in 2016, and it was a play-by-play, step-by-step, breaking change, upgrade checklist for our platforms. So what needed to be done in what fashion, in what order for an upgrade to be successful? And our goal was to not bring the platform down. That was our whole focus and my job was to make sure that that didn't happen. See, in 2016, we were still very early in our software delivery cycle. We focused primarily on single customer, single deployment models, oftentimes deploying into customer on-premise data centers or customer cloud environments if we were lucky.

(04:20):

And all of the automation around delivery was me basically sending Slack messages, sending emails, double checking a checklist. It was definitely different than what I thought mission developing software looked like. So we had to spend a lot of time really evolving that and kind of go down the continuous delivery framework that was talked about earlier. In 2018 and 2019, we started to automate my job away, like I was the target. How do we get DJ out of doing upgrade checklists and into managing fleets of deployments? So we were still single customer, but we can manage many deployments at once and focused largely on the automation that helped us do that. This is when we developed this early stage platform internally called Apollo. That was an internal code name at the time, and it was largely just to take everything that I did, the manual upgrades, the rollbacks container vulnerability checks, and move that into tech.

(05:17):

In 2021, we kind of upped the stakes a bit. We invested in infrastructure that allowed us to be more multi-tenant, more dynamic at our deployment. And today how we deliver software looks very different. We're deployed globally across multiple clouds and form factors on-prem, low side, high side, top secret networks. And just to give you a sense of what delivery looks like today, this gif on the right hand side or gif on the right hand side is basically every single operation that Apollo took automatically on February 3rd. So two days ago, and it's not a looped gif, this will continue to play. We're deploying hundreds if not thousands of pieces of software per day.

(06:03):

The two platforms that helped us do that was the platform called Apollo, which I already talked about that continuous delivery software, but we also invested on the infrastructure side. How do we build secure containers based infrastructure that allows us to support our federal partners, but also allowed us to scale across heterogeneous environments? We call that product Rubix, and that's really a hardened securitized Kubernetes layer. So all of this was internal, and this continues to be internal. It continues to be the software that's driving our work at Palantir. But over a year and a half ago, we made the decision to take those internal products to our external customers, not just our federal government partners, but also other entrants in the defense tech market. It took us 20 years to get to this point of software delivery and as we've built a really exciting consortium of defense tech companies, we wanted to help those folks deploy as well.

(06:57):

So we took those internal platforms and built out a concept called mission manager. It's focused on a secure container runtime that incorporates software delivery and enables other companies and government programs to scale. And that's all I have to say about mission manager. To Bryon's point, take it really seriously. I do not want to sell you mission manager, that's not the goal of this talk, but I did want to provide you a little bit of background of how long and how arduous and how long that evolution takes to go from building a really manual software deployment framework to something that is codified in technology. It's a lot of work, it's a lot of effort. And frankly, when I try to sell mission manager to my government customers anyway, I don't really get that far. Two sentences in, they immediately stop me and they just ask why?

(07:48):

Why is Palantir doing this? You're a mission company. I used you previously in a defense context. Why are you spending time on infrastructure deployment? And when we started on this journey, I honestly had the same question, like why should a commercial company really build commercial platforms for underlying infrastructure? But over the course of the past year and a half, seeing this from the commercial perspective has taught me a lot about interesting dynamics and motivations that occur to us on the commercial side, but then they end up in our product delivery for our end users. So in terms of how I want to spend my time today, I want to spend it mostly on that. What are some of the dynamics as we take our internal products external, what are some of the dynamics we see at play and how do I think that benefits the quality of the software?

(08:35):

And ultimately how does it shed light on some of the broader considerations in build versus buy discussions? Alright, so let's dive in. The first learning that I've really had over the past year and a half since we've taken our internal products external is the landscape of our customers has really changed. Earlier in the presentation I talked about what it was like to deploy. In 2016, we would go into a customer deploy into their on-premise data center that was super manual, but now the federal environment is starting to become really dynamic in terms of what does a software program look like? It's not just a one piece of Palantir software in the field or one piece of commercial software in the field. It's an interconnected web of many capabilities all working together to deliver the end mission. And the thing that's really challenging about this is programs and users.

(09:35):

They put a premium on the seamless experience of leveraging all of that infrastructure. I think when we talk about interoperability in the government sector, or at least this is what I've found, we're oftentimes asking the wrong questions. We're talking about do you have restful APIs or can I get data out of your system? Is it going to work in this other system? Those are definitely important, but I think the types of interoperability that I often see with our government customers is, is this going to feel good to use? Is the capability that I'm getting day to day going to feel cohesive if I ask for new capability, is it going to be really cohesive to deliver that? And from my time at Palantir, internally, microservice large scale architectures are really complicated. There are a ton of dependencies, and the one lesson that I've learned throughout that time is that you are only as fast as your slowest shipper.

(10:28):

We can come to an end customer and say 75% of our teams are good, 25% of them are a little behind. We don't get any credit for that. End users want the full experience, they want the feature delivery. So traditional wisdom I think often pulls us into kind of more of a sprint based approach here. Trying to work across multiple vendors or multiple capabilities to do major upgrades maybe once a month in minor upgrades every two weeks and bug fixes. Those can be more continuous. If you get everyone on the same page, maybe you could deliver a program that kind of works, but it's just not what I've seen in practice. It's the underlying tech that often matters. As a commercial software provider, I'm actually incentivized to have other people in a defense ecosystem, whether they're on Palantir software or not deliver and develop faster because the capabilities that we deploy can deliver and develop faster, especially as they're more interconnected.

(11:29):

And I think that that allows us in a really kind of self-motivated way to really deliver for end customers. If we could spend less time on program management and less time on kind of aligning to our requirement stock and more time enabling people to ship quicker, ship faster, ship securely and iteratively, it's better for us, it's better for the programs and it's just been a dynamic I'm seeing inform a lot of our product delivery as well. Okay, the second theme that I've really realized as we've externalized a lot of our product is there is such richness in the product feedback that we've gotten since doing. So. I have worked with some tough customers and the toughest customers are often my favorite. They give you the good feedback, they tell you directly what's going on, but there is no tougher customer than your competition. It is it a whirlwind.

(12:25):

Honestly, for many years as I've worked internally at Palantir, I kind of believed that we built this pristine platform. But the reality is the first time we started externalizing it, it was rough. The feedback was sometimes brutal, but it was glorious. It's the type of feedback that every product manager wakes up in the morning and wants to hear, this is what's going to enable me. I'm currently not enabled. Get it done. That'll let me deliver. And that dynamic is really important because I think this competitive dynamic actually fuels us to do more, to do faster as well. The defense tech ecosystem is actually quite collaborative. There's a ton of partnerships, but the way our government is structured is everything's a competition. How do we win pilots? It's a competition. How do we win contracts? It's a competition. That competitive dynamic I think adds honesty to the type of feedback that we're getting every day when we work with our customers.

(13:19):

And for us it is like gold and that dynamic really, really is like gold. I tried to think of other times at Palantir's history where I've seen this dynamic and the closest thing that I can get to is when we migrated to the cloud and took more of a dependency on a hyperscaler. If your virtual machines go down, that impacts us. If your storage goes down, it impacts us. But even then the stakes were not as high. I didn't have any product leverage over the hyperscaler. They were doing their best effort, that infrastructure started to commoditize. So even though there was this sort of interplay of dependency, there was not this richness of reliance and competition and that richness has been game changing for us. The product that we deliver now, and I think anyone that operates in this space is so much better. Three weeks ago it's so much better than it was three months ago.

(14:13):

It's so much better than it was six months ago because of that dynamic. I think that this is something that's non invisible between commercial parties and especially from federal folks that are thinking about buying platforms, but it's so non-trivial and how much it's at least forced us to think differently about development. So I think that dynamic has been really helpful. The third realization that comes to mind is really kind of more about the world that we're operating in the federal space, and I call it what's happening beyond IL6. In many ways, I feel responsible for a dynamic that I'm now a little bit chafing against as a SaaS company. My main goal working with our federal partners for a long period of time was to abstract away the complexity of how software gets delivered to them. It was to guarantee via frameworks like FedRAMP or IL5 accreditations and IL6 accreditations that you don't need to worry about all of these components or all of the complexity that's happening in the background.

(15:17):

Lean into the compliance frameworks, lean into those compliance checklists that we're automating and sending for you every day. And in many ways, this helped us scale. So I don't regret it, but now I'm kind of kicking myself as we're focusing on a platform that's focused more on software delivery. And I think this is a dynamic that's not just in the commercial space. I think a lot of homegrown government platforms as well help attract entrants and attract participants by making compliance easier or kind of making more compliance guarantees. But it really takes the focus away from the functional components of delivery of how software gets delivered, how software gets rolled back. In all of the complexity that comes with it up to IL6, this is something that I think will always hold true, but beyond it, the functional components are so critical. When we talk about top secret or when we talk about SAP or when we talk about distributed edge networks, the incentives are not just, Hey, this is how you deploy compliantly. The actual infrastructure is the mission win. I need to visualize the way that data traverses between edge nodes. That's an infrastructure investment, but it is a mission outcome. I need to consolidate my upgrade paths using artificial intelligence because my edge nodes are only connected once every month and I don't have a lot of time. That's a mission outcome. That is not an infrastructure outcome. I need to ensure robust audit of all data access for SAP programs, especially those that have crossover or collaborate.

(16:55):

And I work at a company that builds mission software and many of the defense tech ecosystem builds mission software. So where the mission is, that's where we'll focus and that's where we'll spend time. So when it comes to those functional components, that's really where we're investing. But why do I think it's important to mention is because I think a lot of the conversation, the debate, the critical decision making around build versus buy comes from this feeling of comfort. It's like if I buy a commercial platform, I'm going to have less control, or I'm going to have less knobs at my disposal. I'm going to have less configurability. But I think it's almost the opposite. I'm not going to try and convince anyone of that, but just know that as a commercial platform at these echelons, at these top secret, at these SAP networks, we have to focus on the functional.

(17:46):

We have to focus on control. We have to function focus on transparency, what the mission demands, aos, security professionals, they are end users. They are very critical end users here. So I guess I'm more to say don't fear it. That's where we're working towards. And I think for folks that are thinking about buying commercial platforms, I think that's a general consensus as well, especially in these environments. Okay, so that's one of the third dynamics that I've seen play out in ways that I think have been really interesting as we've gotten here. The fourth and final dynamic that I wanted to talk about is a big one, which is this idea of distributed r and d research and development. I think a lot differently about Palantir today than I did a year and a half ago when I was working in our commercial business or working on a customer deployment, I thought about our platforms as enablers for our development team, but now I kind of view it as an r and d factory at any given time.

(18:53):

Palantir has 2000 plus engineers that are hammering Apollo and Rubics and the mission manager infrastructure every day. And they're doing that just to do their job. They're not doing it necessarily intentionally. They're not doing it with this broader vision of creating a new platform. That's just how they get their job done. And that has been a rich source of innovation for us. The same platforms that drive our internal use also drive our external use, and it's justs, just a constant r and d motion. And I'll explain to an example of what that could look like in a bit. This is not unique to Palantir. I think many other companies have gone through this sort of innovation cycle. You think about Amazon was the best customer and the most demanding customer of AWS as an example of this. As Slack spun out of Tiny Spec focusing on gaming, inner communication, Spotify built backstage and released that externally as well.

(19:52):

This is a common pattern, but it's one that I just am seeing play out for the first time at Palantir in really exciting ways. I'll give you one example of this and how unintentional delivery led to really high upside with very little effort in between. So as all of you can probably imagine, artificial intelligence, generative AI are a huge focus for any software company that's working in 2025. I'll leave it at that. So Palantir is no exception. And over the course of our delivery in that space, we really realized that software binaries and software config are a lot different than models. Model containers, model weights, model compute, model inferencing. And we couldn't just, what is it, square peg, round hole, this thing into fruition. We needed to build internally more nuanced capability in our infrastructure platforms to support generative AI models to support autoscaling of inferencing to better support GPU use.

(20:51):

So an internal team working entirely separate to this infrastructure. Focus on that for a period of a month to roll that out for our internal use. Very quickly thereafter, our first external company came to us and said, we are really trying to figure out how we make model shipping work high side. And we're like, wait, we have that. We actually did that last month for some of the work that we're doing. And it was natively a part of our platform. We didn't really have to think about it. We didn't really have to think about the intention there. We weren't really even responding to a market demand beyond what we are experiencing ourselves, which was really interesting to step back and reflect on. I thought to myself, indifferent world, if we didn't have that crossover, would we have gotten there fast? I don't think so.

(21:35):

And I think I just wanted to call out that dynamic a couple of times. Throughout that explanation, I wanted to use the phrase for free as if we got that capability for free, and I might've slipped up and actually used it, but it's a very expensive for free, if I'm being honest. I think the financial data, if you look at it, our Foundry and Gotham platforms took basically 5 billion of r and d to come to fruition, but that R&D looks different. That R&D is happening every day. It's less intentional. It's not nine month scoped R&D projects. It's how are we enabling developers every day and how is that being externalized into real product for end users? So the goal here ultimately is always to pass the most excellent products to our users, whether they're commercial enterprises entering the federal market or government programs that are investing in commercial platforms to grow their platforms at scale.

(22:25):

In this R&D motion, this tension between internal and external has just been an unexpected consequence that I think has resulted in better product. And I think for other folks that are operating, this is not specific to Palantir, the commercial space really benefits from that overall. Alright, so what am I going to leave you with? I build a commercial software platform that's focused on deploying multi-vendor ecosystems and I'm really proud of it, but honestly, I'm more proud of the way that we have shifted our development ethos, our development focus, and the ways that we're able to think more about mission and less about some of these more underlying infrastructure components at our programs. So there are a ton of dynamics at play. I cover them in this conversation and I'm very excited to talk more with all of you in q and a and follow-up sessions about ways this might be or might not be resonating with you and your programs and your software. So anyway, thank you so much. It's been awesome to speak to you all and look forward to hearing more from you soon. Thanks.

‍