Venture with Grace
00:09:10 · Austin Spiegel
[00:09:10] S1: Yeah, for sure. I mean, looks a lot different now than I think it did four years ago. So the idea that we had four years ago was based on the tools that we had seen at SpaceX. And I would say it was very much around the verification and validation process of software built for hardware and then hardware itself, and then hardware operations as well. That vision is, that's what we built. That's what we've, I'd say, continue to build. Although at this point, we've basically built everything that we had at SpaceX and beyond. So now we have to continue to figure out what is the next thing going to be and where are these companies going. I think when we started the business four years ago, we were kind of pretty early, right, to this kind of re industrialization narrative. We were early to, you know, people even realizing that there's a lot that's going to happen in aerospace. I think this this, SpaceX IPO this year has really kind of, like, opened people's eyes to what's happening in space. But certainly now, we're really starting to feel that there's a pull here and there's an opportunity here. A lot of these businesses that were founded, hardware businesses that were founded, say, four years ago are finally really getting their legs, right? I think you've seen a lot of big contracts signed and now they're actually transitioning into a production phase where they have to deliver on those contracts. And I think that's actually where Sift can really help benefit our customers. So, I think there's a multi part answer here, it's to say we built the vision that we had initially, we continue to improve upon it. There's some really exciting things that we're thinking about, especially now that generative AI has become such a big deal. And then the market is just continuing to evolve to a point where I think our existence is even more justified than it was four years ago.
00:11:03 · Grace Gong
[00:11:03] S0: I wonder, maybe we could talk about the observability in this space department. What is the core difference between you guys and the current platform? Not current platform, but the legacy platform everybody is using. I also, I mean, I was like listening to our whole notebook out and like you guys also hired people from that company. And I guess like, is there, what would you say is like the core problem that the original solution couldn't really solve? And how do you think about like, know, ensembling the talent as well since, you know, I've heard you guys hired from like Palantir, Anduril and like a lot of these really robust, I don't think Palantir, but I'm pretty sure it was one of the executives from Anduril. And maybe you want to talk about how do you ensemble a team as well after Series B?
00:11:59 · Austin Spiegel
[00:11:59] S1: Yeah, yeah. Okay, good question. Let me start with the first question, which is like, what's the difference between what we built? So, I think there's kind of a couple of things to point out here. One is, if you look at observability software, which is software for understanding what's happening within a system, If you look at observability software prior to Sift existing, it's primarily software that's built for software engineers, right? So you think about Datadog's a good example, Honeycomb, Splunk, kind of all these solutions where you capture telemetry from software. So, everything from CPU usage, network IO, memory usage, and then of course you collect logs from software. These solutions are really built with that user in mind. So, any of the end applications are really about application uptime, traces through distributed systems. Then on top of that too, you care more about aggregated statistics in software. So, you think about what's the P99 response latency and you don't necessarily need to look at each individual response latency, right? That is a very... It's very different in hardware. So, hardware, one thing is the fidelity of the data really matters. So, if you think about testing a rocket engine, for example, a rocket engine has thousands of sensors on it, those sensors are emitting data tens of thousands of times per second, your test only lasts maybe sixty seconds. You need to capture every data point from that sixty seconds because something might happen in a nanosecond that you need to analyze. So an anomaly might occur, you need to understand why the software switched the rocket off, maybe there was an overpressure event, stuff like that. So the data platform needs to be different to be able to handle that frequency and volume of data. And then I think the second part too is just like the end applications, right? The way that engineers want or sorry, hardware engineers want to interact with the data is kind of fundamentally different. So, the types of analysis they want to run, the types of plots they want to create, these things differ from what a software engineer is doing. So, that's kind of why you couldn't use the old solutions. And then if you look at what existed on the market, it was basically a patchwork of tools.
00:14:18 · Austin Spiegel
So, if you think about how a software engineer is maybe looking at data from a simulation, maybe they're creating some files from that simulation like HDF5 files or CSV, then they have the Jupyter Notebook that they're using to kind of parse that telemetry and run analysis on it. If you think about like a hardware engineer, maybe they have a test bench that's using LabVIEW and they're capturing TDMS files from that. And then you think about production automation, they have a PLC that's creating data. So, you've got all of these different data sources and all the data is not stored in the same spot. So, it makes it really difficult to actually go and then when you want to look at a problem that maybe spans multiple stages of the hardware development lifecycle, you can't do that because the data is all disparate. So, that's kind of what existed and what the challenge was. And basically, point of Sift was like, how do we unify all of this data, put it in a single source of truth so that when something happens to a satellite on orbit, you can trace that problem back to the satellite during test. And then how do you basically provide hardware engineers and the variety of personas, it's not only hardware engineers, but it's technicians on a shop floor, it's embedded software engineers. How do you provide them with the tools that they need to diagnose problems and bring vehicles to market faster? So that answered your first question. Happy to go on to second question, does that make sense?
00:15:50 · Grace Gong
[00:15:50] S0: Yeah, I think so from a non technical perspective, so what my understanding is essentially when you're launching a rocket, takes very, like the speed matters. Like, basically, every second, something may change, then you have to have like the real life, like real time data to like, make sure that it's like it doesn't go south. And like when you're building something like this, I guess like one of the question I had was like, what would you think is like the core thing that makes like a company pay for a different software? So my answer, my assumption is like, wherever all your data lives on, when your data is all living on one platform, I don't know if there's a lot of historical data in this space industry that it's hard to move while in the software land. Obviously, you have a lot of data sitting on one software. Then when you change to a different one, like it's like a nightmare. So is there any kind of like situation that's similar in the space industry? And the other part is like, how do you leverage AI in the current landscape to power your company's growth?
00:17:01 · Austin Spiegel
[00:17:01] S1: Yeah, good question. Yeah, so the first question, there's certainly a lot of historical data. I think what people don't realize is actually there's less data created from operations, so maybe like a rocket launch or a satellite on orbit than there is from testing, right, whether that's software simulation or hardware simulation. Because you're just running those tests many, many, many, many more times than you're launching a rocket. Right? And then when your satellite's in orbit as well, like the rate at which you can downlink data is pretty low, so you're actually not sending a ton of data down or all of the data that you could potentially capture from the satellite. So, there's definitely a lot of data. I would say one kind of tailwind for us has been that This is a relatively youthful industry, especially with the startups, so they haven't created that much data yet, so we don't really have to be too concerned with migration. But certainly, we've migrated data before and it's not the end of the world. I think, fortunately, one of the unique things or one of the things that benefits or makes it easier is that we have a data lake. So it's really just files, right? So if you can convert the files into the format that we can read, then your data is migrated and it's not really much of a challenge. But to answer your second question, and also I think AI actually makes it easier to migrate things now. But to answer your second question, there's like two parts here, right? One is like what are we doing with AI to improve our product and then like what are we doing internally with AI to help us build better? The anecdote that I like to tell here is at the beginning of the year, we were in a few sales cycles with smaller companies. So only a couple of people would be using the tool. And we presented pricing to them and they felt that they weren't willing to pay the price yet for this type of tool and they were able to kind of like a vibe code, a dashboard that showed them specifically the information that they wanted. And what they did acknowledge though was that the infrastructure, so the data platform would not scale as they scale their data volume and business. Second thing that happened is one of our AEs actually vibe coded his own CRM because he didn't like the CRM that we were using at the time.