New Podcast Episode—The Hidden Costs of Cheap Lateral Flow Development: Why Experience Matters

Mitzi Rettinger: Hi everyone, and welcome to another episode of Expert Insights. I'm Mitzi Rettinger. Today we're diving into a major issue facing diagnostic developers the hidden costs of choosing cheap lateral flow assay developers. Now I understand the temptation, especially if you're working with limited budgets or you're trying to move really quickly. But more often than not, those cost-saving measures end up costing you more in the long run. In this episode, we'll be talking to doctor Pat Vaughan, Chief Operating Officer at DCN Diagnostics, to explore why experience and technical expertise are critical when you're developing lateral flow assays. Pat has seen firsthand how cutting corners with low-cost developers leads to project delays, failed products, and ultimately missed market opportunities. Whether you're a startup trying to bring an innovative assay to market, a company with an established IVD portfolio, or a nonprofit working on life-saving diagnostics for public health, this episode is for you. We'll also be discussing real-world cases where DCN stepped in to rescue projects, and how to avoid those costly mistakes from the start and stick around, because at the end, we're going to share a free downloadable template to help you evaluate developers for more informed decisions for your projects. Today I'm joined by my friend and my colleague, doctor Pat Vaughan. Pat serves as Chief Operating Officer at DCN Diagnostics, where he oversees the company's IVD, CDMO and CRO services. With a career spanning more than three decades in the IVD industry, Pat has played a pivotal role in advancing lateral flow assay technologies. His background spans multiple diagnostic platforms, including molecular diagnostics and point of care devices. Pat is also known for guiding complex projects from those early-phase feasibility proof of concept all the way through full-scale manufacturing, ensuring that products meet both the regulatory standards and commercial requirements. Pat's leadership has been pivotal and guiding both startups and established companies through the rigorous demands of development through analytical and clinical validation, regulatory approval and manufacturing, all ensuring successful commercialization. Welcome back Pat.

Patrick Vaughan: Hey, Mitzi. Good to be here.

Mitzi: Let's get started by exploring how lateral flow assay development has evolved. Will you explain how the industry looked before COVID and then how it's changed? With so many new players entering the market during and post COVID?

Pat: Sure. Yeah. Well, it's I guess I can start by saying it's certainly changed. You know, lateral flow has been around for several decades now. And over that time period has changed a lot. But obviously with the advent of the pandemic and COVID, it has changed dramatically and the landscape has changed dramatically. Prior to COVID, you know, some of the big sellers in lateral flow would have been near classical malaria, HIV tests and obviously women's health and pregnancy tests. But along came COVID, which changed the dynamics incredibly, and it became one of the largest selling rapid tests, competing with the volumes that we see in HIV and malaria and probably even more. And with that, obviously it changed the whole landscape. Suddenly, there was a huge need in the industry to be able to develop these tests rapidly and then to produce them in extremely large amounts and very, very rapidly. And, you know, it was all done under the microscope of media attention as well. So everything was done in a little bit of a hurry. But of course, everybody decided to get in on the act as well. So you had a lot of people that had no probably previous background in lateral flow suddenly jumping in as well. So that's certainly changed the dynamic. You know, obviously the main players, the big established diagnostic companies and even the smaller ones that had lateral flow products on the market, they obviously took hold of this opportunity and got in on the action. But there was a whole host of other different new players came on the scene as well. You know, I guess everybody looking to get a piece of the action, there was a lot of. Well, I suppose you could call it free money floating around the place. All the governments right around the world started investing heavily in that because they needed a rapid response to the pandemic. So that fueled a lot of anticipation, but a lot of interest in this whole area as well. So it definitely changed with a lot of new faces, new people, new companies coming on scene looking to develop and manufacture and markets rapid COVID tests.

Mitzi: Let's talk about the financing you hit on, you know, the free money. We're seeing more grant-funded programs right now, particularly for public health and infectious disease testing. And it's driven, at least in part, by initiatives that are coming out of BARDA, NIH, FDA, and then some NGOs like FIND, and Bill and Melinda Gates Foundation. How has this influx of these inexperienced developers affected these programs, especially for organizations that have limited budgets?

Pat: Great question. And it certainly has impacted them. I suppose if I take a step back for a second and just kind of look at before we get to the funding and look at the dynamic that's that's involved with funding, obviously it enabled a lot of people to get into the lateral flow and the COVID marketplace, regulatory authorities like the FDA and similar regulatory authorities right around the globe, wanted to make sure that the market had sufficient amounts of these new rapid tests that started with some serology tests for COVID, but obviously then moved on to antigen tests, paralleling the availability of PCR tests or nucleic acid tests as well. But obviously, there was a huge need for rapid antigen tests here in the US, for instance, the FDA started. They decreased the barrier from a 510(k) to for market entry to an EUA, an emergency use authorization. So in one sense, that probably reduced the bar a little bit from a 510(k) or a PMA per se, to be able to get in with, with some limited data. And obviously things were done in a hurry. So maybe the development wasn't as strong as it needed to be in most in a lot of cases. And some of these people, you know, obviously didn't pass the bar even though that bar was low. But I guess when people started developing COVID tests under that, it, you know, within that those guidelines for, let's say, the EUA and so forth, presuming that the bar was lower, but really it didn't prepare them for how it normally is, because once the EU was, once the emergency authorizations went away and you had to go the traditional route, now the bar was back to normal and. Probably. I would say the bar has increased since then and the bar has been increasing a lot, even pre-pandemic and now more exaggerated as well in that. And you and I know as we talk to customers that the requirements for FDA approval have increased dramatically. So in years gone by, we may have spent 1 or 2 months doing validation studies. Now it's 2 or 3 months or more kind of thing like that. And there's an awful lot of follow up with the agency for more and more testing being required and more exacting on the results. So that has really raised the bar for everybody, for every type of test. And that's not just in the US with FDA regulation. The same can be seen in Europe now with the new IVDR regulations as well. That is certainly increased the bar for rapid tests entering the market. And similarly I would say for worldwide for those rapid tests that come under WHO regulation as well. So the bar is very, very high. So it's a bit of a paradox in that a lot of these people, these new developers came into the market when the bar was low. But suddenly now the bar is very high back to traditional or normal run of the mill assays. So now they're finding it more difficult. And, you know, getting back to the funding question that makes it very, very difficult for clients that are funded by the NIH or some EU grant or whatever the case may be. There's a limited fund. There's not an endless pot of money, basically. So these tests have to be developed within a certain time period and within a certain budget. Unfortunately, what we are seeing as well is a lot of people start out on that course with some of these inexperienced developers and of course, run out of money because the product is not developed in time or. It's not developed to the level that can sustain reproducible manufacturing.

Mitzi: So you made a comment earlier where you said, you know, a lot of people got in. They didn't have experience. Everybody was focused on COVID, only they created something low bar. And then now there are a lateral flow assay developer. And so they could do anything. And when I think of this particular example of saying, okay, now I have this not for profit organization that has these limited funds and they're bringing something that might be more complex, like a multiplex infectious disease or something like that, and they're failing. So do you have an example of something where we had this sort of situation that occurred?

Pat: Yes, absolutely. Yeah. So we had a project and actually we're not long after finishing it up, finishing up, and we're in actually a transfer mode at the moment. But this was a program for a neglected tropical disease. It was funded by an NGO, as you mentioned. I think it had been under development for almost two years with another developer. Obviously, the NGO came to us to say, I think we need some help here, maybe in the transfer, but potentially in more in depth. Look at the performance of the assay. We rolled our sleeves up, we dug into the into the program and very, very quickly we were able to see that the problem wasn't just going to be transfer, it was actually the inherent design of the product. It was very poorly designed. You know, some of the conjugations were very poorly done, and it definitely didn't lend itself to being able to be reproduced in manufacturing. So where we came in, as the transfer had kind of pseudo started, we jumped in and got trained as part of that transfer and then started to identify all the all the problems. So at that stage we took over and we really had to redevelop some of the fundamental aspects of the Assay Board from the conjugation. The reagents that were being used were incredibly expensive, so there was no way that product could be sustained in a low to middle income country with the cost of those reagents. So we had to reselect some of the reagents. Some of them we had to reselect and pick different ones. Other ones, we actually were able to manipulate the design, so we were able to use less of the reagent and ended up with a very robust process and product with the performance that was required by the original specification. Now we're happily transferring it into that LMIC country into manufacture there, you know, again, inexperience. Just because you can produce a prototype doesn't mean it's a product and doesn't mean you can make it sustainably and reproducible as well. So that was a very unfortunate incident from the point of view of this was a funded project for several for a couple of years. And, you know, money had to be re spent basically to do things correctly.

Mitzi: Right. It sounds like DCN's agility and collaborative process really helps you overcome some of that resistance and generate something that was more reproducible and also was able to reduce the cost, which is critical, especially for trying to put diagnostics into the mix. So that's fantastic. So if we go back to COVID and how it changed things, it really did create a massive demand for rapid diagnostics. And as we just discussed, we saw this flood of the new companies that entered the space. Can you talk about the impact this had on product quality? And you kind of hit that already in your previous example, but also just bringing products to market that were successful?

Pat: Yeah, absolutely. And you know, when I was kind of brainstorming and thinking about this podcast coming up and thinking about different aspects of this scenario, I started to think really that it's not just about the impact it has had, but I think it's really going to signify the impact we will see yet. Because I think what's what's been happening is there's been a lot of people jumped into the market, started developing these tests. As we've seen, they're not successful. Some of them will be, of course, but a lot of them will not be. I think what will happen as well is that obviously those products are not going to come to market on time, but how that's going to be realized is there's going to be a delay in getting good products to the market. So I think post-pandemic you're going to see a lull in the amount of good products coming to the market because the bandwidth is going to be taken up by these developers that think they can do it. But obviously the timeline is going to be extended, the budgets are going to have to be inflated, and that will all result in the timeline of that product getting to market. So what you're going to see is potentially a lull in good quality products coming to the market until eventually they get it right. Or I'm biased, but unless until such time as they, they find, you know, developers like DCN and come to us and we can fix their problems basically, and get them a good robust manufacturer product and get it onto the market.

Mitzi: So these struggles to bring the products and you already even mentioned something talking about the difference between a prototype and a product earlier. But what are some of the common issues that you see occur? What are some of those reasons why they fail?

Pat: It may seem obvious to us, but firstly, I think some of them think that the end goal is a prototype and not a product. And there's a vast difference, right? But I think the first point of failure is that those prototypes and even moving further along, they're failing to meet some of the specifications set out initially. Okay. They may hit it once or twice during development and think, oh, we're there. But specifications are there to be hit by the final product and they must be hit sustainably every time you manufacture a batch of product as well. So I think that's one of the main thing that's happening, is that the performance isn't sustainable, so that you every time you go to make a batch that you can do it, or when you transfer it to manufacturing or to another manufacturer or into an LMIC or into the you're transferring it anywhere into a manufacturer here in the US or in Europe, I think that's where the problems start, start to appear. And basically then a lot of that can be driven by the robustness of the manufacturing process. You know, the fundamental design doesn't lend itself to a good design for manufacturing. And, you know, basically you need to make it easy for the manufacturing personnel, right? They should. They're not the development scientists. They shouldn't have to scratch their head and figure out, how do we do this. They should be following clear instructions and the product should pop out every time. So I think that's where it kind of falls down in that it's poor design, maybe just barely hitting some specifications, but it all falls apart when you try to do, you know, high-throughput and reoccurring manufacturing, everything from selecting maybe expensive but poorer reagents, maybe from poorer suppliers potentially, and then not having a sustained long-term manufacturer or product, as you said as well, a prototype is not a product. You know, I think it's important to point out the difference between a prototype and a product. A prototype is something that can be done maybe just once or maybe just a few times, but it's typically the output of a feasibility study by a development scientist. A product is something that's gone all the way through full development and optimization, and that can be reproduced and is reproduced robustly and manufactured every time the manufacturing personnel go to go to make it. And being reproducible, being robust. Every time you go to make a new batch of product, you could potentially be dealing with a new batch of membrane or a new batch of antibody or antigen. All of those have to come together with all the inherent variations and tolerances that are there, and everybody should expect them to be there every time you pull them together, a product needs to pop out, and that's only the result of full on development optimization and the development and a full, robust manufacturing process to generate the product. And that's the key difference between a product and a prototype. It reminds me of another incident we had where another client came to us from another developer. They had gone through feasibility or what they called feasibility, and had started to enter phase two development. And really, our client just got a little bit. When I say impatient, I guess they were a little bit disappointed with the progress with the both the performance and also where they could see the development going or I guess I should say, where they saw it wasn't going basically, and that was heading towards a robust product. So they came to us, gave us everything they had. And again, what we looked at there was. There was the basis of, of some feasibility, but even still the performance of that, even that prototype was, was shaky at best, basically. So we had to delve into some of the fundamentals of the design. We were able to change them very quickly and then move through a full on phase two optimization and development got through the whole thing, did full verification, validation, and that product is now undergoing FDA clinical trials. Okay. So we were able to move it from you know, it was kind of wallowing basically. And I think our client just felt that they were being neglected really. And but I think part of the reason for that is maybe that developer got as far as feasibility and just simply didn't, didn't know what to do with that prototype afterwards and how to make it a product.

Mitzi: Yeah. When I hear the story, I always think technical challenge. Like there, there were issues and they just don't know what to do next. And I think being able to troubleshoot like a complicated process and moving it through the prototype to the product, it does, you know, I've noticed it requires years at the bench. You know, people who have done this so many times that kind of becomes second nature. And it's interesting because I look at DCN's bench and I see expertise that goes way back. And in fact, I think we have employee number one from 2006 is still managing DCN programs. And that's just really impressive. That's not something you teach. It's something that people develop over time. So that's that's good. I guess that brings us to risk. So let's talk a little bit about risk. From your experience, what are some of the hidden costs of working with low cost, inexperienced developers?

Pat: Well, there are a lot I suppose. Unfortunately, it all manifests itself in extra cost because what it ultimately results in is that you have to repeat something and delve back in to what you thought was a good idea. So one thing that I think is a very important point to make is obviously when you deal with some of these relatively new developers, what you'll probably find, and you need to be very cautious, is that they will most likely tell you what you want to hear. Okay. Would you talk to an experienced developer like DCN? And we're going to tell you what you need to hear or what you need to know. And there's a there's a huge difference between those two things. So, you know, I'm not going to sugarcoat something for you. If you come and chat with DCN about doing, I'm going to tell you exactly what I feel it's going to take to get you right through feasibility and your prototypes, right through to a product. You may or may not like it, but you know it's going to be pretty close to what it's going to take. We've had years and years of experience, and it takes a lot of hard work to get to a product, people. Think of phase as simple tests. Well, they are simple tests for the end user. They are very difficult tests to develop and manufacture. But you have to make the manufacturing as easy as possible so that you can keep costs low, but keep them reproducible as well. So you have to have very good design and development in there. You know, it kind of reminds me as well of another client that came to us. They had been with another developer had gone through quite a lot of development. I think they were probably somewhere through phase two optimization development. But again, just I guess the client started getting nervous because there was not enough forward progress being made. So they came to us, we took it on, we brought it in. We obviously feasibility was complete and as I said, started phase two, so we started to look at it. We started to take a look at the instructions, start to make some prototypes from the instructions that we receive. And soon we were able to identify that the prototypes were not performing like they should. They weren't hitting the specifications that were needed. So we looked a little bit more, and that one ended up being such that it wasn't hitting anywhere near the sensitivity. And no matter what label we tried, there was no getting around using the original label that the client or the previous developer had selected was nowhere near it. We had some other visual labels that we that we looked at that increased it, but still not to where it would hit the performance that the client really needed to make a good product on the market. So it required a switch to a fluorescent label, which meant that it needed a reader. They were already intending to have a reader, but obviously it was a change in reader because it would need a fluorescent readers. What ended up in that case is that. Obviously it was just going to require so much more development that client obviously decided not to proceed with the product. In one sense, they came to us after spending a lot of money. We spent a little bit of time on it and helped clarify for them, really, that the product where they were going, they weren't going to get where they needed to. From a point of view of a viable product on the market, and it would have required much further investment into a fluorescent assay with a fluorescent reader. And decided to call it quits on that one. So, you know, they were very thankful. They were disappointed that they weren't getting the product per se. They had the option of obviously keeping on going, but they had sunk so much money into the previous development that they just didn't feel it was worth the return on investment proceeding, which is very disappointing. When I see cases like this, I you know, I am saddened because I know if they had come to us in the first place, we would have delivered a product for them that would have been suitable for the market.

Mitzi: You know, it sounds like transparency, although difficult in the short term, really does show the company's integrity. And that's what it's about. It's being a great partner. You know, you say you're an extension of someone's team when you're a CDMO or a CRO, but it's times like this that really are showing that you are, because we pretty much told them it wasn't a good idea to move forward, will be someone they'll want to work with again in the future, I'm sure. Yeah, absolutely. We've talked the first half of this podcast a lot about what goes wrong. If you make price just the main selection criteria, or you're not really fully looking at the developer holistically. Let's now talk about what should we be prioritizing beyond price. So, Pat, if you were you had this great idea for a rapid diagnostic and you were going to select a CDMO, what would be your criteria? What would you be looking for?

Pat: Yeah, that's a good question to kind of put your put yourself on the other side of the table, you know, or the other side of a conversation, probably sum it up in that it may sound very simple, but it's one size does not fit all. Okay. So everybody and Mitzi, you and I talk to a lot of clients that come through the door and start discussing what they want to do and stuff, and everybody has a different angle, right? They all want to achieve a product on the market. But there's there are different ways of getting there depending on the client, depending on the products, you know, the target market, the sample type, whatever the case may be. So really, I think the first thing is, you know, be very cautious when you're talking to a developer. If they're saying, well, we have X, Y and Z and we're going to slot you into this kind of machine, and we're going to do this because we do this well. And off you go. Well, I can safely say is the chances of success there are reduced because now you're boxed in, okay. You're boxed into their system. And we all know that developing lateral flow assays can be challenging, right. Especially to make a product, not the prototype that works once, but a product that can be made over and over again. That's the way DCN approaches it as well, is that we use labels, materials, from everybody. We're not saying we're only going to use this label because we make it ourselves, or we buy it from our best friend, our best, our partner company. And we're only using this material from this company. We look at the plethora of all reagents and materials out there and select the best one for that assay and for the market that they're targeting. So I think that's going to be very, very important in making sure that, as I said, one size doesn't fit all. You need to talk to developers or work with developers that look at everything possible that's out there and select the best combination of reagents and materials to get you to where you need. I would sum that up and saying, if somebody says, I've got a magic formula for a label, well, that's great, but you should be trying others as well, because the reagents simply may not mesh with that magical label and produce a good product at the end of it, so that's important. Other things, like as lateral flow on a point of care test, develop and get more exacting and higher performing these days as well. Obviously, a lot of people now want fully quantitative tests. So that requires use of a reader. So very important to be able to get a good quality reader to associate and put with your assay to create that system that you're going to take to the market. We're very fortunate here at DCN that we've developed a really good, excellent reader that we can provide to our clients as well. But I think the beauty of that as well is not just it's a reader, right. There are there are several other readers out there, but I think you have the ability of now a developer working hand in hand, developing your assay and developing your reader, or adapting or customizing your reader at the same time. So you have scientists and engineers. Communicating daily to provide that system, that you're going to take that assay and that reader system so that you can get a fully functional product to market. And remember, it's not just about the development of it. It's not about developing the reader or developing the assay. It's developing that system or the process that will produce it every time. So with a fully quantitative test, it will require a full on calibration curve every time. So you need a process that can develop that. How do you get that calibration curve into the reader for every batch? That process of how you do that, not just how you develop it, but how you produce it, is so vitally important. And that's something that DCN can provide our clients as well. I suppose then it's it's more somebody that can provide an end to end solutions. So a lot of people can say they can develop the prototype or even develop the product. But how do you do they have the experience in producing it in manufacturing as a product? Okay. So can you do it once it works great, you get great results, but then have you developed the process that will make it every time and that's crucial. So working with somebody that can go end to end, it can take it right through from the concept, from a sheet of paper with a specification on it, right through development and right into manufacturing. And obviously then of course, take you through to clinical trials as well. Somebody that can see the picture right from the first specification, right through to when it's a product and fully authorized by a regulatory authority as well. It takes a lot of experience to know all the nuances that you need to go through as you're going from A to Z in that process. And I think dealing with an experienced developer like DCN would provide that quality service to you that you just will not get from inexperienced developers that have only been doing this since COVID. Basically,

Mitzi: I get what you're saying about being able to provide that end to end, even if a client just if they only wanted you to do a piece of the process. I think understanding the whole process makes a huge difference. What do you think about things like certification, documentation, communication? What is important to you in those areas?

Pat: Well, I would say all of the above. Okay. So one is the communication with the client and the transparency. Okay. So I look at DCN as we're experts in assay development, we may not be experts are probably not the expert in that specific clinical area of wherever that product is going to be used. The client is most likely going to be one of the most experienced people. Just understanding that marketplace and where that test should be used, or at least they should be. Right? So you need to listen to them, right? Listen to what they want to do. You shouldn't be developing and producing a product that we think is the product. It needs to meet that market needs, so that communication is going to be vital. And then documentation, of course. I mean, everything that we do and every product that's developed should be done by design control. That's how we operate. Everything is done through design control. Everything is documented. We start with a set of inputs, we finish with a set of outputs. And most importantly, we finish with a manufacturer product that's clearly vitally important throughout the whole process. And you made a good point in that if somebody just comes to DCN just for a part of that process, us with our experience, understanding the entirety of it, we can slot in very well into that process because we have that depth of experience. So we can take a piece of that and maybe, you know, overcome some of the inefficiencies or deficits that may exist in that process in the in that product's life cycle, and take it on board and bring the depth of experience that we have from like looking at the full process and play our part in the part that we're being challenged with. So I think that's vitally important.

Mitzi: What does a typical LFA development contract look like and what are key areas should developers focus on when they're comparing potential partners? Kind of taking it a little a little bit deeper dive here. Are there elements within that contract or that proposal that's being put forward that they should be looking for some keywords and some things that would be warning signs if they're not there?

Pat: Yeah. There are some key points, right. One is first, before you ever get to a scope of work I would say is specifications or design inputs okay. So you need to have a conversation with the client and say what kind of product do you want. What are the specifications? What performance criteria do you want to hit. Who's going to use it? For instance who's going to regulate it? If you're going to take it to a regulatory authority, what are they going to need? And even asking something like what's the intended use of the kit? You know, somebody may say, well, I just want to measure this protein. That's fine. That's what the. That's what the assay will do. But what's the intended use or what's the claim you're going to make on your kit on your test or kit. And that's going to be a vital starting point. Once you have that and understand what that is, then you can come up with a scope of work to be able to start the development process and take it right through. And then what I would typically break that up into is the first part is kind of proof of concept and feasibility, and that's coming up with your with your prototype. Back to that word again. That's the process where you go and say, okay, are there reagents available and materials available? I can put formulations together and devise prototypes that will demonstrate that you can meet the specifications or hit performance requirements that are needed for that assay in the marketplace. Once you feel comfortable that can be done, then you move on to the next phase, which is phase two, which is full blown optimization and development. In there, you're taking the prototype and making it a product. To make it a product, you have to be able to design the process to make it so. Inherent in designing the product as to how it functions and hit all those performance criteria is going to be. Another phrase that you should be aware of is which is designed for manufacturing. Not alone. Does the test have to hit a certain performance? You have to be able to manufacture it. So that design, it has to be designed for manufacture. So you have to be able to make that test over and over again another vitally important part. And then obviously how is it going to be assessed in the marketplace? How are you going to get it onto the market? What validation studies do you have to do that both the analytical studies, but also then the clinical validation. What does that need to do? What are the regulatory requirements from predicate devices or similar products already on the market? How are you going to have to compare yourself to those? So you need to know how to design all your studies to make sure that you're going to tick all the boxes and get the performance you need relative to some comparative device or some gold standard, and then, you know, providing a full scale of that background knowledge from flex studies and guard band studies that provide vital information to your. Ultimately, when this product is on the market, you're going to have your tech support people taking calls from customers saying, I don't understand this or I'm observing this. If they're armed with a full repertoire of all those flex studies that were done during development, they're going to have a, you know, a master cheat sheet, basically, of being able to decipher what's going on in the customer's hands, and you're going to be able to answer many of your customer's queries and complaints right up front from a good, solid bank of documentation and knowledge, basically from your development program. And that's going to be vital, obviously, because product development isn't about just developing the product and getting and saying and waving it in your hand. It's about being able to put it on the market and have it sustained on the market and having happy customers. So vital to create that bank of knowledge about how the test works or what can go wrong if it's incorrectly used by the end user, so that you can quickly alleviate the issues that your end user are having. So. I think I hit on several key aspects there that inputs are specifications. The scope of work, feasibility, optimization and development. Developing a manufacturing process or design for manufacturing through to getting it ready for regulatory approval. Be it analytical or clinical validation, and then having a bank of information and knowledge to support the product post-launch.

Mitzi: That's good. Pat, a couple of times in our conversation you've mentioned should have come to DCN. So why is DCN the right choice for companies looking to avoid all these pitfalls of working with either inexperienced or maybe, maybe even just less resourced developers?

Pat: Well, I suppose simply put, experience right? So we've been doing this for, you know, for almost two decades. And the expert team we have, if collectively we've been at this for, I don't know, a couple of centuries. There's no substitute for that experience and no substitute for understanding what it takes to do that. It's not just about going to the lab bench, you know, stripping a membrane, making a conjugate, putting it together and seeing a test line. That's not what assay development is about. It's about the complete picture of taking specifications and looking at what the customer needs, the claims that they're going to make on their assay, and realizing what it will take to have that product on the market and everything in between. And that only comes from experience. You know, just because you were able to manage to, you know, develop a COVID test and get it approved under emergency use authorization doesn't make you a developer that you can turn your or your hand to basically any other type of assay. There's a whole host of different assays. There's a whole host of different matrices that you have to work with. Some of them are a lot more challenging than others and just having that depth of experience, you know. Sensitivity. You may come across a marker that is, you know, just present in very, very low picogram per mil amounts. And how are you going to detect that? There's a whole host of hurdles that you're going to have to face. And really it comes with experience. But also then you mentioned that word earlier transparency as well. Dealing with DCN. And you're going to you're going to have transparency all the time. We're going to lead you every step of the way and talk to you, discuss everything with you. We're not going to make any decisions for you. We'll make decisions with you and really guiding you every step of the way to full product launch. And, you know, it comes back to what I said earlier, we're going to tell you what you need to hear, not maybe what you want to hear or maybe what your investors want to hear. We're going to tell you how it is not sugarcoat for you and tell you this is exactly and this is based on experience. It will take you this predicted estimated timeline and this estimated budget. And we're very kind. Often that you will get there for that and not just say no, we can do it for in half the time and half the money and really leave you hanging at the end of that. We're not going to do that.

Mitzi: Thank you Pat. So to wrap things up, I mean, my takeaway for listeners is that I guess one of the most important things for you to think about in choosing your LFA developer would be expertise, agility, collaboration, transparency, service excellence. That's what I've heard through this as you've been answering these questions. Is there anything, Pat, that you would like to be a key takeaway for the listeners?

Pat: You just need to make sure that you're working with somebody that is communicating has a lot of transparency, but just make sure they have the experience that they have done it before. They and it's not that they've just developed an assay feasibility or produced a prototype. Have they developed a product? And what I mean by a product is this is a product that can be manufactured over and over again, and that's launched on the market and successfully taking its place in the marketplace. Has somebody done that? Because there are a lot of pitfalls all the way through that process, and it's really only dealing with somebody that has gone through that, that can guide you through that, and that's going to be the key to success.

Mitzi: Thank you Pat. That's all for today. A huge thank you to you for joining us and sharing your expert insights and perspective on what's important in selecting a development partner. And thank you for listening. And don't forget to download your free template and visit the DCN Diagnostics website to learn more about how we can help bring your diagnostic products to market. I'm Mitzi Rettinger, your host, in another episode of Expert Insights.