From Idea to FDA Clearance: What Nobody Tells Medtech Founders with Darcy Bachert | Ep. 57

The lack of clarity causes the most problems in humanity, in anyone's life, not just in software development. Project clarity starts with the early stages of what we are doing, why we are doing it, and then every step of the way, making sure we communicate progress and show what we are building. So, in the end, what we have built is something that they actually need, that they can use, and that will be successful. What other challenges are pretty common that you encounter? Really understanding how to do it the right way and how to do it in a way that can be adopted by the end-user. I do not know if there is as much awareness about how much different it is to build a medical product than to just create a product. There is so much more that goes into it, just from a planning and process perspective. Welcome to another episode of The Med Device Cyber Podcast. Today, we have a guest, Darcy Bachert, and we are going to be talking about software development and how to do secure software development, and a little bit about the Canadian medtech market because Darcy's organization, Prolucid, is based in Canada. Before we dive in, do you want to give us a little background of yourself, Darcy, and Prolucid, and maybe why the name Prolucid? I was wondering that earlier, actually. Absolutely. First off, thanks, Trevor and Christian, for having me on. As mentioned, I am Darcy Bachert, founder and CEO of Prolucid. We are an ISO 13485 certified software development firm based in Toronto, Canada. We have been in business just over 17 years now. We actually do work in both medical and nuclear, so highly regulated industries, both with very unique development as well as cybersecurity type challenges, and we work with customers really across the world. The bulk of them, though, would be North America, Western Europe, and Australia, but others as well, helping them take an idea all the way through FDA. As you all know, cybersecurity is a huge part of that, so that is something that we help support. Where did the name Prolucid come from? It is not what it maybe sounds like. It is actually two different words joined together: "project clarity" is where it comes from. We find that one of the most challenging things in any project is not so much writing the software, but really understanding what problem they are trying to solve and what they are trying to build. And so, that project clarity starts with the early stages of what are we doing, why are we doing it, and then every step of the way, making sure we communicate progress and show what we are doing. So, in the end, what we have built is something that they actually need, that they can use, and that is going to be successful. So, we try and build that into everything that we do. But that is where the name comes from. I like it. I think the lack of clarity causes the most problems in humanity, in anyone's life, not just in software development in general, especially like building a business or going after a goal. You have to have clarity. Without clarity, people rarely know what to do; they do not know what steps to take, and it makes it very challenging. And I think you are the same when we are talking to people. They need help; they do not have all the answers. They are looking for that. And so, you are not just there to solve cybersecurity or to solve software development. You are there to share advice where you can, give input where you can, and ask good questions because, collectively, that is what we are all trying to find: that clarity on what we are building, how we are going to build it, and do it the right way. And that is where we create the best successes. And what is the weather like today in Toronto? We have almost 10 degrees. We have been dealing with blizzards and nonsense and a very, very long winter that has already started, but we have a bit of a thaw that we are dealing with right now, so I cannot complain too much. I think it is probably low 50s here. Gosh, I am in Arizona, it is like 55 today. That is like pretty cold for during the day in Arizona, 55 Fahrenheit, otherwise it would be super hot in Celsius. And Trevor is in San Francisco. He just moved to California not too long ago, and he is dealing with foggy weather and chilly weather typically. The sun has finally broken out today, it is nice to see. Hopefully, the sun stays out for the JP Morgan week next week. But yeah, it has been rainy, floody, earthquakey, fiery, just every bad thing that can happen seems to happen to San Francisco. I am guessing you are quite glad you moved there, then, is what you are saying? Exactly. I was actually in Toronto for the first time a couple of weeks ago, and I do not think I have felt cold like that in a long time; that was incredible. Yeah, the polar vortex hit, and it is not just cold, it is like a wet cold. You feel it a lot more, I think. So, welcome anyways, I guess after the fact. Yeah, well, we will all see each other, I guess, in JP Morgan and San Francisco. So, hopefully the weather holds out there and is nice. Yeah. So, what are some of the primary challenges you deal with, that Prolucid deals with, with companies that want to have you help them with software for their device? I know you talked about clarity a little bit and trying to drive that clarity because from a software development perspective, obviously, you need to know what the actual requirements are, and I know that is a challenge with people, but what other challenges are pretty common that you encounter? There are quite a few. We tend to find that the first one we have already talked about is the biggest one. When they have an idea of what it is they are trying to build, they have an indication of use, they have an understanding of the therapy or the treatment or the diagnosis that they are building, but really understanding how to do it the right way and how to do it in a way that can be adopted by the end user. There are a lot of very innovative ideas that, if when built, do not make the end user's life easier, it just will not get adopted. And so, we will do a lot of great things together but not see the success that we want. So, it is clarity on requirements. It is really understanding that environment, the end user, and how they are going to use it, and how it can make their lives easier and better and improve patients' lives, how they can get reimbursement, and how they can get funded. I am not saying software is the easy part of it, but a lot of the problems and challenges that we definitely have to work through are all those things around it, including clarity around things like regulatory and cybersecurity and making sure they do get to the FDA, that they are going to be approved and not rejected and sent back and have delays that go with it. So, it is a lot of those surrounding parts that we tend to find some of the biggest challenges or gotchas for the companies that we help support. And Toronto seems to be the mecca in Canada for medtech. Is that true? I mean, that is what it seems like from outside of Canada. I mean, you are there, so it might be different. It is definitely the largest hub for medtech, especially if you expand out into the Kitchener-Waterloo region. There are the most, I guess, the largest number of companies would be here. Montreal also has a really strong medtech startup scene. They do quite a lot of work in AI there as well. It is a bit of a hub not just for medtech AI but AI in general. And then, as you get beyond that, there are smaller regions: Vancouver, Calgary, some on the east coast, but this would be, I think, you would consider it the largest hub for medtech in Canada. And I know Trevor and I have talked a lot about IEC 62304, which is the standard for secure software development for medical devices. And I know your organization follows that. One of the things we try to educate medtech innovators on is when they are trying to find a software development partner, they should choose one that actually has experience in regulated industries, like you do, like Prolucid, and follows IEC 62304. Do you find that that is a factor when people choose you over someone else, that they are looking at those things, or is that more something you have to educate them on? We find it is actually a pretty important thing to have. Before we had it, going back a decade before we were ISO certified, we did follow 62304, but we found that most of the companies we worked with were local in that they were fine with us not having everything. But as we got our full 13485, so the quality management system, and more track record of taking companies successfully with 62304 through FDA, through CE Mark, through other regulatory approvals, that is really launched the international side of our business where now the expertise level that we bring on these sides just really de-risks working with a company that has those accreditations. It just de-risks it from an execution point of view. The companies that are funding them, they like it because they know they are working with a trusted partner. The amount of expertise and knowledge that you bring around all these different best practices, it just really changes things. And so, before you have it, you are not really sure what the impact is, but after having it and having that track record that goes with it, it really makes a huge difference. Not just on initial conversations, but again, the amount of value that a company like that can bring to a startup who has so many things that they need to figure out, and this is one where we can just bring it, educate them, and help take them end-to-end as part of it. So, it is really important, and for any startup company that is looking at working externally, whether it is us or someone else, making sure they have got that, you know, got the quality management system, understand the processes, and have the track record of doing it. I think that is a pretty huge requirement or consideration. Cool. And we are looking at ISO 13485. I know Trevor is in charge of working on that and getting that implemented in our organization. It is not a requirement for us. We do cybersecurity, but some of our prospects and clients ask about that, and I think it is just generally good practice to have some sort of quality management system in place. So, Trevor, do you have anything to add on ISO 13485? Yeah, you said something that really stuck with me, Darcy, and that is about de-risking this process. So, any of these compliance areas, like even how you mentioned, Christian, we do not technically have to comply with ISO 13485. Our quality system is compliant; we do not hold that certification. That is something that we are currently pursuing. But building out that quality system was such a valuable exercise for us to solidify the processes that we had internally. Even though nothing really changes as much on the execution, the proven consistency, all of the traceability and artifacts working their way back have been tremendously helpful for us to make sure that we are providing a very consistent and a very good product. And then, I think, providing evidence of that to any of our clients, it just really does bring that risk down in their submission when they see that we are following best practices, you know, general good documentation practices. We have a formal quality system, we have a quality manual, procedures, plans, backup, recovery, disaster restoring, and recovery procedures for anything that can go wrong there. It does provide a lot of assurance that we are doing things the right way. So, I think it is very important to make sure that we are referencing standards such as that, even if it is a voluntary standard for a company like ours. No, I would agree that I think sometimes quality management systems are looked at as this thing that you have to have in place to get a piece of paper. You get your certificate, and away you go. But how you actually do things within that and doing it the right way is way more important than just the piece of paper with the form around it. And I think one of the things that is probably a bit different for us than you is a lot of our customers when we start working with them, especially startups, they often times do not even have ISO 13485 themselves. And so, what we are able to do is do all the development, design controls, and documentation under our QMS, and then as soon as they have theirs, we can take that entire design history file and transfer it over. So, it really does unblock them on that early stage while they get it because it does take time to get a quality management system in place, and if they had to wait for that to get going, that would be a pretty big delay. So, but I do agree with you, how you actually do things, how you document, having a really strong process that is also efficient, that is where the value is as opposed to just the piece of paper that says you have a QMS. Definitely. Yeah. I think exactly like that, the certification itself is not as worth as much as the process behind it. It is, you know, it is a good way to just show you have that process behind it. But yeah, it is even just trying to bridge that gap from ISO 9001, which is just general quality system practices, into the medical-specific quality practices. ISO 9001 still has a lot of coverage on what you need to do, how to have good general practices within your documentation and within your quality system, but taking that step up into a safety-critical industry such as healthcare or, you know, you mentioned that you are in nuclear. Obviously, that is not quite as much our area of expertise, but I am sure it is very similar. Making sure that you have these processes very strongly formalized in place. But yeah, it is a great way just to make sure that we have this consistency there. And I think it is correct for any companies that we would be reaching out to or that are reaching out to us or know companies that you are working with. They should want to see these artifacts of compliance. They should want to see that we are handling things in a proper, in a safe way. Well, that is, I think, one of the challenges we have from a sales perspective to set all these things up and to be very niche and regulated, and have all the procedures means we are going to cost more than some fly-by-night company. But I know in software development and in cybersecurity, we have the same challenge. It seems like a lot of prospects are doing some comparison between us and somebody else, and they do not understand what they should be looking for. So, they will choose someone cheaper, but then they have to redo everything because it was not done to the right level of scrutiny that the FDA wants, for example, or it was not done for a regulated industry. So, part of our mission is to try to raise that awareness so they make the right decision, and we are trying to do it in cybersecurity. We also try to do it for software development since they are closely tied together. Have you found that to be a challenge, Darcy? Like, you know, you have a prospect on a call, and then they end up going with somebody else that does not even do regulated software development, but then later on, they may come back to you to fix what was developed, what was, quote, developed. It does happen. Yeah, I think there are some companies we talked to that really understand. I think companies that have outsourced before, either in their current capacity or in previous roles, they understand the value of a partner that has the right qualifications, that has got the track record of doing it successfully, and because time is money, and redoing things can be what sinks a company. So, most of who we talk to do understand that value of it, and in those cases, they are looking for a partner. So, now we are competing against other companies with similar infrastructure and track record, and in that case, we can be very competitive. There are always going to be the ones that look at that low-cost option or try and do it internally. We have seen some companies that do things internally, and they do a great job because they have got the expertise and they can, and that is great. And that is, if that is the case, you know what, if you ever have questions or you want a bit of extra horsepower to throw out a project, we are there to help. But we have seen some where they have went with that low-cost option. Oftentimes, it is maybe more local or just or even offshore, and we have had to come in and fix it. And by the time that happens, they are now looking at months of delays. And I know you, I know you see the same. It is months of delays, and the burn that is associated with that is way higher, both in time and money, than if they had just came to someone that can do it right the first time. And oftentimes, a lot of what was done is just not usable because it was not done the right way. So, we are not going to sell to everyone; there are going to be some, as mentioned, they can do it themselves, or they have that track record, but the ones that really get it, that is where having everything lined up and ready to go can be a really strong partnership. So, we really try and focus there and fail fast in some of the other ones. I think in the medical space, I just do not know if there is as much awareness about how much different it is to build a medical product than to just create a product. There is so much more that goes into it, just from a planning, from a process perspective. And I think it can catch a lot of people off guard, even how long it takes to create a product. When you tell a lot of people trying to break into the medical startup space that you are likely not even going to see your product on the market for close to seven years on average, that is a surprising figure to a lot of people, seeing, wow, it really does take that long to create something like this. In the cybersecurity industry, we always have a term for kind of these quick shops that are just trying to churn out test results as fast as possible. They are called pentest puppy mills, and it is basically running an automated scanner or something, just trying to throw all the output of that into a report template and then give it away and do it as cheap and as fast as possible. And we have seen in the past a couple of companies reach out to us, ask for assistance with the cybersecurity process. We say, "Yeah, this is what it takes for us to do it from a manual intensive process." And they say, "Well, you know, this guy over here can do it for this much lower price." And then they will use those results, and the FDA is going to reject it for lack of sufficient testing. They do not see that it is done against patient harm as a primary metric. They do not see complete coverage of the system. They do not see that it included the depth of testing that is required for a medical device. They do not see the right documentation around it. And so, it really is then coming back to the drawing board from the ground up. And so, I think the saying, "Buy once, cry once," really does apply well here. Absolutely. I think she mentioned seven years, and I am not sure if this stat, it is probably worse now, but I think seven years and 35 million is roughly what it takes on average to bring a device to market. And we do find, especially companies where they are coming from consumer or very an industry where you can just throw something out, and you still have to make sure the product works and so on, for those to really understand the medical side is a bigger challenge. Some of the startups that are doing this for the first time and do not have that bias are a bit easier to kind of communicate, but it is a long path, and there are a lot of steps along the way. And I think, just like you mentioned, that knowledge of what it takes for success for FDA, for cybersecurity, for success for the software development side of things for FDA, and also user adoption reimbursement, there are these layers of value that you yourselves and us bring to an engagement that you do not get from the pentest puppy mill or the offshore development that has no experience in the industry. So, I think, just, we do our best to really message that value, and the ones that understand that, we end up having great partnerships with, but not everyone will, and often times we will fix it in a year or two down the road. I think that stat is pretty sobering for people that do not think about the industry too much. Seven years and 35 million, you said that is average. And that is very different to throwing something up on the cloud like a SaaS platform and trying to make revenue while you are still building it, basically. It is a very different model, and it is very different from a software development perspective and a cybersecurity perspective, and we run across that challenge quite a bit. People do not understand, like, we cannot just test this in five minutes and say it is good to go. We have to provide a level of diligence to this because, you know, if your device is hacked, it could kill a patient or harm a patient. It is much more risky than somebody stealing a credit card number, for instance. And it does not just, I mean, that seven years, obviously there are a lot of steps there. There are trials that are built into that, there are validations, gathering data all the way to approval. But I think also people sometimes forget what happens after your product is on market. And both with software development and cybersecurity, your journey does not end there. You have to make sure it stays secure, you have to make sure it is updated. There are going to be new features that are required. So, it is not like you just, you know, throw the app out, start getting revenue, build as you go, test as you go. There are very clear steps you have to follow. And then, once it is on market, you have to make sure it is secure, you have to make sure it is updated. So that is something that we also have to message to companies that are they are looking to build a device. It is this is not just a one-and-done. This is a whole product life cycle that includes potentially five years, maybe 10 years of ongoing maintenance while it is out in the field being used. And again, I think when you think about that, it is a bigger challenge. I am not trying to talk people out of building medical devices because we need them, but there probably are easier things to do. Yeah, I think especially even being here in the Bay Area and seeing what the startup ecosystem looks like outside of this space, there is very much, I think even recently with the huge prevalence of AI development tools, trying to get something out as fast as possible and just keep throwing stuff against the wall until something sticks. And that practice is common with both founders currently and even with investors and venture capitalists. You will see a lot of the VCs in the area just trying to throw money, a little bit of money at everyone because they think that one of them is going to go 10,000x and become the next, the next OpenAI or whatever it might be. But I do think there is a very big trend of just trying to make something super fast, see if you get a little bit of user adoption, and then maybe take it off from there. And it is so hard to do that in the medical space since then. You are probably already four and a half, five years into development, fighting through regulatory approval. You have sunk millions of dollars into this project, and if you realize at that point that you do not have market fit, then you are in a really difficult situation. You cannot just make a hard pivot and go, "Well, we tried to make a pacemaker, but now we are going to make an oxygen pump." You have to stick with the pacemaker; you have already built it. And so, it is a lot different of a mindset. And I do think, you know, you kind of mentioned, like, people getting into this for the first time, they are not stuck in that mindset of try to make something and iterate it. They are a little bit more new and willing to see exposure to a different way of doing things, which I think is a really big benefit that is not really talked about too much. Yeah, that there is not a bias going into it so much, and you mentioned something, product-market fit. This is, despite the fact that you have all these restrictions around what you can do, we do find that is an area that we have to challenge on quite a lot. There are, you know, people are so focused on the core research or the core science or proving their algorithm does what it needs to do, they do not spend enough time talking to the clinicians, the nurses, the doctors, the end users, and really understanding not just what this technology can do, but how they would use it, how it integrates with their workflow, because product-market fit is when you have got a solution to a real problem that is easy to use, that integrates well, that they, you know, they cannot wait. They are wondering when they can get it. And so, there is, it is still critical. It is harder to do in medical than when you just throw an app out, like you mentioned. You just throw it out, you see what hits. If not, you pivot, you do something different. You cannot pivot the same, but you still can talk to people, and there are things, you know, the formative and the summative and other types of steps that are supposed to support with that to a certain level. But we do find it is an area where sometimes we will say to people, "You need to go talk to your end users because you do not know what they want yet. And if you do not know what they want, we are going to spend a lot of time building something that they cannot use." So, you still, again, another challenge of medtech that maybe does not exist is getting product-market fit without being able to put a product in front of them or, you know, demo device. It is trickier to do, but they still have to find a way to do it. Yeah. We have been talking a little bit about de-risking, like choosing software development that understands the industry, a regulated industry and medtech or cybersecurity. I know some investors that have changed how they invest, and they only invest in alumni or people in the medtech innovator program as an example or some sort of accelerator program because they have much higher success rates. Because I, in the past, I have talked to investors, and they have said one out of 10 of their investments actually succeed, which you have to get a very high return on an investment to make it worth your while if those are the odds. But on the contrast, if someone goes through this program, like MedTech Innovator, which I know you support, the odds are like 90% of them or something, like 85% succeed. So, it is very different. I know in, like I said, investors are just now saying, "I am only going to invest in people that go through some sort of accelerator program." What is your perspective on that, Darcy? And I will turn over to you, Trevor. Yeah, absolutely. I think that the stat that you mentioned, so one in 10 startups, and this could be slightly changed by now, one in 10 startups survives. One in 10 of those will make it to 5 million in revenue. So, if you think about the odds of that, one in 100 companies making it to 5 million. One in 10 actually exist, but only one in 10 of those will make it to 5 million maximum revenue, is what you are saying? 5 million in revenue. Yes. So, it really, like there are a lot of companies that exist in, you know, in the US alone, you know, probably in the 8 to 10 thousand. There are a lot of startups, so, you know, as an investor, you are looking at where are you going to put your money, where is the best bet? And, you know, the MedTech Innovator program you mentioned, we are also partners, as you are, fantastic program. A lot of it comes down to their selection process, having 1500 applicants and from that selecting, you know, around 150-200 that pitch. And of that, around 40 that actually get into the program on an annual basis. And so, they are really challenging all those things as part of the program, not just what is the core technology, but they are looking at the team. How good is this team? How open to feedback are they? How strong of a product-market fit do they have? Do they understand reimbursement? Do they understand regulatory? So, they really challenge everything to get selected in. And then, when they do get selected in, they go through a pretty intensive mentoring process, pitch competitions, and coming out of that, you know, these are the companies that, you know, there are others that have not went through the program that have been highly successful, but the ones that do go through it, the stats, I think it is over 90% of them, and over 10 years of history, are still either been acquired, went public, or in business. And so, as an investor looking at companies to really target, I think that is a great checkbox for just the quality of companies in that alumni cohort that exists. Yeah, I think playing a little bit of the other side of the conversation is how many of these do you think are companies or products that were already bound to succeed? You mentioned looking at companies where they have a mature regulatory process. They understand how to go through this process with determining reimbursement, understanding this product-market fit, and they have a genuinely good product before going in. And so, I think that accelerator programs like MedTech Innovator, you know, even going back to things such as Y Combinator for more general startups, it is a great way, and the proven success metrics from these are just the numbers are just there. These companies do better, they succeed more, they get more money, they last longer, and they have bigger outcomes. I do think that there is a lot of it where you are not going to see some. Nobody is inventing a problem to trying to find a solution and then getting into MedTech Innovator. They are looking at companies that do have a good fit, that are actually solving a real problem, and they are doing it in a good way to make sure that they are giving those companies a leg up. But yeah, anything to try to avoid. I think from an investor perspective, it makes perfect sense to try to look for these companies which historically are proven to be much more effective and much better companies than these scrappy ones where they are inventing a problem and then trying to invent the solution. Yeah. Because at the end of the day, it is one thing to get a product to market, but I still believe the biggest challenge for MedTech startups will be when they have to sell. It is they are getting it to market or getting to FDA approval is hard enough, but now you have to sell. So, getting to that 5 million in revenue or beyond is incredibly. We see a lot of companies that get to market, and the sales are not there. And that is one of the things that the MedTech Innovator program really does challenge as well, Trevor, as you said, it is not a solution looking for a problem. They have a problem identified that they are solving, and they really look at things like reimbursement, market adoption, you know, do you have the KOLs on board? Because if all those signs exist, all those things are checked off, the process of selling into the market is going to be a better and a lot higher likelihood of success. So, it is so many different things that factor into it, but, you know, as a program, a pretty fantastic one to be part of. You mentioned you do software development for nuclear as well, is that right? Which, nuclear or medtech, which one is more stringent, would you say? So, we have 9001 as a quality management system, which is the base. So, 13485 for medical is definitely more involved. There is a lot more that has to be done for medtech, especially with the FDA and CE Mark and everything else. The nuclear side of things is a step above that. Again, the quality designation we have allows us to write software that controls reactors. We are not actually writing software that controls reactors right now. We are primarily working on inspection and maintenance of them. But the quality management system there is extremely prescriptive, and even more so than 13485, written from the point of view of building a physical reactor as opposed to writing software for it. There is a lot of misunderstanding of what software is and how it is built. So, that does make it a bit more challenging. But I think from a public perspective, to know that the quality management system on the nuclear side is even more stringent is probably a good thing because if something goes wrong on a reactor, it is not ideal. And so, yeah, it is more challenging. Yeah, I guess you also had things like Stuxnet, which I guess is not really a typical nuclear facility, but it was similar, right? So, that was it took advantage of a vulnerability also. Yeah, you know, there has been a few, a few accidents that have happened. If you overall look at the amount of accidents related to oil and gas as opposed to nuclear on a per capita basis, it is non-existent. The nuclear side is extremely safe. But, you know, when you had Fukushima and Chernobyl and the other things which were either gross human error or natural events that are pretty hard to plan for, obviously it gets a lot of attention. But as an industry, it has really taken off again over the last few years. There are a lot of new builds going in, and with all these AI data centers that are extremely power hungry going in across the world right now, we just do not have the power for them. And so, nuclear SMRs in particular are a big investment that is happening to help with that side of things. I did not really think about that perspective because I thought nuclear there was a push to move away from nuclear and have solar and wind farms, but it sounds like with all the data centers, we need more energy than solar or wind farms or anything else can provide. So, we are back to building more nuclear facilities, it sounds like. It is. And right now, I mean, they are building gas and oil and coal plants to support them, and it is really challenging the grid. And there are a lot of actually states in the US now that are pushing back on data centers because they just do not have the infrastructure to power them, and a lot of money going into it. So, the nuclear side was kind of a downward industry for the last 20 years up until 2022, and then some geopolitical events kind of changed the view on that. The challenge with solar and wind is, you know, the sun is not always shining, the wind is not always blowing, and so you need a lot of storage to be able to level it out. Whereas nuclear can be a very sustainable baseline energy source. There are no carbon emissions during generation, so it is one of the cleanest forms of energy, and it is extremely scalable. So, a lot of, a lot of tailwinds pushing that industry along right now, which is great, as opposed to previously where it was from public perception, kind of a lot of pushback. So, I think just the physical footprint too of nuclear is a big factor to consider. I know that compared to larger tech companies or wind farm or something. Yeah. Exactly. So, a little ways past Oakland, when you are driving out from here to Nevada on the 80, there are these massive solar farms covering both sides of the highway, and it takes up so much land, especially in a place like California where we have these huge concentrations of data centers and huge concentrations of AI companies. Land is extremely, extremely expensive here. And so, for when you have, you know, a square mile of land of solar farm comparing that to a square mile of nuclear, you are getting an exponentially higher amount of energy out of that nuclear plant. So, you are able to create so much more with so much less space. I am personally a huge, I love nuclear. I wish that there was a stronger push for it across the board, especially with all these huge problems that we are facing now in the data space, but it is just such a more efficient way to produce this energy. Yeah. Where I grew up in Arkansas was next to a nuclear facility, and I toured that facility a number of times. The only thing that was environmental, and I was naive back then in high school, was they had to cool, you know, they had that big tower where they dropped the water that was hot, and it ran into like a river, so the river for a while was hot. I think that is the only really environmental thing unless there is a leak or something, right? Yeah. Yeah, you need, you need a source of water for cooling, but you know all these big data centers have the exact same thing. They need a lot of, they are very water intensive. So, there are only certain, you know, places, lakes are a great example. We have a lot of great lakes in the region here, and so there is a lot of nuclear that is built right against them. So, you do need that. The data centers need the water. There is so, the data centers need water also from a cooling perspective. You know, most of those data centers are pretty intensive on that side as well. They will need sources of water to go with it, and along with the power for cooling and heat and everything else. I am excited for the push for launching the data centers into space and dealing with the cooling problem through that means. I think still a little ways off, but I do think it is actually closer than we might even think, and I think that is going to be a big push in the future. Do you think so, having to transmit the data back to us quickly or to the to the Earth? Well, that is probably going to be the big constraint is you do not do it quickly, but you can store a massive amount of it for far cheaper. And so, I even think at the current costs of storing and processing a lot of data, it is going to become a little bit more cost effective quickly, as long as you do not need the rapid retrieval. And so, then I think that is going to be that is going to be the next thing to figure out is that rapid retrieval side of things. But I know even like in the Shenzhen Bay in China, and I think they are trying it a little bit here in the San Francisco Bay, but they are also just sinking these data centers into the ocean to try to benefit a little bit from that cooling. Do they actually have any operational ones in the ocean right now? There are a few in China, and I believe there are a couple on the Oakland side in the Bay here as well. Hmm, it seems like that would disturb the ocean and the fish. It would heat up the ocean. Everything disturbs the ocean in the Bay. We are not supposed to eat anything that comes out of the ocean here. You will get mercury poisoning, lead poisoning, you will grow a third eye. It is crazy. Radiation. Yeah. There is so much heavy metal poisoning in the ocean here. Oh wow. Because of all the manufacturing and facilities there or what is causing the heavy metal poisoning? Manufacturing, shipbuilding, even, you know, now what is the big techie hub in Soma here in San Francisco used to just be industrial, and it is still all these converted warehouses everywhere, but they were storing God only knows what out there. And so walking through the, I guess that would be the east side of San Francisco, you will see signs put up on a lot of these buildings, you know, hazardous material site; nobody can enter them, and they are just boarded up and abandoned. They do not like tear them down or clean them up, they just leave them like that, so it is like leaking hazardous material go to the ocean, basically. They leave them like that, and then eventually they convert them to apartments. And so, I am hoping I can cash in on the class action when it happens. But, um, yeah, it leeches out into the San Francisco Bay. And so, there are big notices that you are not supposed to eat anything that comes from inside the Golden Gate Bridge, except for halibut because those only come in temporarily and leave. Oh, no. I just bought a bunch of sardines and oysters. Hopefully, none of those came from that area. There you go. Yeah, I think they are still getting those up in the Humboldt Sea and out by Monterey. Okay. Yeah, you got me hooked on the sardines, and I kind of migrate to oysters as well. Well, I still have some from Portugal from this summer. So, I will have to have some when you come out to San Francisco next. We went to Monaco, and Trevor ate nothing but sardines, and then he slept on the top of this boat, and what happened, Trevor, about the seagull or whatever? Yeah. So, we were going to sleep on top of the boat, and we had, you know, some wine and sardines and bread out, and we were just eating that, and then I fell asleep up there, and I woke up. I felt this little tapping on my chest, and I woke up, I opened my eyes, and there is a seagull right here staring right into my face. And I, you know, I was kind of freaked out for a minute, sat there and stared. But as soon as he saw I woke up, then the seagull freaked out and was running all over the place. You, you might be one of the few people I know, Trevor, that has a real passion for sardines. That is not, it is not the typical go-to that I hear from people. So it is very interesting. You got me hooked on sardines, too. But he ate so many that the seagull probably thought he was a big sardine, you know. He is like imitating sardine odors and stuff. Yeah. But I have got since that trip, I have trying to find like the sardines he bought in Portugal are like really good. So, I try to find good ones as well. I bought some at Whole Foods yesterday, but I do not think they are as good. There is the store not too far from here, and they will sell in a single can of sardines for they have some that are like $90 and super, I do not know what they do with them, honestly, but they have, maybe it is the California tax, but they charge for those now. 90 bucks for a small tin of sardines is pretty expensive. If they gave them to me, I am not sure if I would eat them. So, I apologize as a Canadian, I am so sorry. But that is, yeah, I am not a sardine guy. So, I will wait for you guys to convert me. There you go. Yeah, that is pretty easy to do if you are on a boat in Monaco with the right champagne and bread environment. Pretty awful. Cool. Well, we are coming up on time here, so I like to go around the room and ask for last-minute words of wisdom. So, I will start with Trevor, I usually start with Trevor, and I will go with you, Darcy, next. For our audience, what are some departing words of wisdom? Well, I think I have there are two angles that I want to come about this for. The first is, do not invent your problem. When you are trying to understand what you are doing with your product, you cannot just go through iterations and try to pivot back and forth as fast as you can like you do traditionally in tech within the medical space. So, really drill into your problem statement. What are we trying to solve? Collect feedback from physicians. How would you like to use this product? Does this make sense? Is this effective? I think that another thing that we did not really get into but comes up as a constant concern for medtech startups is how is a physician going to use this? Physicians do not like passwords. They do not like complexity. They do not want to add new steps. They want things to integrate into an existing workflow for it to be easy and efficient for them. So, start with these considerations and then work your way back. And then as the second part of it, just be sure that when you are building this, build it with quality. Do not try to just cobble something together and see if it works. Start with the quality artifacts. Start with your risk management at the beginning. Do not write any code until you understand what you are going to do in the event of a problem. How are you building this code safely? How are you building this code with security in mind? So, those are, I guess, two closing thoughts. Those are excellent. I think the first one, I probably would have said the exact same thing, but because you already did, I will share a couple of others. A lot of what we talked about here are some of the challenges we how long it takes, how much it costs, the chances of success. And so, I do not want people to be concerned or, you know, I should not do this. We do need these technologies. So, there are great resources out there to help make that journey a lot higher, a lot better, a lot easier, a higher likelihood of success. We talked about the MTI program. That is a great example of where you can go to find a network of advisors and people that can support you along the way. If you do not have all the expertise that you need internally, find people that have done it before that you can work with. You know, Blue Goat yourselves on the cyber, for us on the software side of things. There are a lot of great partners out there that can help make that journey a lot easier and take you from the odds of success being on the lower side into, you know, as Trevor mentioned, a problem, a clear problem you are solving, a really easy way of integrating the right partners along the way, the right accelerators along the way, just in taking something and really making an impact, make a difference. So, I think there are a lot of great resources out there, a lot of great groups that can support. So, contact them, talk to them, pick their brains, take advantage of it, because we are all here to help. And I will add two things that my wife Melissa works for the company. She used to be a nurse. And a couple of things she mentioned with MedTech is like the innovator would bring the product to the hospital, and they would try it out, and they would love it, but then they never saw the product again because they got the buy-in from the people that would use it, the users, but they did not get it designed properly from a cost reimbursement strategy, for instance. So, she has seen that problem, and she has also seen the other side where they got it approved from a reimbursement perspective, but nobody wanted to use it because it was not easily adopted in the environment. So, you have to consider both those angles. Cool. Well, we will close here. So, thanks for tuning in, everyone. Hope you found value in this episode, and we hope to see you on the next one.