Navigating Startup Success with Strategic Product Development

Featured Image: Navigating Startup Success with Strategic Product Development

In this episode of Grow Fast Podcast, host Mark sits down with David Hirschfeld, founder of Tekyz, to dive deep into the strategies behind rapid business growth through smarter product development and scaling. David shares insights on building exceptional software teams, mastering the “launch-first” method to achieve product-market fit faster, and navigating the evolving AI landscape. From hiring practices that prioritize intelligence to real-world success stories, this conversation offers practical advice for startups and scale-ups looking to grow efficiently and sustainably.

Key Takeaways:

  • Build Exceptional Teams: Focus on intelligence, rigorous hiring, and continuous improvement to ensure predictable and optimized project outcomes.
  • Adopt the Launch-First Method: Validate product ideas early through high-fidelity prototypes and niche targeting before heavy investment.
  • Prioritize Smart Hiring: Intelligence often outweighs experience; invest in candidates who can think critically and drive innovation.
  • Use Microservices for Scalability: Architect systems for flexibility and cost optimization from the start.
  • Adapt Quickly with AI: Leverage simple, accessible AI tools to enhance internal processes and stay competitive in a rapidly changing tech landscape.
  • Document and Scale: Create detailed playbooks from successful practices to support fast, repeatable growth.

Grow Fast Podcast with David Hirschfeld of Tekyz

This podcast episode discusses strategies for rapid business growth, focusing on the crucial role of efficient product development and scaling. Mark, the host, interviews David Hirschfeld, founder of Tekyz, a software development company specializing in helping startups and scale-ups. The conversation explores best practices in software development, team building, and the “launch-first” method for achieving product-market fit.

Building Exceptional Software Teams

David emphasizes the importance of building exceptional software teams, highlighting key characteristics that differentiate them from mediocre ones. These include a commitment to continuous improvement, meticulous tracking of estimates versus actuals, and conducting post-mortems to analyze deviations. He cites Tekyz’s achievement of a 5.6% variance on their largest project as a testament to their accuracy. David also stresses the importance of granular estimations, incorporating all overhead costs, and designing architecture around microservices for cost optimization and scalability.

The Importance of Smart Teams and Hiring Practices

Mark agrees on the importance of predictability and cost optimization, prompting a discussion about the perceived drawbacks of outsourcing. David counters concerns about outsourced teams lacking commitment by emphasizing the importance of company culture. He details Tekyz’s rigorous hiring process, prioritizing intelligence and experience. David explains that they test candidates with paid internal projects to assess their abilities and prioritize intelligence above all else, even over experience in some cases. He explains his philosophy of hiring individuals smarter than himself to ensure continuous improvement and innovation.

The Launch-First Method

David introduces the “launch-first” method, developed from his experience with over 90 startups. He observes that most startups fail due to a lack of product-market fit, often after significant investment. The launch-first method aims to mitigate this risk by focusing on early validation. Instead of building a full MVP, David advocates for creating a high-fidelity prototype, which is less expensive and allows for demonstration of a broader product vision. This prototype is then used for pre-launch sales, targeting early adopters identified through a rigorous problem-state niche analysis. This process helps determine which niche experiences the most significant impact and cost from the problem being addressed, allowing for targeted marketing and early revenue generation.

Real-World Pivot and Success Story

David shares a success story of a healthcare software company that pivoted from a wearable device and predictive analysis model to an AI-powered virtual nurse. This pivot, driven by market feedback and the CEO’s responsiveness, led to a $5 million investment and a more valuable product-solution fit. The AI nurse now handles customer service, patient transitions, and medication reminders, addressing critical needs within the healthcare system.

Navigating AI Chaos

The conversation shifts to the rapidly evolving landscape of AI. David acknowledges the “AI chaos” and the increasing accessibility of AI tools. He discusses the shift from complex RAG models to simpler, more readily available AI solutions. Tekyz utilizes AI internally for project estimation and other tasks, constantly experimenting and adapting to new advancements.

Transcript

[0:05–0:16] Mark: 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. Hey, David.

[0:17–0:27] Mark: How are you? I’m good. How are you doing, Mark? 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.

[0:27–0:30] David: Oh, well, I couldn’t be flexible. I couldn’t run a software company.

[0:31–0:43] Mark: Oh, my gosh. After running a software company only for last year, I’ve taken my flexibility to a whole other level. There’s little things called bugs and releases and bugs, and every time there’s a release, there’s that.

[0:44–0:47] David: We have to have a whole other podcast episode then.

[0:47–1:02] Mark: Yeah, exactly, exactly. Whereabouts are you located? In the San Diego area, a town called Vista. 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.

[1:03–1:10] Mark: We’re in Mexico. Yeah. If you’re hiring and you pay for relocation costs, let me know. I’ll be down there in a heartbeat, okay?

[1:10–1:14] David: Right. Yeah, of course. And so would another 100,000 people, right?

[1:15–1:27] Mark: Exactly. Exactly. Normally on the Growth Fast Podcast, we talk to people about sales and marketing strategies or proposal writing. The whole point of is how companies can grow their business fast.

[1:27–1:44] Mark: And a lot of times business growth, it comes in the context of sales and marketing, right? But there’s a whole other element of growing your business fast, which is building products in a kind of lean, agile way, getting it out to market, getting feedback from the market, and then creating positive iterations on that.

[1:44–1:57] Mark: And I have a sense that, 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.

[1:57–2:04] Mark: But before we jump into that, maybe you can tell me a little bit about TechEuth and what you guys do. Sure.

[2:05–2:27] David: And real quick background, I’ve been in the software development world for 35 years. I started out in 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.

[2:27–2:42] David: So I had a successful exit. Later, I 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 enterprise.

[2:42–2:55] David: So 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.

[2:56–3:20] David: 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 processors that they can then scale.

[3:21–3:40] David: So those are all things very near and dear to the influence. So what Tekyz does 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.

[3:41–3:52] David: So whenever you’re talking to a software team, ask them for the evidence that they can prove to you that they’re exceptional. And I could talk about that. That’s probably a different podcast, what that looks like.

[3:53–3:58] David: So let’s talk about the things that we do to help companies, what they should do.

[3:58–4:10] Mark: You know, I’ve been running a SaaS startup for the last, well, it’s been about a year and a half, and it took us about 9 to 10 months to get the product out the door. we get our MVP out there and start circulating the market.

[4:11–4:23] Mark: 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 the sales and marketing element. And that’s kind of where historically I’ve tended to focus.

[4:24–4:43] Mark: But maybe you can talk about some of the best practices related to getting the right people on your dev team, getting them working in the right way, creating what you said, those critical artifacts, and then explain possibly, I think you have something called the launch-first method, and then maybe you can tie it all into that as well.

[4:43–4:55] David: Okay, yeah, sure. So start with what makes a competent, the kind of evidence or artifacts you produce when you’re a really competent development team. Not competent, but exceptional.

[4:55–5:06] David: Because there are a lot of, and like it’s within the industry, there’s lots of mediocrity out there, right? And software development is hard, So you have to work hard just to be mediocre.

[5:07–5:22] David: But to be really exceptional, there’s things that you do a little bit differently. One is there’s a philosophy of continual improvement in terms of your discipline, your protocols, your procedures, your ability to track, project and track.

[5:23–5:47] David: 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.

[5:48–6:03] David: And then 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.

[6:03–6:23] David: Either we went off the rails or where managing requirements got out of control or whatever the reason that the actualist doesn’t meet the aspect. 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 don’t talk about what we do.

[6:24–6:35] David: But last year with our largest clients, our variance was 5.6% across the year. So that was a big win for us in terms of how much more accurate we’ve gotten.

[6:35–7:06] David: One of the artifacts is how estimates are done. So when there’s an estimate either for a feature or for an entire MVP or for a new module or whatever, something large or something small, it’s broken down into very discrete modules that are minimum, but 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,

[7:06–7:20] David: but all of the other overhead things related to it, such as project management, analysis, design, DevOps, effort if it’s manually done or building QA automation if it’s automated or some blend of the two.

[7:20–7:31] David: So all of those things are overhead items to the actual development effort for that piece. And that all gets estimated in, and then there’s a range, right? There’s a low and a high on all these things.

[7:31–7:43] David: 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 explored for you during the design and development, then the variance is going to be much bigger.

[7:43–8:03] David: And still, even with that, your range should fall somewhere within the range that you set. Architecture is a big one. It’s really confident teams design everything around microservices so that microservices are containerized deployment and on-demand the type of serverless functionality.

[8:04–8:20] David: So among software companies, their products don’t have constant demand. They’ve hit these peaks and valleys that are pretty extreme. You might even have 1,000 users, but at any one time, you only have a few people hitting a button that causes any kind of back-end server functionality.

[8:20–8:31] David: 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 1,000 images, and that’s a big lift on your server.

[8:31–8:41] David: 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.

[8:42–8:59] David: What the competent companies do when they’re building microservices and all this stuff is loaded and is containerized, then you can take each of these microservices 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.

[8:59–9:17] David: 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 thousands of dollars a month that you’re paying at a minimum overhead, that your overhead costs are really low until your systems start to really scale up in terms of demand.

[9:18–9:30] David: 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 partners.

[9:30–9:35] David: And there’s a lot more things that exceptional teams do that average teams don’t do.

[9:36–9:56] Mark: So what I’m hearing you saying is that predictability piece is super important. And, you know, I mean, it doesn’t matter if you’re an in-house dev team or if you’re working with an outsourced team. You, as the CEO, the founder, 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 many resources are required.

[9:57–10:11] Mark: And if it doesn’t get done, why not? But, you know, if you’re typically within 5% to 10% of your estimate, that’s pretty good. you also need to be able to make sure that you’re designing a team that can be optimized for usage.

[10:11–10:21] Mark: 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 all of a sudden you have 1,000 users on, you can throttle up and meet that demand.

[10:22–10:32] Mark: And so having smart people that understand how to build that kind of predictability and the cost optimization into your platform is super important.

[10:32–10:44] Mark: Let me ask you this. I have both, I kind of have a hybrid team, both, you know, employees, but also that we work with a firm that provides outsourced services, right?

[10:45–11:03] Mark: 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 day-to-day kind of operations.

[11:03–11:14] Mark: because 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?

[11:15–11:18] Mark: Right. So what’s your counter to that kind of concern?

[11:18–11:50] David: Yeah, that’s absolutely true. And it’s not because they’re offshore outsourced. 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 hired 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 who the person is how much experience they have There are a lot of things that, you know, and just the basic hiring process that you go through in terms of what you’re looking for.

[11:50–12:02] David: So when we’re hiring, everyone on our team is experienced. You know, a lot of optional teams have a lot of really inexperienced people and one or two people per team that have experience to try to manage and corral everybody else.

[12:02–12:17] David: And you end up with, you know, endless quality problems. You have people that are not as smart, that 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.

[12:17–12:31] David: So when we hire, everybody has to be experienced, significantly experienced, It’s because it’s too painful for people to learn on the job. More importantly than that, they have to be really smart.

[12:31–12:57] David: 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 everybody else on the crew 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.

[12:57–13:09] David: 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.

[13:09–13:24] David: That’s the very first. And you can’t fix IQ, right? You can fix everything except IQ. If there’s, 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.

[13:24–13:41] David: But there’s always variations 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 make an investment.

[13:42–13:58] David: Also, they start to become believers and commit to the team. So those are things that can be adjusted. but 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.

[13:58–14:17] David: These are all things that 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 take the less experience, let’s say they’re only five years’ experience versus ten years.

[14:18–14:22] David: I would take that five-year person over the ten-year person if they happen to be an outlier. It’s just brilliant.

[14:23–14:28] Mark: How do you test for IQ in the context of the work they’re expected to do?

[14:29–14:39] David: 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.

[14:39–15:01] David: So it starts with the interview process. they have to be able to communicate in an intelligent way and answer questions on the cuff about requirements. So we do a lot of role-playing with people in the interview process because we also need people that are good communicators, that they can distill the information quickly and talk about it in an intelligent way.

[15:01–15:35] David: And 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, and go ahead and build this thing for me, and now quicker. everything. 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 them. Let’s give them one or two projects and see how they do about it, the quality of the work that they do and how quickly they’re able to produce it. And really smart people with good experience

[15:35–15:58] David: can produce things dramatically faster than people who are a little less experienced or not quite as smart. And then the code they produce is smart too. So it’s hard to find really good people that are really smart and inexperienced, but it’s not impossible. You just have to be willing to go through a thousand resumes to find for every person you’re actually willing to commit to.

[15:59–16:17] Mark: 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, Microsofts.

[16:17–16:21] Mark: You know, what’s the attraction for working with a firm like yours?

[16:22–16:32] David: 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.

[16:33–16:44] David: So, you know, he felt like he was a cog and he wanted to be more, feel like he was more part of a smaller team. So sometimes it’s that. Sometimes it’s circumstance.

[16:45–16:57] David: They want to work. It used to be a big one was they wanted to work remotely and they couldn’t get the company they were at. And all of our team works remotely. There could be a lot of different reasons.

[16:57–17:08] David: Sometimes they just think people they’re working with, right, and they’re looking for a 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.

[17:08–17:11] David: These are all really smart people. They’re fun to work, you know. So it depends.

[17:11–17:18] Mark: Are they all in the U.S. or North America, or do you have people all over the world? No, all offshore. All offshore.

[17:18–17:28] David: Okay. Yeah, everybody’s offshore. And I have traveled a lot offshore, 15 trips out of the country between 2010 and the pandemic to build my teams.

[17:28–17:41] David: 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 would hear about.

[17:41–17:56] David: 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 U.S.-based companies that we take them over from.

[17:56–18:03] David: those clients always recognize how different we are from who they were working with before. They’re usually my best references.

[18:04–18:07] Mark: Awesome. So tell me, what is the launch-first method?

[18:08–18:18] David: Okay. So let me give you a quick genesis of why the launch-first method even exists. So I’ve worked with over 90 startups, and like I said, a few of them are really successful.

[18:19–18:31] David: 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. Something’s spent up very little money. And they all fail for the same reason.

[18:31–18:42] David: They lack product market fit. They didn’t build a product for a market that wanted to pay money for it. And they waited way too long to prove that model.

[18:42–18:59] David: And 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.

[19:00–19:18] David: And that way you’ve got enough margin in there to reinvest back into the business to accelerate that growth. So 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.

[19:19–19:29] David: They’re going to be the savior for some stuff. Right. And so they’re coming into being a startup wearing a black robe, basically preaching the vision.

[19:29–19:44] David: 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 think about your startup.

[19:44–19:55] David: usually nascent startups that are either at the design stage or even pre-design. But they have funding and they’re ready to march forward building their MVP.

[19:56–20:10] David: And I say, okay, well, instead of building an MVP, because that’s expensive, and your MVP usually has a 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.

[20:10–20:20] David: It depends on the founder and the product and the market. And so instead of doing that, let’s let’s do that. Let’s build a high-fidelity prototype, which is a very sophisticated design prototype.

[20:21–20:32] David: It’s much less expensive to build in 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.

[20:32–20:46] David: So you can demo it the way you would demo an MVP. You don’t give them to clients to you, 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 up.

[20:47–21:06] David: And let’s do a really yeoman’s job of understanding who your early adopter is. And that requires doing a problem-state niche analysis exercise that is very painful and tedious, but it’s very inexpensive, right, because it’s the founder’s effort usually.

[21:07–21:18] David: And if they’re really committed to it, they can get through it in a couple weeks. So many founders fatigue through this one, so they take a long time to do it. But it doesn’t take that long to do it and do it really well.

[21:19–21:37] David: 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, maybe 10, 15, 20 different niches.

[21:37–21:49] David: 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.

[21:49–22:16] David: 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.

[22:17–22:35] David: They feel threatened by that problem statement. Their career won’t advance. They’re going to lose market share. Their revenue is going to die, whatever. Whatever the reason why that problem statement is so critical to them and why they’ll listen to you is because it touches a survival mechanism, right?

[22:36–22:49] David: That’s what a real root-level problem statement does. And 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.

[22:49–23:16] David: So 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. This is a tedious process but it invaluable because now your discovery interviews which you only do one or two in each niche If it a niche you 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.

[23:17–23:30] David: So they’re only reaching out to the ones that 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.

[23:30–23:43] David: And then how you talk about what you’re doing, and you always talk about it from what problems are you struggling with, not 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.

[23:44–23:56] David: 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.

[23:56–24:04] Mark: But at this point, do you have an MVP that you’ve mentioned? Do you have something to show them? Are you just interviewing people just to understand?

[24:05–24:22] David: You’re just interviewing. It’s like, yeah, this is market research. You could be building the wrong thing, and you’ll find out really quickly if you do this that, well, 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.

[24:23–24:37] David: 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.

[24:38–24:48] David: 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.

[24:48–25:04] Mark: So when you say very affordable, and I’m sure there’s a range, but let’s just talk about a B2B SaaS 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 costs and timing.

[25:04–25:05] Mark: Okay.

[25:06–25:31] David: So if you go straight into doing design and MVP, which is what most people do, you know, depending on the product and the level of sophistication, you’re looking at, and this is what I’m assuming, it’s B2B, SaaS, you know, and it’s some level of sophistication, you’re usually looking at between $50,000 and $150,000, typically what people will spend before they have a viable product that they can start to charge.

[25:31–25:45] David: and 50,000 is on the low side. It 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, you know, and it can be a lot higher than that depending on, again, the level of sophistication.

[25:46–26:00] David: The product, whether you’re using U.S. 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 know, you get what you pay for, somewhere between 50 and 150.

[26:00–26:19] David: 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. Design prototype is anywhere from, again, depending on the level of sophistication of what you’re doing, is anywhere from $10,000 to $25,000 or a fully fleshed out.

[26:19–26:36] David: Looks like a real product when you demo it. And are you using Figma or something or what? It depends. in Figma and or Aksure or both. Maybe the design’s all done in Figma and then we wire it up in Aksure because you can do a lot more functionality.

[26:36–26:56] David: Figma’s just about there now with all the add-ons you can add. We’re able to get a lot of it in Figma now. One of the problems is it takes so long to load the damn thing. So when you’re trying to do a prototype, you’ve got to make sure you’ve got, and you’re going to demo it, you’ve got to make sure that prototype is loaded before you sit down and start the demo.

[26:57–27:16] David: 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’re going to put together a marketing plan to sell to that early adopter to do pre-launch sales using the prototype.

[27:17–27:32] David: 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 pre-launch offer is a big enough value that they don’t want to miss out, and then they will buy in enough numbers.

[27:32–27:36] David: You can prove you’ve got that three-to-one ratio before you ever start to build the NPP.

[27:36–27:39] Mark: Makes a lot of sense and sounds like a smart way to go.

[27:39–27:50] David: Yeah, and you’re generating revenue to help fund the development. So whether it’s 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.

[27:50–28:01] David: It’s harder to do this up front. I always say it’s the hard, easy way, right? Because then you’re not building your product for product market fit.

[28:01–28:13] David: 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.

[28:13–28:33] David: It’s satisfying their needs in a way that continues to keep them as customers, right? That’s product solution fit. But market fit is, 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 it at the amount that I need them to pay for it?

[28:34–28:39] David: And that you can only prove by getting people the right way to check for the product, even if it’s not ready yet.

[28:39–28:54] Mark: 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 the right product, market product solution fit, and they were off to the races.

[28:55–29:16] David: 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.

[29:16–29:34] David: And they started out with and monitoring were both devices with real-time triage capabilities and an AI nurse that calls the patient when it identifies potential outlier situations that may require somebody to intervene.

[29:35–29:46] David: 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.

[29:46–30:16] David: It has morphed into an AI nurse for doing more customer service-related stuff 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 from the 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 in the communication.

[30:16–30:37] David: And so the SAI nurse can do all that and have a very natural conversation with the person because she knows their medical history, she knows the capabilities of the facility they’re moving to 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.

[30:38–30:51] David: 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 a natural person. And they just received $5 million in funding because of this pivot that they made with a potential customer.

[30:52–30:58] David: The funding is coming from one of their customers. They have many investors already in the company, but this was their first real big launch.

[30:58–31:03] Mark: So this is not a traditional kind of VC-funded company.

[31:04–31:23] David: Yeah, this was all friends and family and advisory people. The person that runs this 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.

[31:23–31:39] David: And so, yeah, it’s a very strong reputation in the health care community. And he was able to recruit a bunch of investors early on, many of whom became advisors that have a lot of reach in the healthcare space, in government, and in local healthcare.

[31:40–31:52] David: And then as a result of continuing to kind of refine this process, test different models, and the CEO of this company, his name is Kevin Longoria.

[31:52–32:22] David: He is just really smart and sensitive to what the market cares about. And when he saw that what he was originally trying to deliver to the 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 to other companies, they would say, you know, we need the voice capability that you’ve just come out with.

[32:22–32:52] David: This nurse is just powerful, and we needed to offload all this work going to our nurses, which we just don’t have to pay enough staff. And then all of a sudden you’re talking about, you know, thousands 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 a Medicaid program to remember to take their meds at a certain time

[32:52–33:12] David: or to fill a prescription because they can see that they were prescribed something and the 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 health care system a fortune.

[33:13–33:15] David: And so you get the idea, right?

[33:15–33:32] Mark: It was a 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 instead of just.

[33:32–33:39] David: The original was built around your wearable device and predicting potential situations.

[33:39–33:43] Mark: And biometrics or something like that, right? Exactly.

[33:44–34:02] David: 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 what I was saying with lower income populations, just by sending reminders or making phone calls, you know, having a nurse call you.

[34:03–34:13] David: And the nurse is so friendly and somebody you can have a chat with, right? on the press, I already heard that. Let’s talk about that. Awesome.

[34:13–34:50] Mark: A couple more questions here. You mentioned AI, and we’ve spent the last five minutes talking about this startup that is heavily relying on AI. I see AI from your, from Techie’s perspective, you have both the AI that tools that developers can use, And then you have the actual AI the applications of AI and LLMs that they can deploy to make platforms more effective or yeah to help those platforms to achieve their mission right

[34:51–35:16] Mark: So maybe you can talk about, first off, what are the tools that your developers are using to help them with, you know, speed up their development, and then talk about how do they keep abreast of all the different types of LLMs and everything like that, and then make recommendations to your customers about, here’s what we can do, here’s how we can use this LLM or this type of AI to optimize the platform.

[35:16–35:28] David: 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.

[35:28–35:45] David: 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 Langchain and RAG models, are now all of a sudden very consumable just six months ago.

[35:46–36:08] David: 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 ChatGPT or OpenAI or Quad or Gemini, whichever one, you know, whatever, you’re using that in combination with your own machine learning vector database that you built on a specific industry.

[36:09–36:19] David: And even that model is starting to shift where that was the only way to have a really smart AI tool for your particular vertical.

[36:20–36:45] David: Now there’s other ways of achieving that without having to go to building your own ML machine learning pipeline. 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 in the daily business.

[36:46–36:57] David: Now you can accomplish a lot of that stuff without building this sophisticated rag model. There are still lots of times when you want to do that, but less and less.

[36:57–37:14] David: You just have to do it for everything that’s specialized. And there’s frameworks for building these that didn’t used to exist. And, you know, almost weekly, you look at the reports on which LLM is the smartest, and that keeps shifting in how smart they are.

[37:14–37:25] David: So to answer your question, so 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.

[37:25–37:40] David: We experiment a lot with internal things. We’re building a lot of our own internal AI models. For project estimation, remember I talked about being exceptional. Our project estimates are way more detailed than a typical software company, and that’s expensive for us to create them.

[37:40–37:58] David: And we have a methodology that’s spent years toning 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.

[37:58–38:15] David: That’s an example of something internally we’re doing. We are an agile company, so we use tools to support. We have our daily stand-up meetings and various things that go along with companies that are agile, which many or most competent companies are these days.

[38:15–38:25] David: One of the things that’s a time socket is our daily stand-up. And there’s supposed to be 15 minutes. They always extend longer because people get into discussions about things. So we’re building an AI.

[38:25–38:32] Mark: Just let me cut you off there real quick. Do you do daily stand-up by customer or do you do it as an entire team?

[38:32–38:34] David: By customer, by project.

[38:34–38:39] Mark: Okay, so you’re popping in and out of a lot of meetings, I would assume, because you want to keep it restful.

[38:39–38:50] David: I am no longer in most of those. Okay, okay. It took me years. My director of operations is just exceptional, director of development and operations.

[38:50–39:07] David: She’s exceptional, and she runs all this now. Okay. And she continues to improve our standard on every respect. So I don’t need to be in there. I’m probably just getting away at this point. I ran all this stuff for years, but it’s been probably four years since I’ve needed to be in the daily stand-up.

[39:07–39:19] David: And then I peek in once in a while, and she wants to kick me out. There’s not this kid in the way. And that’s also part of the philosophy. IQ is like the most important thing.

[39:19–39:37] David: I won’t hire somebody if they’re not smarter than I am. 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.

[39:37–39:55] David: 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 that delivery that you didn’t have before. And they’ll 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.

[39:56–40:08] David: So, yeah, that was a philosophy that came up with after having hired a few people 12, 14 years ago that were not smart enough and having an impact they had on the really smart people on the team.

[40:09–40:13] David: So that philosophy should happen very solidly.

[40:14–40:48] Mark: Well, what I’m hearing you say is, you know, if you’re trying to build a company and you want to build it fast and you want to be effective, there are some key takeaways here. One is hire smart people, okay, hire very capable people, hire people that can predict 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 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,

[40:48–40:55] Mark: in your case, over 90 different times with 90 different companies. That’s one way to grow your business fast.

[40:56–41:17] David: Right. Yeah, that would 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 and recruiting, you’re not going to know how to do those things very well.

[41:18–41:32] David: Unless you find somebody that can do it for you. You bring somebody in that has that experience, then they can build those teams. Or you bring in a team, somebody that assembles these teams for companies as an outsource thing.

[41:32–41:44] David: 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.

[41:45–41:57] David: And we work with them on the estimation part because that’s more of a skill. And if they’re smart, they pick up skills very fast. But something else about the scaling is test everything.

[41:57–42:11] David: Everything you believe is true is not true until you’ve tested it and you have evidence that it’s true. That’s why I say when, you know, on our banner or our website, It’s a hyper-exceptional software development team.

[42:11–42:22] David: But whenever I talk to somebody, I say, I don’t want you to just 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.

[42:23–42:38] David: And then you should ask, if you’re talking 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 there are just not a lot of teams that make it their…

[42:38–43:01] David: goal to never be good enough. I mean, there 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 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 in a playbook.

[43:01–43:14] David: Because if you want to bring new people in, and you’re going to scale your company and bring somebody in basically delegate that to, it’s an intellectual effort to train them if it’s just in your head or somebody else’s head.

[43:15–43:30] David: And now it’s in two people’s heads. 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.

[43:31–43:51] David: 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 a personal relationship and understand the culture and the delivery kind of cadence from somebody else.

[43:51–44:03] David: But it will take very little time because now they’ve got a book that can perform all the answers to anything they can ask in the context of doing the thing that you know works already. And now you’re just repeating it.

[44:04–44:14] David: Yeah, playbooks is really critical. Test everything, then once you find something that works, document that workflow. And have the person that’s doing it document it.

[44:14–44:20] David: And then you get that intellectual property out of their head and into a corporate asset.

[44:20–44:27] Mark: 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?

[44:27–44:38] David: Yeah, and thank you for asking me that. My company is Tekyz. You can find me at Tekyz.com. And that’s spelled T-E-K-Y-Z, the idea of a bunch of Tekyz sitting around the table.

[44:38–44:53] David: T-E-K-Y-Z.com. You can email me directly at david at 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.

[44:54–45:13] David: And also, can I mention my podcast? Oh, absolutely. 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 you’re using AI and automation to scale your business or to launch your business.

[45:13–45:22] Mark: That’s awesome. Well, I’ll put links to Tekyz.com and to your podcast in the show notes. I won’t put your email address there because that’s easy.

[45:24–45:29] David: I can’t say anybody that listens to this. I want them to have it, but I don’t want Qualers to be.

[45:29–45:39] Mark: I don’t like to put it anywhere on the web. In the recording is 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.

[45:39–45:52] Mark: Trust me, I’ve learned so much over the last year of running BreezeDocs and going through the development. And there were a couple moments in this conversation where I was like, God, I wish I would have done that. But, you know, it’s all a process.

[45:52–46:03] Mark: And like you said, 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.

[46:04–46:05] Mark: Thanks, man.

[46:05–46:07] David: You too, Mark. And thanks for having me. Cheers.

David Hirschfeld, Tekyz Founder

David Hirschfeld founded Tekyz, a company dedicated to transforming business software development. With over 30 years of experience, his journey began with a physics degree from UCLA and a successful sales career at Computer Associates. After launching and selling his first software company in 2000, David found his passion for empowering entrepreneurs.

He developed the Launch 1st™ methodology, which focuses on generating revenue before coding begins. This helps startups gain traction while minimizing risks. With a commitment to innovation and collaboration, David leads Tekyz in providing AI-powered development and SaaS solutions, making a meaningful impact in the tech world.

Tekyz is set to launch two new AI applications: one for automating the Launch 1st Methodology Niche Analysis and Estimiz, an AI-based project estimation tool. Outside of work, David enjoys golfing and woodworking.

You can learn more about David Hirschfeld and Tekyz by following his LinkedIn profile — David Hirschfeld’s LinkedIn Profile.

For more information about Tekyz’s services and how they can help you harness the power of AI in healthcare, visit tekyz.com or contact the founder directly at [email protected].


Navigating Startup Success with Strategic Product Development was originally published in Tekyz Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

tek