In this episode of the Grow Fast podcast, host Mark Shriner interviews David Hirschfeld, Founder and CEO of Tekyz, a software development firm with extensive experience working with startups. Hirschfeld shares insights from his 35-year career in software development, emphasizing the importance of building exceptional development teams and helping companies scale effectively. He discusses his philosophy of hiring extremely smart, experienced professionals who can think critically and contribute meaningfully to a project.
The conversation centers on Hirschfeld's "Launch First" methodology, a strategic approach to product development that prioritizes understanding market needs before building a minimum viable product (MVP). Instead of immediately investing $50,000-$150,000 in an MVP, he recommends creating a high-fidelity prototype for $10-$25,000, conducting thorough market research, and identifying early adopters. This approach allows companies to validate product-market fit by securing pre-launch sales and generating revenue to fund further development.
Hirschfeld illustrates his approach with a case study of a healthcare AI startup that pivoted from monitoring wearable devices to creating an AI nurse capable of managing patient transitions and providing personalized healthcare communication. He also discusses the rapidly evolving AI landscape, emphasizing the need for continuous learning and adaptation. Throughout the podcast, Hirschfeld stresses key principles for fast business growth: hire smart people, test everything, document successful processes, and remain flexible in product development.
You can find the whole episode of the Grow Fast Podcast with David Hirschfeld here:
Tekyz Corp
Scaling Smarter Podcast
The Grow Fast Podcast is brought to you by Breeze, the fastest, easiest, and lowest-cost way to process RFPs, RFIs, security questionnaires, and other important documents.
Breeze
This is the transcript for this episode:
Mark Shriner [00:00]
Welcome to The Grow Fast Podcast where we talk with leading sales, marketing and personal growth experts about how companies can accelerate sales, optimize marketing and grow their businesses fast. Let's go.
Mark Shriner [00:15]
Hey, David, how are you?
David Hirschfeld [00:17]
I'm good. How are you doing, Mark?
Mark Shriner [00:18]
Pretty good. Pretty good. We had a couple scheduling back and forth issues there all on me. Thank you for your flexibility and thank you for coming on The Grow Fast Podcast.
David Hirschfeld [00:27]
Oh well, I couldn't be flexible. I couldn't run a software company.
Mark Shriner [00:31]
Oh my gosh, after running a software company only for the last year. I've taken my flexibility to a whole another level. There's little things called bugs and releases and bugs, and every time there's a release, but yeah!
David Hirschfeld [00:46]
We can have a whole another podcast episode then.
Mark Shriner [00:48
Yeah, exactly, exactly. Where about you located?
David Hirschfeld [00:51]
In the San Diego area, town called Vista.
Mark Shriner [00:55]
Yeah, that's San Diego. Is one of my favorite areas. In fact, local people say it's not really San Diego, but that whole area from Del Mar all the way up to Carlsbad. Yeah, you're hiring, let me in. You pay for relocation costs. Let me know I'll be down there in a heartbeat. Okay!
David Hirschfeld [01:16]
Of course, then and so would another 100,000 people, right?
Mark Shriner [01:18]
Exactly, exactly. Wait. I, you know, normally on the grow fast podcast, we talk to people about sales and marketing strategies or proposal writing, with the whole point of is, you know, how companies can grow their business fast. And a lot of times business growth, you know, comes in the context of sales and marketing, right? But there's a whole another element of growing your business fast, which is, you know, building products in a kind of lean, agile way, getting it out to market, getting feedback from the market, and then, you know, creating positive iterations on that. And I have a sense that, you know, you know, looking at your experience and background, that you can kind of come at this, growing your business fast from that kind of ladder aspect of, you know, helping companies scale up their development and stuff. But before we jump into that, maybe you can tell me a little bit about Tekyz and what you guys do?
David Hirschfeld [02:17]
Sure, real quick background, I've been in software development world for 35 years, I started out an enterprise and then launched my own startup in logistics, inventory, route distribution, which, despite every effort on my part and my partner's part, we grew it anyway to 800 customers in 22 countries and sold it in 2000 to a publicly traded firm. So had a successful exit, later had a successful failure, and so I'd been on both sides of this and launched many different startups. So, I really understand and love the startup ecosystem, even though I came from an enterprise. So, we are Tekyz. I founded Tekyz 17 years ago, and we've been working with both startups and scale ups during that time. In particular, startups for over 90 during that period, a few of them very successful, but most of them fail. And they fail for the same reasons that companies struggle to scale fast, and that's they lack product market fit. They lack an understanding of being a manager, not a visionary, and what the difference between those two things are, and the idea of testing and building repeatable processes that they can then scale. So those are all things very near and dear to me and close. So, what Tekyz do is we develop software, and we do it in a really exceptional way. And what I mean by exceptional is exceptional software teams produce certain types of artifacts that the vast majority of other software teams don't produce. So, whenever you're talking to a software team asking for the evidence that they can prove to you that they're exceptional and there, and I could talk about that, that's probably a different podcast, what that looks like. So, well, let's talk about the things that they should do.
Mark Shriner [04:19]
Yeah, you know, I've been running a SAS startup for the last well, it's about a bit, been about a year and a half, and it took us about nine to 10 months to get the product out the door. We get our MVP out there and start circulating the market. And I see there's challenges to grow in this business on both sides, on the development side, and getting that product market fit. But also, you know, the sales and marketing element, and that's kind of where, historically, I've tended to focus. But maybe you can talk about some of the best practices related to, you know, getting the right people on your dev team, getting them working in. The right way, creating what you said, those, you know, those critical artifacts and then explaining, possibly, I think you have something called the launch first method, you know. And then maybe you can tie it all into that as well.
David Hirschfeld [05:12]
Okay, yeah, sure. So start with what makes a competent the kind of evidence artifacts you produce when you're a really competent development team, not competent but exceptional, because there are a lot of and like it's within the industry, there's lots of media mediocrity out there, right? And software development is hard, so you have to work hard just to be mediocre, but to be really exceptional. There's things that you do a little bit differently. One is, there's a constant philosophy of continual improvement in terms of your discipline, your protocols, your procedures, your ability to track, project and track. So for example, when we do our weekly status reports, we have our estimates, our actuals on the status report, along with the estimates for a week to date, month to date, because we estimate how much effort everybody is going to spend every month on specific things and specifically what deliverables we're going to produce during that period, by micro release after micro release after micro release. And then we in our status reports, we have the actuals next to those estimates, and if we vary more than 10% from what we estimate, and that's across the whole project, that we do a post mortem, trying to figure out where we went, either we went off the rails, or where managing requirements got out of control, or whatever the reason that that the actual stuff. And for our largest project last year, and we used to struggle with this, like most companies do, we've gotten really, really good at it, because a lot of other things, I'll talk about what we do. But last year with our largest clients, our variance was 5.6% across the year. So that was, you know, that was a big win for us in terms of how much more accurate we've gotten. One of the artifacts is how estimates are done. So when there's a an estimate, either for feature or for an entire MVP or for a new, you know, module, or whatever, something large or something small, it's broken down into very discrete modules that that are minimum the no smaller than a certain size and no bigger than a certain size, but that are discrete in terms of how much the estimate is for, and that the team is good at accurately estimating not only how much long it's going to take to develop, but all of the other overhead things related to it, such as project management, analysis, design, DevOps, effort, if they're QA, if it's manually done, or or building QA automation, if it's automated, or some blend of the two, all of those things are overhead items to the actual development effort for that piece. Except and that all gets estimated in and then there's a range, right? There's a low and a high on all these things. And what's that variance? And if it's a really, really well-known requirement, then that variance should be very small. If it's something that's going to be exploratory during the design and development, then the variance is going to be much bigger. And still, even with that, you still your ranges should, it should fall somewhere within the range that you set. Architecture is a big one, really confident. Teams design everything around microservices so that microservices have containerized deployment and on demand type of serverless functionality. So most software companies, their products don't have constant demand. They get these peaks and valleys that are pretty extreme. You might even have 1000 users, but at any one time, you only have a few people hitting a button that causes any kind of back-end server functionality. Every once in a while, you have a bunch of people do the same thing, or you may have a few processes that when somebody submits it, it's processing 1000 images, and that's a big lift on your server. So what typical companies do is they build all these things as kind of integrated applications running on servers, and they have to have enough server capacity to handle those peaks, which a competent company does when they're building micro services and they create and all this stuff is loaded and it's containerized. Then we take each of these micro services and split them into their own containers, create them as serverless processes, and they now don't have any cost except when there's demand and. Demand periods can be very short, and you're paying very little for that short period of demand, and then the cost disappears. And instead of having all these servers and 1000s of dollars a month that you're paying at a minimum overhead, your overhead costs are really low until your systems start to really scale up in terms of demand. Competent teams track everything very carefully, and they're very transparent, so all the team members that are involved in particular aspects of the project are always there with customers, and they're all critical formers. And there's a lot more things that exceptional teams do that average teams don't do.
Mark Shriner [10:40]
So, what I'm hearing you saying is that predictability piece, is super important, you know? I mean, it doesn't matter if you're an in-house dev team or if you're working with an outsource team. You as the CEO, the founder of the company, the people who are running the company, you need to know what's going to get done and when it's going to get done and how much, how much, how many resources are required, and if it doesn't get done, why not so? But you know, if you're typically within five to 10% of your estimate, that's Pretty good. You also need to build, make sure that you know you're designing a team that can be optimized for usage. So, you know, you want it to be able to be flexible. So, if you've got one user right now, you scale, you throttle everything down, but also you have 1000 users on, you can throttle up and meet that demand. And so having smart people that understand how to build that kind of predictability and the, you know, cost opposite optimization into your platform is super important, let me, let me ask you this, yeah, you know, I have both. I kind of have a hybrid team, both, you know, employees, but also then we work with a firm that provides outsourced services, right? And, and, I think there I see pros and cons to both sides. But one of the cons I see to outsourcing is that, you know, maybe there's a perception that the people you're outsourcing to maybe aren't as committed to the cause and aren't as knowledgeable about the cause, because they're not, you know, in the in the day to day to day kind of operations. They're definitely not in the office if they're outsourced overseas, but there could be this perception that they're not as committed, right? They're kind of, what's the word, the hired guns, mercenaries, you know? So, yeah. So, what's your counter to that kind of concern?
David Hirschfeld [12:39]
Yeah, that's absolutely true, and it's not because they're offshore, outsource. It's because of the culture of the company that you hired to do those sorts of things. If that's the case, because you can have the same thing with employees that you hire too, right? You have some employees who are really committed to the mission, and other employees that are there to work and a lot of that comes from where you know, who the person is, how much experience they have. There are a lot of things that you know, and that is just the basic process, the basic hiring process that you go through in terms of what you're looking for. So, when we're hiring, everyone on our team has experienced, you know, a lot of options. Teams. Have a lot of really inexperienced people, and one or two people per team that have experience, are proud of managing, corral everybody else, and you end up with, you know, endless quality problems. You have people that are not as smart or lack critical thinking. You know, the whole philosophy of teams like that is that they're a lot less expensive to run. And the problem is you get what you pay for. So, when we hire, everybody has to be experienced, significantly experienced, because it's too painful for people to learn on the job. But more and more importantly than that, they have to be really smart. So, our very first requirement when we're hiring is, are they smart enough to be on this team? Because if they're not, then the rest everybody else on the team has to carry them. And it brings the, you know, basically the team is only as good as the weakest member to a certain degree, because that weak member ends up loading everybody else with either slows everybody down because there's dependencies on the person, or other people have to kind of pick up and support and help that person, and it sends the wrong message to the team that you don't respect them enough to make sure that you're keeping people in that they're going to be working with that are challenging and motivating and smart like they are. That's the very first and you can't fix IQ, right? You can fix everything except IQ, if you know, integrity is a flexible thing. You want to hire people that are focused on the mission and don't care about anything else, but there's always very. Innovations of that. But if you are on a team, they recognize that it's a great team and it's a rare place to work, and they're given their voice, and they're able to express their critical thinking and their suggestions and all and make an investment. All of a sudden, they start to become believers and commit to the team. So those are things that can be adjusted by somebody's work ethic. There has to be a good work ethic there, but that work ethic increases dramatically when they're working with people who love what they do and like the people they're working with; these are all things that the culture can address. IQ you can't experience. You can't but if I had somebody less experienced with a super high IQ and somebody much more experienced who just wasn't as smart, I would think the less experienced, let's say they're only five years experience versus 10 years. I would take that five year person over the 10-year person if they happen to be an outlier, just brilliant. Mark Shriner [15:58]
How do you test for IQ, in the context of the work they're expected to do?
David Hirschfeld [16:05]
We always test them, so we give them projects to do, and we pay them contract fees for these projects. They're all internal stuff that we have them do before we consider whether we're going to hire them or not. So starts with the interview process. There's they have to be able to communicate in an intelligent way and answer questions on the cuff about requirements while we're so we we do a lot of role playing with people in the interview process to see because we also need people that can are good communicators, that can distill the information quickly and and talk about it in an intelligent way. Then, if they're a developer, then it's about how, you know, assess this code, give me your feedback about it. How would you improve it? What's wrong with it? Go ahead and build this thing for me. And now they are quick? And some people, you know, it's very clear when you're dealing with somebody who's really smart, they just stand out in their ability to distill that information and create something out of it. And then we say, Okay, this person's a strong candidate. We're probably going to hire him. Let's give him one or two projects and see how they divide the quality of the work that they do and how quickly they're able to produce it. And really smart people with good experience can produce things dramatically faster than people who are a little less experienced are not quite as smart, so, and then the code they produce is this smart too. So, it's, it's, it's hard to find really good people that are really smart and experienced. But it's not, it's not impossible. And you just have to be willing to, you know, go through 1000 resumes to find, you know, for every person you are actually willing to commit to.
Mark Shriner [17:44]
Okay, everything you're saying makes a lot of sense. I'm just curious about a couple things. Then, if these people are that good and that smart, why would they work for Tekyz and not maybe go to, you know, of course, I can name the big names, the Facebooks, the metas, the Googles, the, you know, Microsoft. You know, what's the attraction for working with a, you know, a firm like yours?
David Hirschfeld [18:10]
Sometimes people come from those firms. We have a guy working for us right now that came from Microsoft, and he is really smart, but he just didn't like working for a good company. So, you know, he felt like he was a cog, and he wanted to be more, be more, feel like he was more part of a smaller team. So sometimes it's that, sometimes it's circumstance they want to work. It used to be a big one as they wanted to work remotely, and they couldn't at the company they were at. And all of our team works remotely. There could be a lot of different reasons. Sometimes they just take the people they're working with right and they're looking for change, and we just catch them at the right time. Somebody that works for us recommends them and says, you want to work for this company. You know, they're doing really cool stuff. These are all really smart people. They're fun to work with, you know. So, it depends,
Mark Shriner [19:08]
Are they all in the US or North America, or do you have people all over the world?
David Hirschfeld [19:12]
No, all offshore, all offshore, okay, yeah, everybody's offshore. I have traveled a lot offshore, 15 trips out of the country, between 2010 and the pandemic, to build my teams. You know the idea that you're going to hire an offshore team? If I was doing that, and I had some contracting group and I was just throwing stuff over the fence, then it would be that typical thing that you hear about. We take over a lot of projects like that. I call them recovery projects, yeah, you know the projects in recovery and those are my favorite, because those clients, and some of them are from companies, big companies that are US based, companies that we take them over from those clients always recognize how different we are from who they were working with before and. They're usually my best references.
Mark Shriner [20:03]
Awesome. So, tell me what is the launch first method?
David Hirschfeld [20:03]
Okay, so, and let me give you a quick Genesis. Why does the launch first method even exist? So, I work with over 90 startups, and like I said, a few of them are really successful. Most of them, though, unfortunately, fail, and they only fail after having made a huge investment and many years of effort. None of them fail after a few months having spent very little money. And they all fail for the same reason. They lack product market fit. They didn't build a product for a market that wanted to pay money for it, and they are and, but, and they waited way too long to prove that model which and the only way, there's only one way to prove product market fit, and that's people are willing to pay for your product, enough money for your product, and enough volume based on the amount of energy you're putting into sales marketing, that you can show a three to one ratio between lifetime value versus cost of acquisition, and that way you've got enough margin in there to reinvest back into the business to accelerate that growth so and the problem is, a lot of these is that founders come in with this concept, with the belief that they're going to be successful because they found a gap in the market, and they know everybody needs this. They're going to be the Savior for some summer, right? And so they're coming into being a startup wearing a black robe, basically preaching the vision. And so, what I try to do is gently peel off that black robe and try to slowly wrap them in a white coat and turn them into clinicians. And launch first is this process of basically saying, let's read, think about your startup. Usually, nascent startups are either at the design stage or even pre design, but they're fun, they have funding, and they're ready to march forward building their MVP. And I say, okay, instead of building MVP, because that's expensive, and your MVP usually has minimum amount of features, and they're hard to sell, and you get all this feedback about what it needs when you put your MVP out before you can start charging for it very often depends on the founder and the product and the market. And so instead of doing that, let's not do that. Let's build a high fidelity prototype, which is a very sophisticated design prototype. It's much less expensive to build than an MVP, and it shows the two year roadmap of the product, not just the initial MVP version, and it looks like a real product, so you can demo it the way you would demo an MVP. You don't give them to clients to use, but you can show them all the workflows on screen functionality, and you can tell the story of what you're building the full story, because it's all designed out at once. And let's do a really, really yeoman's job of doing, understanding who your early adopter is, and that requires doing a problem statement, niche analysis exercise that is very painful and tedious, but it's very inexpensive, right? Because it's the founders' effort, usually, and if they're really committed to it, they can get through it in a couple of weeks. So many founders fatigue through this, and so they take a long time to do it, but it doesn't take that long to do it and do it really well. So launch first, I created a metrics driven methodology for doing this, because your number one job, I believe, as a founder, is considering you have this thing you're going to build, and it will probably be applicable to lots of different niches in the market, and you know, maybe 1015, 20 different niches, and if you distill down the problem statements to root level problems that stakeholders in each of those niches would relate to, when you say the problem statement to them, they go, I hate that. And then they lean forward, right? And they say, can you make that stop? Because right? That's a root level problem statement. And when it's articulated, right, and you may have 10 or 15 of those that you're addressing with your product, then which of all those niches has one or two of your problem statements, where the perceived impact because of that problem to the stakeholder, they perceive that as really impacting them in a bad way, like they need to make that stop. They feel threatened by that problem statement. Their career won't advance. They're going to lose market share. Their revenue is going to whatever, whatever that the reason why that problem statement is so critical to them, and why they'll listen to you is because, because it touches a survival mechanism, right? That's what a real root level problem statement does. And when you know which niche has one or two of those root level problem statements where that perceived impact is really high, they feel very threatened by it. And the cost is really high, we do two matrices with these two with the niches across the top and the problem statements down the side, and then we score all of those intersections. So this is a tedious process, but it's invaluable, because now you're discovery interviews, which you only do one or two for in each niche. If it's a niche you're not really familiar with. A lot of founders are very familiar with half of the niches that they could possibly market to, and not with some of the others. So, they're only reaching out to the ones they really don't know, those stakeholders, and only doing one or two. And now it's very niche, specific assessment of what problems they're really struggling with within the context of what you're trying to build, and then how you talk about your what you're doing, you always talk about it from what problems are you struggling with? Now I'm going to build this product that solves these problems, because as soon as you make that switch, the person you're talking to stops being honest. But if you talk about them and their problems, and how they've dealt with these problems in the past, and why it's such a struggle, and if they've been able to mitigate it or use any product, then you're getting real honest answers from them, because they're talking about themselves and what matters to them.
Mark Shriner [26:11]
But at this point, do you have an MVP that you've mentioned? Do you have something to show them? Or you're just interviewing people, just to understand.
David Hirschfeld [26:18]
You're just interviewing. It's like, yeah, it's just market research. You could be building the wrong thing, and you'll find out really quickly, if you do this, that I should be building what I was talking about. But I do realize that I can pivot just in the concept right now, and there's all this affinity to this other set of problem statements and so, right? So, usually we're doing a design working on the design prototype during this period, the interviews and this process is helping inform the design prototype in terms of where we need to make sure it's really deeply fleshed out in terms of workflow and functionality. And the design prototype is very inexpensive and easy to change and pivot if we're getting different feedback, and it shows a much more rich functionality than what you get at an MVP and can be done much faster.
Mark Shriner [27:08]
So when you say, when you say, very affordable, I'm sure there's a range, but let's just talk about a B to B, SAS platform that you're trying to build, you're trying to roll out as a founder, right? What's the range to get a design prototype out and, you know, approximate cost and timing? Yeah.
David Hirschfeld [27:27]
Okay, so if you go straight into doing design and MVP, which is what most people do, you know you're looking depending on the product and the level of sophistication you're looking at, and this is, I'm assuming it's B to B SAS, you know. And it's some level of sophistication, usually looking at between 50,100 $50,000 typically, what people will spend before they have a viable product that they can start to charge for, and 50,000 on the low side, that rarely ends up being that low. And this isn't just us. This is, you know, this is typical, and it's much higher if you're using and it can be a lot higher than that, depending on the level of sophistication for the product, whether you're using us or offshore resources. I'm assuming you're using solid, competent teams, maybe not exceptional teams, but these are not low cost teams, because you get what you pay for somewhere between 50 and under 50. And I don't know if that jives with what your experience has been to get your MVP ready for market, but that's usually what we see. A design prototype is anywhere from, again, depending on the level of sophistication of what you're doing, is anywhere from 10 to 25,000, for a fully fleshed out looks like a real product when you download.
Mark Shriner [28:50]
Is it using Figma or something, or what?
David Hirschfeld [28:53]
It depends on Figma and or Actuar or both. Maybe the designs are all done in figma, and then we wire it up into action, because you can do a lot more functional the pigments just about there. Now, with all the add ons you can add that we're able to get a lot of it in pigment. Now, one of the problems is that it takes so long to load the damn thing. So when you're trying to do a prototype, you have to make sure you've got it and you're going to demo it. You have to make sure that prototype is loaded before you sit down and start to demo because you don't want those long pauses. It just takes away what you're looking for when you're demoing this. And the reason for doing all this and that niche, and understanding the early adopter is because then we put together a marketing plan to sell to that early adopter to do pre launch sales using the prototype. And if the problem you've identified, they perceive the impact really high, and it costs them enough, and the value you offer them in this. Launch offer is a big enough value that they don't want to miss out, and then they will buy and enough numbers you can prove you've got that three to one ratio before you ever start to build the MPP.
Mark Shriner [30:12]
Makes a lot of sense, and sounds like a smart way to go.
David Hirschfeld [30:15]
Yeah, and you're generating revenue to help fund the development. So, whether it's an exhibit of a brand-new product you're building, or whether it's new features on an existing product, or, you know, it doesn't really matter. It's harder to do this upfront. I always say it's the hard, easy way, right? Because then you're not building your product for product market fit. That's not your reason for building anymore. You're building it for product solution fit, which is the reason why you want to be building it so that you know that once the paying customers are using it, they're engaging with the product, it's satisfying their needs in a way that continues to keep them as customers, right. That's the product solution fit. Product Market Fit is that what I do? I have? Do I know how to communicate what it is I'm selling, and am I selling something into a market where they're willing to pay for that the amount that I need them to pay for, and that you can only prove by getting people to write you a check for the product, even if it's not ready yet.
Mark Shriner [31:19]
Maybe you can share some examples of some success stories of companies that you've worked with that maybe have had to pivot partially or entirely along the way, but then they came out and they found, they found the right product market, product solution fit, and they were off to the races.
David Hirschfeld [31:36]
Okay, so we've been working with a healthcare related software company, and this isn't about launch first, it's just the pivot thing right for the last not quite two years, and they're in the healthcare space, where AI healthcare, providing services to vulnerable populations, Medicaid populations and there and they started out with and monitoring wearable devices with triage capability, real time triage capabilities and AI, an AI nurse that calls the patient when it identifies potential outlier situations that may require somebody to intervene. That was the original month. It has now shifted and the AI nurse originally was just going to be a text based chat nurse and help them schedule and things like that. It has morphed into an AI nurse for doing more customer service related stuff, and nurse as an AI nurse that knows their medical history can transition them from the hospital to long term care, because there's not enough nurses to make that transition for big hospital systems when you've got 50 people a day going from the hospital to a long term care facility and all the things that have to be managed, and the communication, and so this AI nurse can do all that and have a very natural conversation with the person, because she knows the medical history, she knows the capabilities of the facility they're moving to, and what the and what their current condition that they're dealing with is, and who their doctors are, and if they need to connect them with somebody and actually schedule those things for them, and the person can interrupt them and ask questions, say, I'm not sure that's going to work, and then start and talk to them like an apple person, and they just received $5 million in funding because of this pivot that they made with a potential customer. The funding is coming from one of their customers. They have many investors already in the company, but this was their first real big tranche.
Mark Shriner [33:56]
So is this not a traditional kind of VC funded company?
David Hirschfeld [34:02]
Yeah, this was all friends and family and advisory people that the person that that runs his company has a lot of gravitas, because he worked in the National Health Organization, doing a lot of predictive analysis around diseases based on preliminary information that before disease showed any symptoms, and so he has a very strong reputation in the healthcare community. And he was able to recruit a bunch of investors early on, many of whom became advisors that have that have a lot of region in the healthcare space, in government and in local health care, so and then, as a result of continuing to kind of refine this process, test different models, and they and the guys, the CEO of this company, his name is Kevin Longoria. He is just really smart and sensitive. What the market cares about. And when he saw that, that the market that what he was originally trying to deliver to market was going to be complicated for the actual end user, and it wasn't really providing them the value that they needed, and that there was much bigger value, as he started to show this capability at other companies, they would say, you know, we need the voice capability that you've just come out with. This nurse is just powerful, and we needed to offload all this work going to our nurses, which we just don't have the big enough staff, and then all of a sudden, you're talking about, you know, 1000s of calls a day being done by what would normally be very expensive people in critical situations, to make sure that people's transitions from one health facility to another are being addressed, or to remind somebody who's lower income population on Medicaid program to remember to take their meds at a certain time, or to fill a fill a prescription, because they can see that they were prescribed something, and this prescription had not been filled yet. And so many people that are prescribed things in lower income populations don't end up filling a prescription or don't take their meds, and they end up in the hospital with critical situations that cost the healthcare system a fortune. And so this so you get the idea, right?
Mark Shriner [36:23]
It was a great, great pivot. I didn't really understand what the initial, what was the big difference between their initial setup, other than the fact that it seems like that there's a lot more of this virtual care provider, which is an AI agent or bot that is kind of being..
David Hirschfeld [36:42]
Originally was built around the, you know, your wearable device, and predicting potential situations and based upon some biometrics or something like that, right? Exactly and that, and that turned out to be not what the market really needed, because some of these things can be prevented by just some kind of by just like, like, what I was saying with lower income populations, just by sending reminders or making phone call, you know, having a nurse call you, and the nurse is so friendly, and somebody you can have a chat with right on the press. Oh, already hear that, you know, you know, let's talk. Let's talk about that.
Mark Shriner [37:24]
Couple more questions here. You know, you mentioned AI, and we spent the last five minutes talking about this, this startup that is heavily, you know, relying on AI. I see AI from, from your from, from Tekyz perspective, you have both the AI that tools that developers can use, and then you have the actual AI, the applications of AI and LLM that they can deploy to make platforms more effective, or yeah to Yes, so to help those platforms to to achieve their mission, right? So maybe you can talk about, first off, what are the tools that your developers are using to help them, you know, speed up their development. And then talk about, how do they keep abreast of all the different types of LLM and everything like that, and then, and then, and then make recommendations to your customers about, here's what we can do, here's how we can use this LLM or this, this type of AI to to optimize the platform.
David Hirschfeld [38:35]
Yeah. So what you're referring to is what I call AI chaos, okay, right? Because nothing has ever evolved and changed as fast as what the AI industry is doing, the I and of course, that means things that were not consumable six months ago, even by the tech community, except for you know, top developers building sophisticated things using Lang chain and rag models are now, all of a sudden, very consumable, just six months later. And you know even the concept of a rag model, for people that don't know this is where you're using a large language model, like chat, GPT or open, AI or quad or Gemini, whichever one you know, whatever this new one would be in what you're using that in combination with your own machine learning vector database that you built on a specific industry. And even that model is starting to shift, where you don't where that was the only way to have a really smart AI tool for your particular vertical. Now, there's other ways of achieving that, without having to go to the building your own ML machine learning pipeline. About six months ago, nine months ago, there was no other way to do that, so you wanted to have an expert, for example. Like in your business as a financial expert, and not only on what it means to be a financial expert, but also on your particular financial model. You know what your investments are and how they're performing on a daily basis. Now you can accomplish a lot of that stuff without building this sophisticated rag model. There are still lots of times when we want to do that, but, but less and less you just have to do it for everything that is specialized. And there's frameworks for building these that didn't used to exist. And it's just and, and you know, almost weekly you look at the reports on which LLM is the smartest, and that keeps shifting and how smart they are. So, to answer your question, there's a big group of us that meet constantly talking about AI stuff, what's new, what they're doing, what ideas they've had. We experiment a lot with internal things. We're building a lot of our own internal AI models for project estimates. Remember, I talked about being exceptional. Our project estimates are way more detailed than typical software company, and that's expensive for us to create them, and we have a really a methodology spent years honing to produce these estimates, and so we're turning that into an AI model, which our goal is to actually not only be able to produce these estimates with very little effort, but even improve on the estimates with this AI model. That's an example of something internally we're doing. We are an agile company so we use tools to support our daily stand-up meetings and various things that go along with companies that are agile, which many of the most common companies are these days. One of the things that's at times is our daily stand yeah, there's supposed to be 15 minutes. They always extend longer because people get into discussions about things. So, we're building an AI.
Mark Shriner [41:59]
Just let me cut you off there for real quick. Do you daily stand up by customers, or do you do it as an entire team?
David Hirschfeld [42:07]
By customer, by project?
Mark Shriner [42:09]
Okay, so you're in a lot of you're popping in and out of a lot of meetings, I would assume, because you want to keep..
David Hirschfeld [42:16]
I am no longer in most of those. Okay, it took me years. My director of operations. Is just an exceptional Director of Development and Operations. She's exceptional. And she runs all this now, and she continues to improve our standard in every respect. So, I don't need to be there. I probably just got in the way at this point. I ran all this stuff for years and then, but it's been probably four years since I've needed to be in the daily stand up, okay, you know, and then I peek in once in a while, she wants to kick me out because I'll just get away. And that's and that's also part of the philosophy I said, IQ is like, the most important thing. I won't hire somebody if they're not smarter than I am, and I know, and she won't hire somebody if they're not smarter than her, because what happens if they're not as smart as you? Then you're going to recognize what they're not doing quite good enough, and you're going to try to basically carry, pick up the pieces and work with them a lot, spend a lot of time if they're smarter than you in the aspect of the thing that you're hiring them for, then they're going to start to add new value to deliver that delivery that you didn't have before. And they'll and they all start to be the reason why you're improving, instead of just trying to get them up to the level of standard that everybody else is at. So yeah, that was a philosophy I came up with after having hired a few people 1214 years ago that were not smart enough and had a big impact on the really smart people on the team. So that philosophy should happen very solidly.
Mark Shriner [43:49]
Well, what I'm, what I'm hearing you say, is, you know, if you're, if you're trying to build a company and you want to build it fast and you want to be effective, there are some, some key takeaways here. One is, hire smart people. Okay, hire very capable people. Hire people that can predict, to with a high degree of accuracy of how much work they'll get done by when that they'll build a platform that can scale on demand, and that sometimes it may might make sense, instead of building that team yourself, is to just go ahead and outsource that whole process to an organization that has done it in your case, over 90 different times with 90 different companies. Yeah, that's right, and that's, that's, that's one way to grow your business fast.
David Hirschfeld [44:36]
Right? Yeah, that will definitely speed it up. Because if you're trying to do all that recruiting yourself, then you're going to be limited by your capability to do that right. And if you're not a software developer and don't have experience in all these different areas in terms of building teams or recruiting, you're not going to know how to do those things very well. You can. Unless you find somebody that can do it, you know, you bring somebody in that has that experience, then they can build those teams. Or you bring in, or you bring in a team, somebody that assembles these teams for companies as an outsourced thing, and if they're really good, then it's going to accelerate things for you. But a couple things, I don't necessarily hire people that are super accurate at estimating. I hire them because they're really good and productive and can deliver and if they're and we work with them on the estimation part, because that's more of a skill, right? And if they're smart, they pick up skills very fast. But something else about the scaling is, test everything. Everything you believe is true is not true until you test it and you have evidence that it's true. That's why I'd say when you know, on our banner on our website, it says a hyper exceptional software development team. But whenever I talk to somebody and say, I don't want you to just believe I believe me, because I say that, ask me for the evidence, and I will show you the things that we were just talking about, and I show them examples of all these things and other and then you should ask, if you talk to other teams, ask them to show you the same things. And if they can show you these things, and maybe they'll show you other things that are even better, then that's who you should hire. That rarely happens, because they're just not a lot of teams that make it their goal to never be good enough. I mean, it always is something that they can improve on in their strive to improve. Another thing scaling that's not related to what we do specifically, but it's that it's related to everything you do in a company is, once you've tested something and you see that it works, document the process to achieve it in a playbook. Because if you want to bring new people in, and you're going to scale your company and bring somebody in to basically delegate that too. It's an intellectual effort to train them, if it's just in your head or somebody else's head, and now it's in two people's hands, and if you want to bring a third, and so you end up losing the time of the person who knows this stuff until the other person comes up to speed. And then it's still not recorded in a way where you can say, there's our intellectual property as a company, and we can scale. So if you document these playbooks really well with all the references they need and all the nuances captured in the decision process, then you bring somebody new in, and you still train them because you want them to have personal relationship and the culture and how and the delivery kind of Cadence from somebody else, but it will take very little time, because now they've got a book that gives them all the answers to anything they could ask in the context of doing the thing that you know works already, and now you're just repeating, yeah. Playbooks are really critical. Yeah. Test everything. Then once you find something that works, document that workflow in this and have the person that's doing it document and then you get that intellectual property out of their head and into a corporate asset.
Mark Shriner [48:15]
Makes a lot of sense. Hey, David, if any of our listeners or viewers want to get in touch with you. What's the best way to do that?
David Hirschfeld [48:24]
Yeah, and thank you for asking me that, my company is Tekyz. You can find me@tekyz.com and that's spelled T, E, K, Y, Z. The idea is a bunch of Tekyz sitting around the table, tekyz.com, you can email me directly at david@tekyz.com I'd love to hear from you, and I'm pretty easy to find on LinkedIn. David Hirschfeld, or search for Tekyz on LinkedIn, and I'll come right up also. Can I mention my podcast?
Mark Shriner [48:59]
Oh, absolutely!
David Hirschfeld [49:01]
So I also have a new podcast called Scaling Smarter as it turns out. And so, you know, it's about talking to people like you, exactly like you, and how to use AI and automation to scale your business or to launch your business.
Mark Shriner [48:59]tekyz
That's awesome. Well, I'll put links to tekyz.com and to hear your podcast in the show notes. I won't put your email address there, because that's usually..
David Hirschfeld [49:28]
Anybody that listens to this. I want them to have it, but I want problems.
Mark Shriner [49:32]
I don't like to put it anywhere on the web. You know, in the recordings, fine, but once it's there, all kinds of funny stuff happens. But Hey, David, it's been great talking with you. I've learned some lessons. And trust me, I've learned so much over the last year of running breeze docs and going through the development and there were a couple of moments in this conversation where I was like, God, I wish I would have done that. But you know, it's all a process. And like you said, if you're going to if you're in software. Development, it's not easy, and you have to be flexible, right? And you have to learn. So hey, thank you so much for being on The Grow Fast Podcast. And wish you an amazing 2025!
David Hirschfeld [50:10]
Thanks and you too Mark, and thanks for having me.
Mark Shriner [50:13]
Cheers.
