Stavros Papadopoulos: Scaling TileDB & Revolutionizing Data Infrastructure (Part 3/4)

Intro - 00:00:01: Welcome to The Biotech Startups Podcast by Excedr. Join us as we speak with first-time founders, serial entrepreneurs, and experienced investors about the challenges and triumphs of running a biotech startup from pre-seed to IPO with your host, Jon Chee. In our last episode, we explored the early days of TileDB with Stavros Papadopoulos, his transition from research to business, the technical hurdles of building a scalable database, and the complexities of breaking into enterprise markets. If you missed it, be sure to go back and listen to part two. In part three, Stavros takes us through the next phase of TileDB's journey, scaling the technology, expanding its applications, and securing key customers. We'll hear about the challenges of building a high-performance team, the realities of enterprise adoption, and the strategic decisions that fueled growth. Stavros also shares insights on fostering an engineering-driven culture, overcoming market skepticism, and how TileDB is reshaping data infrastructure for scientific discovery. 

Jon - 00:01:18: So now, you know, you've incorporated, but you've also just been, the timing couldn't have been worse with the, you know, mortgage that the family's about to start, you know, and so take us back to that, that moment. And like, what were some of the kind of the, what were the early days like? And what are the, you know, just like, maybe at the highest level, what is TileDB's mission and value set? 

Stavros - 00:01:44: Yeah, absolutely. So, trying to remember, probably, I'm blocking on purpose.  

Jon - 00:01:50: Yeah, yeah you blocked it out. Yeah, yeah. 

Stavros - 00:01:52: You know, you're just like sequestered it. The depressing moment, so to speak. And for anyone that is trying to do this for the first time, if it's your second time, you're good. Like the first time, it's the tough, then there's gap, and then second, third, fourth. Like those, senior entrepreneurs, are saying, oh, it's a hurdle and it's hard. It is. Not for you. 

Jon - 00:02:16: Yeah, yeah, yeah. Not for you though. 

Stavros - 00:02:17: If I do it again. It's not going to be as difficult. It could be very hard, but nowhere near as difficult as it was. Doing it the way I did it. Okay. For the first time. 

Jon - 00:02:30: Yeah. 

Stavros - 00:02:30: A technologist without understanding business at the time and all of that stuff. So nowhere near, I think it was maximum difficulty level.  

Jon - 00:02:38: Yeah. Sounds like it. Absolutely. Sounds like it. 

Stavros - 00:02:42: So it was extremely hard because, first of all, during the first 18 months, I was... Coding like crazy. Again, I don't want to, and you can see my code on GitHub. I have like a million lines of contributions to TileDB. So to see, I'm not joking, but again, I'm very good at architecture. Like I was architecting TileDB and the architectural decisions of the core engine, because now we build a lot that I was not, I was involved in the designs, but not in the implementation. I was involved in the implementation of the core and then the VCF, the VCF stuff on top, the variant stuff. And the architectural decisions that I made, they were the right ones. These are the ones that solved the problems and built the foundation for the success that came afterwards. Unfortunately, we had to build a lot on top. I'm going to speak about the vision and all that stuff and the difficulties in building a company like TileDB. But the architectural decisions for the core engine plus the VCF stuff were the right ones. The algorithms were correct. The correct algorithms that give us a close to optimal performance for the problem at hand. The core quality had to be improved. By professionals that came in and then they started pulling apart the nitty gritty details and perfecting it and then deploy it because that was not my strength. Deploying it, installations, cleanliness, all of that stuff that professionals do. So I was fortunate to find a couple of those people, young ones, but still extremely good from MIT. And one value, for example, from the get-go that was paramount was the intelligence and the technological skill. The first few people that worked on the code were highly intelligent. Extremely skilled, extremely. We didn't know business just yet. So I can speak about business in the later years, but at the time it was pure software engineering, hardcore, hardcore software engineering, and countless hours of coding stuff that you can't even see. You know, if you're building an AI application or if you're building a nice UI, you know, you build something. It's difficult, don't get me wrong. But then you see it. Then you say, it's beautiful. I mean, you get inspired and say, whoa, that's getting more beautiful. We are very low level. Our investors didn't understand what we were doing. Very low level. Everything, of course, programmatic. No concept of a UI. Nowhere near. Nowhere near. Only lately we started adding a little bit of fanciness to the UI. You need to be a hardcore engineer, C or C++, understanding computer architecture. To optimize for, you know, the CPU cycles in the algorithms and very big emphasis on performance. Not utility, not usability. I don't know if that was a mistake because we were emphasizing on the differentiation. When you go to the market, the customer might not care about this stuff. They might care first about the usability, then about the technology. We did it in reverse, which I don't know yet. We'll see how it works in the future. But. I felt that this is the real innovation. So you see, still I have a technological mind back then. And that's why... Back to your question, what it felt like was strong innovation at the lowest level with a lot of coding and very skilled. A few, three, four. We became four. After 12 months, 13 months, even more. We were two for six months. Then the third one came. And then the fourth one came in 12 months, 13 months, something like that. So average headcount, two and a half in the first 18 months. With a million dollars. What did we expect? 

Jon - 00:06:36: Yeah, what are you going to do? 

Stavros - 00:06:37: And then, of course, we had to raise money with Runway. We needed at least six months of Runway. So that I can raise the next round. But in any case, this strong obsession about performance caught the eye of our first customer who needed exactly that. They said, we have a scaling issue. Population genomics, we have much more data abroad and we're losing money. We can't do it. We can't analyze this data. So they helped us and of course they became a nice customer for many years. And this led to the next round, the seed round, that was another 3 million. So one was the first, another three was the second. And again, the goal was build the technology a little stronger. Again, nobody's going to understand it for the next 18 months. And we're going to get a second customer. The second customer was the Chan Zuckerberg Initiative, who is still a customer, amazing, amazing partner. We can talk about amazing, critical partner for us. But we got the second customer. And then in the middle of the pandemic, we raised a $15 million Series A round, which was insane. It was in the middle of the pandemic. Nobody was investing. But fortunately, our network and the vision that resonated very, very well with the new investors. And I'm going to talk about this in a moment. The vision and the technical capacity, like the technological skill that a lot of companies out there did not have. And they were saying, wait a second. Yeah, it might take a long time. Like they were saying to me. It's a lot of work. That's not an easy company to build. But the technological innovation, first of all, it has a big purpose. And second is strong IP. We don't know how it's going to work out because, again, it really depends on the resources, on the timing of the market in the enterprise or how enterprise deals close. So there are a few things that are not in our hands, but at least they were seeing a vision that they resonated with. And also the true technological level that you don't find in other places, especially in life sciences. Life sciences, there's, again, we hear that from customers. There's a lot of vaporware. Oh, fancy UI and you're doing a great job. No, it breaks down. It breaks down. When the data accumulate, it breaks down. We do the exact opposite. Strong engine. No problem about scalability. We're working on the UI, okay? We're working on the UI, and we understand. We're working on it. But we wanted to solve the real innovation. It's the core. So anyway, these are, a little bit on the trajectory. If we want to talk a little bit about the vision, perhaps, Jon, it makes sense after two hours. It makes sense. 

Jon - 00:09:22: Yeah, yeah, yeah. Yeah, yeah, no, absolutely. 

Stavros - 00:09:24: To talk a little bit about the vision.  

Jon - 00:09:25: Yeah.  

Stavros - 00:09:26: But here's how it started, all right, and how it is manifesting with the practical realities of a startup. And this also, for your audience, it might have value, right? Like it's a different thing what you want to do and a different thing what you can do when you are constrained. It's an optimization problem. Like you have constraints and you need to have a maximum result given the constraints. If you don't have constraints, the maximum result is different. It's better. But with constraints, the maximum result might cap. Like, you can't get better than that because you have the constraints. And of course, I was thinking about all of that stuff, but I was learning more as it was manifesting. So what I wanted to build was conceptually very simple, but a lot of people could not comprehend it, which is crazy. And now it's easier to understand because people have started to feel the pain. But at the time, they could not get it. We're talking about 10 years ago when I was talking about this, right? 11 years ago. So I had the observation that it's just a logical sequence of thoughts. First observation. There is certain data that can fit in tables. An image. You cannot store an image in a table, correct? Believe it or not, genomics is similar. Genomics is a different beast. It's complex. And the single cell also very different in nuances and a lot of protomics and other stuff. So anyway. There is certain data that can fit PDF, text, right? All of that stuff before the AI craziness. There is certain data that cannot fit in a table, correct? So what do organizations do? They buy Snowflake or Databricks or something else for the tables. Then they have Dropbox, Box, or whatever for files. And then they have a million different solutions, either bespoke for imaging from General Electric, I don't know, just contrived examples, okay? Or something that they are obliged to build in a big pharmaceutical. They were obliged to build it. It doesn't exist. I don't judge them. It doesn't exist, so they're obliged. To build it. And you end up with an infrastructure which is insane. And then because it is insane and people want to reason around it, they started calling it names. In the past, we just had Oracle, right? You said it's Oracle. DB2. Microsoft SQL Server. Whatever it is. System R. Whatever it is. But it's one. And I have some DBA, some database administrators, and that's it. Today, you have... 1,000 vendors. And I'm talking to a lot of CEOs and it's crazy what's happening with those CEOs. Like they're fed up and they're starting cutting heads, like cutting vendors like crazy. What's happening now is, they call it digital transformation, by the way. 

Jon - 00:12:11: Yeah, yeah, yeah, yeah. 

Stavros - 00:12:14: Of course, it's a digital transformation. You accepted 10,000 vendors to solve a problem that is solvable, but not like this. It is solvable. So you ended up having 10,000 vendors and infrastructures, architectures, and solutions architects, and data engineers, and all of these people to try to patch, to hack something to solve your problem. And they started calling it names. Modern data stack, data fabric, Data Mesh, like all these things. Which, hear me out, if you accept this reality that I will have 10,000 vendors, if you accept it, then modern data stack, data fabric, and Data Mesh makes sense. But I was refusing to accept the reality, man. For me, this could either end up being spectacular or it's going to bring our demise. I want to be very clear here. Either it's going to fix everything and people will shift and they're going to start reasoning around this problem differently. Or people are going to say, you know what, look, I'm sticking with this craziness, in which case we don't have a place or we have a small place in that stock. What I was saying is, I refuse to accept needing 10,000 vendors and 10,000 people to manage data. I refuse to accept. So I'm going to go back to the roots and see what the problem is. The problem is that Oracle, Snowflake, Databricks and all the others are focusing on tables and your data is not popular. That's the problem. 

Jon - 00:13:41: Yeah. 

Stavros - 00:13:42: That's the problem. So why don't we build a database that can handle multiple types of data? Now they're calling them multimodal. We have been calling them multimodal since the beginning of time. And now everybody said, oh, because ChatGPT and Gemini and whatever, they're multimodal. Oh, we need something multimodal. Oh, now you need multimodal. You didn't need multimodal before ChatGPT and now you do. You have always needed multimodal. Your data is not only tabular. You have a lot of tables, but you also have PDFs. You have images. You have reports in multiple different formats. You have so many different things. And there is no database to handle all those data types. And therefore, you end up, you're accepting this reality and you're doing the next best thing to bring in 10,000 vendors. That's the next best thing. So I was refusing to accept that. And I was saying, we just need to change the model. And that's a hard path, by the way. Because you need to start reasoning around arrays, much more general, more powerful data model. But don't forget the relational model, because the relational model is also powerful for tabular relationships. So keep that into the array model as well, which is something we're doing. And then tell all of those folks to start changing their practices, which is very hard. Very hard. That's what I'm saying. Either people will start coming around. It's going to take longer. And I told my investors, even now, I'm saying this publicly, it's going to be hard. But it's the right thing to do. It is. I'm sorry. It's the right thing to do. We're wasting money. You're wasting money as an organization, like hundreds of millions of dollars. I can save you that money easily. But you have to start reasoning a little bit differently. Like you need to understand that it can be a single database, no platform, not whatever you call it, mesh. It's a database. It has authentication, access control, logging, execution engine. It organizes everything. It creates those data products that you like. All of that stuff can happen. It can happen. And at the same time, structure the data. There's nothing that is unstructured. There's a very big convention, which is mistaken, that there is structured data, which is tabular. And then there's unstructured data, that is files, image. An image is unstructured. An image has width, height, and pixels, which is a cell. And every cell has maximum four numbers. RGBA, that's your image. And you- And the baseline, there are others, other images like they may have a beta data annotation, all of that stuff. Fine. But the bottom line is that this is extremely structured. Extremely. It's just that it cannot be structured by a table. So why are you calling that structure? Call it something that is non-tabular. 

Jon - 00:16:26: Non-tabular, yeah. 

Stavros - 00:16:27: It's not tabular. So these are the things that I observed and I said, this is insane. So I fixed it. This is exactly what TileDB does. It fixes this. It's a multimodal database. It uses a much more powerful data model underneath. And it can structure the data that others see as unstructured. It can handle tables equally well to anybody else. I don't want to undermine the tabular work. It's a lot of work that has been done in the tabular space, which we follow and we support. But tables is one of the modalities in an organization that is used for what we call discovery. And that's why we like to coin TileDB as a database for discovery. Because contrary to other databases that you query, you have a tabular database and you query it. Quering a database doesn't give you the breakthrough. That's not enough. This tabular database is part of a huge infrastructure with a lot of people involved. And it's just a cog, right? In this huge thing that people query. People query. And then there are so many other things that are going on in order to discover the breakthrough. Well, TileDB alleviates it. It eliminates those hassles in a single platform. It's a platform that allows you to actually discover, not query. You can do many queries. You can query the electronic health records. Then you can go and find the genomic profile. Then you can go into transcriptomics. Then you can see some images. And then you can derive a particular answer or insight. And that's your discovery. So TileDB is a database for discovery. But in order to be a database for discovery, we have to fix the elephant in the room. You have 10,000 vendors because your tabular databases cannot handle your data. You ended up having 10,000 vendors and building in-house, which is insane. This is the last thing I'm going to say and take a pause. 

Jon - 00:18:22: I'm fascinated. No, actually. 

Stavros - 00:18:23: This is the craziest I've seen. I don't judge them, but I want them to think about this. A big pharmaceutical. Building a database, effectively a database product. They don't say it's a database product. It is. Like if you have, if you are dealing with catalogs, authentication, access control, logging, compliance, execution, deployments in the cloud, you build a database, okay? You build a database. And you're spending hundreds of millions of dollars for this because you need 20 people, very expensive. They need to build it. And most importantly, they're doing the same thing as the next pharmaceutical and the next pharmaceutical and the next pharmaceutical and the whole domain. In other words, all these human hours are completely wasted. All of them. Why? Because there can exist a single product that you can all buy for a fraction of the cost. And in all likelihood, it's going to do a much better job because that company is hiring professional database people. So building a database in a healthcare and life sciences organization, to me, is equally crazy as us, a database company, creating a wet lab to find the cure to cancer. 

Jon - 00:19:27: Yeah. That's the same. 

Stavros - 00:19:30: And let me elaborate. We can find smart people. We have smart people. We don't have experts for therapeutics and drug discovery, but we can find them. Given the same funding that you guys may have with the pharmaceutical, we can find them. And we can go to a warehouse, create a web lab, and we can start building this with enough expertise and with enough money. But we're a database company. It's not a core business. It's not that I cannot do it. I could with enough funding. And if I'm charismatic enough and go raise a gazillion dollars out there, I can build it. But then we should not be called TileDB. We are not a database company. It's the exact same argument for the big pharmaceuticals. Don't build these things in-house. It's insane. Like you're using Snowflake and Databricks and Oracle for the tables. Why are you using something bespoke that you built for single-cell? It doesn't make any sense. It's equally difficult, single-cell and genomics and all of these, equally difficult to build in a tabular database. So this is the kinds of problems that a company like ours, which does something significantly different from the status quo, which requires behavioral change. In order to be able to succeed in a domain like this. And the reason why we are taking the risk, right, because this is our career, this is VCs money, is because we believe in the mission and the vision. Because if it does work out... It will accelerate science significantly. We're seeing it already. We have partnerships with the Rady Children's Hospital for an amazing initiative on newborn screening. And right now they're finding insights that they wouldn't have had before because of the scale we're addressing. They're currently getting insights immediately before it was taking days, now seconds. And this is a huge purpose for us guys. Yeah, we're going to put in the work. We're going to definitely put in the work, even if it is extremely highly unlikely to succeed in the broader scope of things. Somebody has to. Somebody has to. And even if we inspire the bigger companies to do it, even that is a success to me. Okay. At least we're hoping to prove that this is what needs to be done. Stop doing what you're doing. If other companies adopt this, it's fine. It's fine. We're okay with this. And everybody in my company is going to be very happy. They're going to tell their kids and their children, you know what? We shaped the market. We shaped the market. And this is what has been done. And now we have discovery faster. It's not that discovery is not going to happen. It's going to happen. But the philosophical question for everybody to answer is this. If you have the chance to do it faster. And you didn't do it. What's your contribution? The philosophical aspect of it. For example... If you do something that can save a couple of baby's lives and you don't do it. Those babies' lives are lost. Granted, you may do it in five years and you may say, yeah, but look at how many babies lives I saved afterwards. No, man. I said, if you have the choice to do it now, you can do it now, but you're not doing it. So think about that aspect. Don't think about how successful you're going to be in five years. Think about what happened in these five years that you have the choice. Right? To do it and you didn't do it because you had to build something in-house or because of egos or because I don't know what happened. You didn't buy the right technology. You didn't adopt the right technology that could have helped you save those lives or find a drug faster than you did. That's the philosophical aspect that keeps me up at night. And the reason why we're pushing in this company and the reason why this sense of purpose is very high in our company. 

Jon - 00:23:09: That's amazing. And my wife is in tech and we were talking about it earlier, but kind of like this inertia, like they're just having, they have a company's organizations, broadly speaking, private public doesn't matter. There's just like this like organizational inertia that just kind of like, pulls you in sometimes directions that you should not be going. And as you're describing this piecemealing, it's a bunch of technical debt is what they're building up. But they just refuse to pay it down. That applies in databases, software, everything. It's kind of like this organizational inertia. And I think I love to hear that the mission that TileDB has. And honestly, I think as you guys are building up momentum, what I've found, at least for Excedr, so Excedr, we do equipment leasing. The status quo has always been to buy equipment. And when I was in the lab in academia, that's what you do. You buy, you get a grant, you buy a bunch of equipment, you know, and then you just like move on. But in startup life, when you raise, you know, a seed round, there's a couple million bucks. And you buy like, you know, let's say you, you, you have 3 million bucks for your seed round and you spend a half, you know, a million and a half on equipment, your hat, your Runway just went in half. And that was just, that decision was just because of status quo. Right. It's just like, I just, that's what I've always done. I've always bought equipment and it's kind of like similar. It's like, well, we just always work with Snowflake and we've always had these like, you know, piece together. It's like this own database internally. We're just going to do it because we've always done it. 

Stavros - 00:24:39: That's the argument. That's exactly the parallels that we can draw 100%. 

Jon - 00:24:43: But it's kind of like crazy because like I think I would have thought that it seems like the rational thing. Like it sounds very rational to me. But, I think what I've learned and what I'm sure you're experiencing is that a lot of this behavior and decision making, it's oftentimes not rational. 

Stavros - 00:25:03: Jon, it's also complex. It's not always, you know, the fault of a particular decision maker. It's not. And actually, I think it's worth discussing this a bit because it's also crazy. We're working almost exclusively with very large pharmaceutical companies. There are, of course, exceptions for some very good startups that we're working with in the life sciences domain. But it's mostly Big Pharma. And we saw a huge variance in these interactions. Like we have seen us signing contracts end-to-end, like procurement, legal, information security within a month. And we have seen deals dangling for a year and a half, two years. And it's not because of decision making that there is, especially in our organization we're working with, where the technical aspect is given. Like we made tests, we're crushing competition. They can't, like, a hundred percent block from doing science without our product. So, you know, we have the so-called business validation because in these organizations, you need the business validation. You need the IT. You need the IT. You can't do one of the two. IT cannot bring in anything without business justifying it. Business cannot bring anything in unless IT fits it. But sometimes these organizations are disconnected. Like when business and IT doesn't work very closely together because they have completely orthogonal KPIs, right? Like goals. And the deal dangles in the most remarkable places, which are irrelevant, irrelevant to whether this organization wants your product or not. Granted, someone may argue, and this is the easiest argument to make, but it's flawed. I promise you. The easiest argument is, come on, like if the business wants it, it's going to get in. I agree, but that doesn't mean it's going to get in tomorrow. And because there are people involved in these different steps that can lose, I don't think there's a job over this because they skipped a step.  

Jon - 00:27:05: That was exactly what I was thinking, by the way. 

Stavros - 00:27:07: Oh, absolutely. Like there are people that know they're not getting the benefit of the product. Business does, but not these particular people. And these particular people are seeing it as a black Box and they're saying, oh, I'm going to follow the same process as everybody else. It takes six months. And then you say, yeah, but if really the business wants it, that's what we're doing. Okay. We're going to the, to the senior architects. Then we're going to R&D IT bosses. Then we're going to the CIO. We're doing that. Trust me. And in my opinion, we're doing it successfully building the relationships. They trust us and they're seeing results elsewhere. So we're doing everything well, still a year and a half. Okay. So, and this is exactly what we're telling also the VCs. The VCs are saying all product market feed and everything. How do you define it? Because there are so many organizations that want us, so many, but they're struggling with, oh, how do I get the budget? Because it's new, right? So new budget needs to be unlocked. We need the budget. There are reorgs. Reorgs are screwing things up all the time. A single reorg may screw the deal completely because there is a reorg. And the champion left and the strategic objectives changed. That doesn't steal away from the fact that this technology is absolutely necessary to drive discovery.

Jon - 00:28:18: It's the right solution. It's the right solution. 

Stavros - 00:28:20: Not only the right, necessary. Yeah. Necessary. Without it, drug discovery stalls.  

Jon - 00:28:26: Yeah. 

Stavros - 00:28:26: It doesn't mean that. It only means that the logistics, unfortunately, at this stage, maybe the future is going to be easier because the domain becomes more mature, right? At this stage, the logistics are extremely hard and it requires a little bit more patience to get the technology into the hands of the organization in the formal capacity, in official capacity. And that's what we're working. 

Jon - 00:28:51: And that's exactly spot on. And I was thinking about, what was that saying? It used to be no one got fired for buying IBM. And now it's nobody got fired for buying Microsoft. Like that's kind of like... 

Stavros - 00:29:02: Or Snowflake for Databricks. 

Jon - 00:29:03: Yeah, for Databricks. Yeah, similar thing where, you know, you could have exactly what you said. It's necessary and it's the right solution. But there's like so many stakeholders that might be involved in this thing. And you just don't know what their priorities are. Yes, the end user is emphatic about what you have to offer. But then there's this other conflating kind of factor. And it's like, you mentioned that, like, you know, you said some will close in a month, some will close in a year and a half. And these are all large Big Pharma. Do you find that when you work with the handful of smaller companies, that this is not a problem? Or do you find the same kind of through line with these kind of like organizational rowing in different directions or having different priorities? 

Stavros - 00:29:48: Yeah, this is a great question. No, the smaller organizations are way faster to move. The problem you see with the smaller organizations, it's the same outcome, but different reason. So the big organizations, they might be afraid about their role. Like, oh, I'm going to bring this in. Like, they really need to be pioneers. Like if you read another great book, Crossing the Chasm, that's exactly the Cosmos. Like you get the pioneers, but then to get it to the mass market is a Cosmos. And then you need a lot of things. You need the mindshare of the market. You need a future completeness, very important, and maturity and other stuff, right? But the pioneers are there. The smaller companies, well, in the past, we were expensive in the sense that the only way for us to get to revenue goals, to raise money, was closing big contracts because we did have a lot of people to support a lot of smaller contracts. We're not a PLG kind of like product-led SaaS. That's not the nature of our business. We're enterprise. It requires expensive talent and expensive time spent for deployments. So we couldn't afford to have a very small price tag because we were providing all this value and it was costing us to provide this value. Now things are different. We have different pricing, much lower, much more flexible and all of that stuff. So we appeal. To the smaller organizations as well. The problem with the smaller organizations are that either they don't know us yet. Remarkably, the Big Pharma does, and not so much the smaller ones, which I find fascinating. And it's that they have a specific network that we didn't break into just yet, where they have either some common tools that they use, open source, and other tools that infiltrate that domain, also relatively on the cheap side, just satisfying their current data needs. Or they just go with boilerplate solutions from AWS, for example, or from Azure. Again, not very deep, at least today, in sophistication, but good enough, for sure, for them to go and say, okay, I'm going to do this. If I get into scalability issues, or if I get into feature issues, I will consider something else, but it's good enough. And since it's good enough, they get credits from those cloud providers, but I can spend credits there. So it's different reasons. It's different reasons. Still, they're not choosing the right solutions, but for their states, they might think, they might not know, they might think that, actually, that's the solution, I mean, and I'm okay. Or they do things in-house, again, with the same reasons as the Big Pharma, that I think that's the status quo, what you said before, pretty much. I don't know any better. The top five pharma does it. And I can do it for the scale, we're talking about, so I'm good. I'm good with my own solutions. Yeah. But you have an FTE there, with an employee, right? And that could cost you 200K. You can buy TileDB for 10, 20, you see? And you can get top-notch support and top-notch quality, and you can grow with TileDB. You can actually, at this stage of our company, you can even shape our product, right? Because now we're very accessible to all customers. Obviously, we're small enough for that. But they don't think that way because they don't know. They don't know that, but this is on the table. So that's on us to create a little bit more awareness. Again, surprisingly, the Big Pharma comes to us because they do have the pain immediately and they say, you know what, I really need this, like now. Versus the others, they just don't know that this is on the table. 

Outro - 00:33:21: Thanks for joining us on this episode of The Biotech startups Podcast with Stavros Papadopoulos. Be sure to tune in for part four, where Stavros tells us about the future of TileDB and its impact on the life sciences. We'll hear about the broader vision driving the company, how Stavros and his team are tackling industry-wide inefficiencies, and what it takes to disrupt entrenched systems. He also shares his thoughts on the evolving role of data in biotech, the importance of long-term thinking, and the lessons he's learned from building a deep tech startup. If you enjoyed this episode, subscribe, leave a review, and share it with your friends. See you next time. The Biotech startups Podcast is produced by Excedr. Don't want to miss an episode? Search for The Biotech Startups Podcast wherever you get your podcasts and click subscribe. Excedr provides research labs with equipment leases on founder-friendly terms to support paths to exceptional outcomes. To learn more, visit our website, www.excedr.com. On behalf of the team here at Excedr, thanks for listening. The Biotech Startups Podcast provides general insights into the life science sector through the experiences of its guests. The use of information on this podcast or materials linked from the podcast is at the user's own risk. The views expressed by the participants are their own and are not the views of Excedr or sponsors. No reference to any product, service or company in the podcast is an endorsement by Excedr or its guests.