Scott Sanders, Chief Growth Officer at Forterra, on autonomy for every vehicle

Key points from our conversation via Sacra AI:

Last time we spoke, you talked about a “single product, multimarket” autonomy vision. You hoped to be cash flow positive within eighteen months. Could you give us an update on where you're at today, what turned out to be the hardest part of pursuing these goals?

We have this thesis that in order to be a venture-backable company in defense, you need multiple outlets for how you sell your core product. Our first part of the playbook was how do we get into as many markets as possible. We exceeded what we thought possible for that model from a timeline perspective. We'll deploy 200-plus systems this year.

When we look at what an autonomous ground vehicle is, it's a fully integrated computer system that lives at the edge.That in turn enables us to go and tackle other use cases as well. These may not look anything like current autonomy, but are at least orthogonal to that. They rely on the core components that you need in an autonomous system: really good sensor fusion at the edge, distributed communication systems, predictive logistics and maintenance. They also require you to know exactly where you are.

When you consider what the warfighter needs, given the early status of the defense tech revolution that's happening, everything that you see at a trade show—AUSA, Modern Day Marine, DSEI—very few of those are products you can carry in your backpack. So they have to get to the fight. Right now, all that gets to the fight on vehicles that take people and logistics. Every human you add to your logistics convoy is just a human who needs bullets, water, food, and a place to sleep. The more you can minimize that, the more you can increase lethality through optimizing your logistics train.

We also do this in the commercial space, and we've had a lot of traction there. There are many similarities in terms of needs. Yard trucks don’t need to have missile carriers in the back. But they need to connect into enterprise resource planning both inside and outside the warehouse. Customers need to know where those assets are. They need to talk to each other, and they need to do that on networks that probably aren't that great. You can't rely on every single site that you set up to have high throughput mesh networks or perfect LTE.

So you end up building a platform-based approach that you can use both in the defense space and the commercial space. Based on the traction that we've had in the defense space, that's really where we've focused, because the need is there today. At this time, US troops aren't actively deployed in combat anywhere, but they're present in a lot of places. Without being in conflict, we seem pretty close to it every week. Every week it seems someone new has decided to fight somebody else.

As we turn the military from an organization that was really structured to fight the war on terror for the last twenty years into one that can compete in large-scale combat operations or against a near peer competitor, we need to think about how we do that. Air-powered drones and seaborne assets, whether USVs or UUVs, are super important, but no war has ever been won from the air or sea alone. We've tried a lot. Until you put boots on the ground and you hold terrain, and until you put boots on the ground in the adjacent country to deter action, you can’t fully achieve your goals. Air power is only valuable and useful to a point. We should definitely keep buying stealth bombers—turns out they're quite good—but it doesn't really change the calculus on the ground.

You need to put combat operations forces into a place where you don't need nine people to support one. Let's get that ratio down. Let's optimize our tooth to tail. Let's make our forces more combat effective with more sensing and more capacity at the tactical edge.

Q: You’re working in an environment where you’re dealing with both software and hardware, so costs must be difficult to control. How do you approach balancing growth and profitability?

Our strategy here is this is a big space and a big market, and we want to continue to grow, especially with the amount of demand that we have for even just our current product offering, nevermind everything else that we're trying to build. Our goal is to always have line of sight to a pathway where we could be profitable if we had to, but not necessarily do that.

That's the right approach in this space. You don't know how long venture capital is going to stick around, and their funding cycles tend to look very lumpy. You need to build your business in a responsible way, but you also can't sacrifice growth for getting a profitability metric that doesn't make a lot of sense, because you're capping your upside. Continuing to reinvest back in the business and invest in new technologies, new acquisitions—that's what we think is the right way to build this business.

Q: Earlier you spoke about building an autonomy platform where one of its jobs might not look like anything it’s doing today. Are you referring to applications you can layer on top of ground autonomy, like logistics and communications? Or were you speaking to future use cases we might not even be thinking about right now?

Both. If you can't communicate with your autonomous system, it doesn't really matter. You need to be able to tell it what you want to do, and you need to interact with ground forces, and you need to interact with the air. You need to work with USVs from any of the companies that are building those solutions and build a platform that people can integrate into in a way that is meaningful for the actual operator.

There are a lot of exciting companies that are building cool technology, but they're building technology, not a mission capability. We look at everything through the lens of what is the capability we're delivering, not the technology. The technology is certainly neat and interesting, and we think we make some of the best out there, but it has to tie to actually accomplishing the mission.

How does a dismounted operator connect to a system? How do I know where my dismounts are? How do they communicate and move data across the battlefield? It's been four years since the war on terror officially ended, and we're still using the equivalent of the networking ontology that we used twenty years before that. That doesn't mean that efforts like NGC2 aren't good ideas or that the army isn’t pushing in the right direction, we 100% agree that they are. At the end of the day, today’s user experience for that infantryman in a rifle battalion in the Marine Corps, or in a brigade combat team—their kit might be a little bit newer, a little bit lighter—but foundationally it’s not that different.

In order to improve that, whether it's IVAS or next generation EW systems for command and control—how does that start to impact the user? If you build a platform that enables those users to be more efficient, you're building something very valuable.

Q: We’ve often heard the multiyear slog to obtain the first program of record with the Department of Defense referred to as “the valley of death.” Has the environment in the last year made you more or less bullish on defense startups' ability to cross that valley of death? Is it getting easier to navigate?

Our realization here is that the valley of death is a weird concept. The initial premise when this first came out, probably eight years ago, was you got this great prototype, you got a user who wants it, and it takes you two years, and you're going to see your revenue number dip really low or flatline before you can get the right program to really scale it. But I don't know how true that is.

If you're working with the system in the right way and across multiple buyers of your platform in the services, you never see anything resembling a valley of death. Part of it is that there are very few people in the space who fully understand how the DoD actually buys, and they rage against the machine and make it the machine's problem. It's a 3 million person machine. You, the 20-person defense tech startup or the thousand-person defense tech startup, probably aren't going to change that overnight.

You need to learn to work with the system and understand what it is that they want, where can you meet them in the middle on how you sell your product. The DoD isn't one market. It's a bunch of micro markets. Every PEO, PMO, you name it, has different preferences for how they want to buy, what they're used to, and what they're comfortable with.

Our approach here is to figure out what that is and work with them on it. Sure, we're going to be active on the Hill, and we're going to advocate for making the rules better for everyone. Well, easier is probably the wrong word.

Sometimes the defense space forgets how we got here with Goldwater-Nichols. There's a reason those rules exist—before Goldwater-Nichols and Share Procurement, it was a free for all. You could go get something going, and it might not be actually a useful product that DoD really needs. Now you have folks talking about revamping it or getting rid of it entirely. From a taxpayer perspective, there are some smart things inside of Goldwater-Nichols.

It comes down to how much time and effort are you going to dedicate to understanding how your customer buys. Yes, users are super important. You need to build what end users want to deploy, but they're not the only advocates in the space. PMs have a mission. PEOs have a mission. They have to deploy a technology or a capability that was vetted through a process. Yes, that process takes forever. I don't think anyone's really excited about JCIDs, but why does it exist? It's because we had a free-for-all at one point in time, and it didn't work. The companies weren't sustainable. The costs weren't sustainable.

There's got to be a hybrid that enables emerging technology to get in the space quickly and go prove operational concepts. Yes, the department probably needs to take more risk in what they acquire, and it'll help companies move a little bit faster. But you also, as a company, have to realize those rules aren't going to change overnight. It's going to be at least a congressional budget cycle or two before you can start to whittle away at the edges and help improve the system, but you're going to be fighting the system the entire time. So it might feel like a valley of death for some, but if you're structuring your approach to this space correctly and you have a capable product that actually fits a mission need, then you probably don't experience that.

Last time we talked about DoD contracting, I think you expressed some skepticism about routes like going after Operations and Maintenance or O\&M dollars. Did your opinion on O\&M pathways change since we last spoke? What about OTAs? Are these dead-ends and mazes you can get lost in, or viable entry points?

Like any tool in your tool shed, if used incorrectly, is not going to get the results you want. Acquisition officers have really strong feelings about contracting pathways and acquisition pathways. The best acquisition pathway is the one the PM thinks will get over the finish line. If you go in and dictate to them “you should do this, or you should do that,” good luck. It's probably not going to work.

But not every acquisition officer has used alternative authorities to buy technologies—and OTAs are just one of them. There are actually three. It's helpful to educate your customer a little bit if they don't know. A lot of them do, and they just have never done it before. But trying to dictate is bad practice and a better approach is just understanding what they are trying to accomplish and what's the way you can help them accomplish that in a meaningful way.

O\&M pilots are a separate and distinct conversation. Small little pilots are great ways to get quick user feedback. Are you actually solving a problem that makes sense to solve? There's a lot of excitement around some technologies that are out there, where it's super cool, but no one's ever going to use that, or the form factor isn't closed. You learn that in those small pilots. You learn that in the $100,000 one-week extravaganza at some remote army base where users are saying, "Yeah. This is neat, but I need this in a completely different form factor. It's not going to close." Or, "Hey. This is great. We'd love to advocate for this." And then you can figure out where this lives inside of the PM structure. There may be other dollars that can be leveraged to accelerate getting it into the field. You have to know how to really tie together the five different customers you might have to satisfy in order to build a scale program in this space.

I don't think using O\&M is bad. But if you're building your entire business on “we're just going to get O\&M funding until the end of time,” you're eventually going to run into the Antideficiency Act or something else that you didn't see coming. You can't do that forever. It's not sustainable from a business perspective.

If you have a successful product you need to find a way that they can buy from you on long-term contracts over multiple years, because that's the only way you can have the predictability to cost out the system. Vendors need to understand where the demand is. We’re in a place where we only do budgets every year—asterisk, they're often not every year, sometimes it takes eighteen months, and we haven't passed a budget on time in a long while. If you're in this space and you're trying to invest and build ahead of need, you need to know that there's actually a demand signal. The only way you can do that is figure out if the technology you're building is useful.

In terms of the fiscal year 2026 request from the Pentagon that was published a few weeks ago, what were the takeaways relevant to your business and defense tech startups more broadly?

Until you get an actual signed bill, it doesn't matter. Especially the last couple of years, we've had big surprises in the final budget. Lest people forget, DIU didn't get its billion dollars of funding until we got the final budget post reconciliation. It's an interesting tool to look at draft legislation and say, okay, what is the Department thinking, or what is the Congress thinking? What is the Senate versus the House thinking from a funding priorities perspective and where is that going to shake out in the middle? Then you’ll see some lines get absolutely cut to zero and others get crazy plus-ups.

People get a lot of excitement, especially in the investor community. "Oh my god. There's $3 billion for this or that, and there are only a couple companies that build it." Okay. If there are only two or three companies that build this, and they have a billion dollars that they're realistically going to have six to eight months to spend, the odds of that effort surviving the next budget cycle are zero. Because they're going to obligate a bunch of money. They're not going to be able to execute it. You just can't build some of these hardware products fast enough. Then they're going to get hit by the CBO or whoever is doing a review of obligation-to-expense. They're going to say, "Well, you didn't even spend the money we gave you this year," because they never remember they only gave you five or six months to spend it.

Some program lines get hit with “early-to-need” or low obligation to prior fiscal year, and it's like, "Well, you gave us money three months ago. How are we supposed to get that on contract?" Still, they’ll take a ding in the next line. So, yes, you got a lot of funding, and you got some stuff out, but then the next year, there's this huge dip because the government's saying, "We didn't spend the money we gave you."

In this area where we're moving budget dollars very quickly, if you're building in a software space, it's one thing. It's awesome. If you're building a product that already exists, you just print more. You go spend on more contract manufacturers. But if you're building big integrated hardware and software systems, you can't just turn that on overnight. I actually think Congress runs the risk of providing false hope of a capability and then changing their mind next year when they say, "Yeah, we gave you a billion dollars. You only spent $250 million of it." So then that next year, they're probably not going to double down and give you even more. They're probably going to give you an amount more in line with what you actually obligated at the beginning of the program. So there is risk in the budget moving as quickly as it has.

There's a belief the current administration is going to spend a lot on autonomy and defense tech in the next few years. What tea leaves should people be reading if they really want to understand what's going on, versus getting lost in the hype?

It's hard. It's funny if you went and talked to investors three or four years ago and asked them how they evaluate business models. Very few of them had ever heard of a J Book \[fiscal year budget justification books\]. Now everyone's saying, "Oh my god. I got the J Books. I have this Oracle." No. You have an Oracle for what happened last year. The only accurate numbers in the J books are prior year of execution. The next ones are guesses: “This is what I'd like to spend.” Go look at the current legislation. Some of those lines got cut to zero. Some of them got quadrupled. If we could predict the future, I'd work at a hedge fund, and I wouldn't be sitting in an office in DC.

People need to look at, okay, macro, what is the department buying? What are other departments buying? What are the MoDs across Europe buying? How are those purchases aligned or how are they in contrast to each other? And then looking at the companies—okay, you've built a prototype or you've got a couple of deployments. Does this actually close for what the customer is highlighting they think they need, via the public documents that you can go find?

The reality is your company is going to know better than outside consultants in the space how that works. It's funny to see venture and PE folks come to the space and default to what they know from any other business space. "I want to go do some expert calls." Okay. What expert are you going to find that knows this? Because the only experts are going to be the people currently working with that customer and that customer. That customer's not going to take an expert call. The minute you leave the department the knowledge ends. I've seen people go after expert calls with people who are former DoD CIOs or CTOs, but it's for some very different application. That person, a very high ranking, former DoD official, would have never seen it.

One of my favorite stories is investors going and talking to ex generals when they're standing up a company, and the generals are saying, "This will never work. It's never going to happen," because that was their experience. But your experience ends the minute you leave that building, and the organization continues on without you. Yeah, you might have friends in the building. You might be able to talk to people, but the ability to get competitive intelligence out of those processes—I've never seen it work, whether it's from the investment side or from the company side.

You really have to bet on, do you believe the team has the ability to go figure this out with their customer? Are they approaching a big market? Are they the only team to go do it, especially at the early stage? Investors get really hung up on tech, which most aren't qualified to evaluate.

Let's switch over to the commercial side and your partnership with Kalmar to create autonomous terminal tractors, used to move truck trailers within logistics facilities. Why was that a Forterra-shaped opportunity in the commercial space?

We had the benefit of exploring several applications in the commercial space at some point in time in our company's history. We really understand how those customers work, what their buying cycles look like, where the costs are in building that system.

The reason we chose terminal tractors is one, you have a dominant OEM, especially in the US. Kalmar has 70 plus percent of the market. Internationally, it's above 55%. So it's a large-scale operation and they been doing this for a very long time. They're more of a systems integrator, to be honest, than just a truck builder. If you buy anything that comes over ship transport at some point in time, that shipping container is probably touching a piece of equipment from Kalmar.

The yard space has really high customer concentration, which we think is important in these spaces. You see a lot of autonomy companies going to mining or earthmoving, but there isn't a single place where there are 200 or 300 earth movers in one spot. It's just not how they're deployed. If you have to go get early traction, you have to do it in a space where you have high concentration. Therefore, your variable costs remain low when you're deploying new technology because—no different than robotaxi in Austin—you're going to have to put some supervision on autonomous systems when they first go out in the field. We wanted to work with OEMs who understand the complexity of what we're trying to accomplish as a team, and no one supports better than they do in ports, distribution centers, whatever it is.

The follow-on pieces are much more similar to DoD in terms of a use case, with something like a container yard or a railhead—everything's moving around all the time. You are not going to be able to build an end-to-end LLM that can solve that because you're going to see a new situation every single day. Maybe one day you can collect enough data to do that, but you're going to have to solve puzzles, not pattern match, which is much more similar to defense applications because you just don't have the training data to go build a large model.

For all those reasons, we look at this space where there's a very high cost of labor and autonomy actually makes sense from a spreadsheet perspective. A lot of other places, we just don't see how it closes without taking on an extreme amount of venture capital to go execute it. So far, we've proven right. Everyone else has gone on on-road or the trucking companies. You just need a lot of capital because there are very long lead times, and those are very low gross margin businesses today. It makes it much harder to get to scale in those spaces versus when it is in a confined space like a yard.

Are there other commercial use cases where you think those conditions have been created so that you could possibly pursue them?

We really think the yard space is probably the only one that matches that exact user profile, user journey, where conditions are always different and there’s a very high cost of labor. The environments are very similar, because you're going to be working in GPS-denied, degraded, interrupted, or limited environments. You're going to work in environments where you're going to have to solve a puzzle every time you move around the yard. You can't have a bunch of infrastructure in place that does it.

Looking at the rest of commercial space, you also don't have a high customer concentration. Even in on-road trucking, the concentration is very low. It's a lot of small organizations, small companies that have 10 to 15 trucks. We also look at it from a supply chain resilience perspective—if you can't move items through yards, shipping containers, distribution centers, like what happened with COVID, then it impacts the industrial base pretty quickly because we just have to import a lot in order to build our industrial base. So we think it was very aligned. It's a very big market, and we think it'll keep us busy for quite some time in our partnership with Kalmar.

In terms of Forterra’s overall commercial and government/defense customer mix, what does that look like? Do you think that'll change in the future or do you think you're at a steady state as far as the blend goes?

Right now, it's very heavily weighted to defense just because of the need. That's where we put a lot of our focus. We see the commercial sector more through the lens of not wanting to move too quickly and get ahead of our OEM partners. It's that there are unique aspects to commercial, especially around the safety case, and especially on OEM integration and factory-line integration. We think these considerations are extremely important. These are not high gross margin businesses, and they don't want to pay an extra premium for a separate drive-by-wire system. They want to have that technology integrated straight off the factory line, which makes a lot of sense.

In commercial, we move at the speed that makes sense to our partners and with our OEM counterparts to be able to deliver that capability, and be able to deliver it at scale. It's interesting to deploy five yard trucks in a pilot. But if you haven't been working on the OEM integration and you haven't been building for scale on your safety case, nothing will come of it because if you haven’t, your customer can't take that technology to scale. You have to line everything up from the start.

There's often a view that with integrated hardware-software companies in defense and robotics that the race is to get as far into the software layer as possible, because of the margin profile. On the other hand, close integration clearly creates value. Is there anything to the “chase-the-software layer” view?

If you are building scale software for the Department of Defense or for industrial applications, you need to be building scale software and hardware together, and you also have to figure out how does production work, how do I service, how do I support this, how do I go track change logs and figure out what I ship to a customer, and track everything carefully. It's very easy for 10 people in a shed to go build an MVP and get a product working. But that's 1% of the iceberg of what you have to go figure out.

You have to do all this in an integrated way, and that's actually just really hard. You have to reach some scale as a company to do that. You have to align competing short—and long-term interests: what does production look like from a forecasting perspective. How do you think about contracting? Are you signed up for terms in early contracts that you're going to sign because you need that first $5 million pilot, but will come back and bite you down the road? Everyone forgets you need a pricing model that closes. Lots of companies get under contract via an SBIR but did not think about what the long term pricing would be. You have not established a commercial price for what you're doing or whether it’s a path you should really be taking.

A lot of times people underestimate just how hard that scaling is, especially in the physical world versus just a pure software business.

What about the view that in drones and robotics hardware is a wedge of sorts, which allows you to then deliver on the software and build value around that?

I don’t think it’s a wedge. I do think it makes your life easier if you're building your own hardware. In a lot of applications, you have to take that path for the same reason any commercial company often has to build its own hardware—the best product is an integrated hardware and software product.

There's this fallacy, especially in the defense tech community, around low-capital requirement businesses. There's a great chart I saw that had what it costs to build Waymo versus what it costs to build a SaaS business. Statistically, it turns out, with the big outcomes in this space it costs just as much to build a hardware business as a software business. In the software space, you just have to buy really expensive engineers. OpenAI is a pure software business. What are they paying for engineering talent? Certainly more than if they went and built a hardware product at this point in time.

There's this myth of, "Oh, hardware businesses are really hard and have low growth, low gross margin, and let’s do software only." Ok where is your software going to run in the DoD? Run in the cloud? Okay. Who's going to use it when it's actually deployed? Because that connection's not going to be there. It's just a business risk perspective that people don't fully appreciate.

For us, one of our competitive advantages is to be able to scale production and go build thousands of something very quickly, as needed by our client, without having to pour a bunch of working capital into long lead-time items. Obviously, you still have to do that. But these are the factors you have to go solve for.

Is there a misconception in DoD contracting that the dollars for autonomy are always in battlefield or direct combat-support use cases. For example, are there ubiquitous maintenance or logistics applications that might be overlooked?

It's less that use cases get overlooked versus where is the need today. There are a ton of government and commercial customers who are saying, "I really want to solve this with autonomy." But the use case is there are maybe 20,000 of the existing solutions in the world, and they're with 5,000 different customers. That probably doesn't make sense to tackle immediately.

That's one of the hard parts for the defense and industrial space. Yes, you have to go build something your customer wants. But if your first customer is having you build something that doesn't scale, then it's not worth the revenue. You can have a good business that isn't venture backed. There are a lot of them out there, actually. But if you're taking on venture capital, you are trying to be the top business in your space. You have to have a dramatically bigger outcome than everybody else. That's why the math has to close.

A lot of times where venture capital is getting used against these applications that would be great businesses if they were bootstrapped, financed through debt or some other instrument. But if you're taking on venture capital, you have to go build a really big company, or it just doesn't close. That gets missed in all the hype and excitement.

In terms of enabling technologies in any part of the stack, does anything on the horizon change the game for ground autonomy in the short-, medium-term or longer?

It's less that there is some missing miracle that needs to happen. It's more about driving the cost down. As GPU compute at the edge becomes more and more performant, you can lower the bill of material costs. As LiDAR costs come down, you can drop costs there. In a world where self-driving didn't close from a cost perspective even five years ago, ten years ago, it starts to close now, and you can address many more markets when your autonomy stack can cost less than whatever I'd pay for an enterprise SaaS license today for a given user.

It's more of a continuous progression on the cost side that makes the most sense. For the most part, with autonomous vehicles—especially ones that aren't actively deployed on-road in cities where you have a billion other factors to deal with around cost—that's what will really dramatically change the outcomes.

Five years out, could you paint a picture of the impact that Forterra has had on the world, your customers, the markets you work in, what it would look like if everything goes right?

Our goal would be that when you look at an operational infantry battalion or brigade combat team or a firing battery, that they can now do two to three times more from a force and capability projection with fewer people. Can we put robotic armies on the borders of NATO and deter conflict with a brigade combat team that has hundreds of small drones and robotic systems that are able to project the power that would normally take a division?

Because we don't have the manpower to go do that. Do you want to resist the Chinese invasion? You can park the entire Marine Corps in Taiwan. Even then, you still have a 10-to-1 offset in terms of manpower. It doesn't matter. You have to really enable those deployed troops to have the critical capabilities they need, whether it's unmanned ground systems or aerial systems or USVs.

You’ve mentioned robotic systems working together. Is there a world where joint autonomy, or a “central brain” coordinating across different autonomous devices across land, sea, air becomes more important?

I don't think you want a single brain. I don't know if that closes. That implies that you have connectivity, and it's ubiquitous. The reality is it's probably not going to be. In fact, if you're going to go fight this war, the first thing you're going to do is take out every piece of infrastructure you can.

What you really need is a distributed system that works when there is no central master or brain that's brokering those communications. Building that from the ground up is the hard part because now you're building a decentralized compute system on the back of vehicles that need crazy amounts of ruggedization, shock absorption, and stuff like that. You're carrying that capability to combat. It's coming in on wheels and tracks.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.