An Ex-SpaceX Engineer on Elon Musk, Starship, and Building a $1B-Valued Startup (Scott Morton, Founder & CEO of Revel)

SpaceX, at least when I was there, the product was getting things to orbit. It was not building an incredible software platform. What we did build actually went viral internally at SpaceX. I talked to a number of other companies out there and asked like, what are you guys using? What are you guys doing? And they were like, oh man, it's awful. I was just thinking about the future and what is the most impact that I could have? Is that at SpaceX or is it leaving SpaceX and delivering this type of platform for all the other companies out there trying to build incredible machines? Today, Revel provides a software platform for controlling hardware systems like nuclear reactors, jet engine test facilities, Systems like oil and gas refineries. One of the biggest keys to SpaceX's success is just that Elon is willing to make massive bets on his team, even though everyone's like, we have no idea how this is going to work. We started building the catch tower before Starship had ever even flown. Everyone at SpaceX was like, this is crazy. And ultimately it was caught on Flight 5. One of the best parts of being at Relic is that in one day you can go to a nuclear reactor company, you can go to the most cutting-edge satellite manufacturer, and then you can go to like a hypercar company. It's pretty cool.

Modern AI systems have made software easier than ever to build, cooling venture capital investment in the category and hammering public software stocks. That's what makes Revel one of 2026's narrative violations: a software startup thriving amid the chill. Founded in 2024 by SpaceX veteran Scott Morton, Revel makes testing and control software for companies building rockets, supersonic aircraft, nuclear reactors, and other complex machines. In less than 2 years, it's raised $180 million, won customers like Impulse Space and Radiant Nuclear, and was reportedly valued at just over $1 billion. In today's episode, Scott and I discuss the hardware renaissance, why industrial software got stuck, in the 1980s, what he learned from Elon Musk, and why Revel decided to create its own programming language. I'm Mario, and this is The Generalist. It's great to have you here. I'm really excited to chat and learn more about you and Revel. Awesome. Yeah, great to be here. I think one of the interesting places to start is maybe noting the sense of Revel being almost a little bit of a narrative violation. You know, we live in a world in which the dominant narrative is that AI is sort of solving all software and that every company will sort of maybe build their own systems entirely from scratch. And you are building a software company for the most demanding buyers in many ways in the world. Where's the disconnect that people miss in that narrative that leaves the space for Revel to thrive in the way that you have?

The biggest thing is That I don't think anyone's really going to kind of bet their career on like vibe coding a control system for, let's say, a nuclear reactor or a rocket engine or something that's very high consequence. A lot of these, I think, kind of shallow web apps that are very easy to code, I think definitely, I think those are maybe in trouble with the new capabilities of AI. But I think fundamentally a company is like an asymmetric capability. You have a group of people that are really specialized in this space. And at Revel, I mean, we are fully leveraging AI tools as much as we possibly can, but there is a lot more that goes into software that controls these high-stakes systems than just authoring code. We have a full CI system. So what that is, is like a bunch of hardware that we control is in a lab. We have every type of hardware or kind of system that our platform supports. And anytime we do a release, it goes through a whole process that takes several days to make sure that it is all correct. When we release it to our customers, it's going to behave as we expect. Also, vibe coding only really helps with the authorship component. So with our stack, everything, every line of code is reviewed by someone that, you know, the right person at the company to review it. And so we've seen a lot of, I mean, internally, We've seen a lot of kind of acceleration of our authorship, but not necessarily, but there's a lot more that goes into releasing correct software to control physical systems.

Is there a version of the future where you think, hey, if these models get so good at this trajectory, maybe there's something we have to do very differently, or will it always just be the case that, hey, yes, those models can keep getting better. That'll just help us deliver an increasingly better system.

I think so far what we're seeing, it's only just enabling us to move a lot faster. And then again, we have this, the kind of specialization in the area. Like we have people, we're a pretty tenured group so far actually. We're pretty light on junior engineers. We do want to hire more junior engineers in the next few months, but it's kind of mostly kind of former SpaceX senior engineers. We have several from Palantir and Anduril as well. But arming these people with AI where they really know what they're doing, they know what the correct solution really looks like, just kind of through their experience has been a huge accelerant for us. And I think it'll kind of continue in that direction.

Yeah, I think it's part of the reason I was excited to have this conversation is that I think it's, Revel feels like an example of what an amazing next-gen software company could look like that you don't want to outsource this capability in. Maybe to take another beat and give folks a better sense of what it is exactly that Revel does. Can you sort of, yeah, give folks a little bit of the texture there?

Yeah, so Revel provides a software platform for controlling hardware systems. Hardware systems being like nuclear reactors, we do rocket engine test sites, jet engine test facilities, and then also kind of industrial scale systems like oil and gas refineries. And what's really exciting right now is we're kind of moving more in that direction. And the fundamental problem that we're solving is that these, the software in this space really hasn't made any kind of material improvements since the 1980s and '90s. I saw this problem firsthand at SpaceX. To have something great at SpaceX, we had to build it all ourselves. And I was part of the team that did that. And then I was just thinking about the future and like, what is the most impact that I could have in this space? Is that at SpaceX or is it? leaving SpaceX and delivering this type of platform for all the other companies out there trying to build incredible machines.

I've heard you mention that, you know, the fact that this sort of state of play has been stuck in the '80s and '90s before. Like, why do you think that's been the case? And when you think about what's been stuck, has it been truly the underlying capabilities that are stuck there, or is it more just the interface layer that is, you know, incredibly Web 1.0 and just not what people are used to in terms of polish? Or is it both of those things?

I think just all the software engineering talent got very excited about the internet technologies. You can really just see it's like these tools that are available really do date back to, it's like 1986 is when one of the major platforms used in tests was invented and really hasn't changed much since then. And then 1993 is when the The platform that's generally used in industrials was created. And then you can see then 1998, nothing. And then all the way through 2000s. And I think it's really just all the software engineering talent went and worked on the internet. And this space just kind of languished. There weren't really any startups focused on this. There was no real pressure on the incumbents to really innovate. And so I think then companies like SpaceX came along and proved that you could do interesting things in in hardware. And I think, you know, there's definitely Revel is kind of part of a couple of companies now that are really focused on this.

And presumably it's also just a testament to how sticky these solutions are that once they're ingrained, it's very hard to rip them out such that, you know, you mentioned there haven't been many startups in this space, but looking over the last 5, 10 years, I've seen a few folks try and take a chip at it. And it feels really hard for folks to make the sort of progress that you guys actually have done. What's that disconnect there?

Yeah, I had this question. And also kind of, could Revel have been invented anytime in the last decade? Totally. Yeah.

What's different?

I think it could have. I really do. And also I think a lot of the companies that are in our space are similar in that they are actually looking to what SpaceX did and they're kind of modeling after this

lighthouse finally.

And I think SpaceX really is, it's like the ultimate proving ground for software, for hardware. They're trying to move as fast as they possibly can. They will make big investments to move really quickly. I was fortunate to write a ton of control software at SpaceX and then also work on how are we going to do this in the future. And so I think there was just a kind of accumulation of a lot of experience. And then it's that experience what we were taking forward to Revel. It's kind of, it's pretty simple. You need to have this kind of incubator to figure out what the next generation of systems look like. And then, um, know, those people can then go and take that experience outside the company.

So if I have to synthesize it a little bit, it feels like the old set of software, you know, didn't develop because there was this massive talent problem where everyone just moves to the internet, plus it's super sticky. So there's, you know, not an incentive to rip it out. Then the few newcomers that come in don't have this experience where they get to see exactly how to build this from the inside of somewhere like SpaceX and learn Okay, here are all these edge cases and it's tough to get these companies to adopt it unless it's perfect anyway. So you kind of have a bit of a chicken and egg issue there. Is that sort of a decent distillation of some of the dynamics that Revel was walking into?

Yeah. Yeah. I would add also that SpaceX is this, this pressure cooker and we were extremely motivated to think very hard about this. And then we had Elon's backing to go and try a few things. And then we also had accumulated decades of experience elsewhere inside the company. This system has to work. It has to also have evidence that it's accelerating the team. And I think the combination of those things is what kind of results in greatness. You need to have the pressure. You need to have, I think, the high-stakes situation. And then that's how you, I think, discover new approaches.

Yeah, you'll know about this much better than I do because of your time at SpaceX, but reading about the company and about sort of Elon's management style, it feels like there's sort of maybe a preference to in-house as much as possible, but also a lot of pragmatism where it's like, hey, if we can get the lock from the bathroom door that's $30 to work on one of our engines, we'll do that too. What was it about the old software systems that just clearly did not work for what SpaceX was doing and it such that this kind of an investment was actually worthwhile.

Yeah, I actually want to add to what you just said there. I think there's this big notion that SpaceX vertically integrates everything. And I think it's actually, it's not what, I mean, I was involved in a lot of these decisions. Totally not what I saw there. If you were to say, you know, in a meeting where you're trying to decide what to do, like we should vertically integrate this. Like, You would just be like, what? Like no one would know what you're talking about. Like, what do you, that's not why you build in-house.

Yeah.

You build it.

It's not axiomatic.

You build in-house when you look at, and we did a huge survey of all the options when we were trying to figure out what to do for Starship.

Yes.

We looked in test. It was like exhaustive.

Yes.

Uh, and we came to the conclusion that these were not a good fit for what we needed for Starship. And we, we looked at, uh, we had the, a massive trade internally and then Then we started kind of looking at prototyping a few approaches that based on our experience on Dragon and Falcon, what, you know, if we could just go first principles and dream up something. And those kind of started to gain momentum. And then finally we kind of got it across the kind of hump of showing it to other people and getting a lot of consensus. And then it was like, we should go try this. And even then there were still a lot of like, why don't we just take forward what we did for Falcon? Even then it was actually very hard, a hard sell internally to actually build it ourselves.

To zoom into a little bit there, and, you know, I don't expect you to go so, so granular, but when you say it wasn't a good fit for Starship, like what exactly were the old systems just like too slow to, you know, not capable of doing the kind of testing you need to do it for this type of machinery? Like, yeah, what didn't work?

We saw a number of issues. Some of them were just that software engineers could not work well with hardware engineers on like this kind of a format that both of them could share. That's another problem, I think, in some of these commercially available options. We also, there's a very big difference between the software that ran on the launch pad and the software that ran on the vehicle. And so we really wanted to try to take the best of both worlds, the best of all the approaches and build something that would work for both. We kind of had this objective list that we wanted, you know, if you could just write in like a, you know, one sheet of paper, all the things that you'd like about your software, And then you take that list and you try to map it to these different solutions. And then what we thought we could build in-house.

And so you had sort of built some version of these systems for Falcon and Dragon. And this was sort of like, hey, take these pieces maybe and maybe a different order of magnitude or a different level of depth that we can run on in a very different way.

Yep.

How long did that take as a project to build something where really it worked in the way that you wanted to.

I mean, I think this is actually part of why I ended up leaving to go build Revel is it was very, very hard to build in-house. And I actually felt like we never really took it all the way to what we could. We could see, you know, we rolled out a version of the system, but SpaceX, at least when I was there, you know, the product was getting things to orbit. It was not building an incredible software platform.

Yes.

And so, Yeah, I think it worked quite well. What we did build actually went viral internally at SpaceX, which is actually very rare because all the programs are actually very siloed and isolated, kind of by design, because you want them to move as fast as they can without being kind of, you know, Dragon be like, oh, you can't do that on Starship because this is how we do it. Yeah. It's fully kind of unencumbered. You can just do what's right for the program. But what we did build actually did spread throughout the company based on a lot of our experience deploying it and then scaling it up to orbital class. I guess it's the largest rocket in the world. I thought there was experience there that I thought could help build something for the future for the rest of the world. And that's kind of why I wanted to leave. And I think I also, I talked to a number of other companies out there outside of SpaceX that were startups trying to go as fast as they could. And I asked like, what are you guys using? What are you guys doing? And they were like, oh man, it's awful. We are using either these commercial tools and we're just like, just doesn't feel like it's helping us out, or we're trying to build it in-house. And similar to SpaceX, I'd say at a different order of magnitude, but they're like, this is just not going to get anywhere soon. Like this is going to take forever. It's going to be actually extremely costly to make this great.

You were there for almost 10 years, right? Difficult thing to do. But if you had to sort of try and distill down the most important lesson that you took from that time, is there something sort of actually quite clean that maybe almost fits in your brain as a mantra? I imagine there might be.

One of the biggest keys to SpaceX's success is just that Elon is willing to make massive bets and on his team that we can do this. And even I was at certain points a little skeptical, like, could we, especially I think specifically the catch tower. I mean, we started building the catch tower before Starship had ever even flown. And originally we were going to try to catch it on the first flight.

For folks that don't know, could you tell them what the catch tower is?

Sure, sure. Yeah. So Starship was designed from the beginning to be, or the booster and then also the ship to be caught by, you know, caught by a tower. It has these arms that come out from the tower and then basically the booster and ship kind of hover in between the arms and they basically catch the vehicle.

Which is this crazy idea.

It's incredible. It's actually, I mean, it saves an incredible amount of mass in the vehicles. You don't have to have these heavy legs down at the bottom and all the structure to support the booster in that way, it's much easier to hold it from the top kind of in tension. You think about kind of a string holding something up versus trying to hold it up from the bottom. And that's a much more efficient way to hold the structure. And so it has massive benefits. And that's, I think what Elon was so, he was like, no matter how hard this is, this is the right solution long-term. And he was, he just made a huge bet on the team. We were, I mean, everyone at SpaceX. On the Starship program, I was like, this is crazy. Can we actually do, we don't even have a flying vehicle yet. Can we actually go directly to catching it? Like on top of building the largest vehicle that is designed from the beginning for reuse, you know, full reuse, both the ship and the booster. And ultimately, I mean, it was caught on flight 5 and just, he was right. So, but it was him, I think, making that bet very early on in the program that got us there so quickly. If we had waited till it flew and then tried to retrofit everything and change the vehicle, it'd be a huge change to how the vehicle is designed. And so making that bet at the very beginning, in hindsight, was clearly like a stroke of genius.

Where does that fit into your sort of mental model on a day-to-day? Are you just trying to make your decisions with, you know, a greater speed than if you hadn't seen that, with sort of greater conviction than if you hadn't seen that?

I think the most tangible thing is there's 2. I think one is at Revel, we've made some bets very early on that seemed, they seemed like pretty big and difficult things to sign up for initially, but they're paying off massively now.

For example?

For example, we're using the compiler toolchain. So we have our own programming language that enables a lot of what we talk about, all the improvements. And we are using LLVM as the backend of that, which is the, it's the compiler toolchain for Rust and the Clang compiler for C++. It was a totally foreign thing to the team. No one ever used it before, but ultimately it was clearly the right solution long-term.

Why was that?

It's kind of just becoming the standard. It's clearly the future, the future-proof compiler toolchain. I think everything is going to converge on using that.

I see.

And it was a huge bet on my team's ability at that point. You know, we were, like 3 people that we would be able to go and figure it out. And then ultimately, you know, this is what, 20-something months later. It's awesome. Yes. Like the language is incredible. It's super performant. The toolchain has a lot that we can leverage to make sure it's correct. So that's one example for sure. I think the other big thing from Elon is just, I think that teams are When you do that, like when you sign the team up or you say, we're going to go try this, engineering teams are inherently often just conservative and they can't imagine what they will come up with down the road. This, this, like the catch tower seems incredibly hard.

Yes.

Have no idea how we're going to solve those, all the problems that we need to, to make that happen. And so engineers, I think, are just, just conservative by nature. Uh, but, and they can't see kind of around the corner of what they will come up with along the way. Uh, and so I think Elon was just, would always make bets on the team and continue to make bets, even though when everyone's like, we have no idea how this is going to work. Like, this isn't looking good. He's like, let's spend another month on it. And he'd keep doing that. And then people had breakthroughs that they did not foresee. And so I think a lot of teams are just much more capable than they even, than they even imagined. I can, I can picture like a traditional corporation. They come to the engineers like, hey, can we make a catch tower? And they're like, absolutely not. And the CEO's like, let's do something more conservative. Uh, but Elon knows how to, I think, yeah, get the best out of his team. And this is, I think, a big way that he does it.

Yes. Uh, I was interested in that, the fact that you guys have, you know, built your own programming language, use your own programming language. Why is that necessary or valuable for what you do?

There's a few reasons. I mean, just like the kind of software platforms, there's been no new programming language designed for controlling hardware systems. Also in 3 or 4 decades. And it's kind of the central component of a lot of these platforms is how you actually write what you want to do down in the form of a programming language. Uh, meanwhile, in the last 3 decades, there's been incredible progress in, I think, just the software world learning about how humans can write code well. Like Python wasn't even in use back then. Yeah. And so I think, you know, we've taken a lot of cues from Python in our programming language, and I think Python has been so successful, not because it's interpreted or other aspects of the language, just that it's very accessible. It's very easy to get started with. And so we've built this language to try to be just, it's kind of, it has several aspects. It's highly performant, it's highly accessible, and it's what we call runtime safe. So if it compiles, it cannot crash. And there's just no language out there that does all those 3.

How extensible is it? Does it work sort of across any possible piece of hardware that you could imagine? How do you sort of wrangle that?

Yeah, I mean, fundamentally what you're doing in these hardware control systems is you are taking a bunch of inputs that are coming from the hardware system, like picture like a temperature measurement or a pressure measurement. And then you're going to do math and then you're going to write a bunch of outputs in the code. And those outputs are like, turning a valve or turning on a pump or something like that. And fundamentally what the, so the language is designed to do that middle part extremely well. I see. Do the math on the inputs to determine what the output should be. So it is very much designed for that problem set. And that's what's made it so, so great for users. It is specifically designed for this problem. You know, the performance is really important for determinism, which is that every time you run it, it's going to behave in the same way. And then it will finish what it needs to, to write the outputs at the right time. Second, accessibility. This is actually a big problem in this space in that a lot of these teams are a lot of hardware engineers and they design the hardware systems. They know it the best. They know it better than anyone. They've physically been in the field building them. Yes. But they can't, but then it comes time to tell it what to do. in the form of a language, and they have to go get someone else. They have to tag someone else in.

Yes.

And then there's a massive interface there. So this person's coming in, they don't know the design at all. And then the hardware engineer has to explain in excruciating detail what they want to have done. And then there's a lot of iteration cycles with that. It takes a lot of time. It's always wrong. I was, I actually, I mean, this is exactly what I went through at SpaceX early on is that So I wrote the propellant load sequence for Falcon 9, and I had to explain to someone else exactly how I wanted it to work. And it took an extremely long time.

Extremely long being how long?

6 months.

Wow, really? Okay. I would have guessed when you say extremely long, like, I don't know, 3 weeks. It's 6 months for that.

And it was, obviously there's a lot of other things going on, and I had, but there's a lot of iteration cycles with that person. And then with Revel today, you could do it in literally an hour.

Wow.

That's crazy. It's extreme. I feel like when we tell people we built a programming language, it sounds like a cool software engineering project, hobby project. And I think probably the first 3 or 4 months at Revel was like, ooh, is this really going to work? This seems kind of insane. But what we're seeing today, I mean, this is like, this question has been totally put to bed at the company. Like it is doing exactly what we had hoped. The hardware engineers are out there using the language day to day. There's probably people writing it right now, running it on test stands. And we've even seen, we've actually had technicians at these companies, like reading the code and even writing it. And that is what I was always, I was kind of always envisioning the hardware engineers.

Yes.

Which I have deep understanding in it. I was actually a mechanical engineer turned software engineer. And so, but it's awesome that it's doing exactly what we had hoped. And then it's, I think it's even going beyond what we had imagined, which is that people that typically at companies never get access to this type of thing. These are the people that typically run the tests and they are actually interacting and even updating the code.

Do you open source the code? Why, why, why not?

I think that is probably what we'll do long term. I would like to do that. I think, you know, we have to, I think in this stage, it's, we're obviously still building it. So I think there will be a point in time when it's the right thing to do.

Because at a certain point you could imagine that becoming just such a powerful standard, uh, and in the end being extremely useful. But I, yeah, I imagine there's Yeah, lots to figure out in getting things right.

Yeah, I think we want to get it to a mature state. Um, I think also it is, you know, kind of a key part of the platform. Uh, and so I think we want to make sure Rebel gets into a good spot before we start to open source things.

Yes, that makes sense. You mentioned that you, you sort of had this transition from mechanical to software engineer, but going even, even further back, what's the first thing that you remember building?

Oh, growing up?

Yeah.

Yeah. Wow. Yeah. I, I build all kinds of things with my, uh, my, my dad. So I grew up in Wisconsin. He had a workshop and we would just, I got really into RC cars and we would, I would build these like off-roading RC, like Mad Max creations.

Wow.

Uh, I really wanted to fully automate them, but you know, we didn't have Revell back then.

Yes.

But yeah.

Um, was he an engineer, your father?

No, he wasn't. Um, he worked in, he worked for the state.

Huh. But he just was into this sort of stuff?

Yeah, he, he did all kinds of like woodworking and things like that.

Mm-hmm.

Kind of in his spare time. So yeah, built a lot of things growing up, obviously. Yeah, I had Legos. I built like an entire city, uh, even a space station in the basement, uh, of our house. And yeah, I, I think there is, there's something really, it's actually what we look for in a lot of the people we were trying to hire at Revel is people that are fundamentally builders. I think how you can look for that is, is do they have side projects? Are they so into what they're doing that they're, especially in college, like, are they also building things on the side?

Yes.

And that's kind of a key thing that if people love what they're doing, they're going to, I think, just do a much better job at it. They're going to really care about the outcome. It's also, I think, just a key to like early startups that you need people that are really passionate about what they're building and see it as really kind of their life's work and their craft.

I love these proxies different founders use to find like who is fit for their mission. I like this side project idea. What is the history of your side projects? Like if you think about the sort of formative ones, what helped you level up bit by bit?

So I was into RC cars and Legos, and then I went into trying to build robots and stuff at my house. And then I I didn't really know what an engineer was, honestly. I knew they built things. And so it was really once I got into college that, and then I was like, I got access to this machine shop and just, I went, it was, I had a lot, I built all kinds of things. I was, helped start a few student groups and we had, it was like one of them was to build a wind turbine that would go to a community in Nicaragua. Uh, that was super cool. And yeah, basically built wind turbines from scratch. It was like you wanted to build it out of materials that were available in that location. And so you're very much constrained because ultimately we wanted to let them, um, be able to, to build these things. And so that was a really interesting design constraint situation of like, what materials can they get there?

What are the trade-offs you have to make for in Nicaragua? It's like engines, certain engines, or—

The magnets are hard to get. So those would have to be sent there, but all the rest you had to be machined, you know, basically to machine it out of Just materials available there. And I mean, it was like, we also made like a solar, it was like a solar panel. I forget exactly what they're called, but they would basically hold a solar panel and point at the sun continuously throughout the day. And we had to, we built it out of just wood and like junkyard parts. That was fun. And then ultimately I ended up at a robotics lab. I always wanted to work at this robotics. I finally kind of got into it my junior year and then I Really, really loved that experience. Like I was just, yeah, kind of similar to like building RC cars and stuff in the basement. I was just, but then I had like all these resources available to me. I like actually had funding and I again had the machine shop and I was building all kinds of, I actually, yeah, published a few of them.

Did you have any, you know, I'm thinking of sort of the PayPal Mafia building bombs in high school. Did you have any sort of close, close shaves with things going, going wrong?

Yeah, we did a little bit of that too. My friends and I, yeah, we made like air guns that would, you know, we were actually like, it would like shoot a pool cue actually.

Oh, wow. Like a, like a harpoon.

Well, yeah, we, yeah, all kinds of things like that. Yeah.

These are, these are somehow fantastically good signals of someone being a good founder in my experience. Uh, this sort of, yeah, smart rule-breaking, uh, tinkering slightly on the edge of danger. Were you thinking about being an entrepreneur in those days? Was that like a concept? You mentioned you didn't have the concept of an engineer really. Was a founder something that you knew about?

Honestly, not really. I just knew I wanted to, yeah, I knew I just wanted to build stuff.

And

if I could do it professionally, that would be the best case scenario. And so, and then I did start following Elon and just what SpaceX was doing back in, it was like, sophomore year of college and just thought that was the most insane version of like, that was like the ultimate building things. And I also just imagined they probably had the best engineers to do it. And so that's really why I was like, okay, I want to try to get into space. Let me sneak into SpaceX is how I was thinking about it. And yeah, I ended up staying at Minnesota a little longer than I expected. I was, I didn't, I wanted to keep taking classes. I kind of got into software side. I was good at the robotics lab, I could build, I could machine everything. I could build the entire robot, I could design it, but I actually, I couldn't write the control software for it. And so then I was like, well, I can stay here a little longer and go. And my professor said he'd sponsor me into the computer science department. And so that's actually why I ended up staying a lot longer. And then I had to go back and take all the prerequisite classes to take the master's, the graduate courses. I see. And so it's kind of funny. There's a full through path there of like, couldn't do this for the robotics in the robotics lab. And then also kind of saw the exact same problem later on at SpaceX and then also at Revel.

Yeah. Do you know the sort of heuristic of the fox and the hedgehog? The fox is someone who loves finding many problems and sort of believes that no one idea can explain the world. And the hedgehog is like, one problem over and over intensively, obsessively. You've sort of found ways to keep solving the same problem, it sounds like, where you're encountering this limit of hardware control and building the language for these systems to work first in college, then at SpaceX, and now with Revel. Yeah, it's fascinating to see that come around.

Yeah. And I think it's interesting because I think really that experience in college and then switching into computer science, And being able to really understand both engineers' perspective, the hardware engineer, but then also the software engineer. And I think that's really what we've tried to create is something that the hardware engineer can use, but then the software engineer can also jump in and it looks very familiar to them. It's a text-based language compared to some of the other approaches out there that are graphical. I say it's like programming with crayons.

Yeah.

And so, yeah, I think, I think that background is exactly, has really set me up well to, to, to, to found Revel.

Where do you think your fuel comes from when you think about your, your history? Like where does the drive emanate?

I think for whatever reason, I mean, I've tended to just go after, it's probably both the hardest thing, but also where I thought I could have the most impact. I mean, I, I joined SpaceX as a, as a 25-year-old intern. And I was like, I'm just gonna go in and outwork everyone. That was my mentality. I was like, I'm gonna sneak in there. I don't believe— I didn't think I was qualified, but I thought I would learn the most and I would really kind of see what I was made of, honestly.

That chip on the shoulder of, hey, I have to outwork everyone. Were you the— I don't know, were you a good student, bad student? You know, the last one picked, that impulse comes from somewhere, right?

I wouldn't say I was the best student in high school. Uh, I was always in like advanced math, but otherwise, uh, somewhat disinterested. I think I had the same mentality going into Minnesota, honestly, as I thought, you know, joining. They actually, I don't know if they do this anymore, but they actually had us, they're like, look to your left, look to your right. Like 2 of you will not make it through the program.

Wow.

They actually said that at the beginning at the orientation.

2 of you won't make it through. Gosh.

It's true. It's, it's, I looked at the statistics on it. It's actually true.

So there was some of that sense of, okay, I haven't been the best student, so now I'm going to have to prove myself extra.

Yes, 100%.

You mentioned that Elon's sort of maybe a superpower, what he really spikes on is this ability to take these big swings and give people the confidence to do something a little outlandish, or at least it sounds outlandish. What are the parts of his mode of management that you have chosen not to take with you that you're like, this didn't work for me, or it's not the way that I want to run my company?

I honestly, I think overall Elon's a credible CEO. I don't have a lot. I think extremely intense. I think it, yeah, again, not for everyone. I loved it. I thrived in it. I think being challenged and I think I also was very fortunate. I was one of the first people to join Starship. I think I was the first software engineer down in Boca Chica, Texas. Now known as Starbase. Yes. And, um, and at that point the program was really kind of this like backwater, kind of like not the, you know, everyone really wanted to work on Falcon at that time. And it was kind of one of the crazy ones that would go and want to go work on early Starship, you know, at the very beginning. And I think letting people do that was awesome. I mean, it wasn't, it was kind of a volunteer scenario, but then he got pretty involved. And, you know, I think enabling people, I mean, if you fly close to the sun at SpaceX, you know, you're going to have, you're taking a lot of risk for sure, but enabling people to do that and giving them a ton of agency and, um, but also holding people accountable, I think is the right recipe to do great things.

Flying close to the sun at SpaceX means taking like a big swing on something and putting your name behind it with a lot of resources. And if that doesn't pay off, it's like, hey, then this didn't work. Is that roughly right?

I mean, Elon says like you, I think he respects people that take big swings, but he also, you know, he tracks the batting average.

Yeah, that makes sense.

It's okay to have some misses. I think it's not okay to not like push hard. If you think something is the right way to do things, you should say it. And if you, I think kind of hang back and don't, and then it's like, it can't, it's then realized that you knew the right thing to do, but you didn't push for it. I think that wouldn't be seen very well by Elon. But yeah, I think there's high risk reward at SpaceX for sure.

You're a couple years in at this point, so I'm sure you're still sort of, you know, the CEO job is like you have to climb the skill curve every day, it feels like, I imagine. But as you think about the way that you prefer to lead, everyone interprets this job very differently. What are the places where you find you're sort of most uncompromising, or maybe you want to hold the highest possible bar versus, you know, other folks that you've seen And maybe where there are places where you have more flexibility.

Yeah, I think the product has to be awesome. It has to do exactly what we say it will do. There's no, I have seen kind of in this space, people kind of forward selling capability or saying it can do certain things. And then that doesn't really pan out after a number of months. And that's when Revel comes in to save the day. But yeah, I think it's extremely important that we are very transparent with what it can do today, what we plan for it to do in the future. And then I think also, I'm definitely pretty involved in making sure the product is what it needs to be. And it's still definitely best idea wins. I mean, I change my mind when there's new information all the time. Even when, if I have like, we just means an engineer or someone on the product side disagrees and then there's new information, it's clear like I was wrong, I will admit it right away. I mean, I think that's a really, really important, like basically no ego. is extremely important to make the best decisions possible. And that was, I think, I guess that is another thing I saw in Elon is he would be extremely passionate, but then presented with new information, he'd be like, well, okay, that was—

Quick switch.

That's it. Let's not go that direction anymore. With the company, we're definitely really trying to run a very tight engineering organization. So I think I've seen, yeah, the proof is kind of clear with SpaceX what has happened. And then you look at how the company was run and, uh, and it's really an, uh, an execution machine. I think we have to adapt some of that for Revel. Uh, it's not, you know, you don't have these launches that are really, really powerful at kind of aligning everyone. We're going to launch on this day and then everyone kind of backs out, uh, their schedules. And it's, it's also a really nice tool to figure out what are, what's actually the critical path. We don't, it's a little different as a software company where you have a lot of things in motion at the same time. You have a lot of customers as well. But I think having a really strong engineering culture and that people join and they feel like, wow, I'm with the most elite. This is an elite team that has an incredible culture that is also moving really fast and delivering products. Like the best thing is when we deliver something for a customer and then they go and and have some awesome test. Like they get through the entire hot fire on an engine and they always post it in our shared Slack channel. Like we get to kind of be part of their success.

You mentioned these launches, you know, that is something that from the outside, at least it feels like Elon does it so well as like finding these galvanizing moments, these, or sort of in some cases, you know, maybe manufacturing even this thing that everyone has to run at. Uh, which feels like just ways of pushing energy into the system in a way. What is the version of that that works for you? Is it doing sort of the Gemba walk down the, you know, the different tables and seeing what everyone's working every day? Is it something else?

No, I think, I think it's, it's some kind of customer milestone.

Customer milestones.

Yeah. So, you know, there'll be some large test that a customer needs to do, or maybe we need, there's some new capability that they really need to do it well. So we'll kind of attach it to that timeline. And then I think the new one for us, I think what's extremely exciting about where we're at right now is we've, we're very competitive in the small-scale testing world. So small-scale testing being like a benchtop test setup. And normally with this, these softwares for testing, as you go from kind of small scale to larger scale, You need different things. Small scale, you want to be really fast, iterate really quickly, typically. Larger scale, something like a rocket engine test site, which is a large facility out in the desert, you want a little kind of more controls, you want more safety, but obviously you still want to move really fast. And I think what we've really struck the right balance in with Revel is we're kind of both very fast to iterate with, but also still very performant and safe. And so what's awesome is we're doing very well in small scale, very well in this kind of large-scale facility. And the next phase is industrials, which is large-scale systems. And we're also, so far we've seen that we are extremely competitive there as well. And these are all of these different scales. There's probably 8 different types of software that are used and even inside of one company. So at Impulse, they literally had 8 different types of software.

Wow.

And they have now fully standardized on Revel and they're only using Revel across tiny, even the smallest, like kind of circuit board testing system all the way up to what they're using at this new site called Site 1C, which they're going to use to test their entire stage.

You mentioned it sort of in these steps of small-scale testing, large-scale testing, industrial systems. This is a very naive question, but are the industrial systems more complex versus a test because it's sort of continuous versus discrete or more inputs? Like, What adds the, you know, that is sort of a discrete step in your mind?

It is just, uh, many more, what they call them tags, but they're just telemetry channels.

Okay. So sort of input of some kind or another.

So we're now, we're actually now deployed, uh, at a 250,000 channel system.

Wow. 250,000 channels.

Yeah.

And so each of those channels is bringing some form of data from the system, whether that's heat or, you know, pressure or whatever that might be. across oil and gas or whatever it might be. Is that right?

Correct. And that's not even, I think some of these will go up to several million channels.

Okay. I don't have good calibration of what to imagine there, but that sounds extremely hard.

Football field or several football fields level.

Yes, but just like complexity-wise, like it sounds insane.

Yeah, it's a lot of systems. Um, it's cool. Yeah, we just had a bake-off. Which I don't know if you know, it's like you kind of try 2 systems out. And there were 2 engineers that were very familiar with these platforms. And so they kind of gave them the same assignment, one with the traditional approaches that they'd been using at this company. And it took them a week and then completely cold to Revel, had never even seen the platform. They did it in one day. And they had been using the kind of old way of doing things for several years. And so that's when we, that kind of happened a few months ago. And that's where we're like, okay, we have something in this space as well. We're both competitive, clearly in the test space, doing very well there. And then now we, it's clear we also have something that is extremely compelling in the industrial space as well.

Do you have to convince some of these large companies that you're going to be around for a while? Because I imagine they're so used to someone, you know, this company's been around 20 plus years, you're around 2 years. You know, they want to know you're going to be around for 20 years, right?

Yeah. And that, that was part of the strategy in the latest funding round as well, is that clearly we are going to be around for quite a while. Uh, you know, there's, there's no way we're going to run out of money. But I think it also comes back to the product just needs to be extremely compelling. Like if the, if the, I think that that's another trait is like the product is compelling enough, they will still at least try it out. And then you move from trying it out. Oh, it is extremely good. And then you move

down the stages

of,

of Taking more off their plates in a way. Very cool. Wow, that's wild to think about. I think you've talked before about your position at Revel almost like a mini VC because you have to sort of bet on which companies to sort of resource and dedicate time to getting set up. What is the process like of taking a company in cold and saying, hey, you know, you're now ready to sort of run your next launch?

Yeah, I mean, this is, something I think has been extremely surprising to me. We essentially can deploy our system in one day. We actually have really never, one actually was that very large system. It took 2 days, but otherwise we have done fully same day or even like a few hours being fully deployed.

So when you look at Revel, the company as a machine at the moment, where do you see the big bottleneck?

Currently, Definitely hiring. We're, I think we have, at least my bet on the company is that we need to keep an extremely high bar. And that just propagates all the way until Revel is 200, 500 people. If we can maintain that, and which is, I think, another kind of lesson from SpaceX is I think they have, they've done a great job at this and we need to replicate that at Revel. You want to still be at 500 people. Everyone looks around, they're like, wow, this is an incredible company. All these people are awesome to work with. That's maybe harder for us a little bit in that we don't have the name brand of SpaceX quite yet, but that's essentially the biggest bottleneck in that we, I mean, demand has totally outrun the current size that we're at, which is, I think, a great problem to have.

Yes.

Even with the same-day deployments, My prime focus right now is hiring and building out the team.

When you say keep a high bar, every company wants to do that, right? What does that mean for Revel specifically? Like, what is a— and how do you find those people in a distinctive way? You know, I've heard, you know, the largest array of different ways people find a little bit of edge in the market. Like, have you found a few pockets where, for whatever reason, we're extremely good at taking Midwestern, you know, tinkerers and turning them into, you know, the world's best engineers or whatever that might be for you? Like, what is your playbook?

We're pretty open to where people are coming from, but I think you just have to have a really good, a really solid process for assessing talent. And I think generally, like, you kind of know it when you see it. Our process is, I think, quite good at this point. And yeah, we have the best engineers can usually determine if they're an engineer sitting across the table is going to be a good fit on the team. And so we rely pretty heavily on that.

Talking about this sort of mini VC role that you have in a way, you get to have an interesting front row seat into the amazing pieces of hardware and companies that people are building. What do you think the world looks like in 5, 10 years from now when some of these different customers that, you know, Revel is serving flourish? What do you see that maybe others Uh, haven't realized fully yet.

This is one of the best parts of being at Revel, I think, is that you get to, in one day you can go to a nuclear reactor company, you can go to this like the most cutting edge satellite manufacturer, uh, and then you can go to like a hypercar company. It literally, they're all, it's pretty cool in LA. There's a lot of them there. So I think as an engineer, that is really great. And also I think Revel has a unique position that it's like a one-to-many platform. So if you work inside a company and you're a software engineer, you're going to work on just that, that company, only get exposed to that company's hardware they're building. And then at Revel, you get to be part of all of these missions. But I think what's really exciting, I, you know, I think the small modular reactor space, I think is really cool. I think there's definitely going to be, at least what I'm seeing is, uh, they're making great progress. And I think the regulations are also kind of clearing the way for them. Obviously, I'm very excited about the future space economy with Starship doing extremely well and then all the companies betting on having low-cost access to space. Hypersonics are also really cool. I think that's, yeah. So we're now working with a couple of the best companies there. It's awesome. I mean, one of them was actually very hard to get into. It took, it actually took a year for them to finally say, okay, we're going to try Revel out. As soon as we got into one place, it just spread throughout the company. Uh, it was like on the order of a month, it went from 1 to like 20 systems.

Wow. What was the hesitation like for, is there, is there something that you learned from that?

This is a critical part of their operation. Uh, and, um, they had tried one approach before and they were kind of trying to see if that was going to pan out. And then they're like, okay, this, let's, let's give Revel a shot. And, uh, we were able to very quickly prove ourselves and then also deliver on the, you know, we say it's 5 to 10x, it's going to increase your your cadence of test. Uh, and then the first one we did, it did exactly that. They had like, their engineers were, became like application engineers. They had to write a lot of Python. Uh, and then they had a lot of, uh, safety issues with that where like, you know, if you have Python, a big difference between Revel code and Python is that the runtime safety. So Revel, if it compiles, it will, it cannot crash.

Yes.

So you may have these 12-hour-long tests. In Python, there's no guarantee of that. And so you may have this, the simplest mistake that's probably most common is like a string interpolation error, and that will just kill your runtime system in the middle of a test. And then you have your system left in a really, in an unsafe state, uh, maybe even broken hardware. Uh, and then you also need to go and redo your 12-hour test. And then whoever was waiting for the results is also upset. Uh, and so that first deployment fully demonstrated all the capability. Uh, and then we had people at other sites asking about it and then it kind of just took off.

Wow. You know, I feel like it's almost axiomatic that every great company has to have at least one near-death moment. Have you had yours yet?

No. I mean, I, I, I really can't complain on the trajectory of Revel so far.

It's, see, that's what it looks like from the outside. I'm like, it looks almost too good.

23 months in. I think it is though, going back to talent, I think it all comes down to that. I mean, we've been very fortunate in that we've gotten just an incredible set of engineers and product folks. Jess Winsinger joined from Palantir, who is, I think, you know, we at SpaceX, we really knew how to execute on the engineering side. And she just brought a lot of product and kind of customer-facing experience. And so it truly is just getting an incredible group of people together. Uh, and a lot of people that have just a lot of experience in the relevant places that we needed.

What's been the hardest week of running the company?

I think honestly, the last month has been a little more frustrating in that we have, we just need more engineers on the team. Like we have an extremely clear vision of the future. It's a very good position that demand is so high. So we've set up an FDE team recently. So that's kind of the biggest bottleneck and we're really focused on You know, how do we hire great FTEs? It's obviously not something that SpaceX had. So it's something that I'm personally having to learn a lot about, but that frustration obviously is just like, it's a, it's a great problem to have.

We talked a little bit about AI building software, uh, and, and the ways in which, you know, you can leverage that. To what extent do you have to build the system to accommodate for agents as almost users? Like, is that something that Is already happening at some of these companies? Is that something that you imagine will start to happen more? Or because of the need for sort of precision control, is that sort of less likely?

I think something very exciting that we're seeing is I think a lot of companies are trying to add AI into their product and kind of push it on their customers and like see what's basically just throwing spaghetti at the wall and seeing what sticks with AI. And we have, people are actually already using AI with our product. And I actually think we found that our code is the best possible format to generate control software from an AI because the code had, that's again, going back to the qualities of it, it's highly performant, highly accessible, and runtime safe. And so if you're going to generate code, those are the exact things that you'd want. Yes. You want it to maintain accessibility, meaning you can still read it and totally understand it. So whatever you generate is still very easy to grok what's happening. And then the runtime safety is also really, if you're going to generate code and you're kind of like, maybe it's less critical, at least you know that if it gets to the compiler stage, it's not going to crash. So those are 2 aspects of the language I think just make it the best possible thing to use with AI. A lot of customers are already doing that. Yeah. It's not something we're necessarily supporting directly, but they are already already heavily leveraging AI with the platform.

When you think sort of like very long-term about what Revel becomes, let's say 5, 10 years from now, if I extrapolate it out, it feels like there's like all these really fascinating things that you can do, whether that's creating an industry standard around some of these coding language, this coding language you've developed, or aggregating demand across different industrial companies to sort of help them procure in different ways. Like there's sort of, feels like a dozen different interesting things. Like what's your sort of vision for what this might look like?

The mission of the company is twofold. You know, I've sat in the seat of many of these engineers. I was a hardware engineer. And then at SpaceX, I wrote a lot of control software, a lot of test software as well. And obviously that scaled up to Starship. So I feel like I have deep empathy for the engineers that are day to day just trying to get through their testing, write the code they need to write. And so we really want this, today I'd say the tools they use, they really feel like a bottleneck on their processes. We want to give them something that feels like an accelerant and it is truly an accelerant. The other side of it is if we do that at scale, what does that mean for all the companies out there going after these incredibly ambitious missions? Many more of them will be successful. They'll get through their testing campaigns way faster. You can test 50 times in a week instead of 5 times in a week. You're going to ship your product sooner and you're going to ship a much better product. And so that's what I'm extremely excited about long-term is that we deliver on that kind of twofold mission of like for the engineer, but then also what does that enable across all of these great companies?

I always like to wrap up with a thought experiment or a question or two. If you had unlimited resources and no operational constraints, what is an experiment that you would like to run?

I watched so much Star Trek growing up, huge TNG fan, Jean-Luc Picard. And I just want to know if, you know, humans going to be out there, you know, maybe are we going to go to another galaxy someday? I think just, are we going to be propagating around our galaxy? Like, is that actually, you know, is that going to happen? I think. And I think we are obviously running that experiment. And that's what I was super excited about working at SpaceX for 10 years. But I just really want the answer to that question. Is that good? Like, I thought Star Trek was, I just like, I was watching it as like a middle schooler and it just blew my mind. And it's like, wow, we could be out there exploring all these other solar systems. And I would love to know.

If you could assign a book to everyone on earth to read, uh, do you have one you'd want everyone to, uh, to have read once in their life? And you, you, you get the assurance that they're going to understand it also.

I reread this book. Uh, it's, uh, Our Mathematical Universe.

I don't know that book. Who, who wrote it?

I'm trying to remember.

It's, uh, I'll have to get back to you, but no, what?

Yeah, it's really interesting. I think it, It really helps me put things into perspective. It just kind of chronologues the, uh, all the physics discoveries up to today. And it presents this explanation of the universe and that it's really just a mathematical model. And that's it. And I think, you know, whatever's going on at Revel or in my personal life, it's like, I listen to this and it's just like, I think it really gives you like, it's like the most zoomed out perspective you could possibly have on everything.

Yes. And there's something that gives you peace in that, in a sense.

Yeah, I think it, yeah, I think it's always like, I think the hard part in running a company is always, I think, seeing the forest instead of just looking at the trees. And it's like, I listen to it, you know, usually when I'm trying to fall asleep and it actually helps a lot just to like, it's like literally the most zoomed out view of the forest you can imagine, like from a The perspective of the universe.

I love that. Uh, well, that's a great, great place to end. Um, Scott, thank you so much.

Thank you.

That's it. Thank you for listening to this episode of The Generalist Podcast. Please subscribe on Apple Podcasts, Spotify, or your preferred podcast app. Ratings and reviews help others discover these discussions. So if you enjoyed the conversation, I'd be grateful if you could take a moment to leave one. For all past episodes and more, visit us at thegeneralist.substack.com. See you next time as we continue to explore the future.