Building Products Right: Essential Advice for Early-Stage Founders by Chad Perry 🚀
Key insights
Starting a tech-enabled business is exciting. But for non-technical founders, the journey to building a product can feel like navigating a minefield. Do you hire a developer right away? Outsource? What about tech stacks and budgets? If these questions make your head spin, you’re not alone.
In this post, we dive into practical advice shared by fractional CTO Chad Perry, who’s guided countless founders through these challenges. Get ready for actionable insights to avoid costly mistakes and build your tech dreams the right way.
Start with a Designer, Not a Developer
Most founders rush to hire a developer to start building their product. It feels like progress, right? Wrong. Jumping straight into development without clarity is like building a house without a blueprint.
Instead, invest in mockups or prototypes first. According to Chad, this step:
Forces you to fully think through your solution.
Uncovers hidden gaps in your understanding of the problem.
Creates a clear visual tool for communicating with developers, investors, and early users.
By starting with a designer, you ensure your vision is clear before spending big on development. Bonus: it saves you heartache later when you discover (inevitably) that your initial assumptions were off.
The Outsourcing Dilemma: Offshoring vs. Nearshoring
Outsourcing can be a lifesaver—or a nightmare. Here’s how to make it work:
Understand the differences:
Offshoring: Typically lower cost but comes with risks like time zone misalignment and cultural gaps.
Nearshoring: Slightly higher cost but closer cultural alignment and similar work hours.
Set clear expectations: Establish weekly check-ins to review progress and adjust priorities. This avoids miscommunication and keeps the team aligned.
Don’t cheap out: The cheapest developer is rarely the best option. Poor-quality work leads to higher costs later when you have to fix or redo the project.
Chad’s pro tip? Stick with well-known tech stacks that are easier to maintain and recruit for in the future.
Should You Hire a CTO or a Developer?
Titles can be misleading. Many founders hire a developer expecting them to act as a CTO. This almost never works.
Developers: Focus on writing code and building the product.
CTOs: Think strategically about technology and its alignment with business goals.
For most early-stage startups, hiring a CTO is overkill. Instead, find a skilled developer who can implement your MVP, and rely on advisors for high-level technical guidance.
Ask the Right Questions (Even if You’re Not Technical)
Feeling overwhelmed by technical jargon? Chad recommends a simple strategy: focus on the business impact.
For example:
Instead of asking, “What tech stack should we use?” ask, “Which option allows us to scale affordably and find developers easily?”
If a developer suggests something you don’t understand, keep asking “Why?” until you uncover how it aligns with your business needs.
Final Advice: Build for Traction, Not Perfection
The perfect product doesn’t exist—especially in your first version. Focus on building a minimum viable product (MVP) that solves your customer’s core problem. Get it into their hands quickly, learn, and iterate.
Remember, every founder has blind spots. Surround yourself with advisors and experts who can help you navigate the unknown. As Chad wisely puts it, “The problem you face is that you don’t know what you don’t know.”
Next Steps
Start sketching mockups of your product today.
Research designers or tools like Figma to bring your ideas to life.
Connect with peers and mentors who’ve navigated this path before.
Have questions about building your product or working with developers? Drop them in the comments, or check out Chad Perry’s LinkedIn profile for more insights. 🚀
Bio
I help founders and CEOs plan, build, and go to market with B2B SaaS products.
But deep down I'm just a nerd who loves to code, market, and sell - and started a few tech companies.
20+ years in tech and software development, started a few businesses, trained with the world’s top marketing coaches, now supporting founders and executive teams in product development and strategy.
If you want help starting or growing your tech business – connect with me on LinkedIn. https://www.linkedin.com/in/perryonfire/
Entrepreneur. Global citizen and former digital nomad. Closet hippie and probable hipster. Bicycle rider of the mountain and touring varieties. Former motorcycle rider. Aviator and pilot with a fascination for helicopters. A real-life rocket scientist who's never built a rocket.
Transcript
Lance: Many founders build products backwards. They can't wait to get something into the hands of their customers so they can start getting feedback right away. And that is just plain wrong. But don't take my word for it. I recently talked to Chad Perry, a highly experienced fractional CTO, about his experiences and the advice he gives to the founders he works with.
And I'll put a link to his bio down in the description. We talked about what to do first, when to finally hire developers, the value of mockups, do's and don'ts of outsourcing, and much more. This will be valuable to anyone who needs to build technology for their startup. And frankly, that's almost all founders.
Chad, welcome to feel the boot.
Chad: Thanks, Lance.
Lance: So I think let's start off by just having you share with the audience just a little bit about who you are and why we're talking to you today.
Chad: Yeah. Well, thank you. My name is Chad Perry, and I'm a fractional CTO. I have a background in enterprise software engineering.
I started coding a long time ago when I was 14 years old, and I just ended up getting into shareware and started doing startup advising in the late 90s before that was cool. I saw the first internet boom and went through that and then after college decided to start a software company that eventually became focused on enterprise e commerce.
My old business partner is still running that day to day. I have, I'm still on the board of advisors, but I have since moved on to working with more early stage startups. Uh, really helping founders get through the, the first really critical steps, uh, in building a tech startup or a, or a startup that has a significant tech component.
Lance: So you're working with a lot of early stage founders. What are the most common questions or issues that they come to you with?
Chad: Ah, you know, um, so, so I would divide that into two categories. Really, there's the founder that comes to me after they've just really made some, some common but unfortunate mistakes and wasted a lot of money.
I've talked to founders before, sometimes who've burned through their, literally their life savings. It might be a few hundred thousand dollars or. you know, they reverse mortgage their house or whatever. And typically, that is because they were very product focused and typically entrepreneurs are very visionary.
And so they're thinking, okay, I just need to get a product done and I need to get it out the door and try to get some traction with it. And so they'd go to, to the first software developer, the first cheapest software developer they find and typically that's offshore somewhere. That might be India, Ukraine, or you know, wherever it happens to be.
And we can talk more about that. There's really nothing wrong with that as long as it's done in the right context. But so that's, that's one category of developers. They've already kind of talked about that. crashed and burned and they've learned some unfortunate lessons. Then the other category is they're just getting started and they just don't know what they don't know.
And so typically in my situation, I'm working with non technical founders who there, they have experience in their field of knowledge. They have, they have domain experience. Um, they may or may not be necessarily. directly related to their field of expertise, although it's ideal if they're doing that. But they have some kind of experience with the problem.
They have a network, they're typically a little bit older, and they have, um, you know, they might have a little bit of cash. And so they're in this position where, There, there, they're almost kind of stuck. There's a lot of anxiety, they don't really know what to do next, what to prioritize, the questions to ask, who to trust.
Um, and that's, you know, that's an unfortunate situation to be in as well, but it's also a powerful situation to be in because if they ask the right questions, and they take the right steps in the right order. There's no reason they shouldn't be success, successful, provided that they have a viable opportunity.
And in my experience, most people have a kernel of a viable opportunity or even a really great opportunity.
Lance: So when we were doing our sort of pre interview discussion, I thought one interesting thing you talked about was the fact that people Rush to hire a developer or an engineer and you were suggesting that people should bring in a designer first.
Can you unpack why that is and how that fits into the whole process?
Chad: Yeah, so I would go back even a step before that and say that it's important to understand that when you're building a product, and especially if you're trying to raise money around that product, you're really telling a story. You're telling a story about what you can do.
For somebody and if you're, you know, B2B or B2B B2C app, uh, that you're reaching consumers or whether you're a B2B enterprise application that's reaching, um, multiple levels of, of users and in a large organization, you're still, you're still creating some sort of outcome. Come and some sort of change in their life.
And typically that starts with, they have a problem, they have some kind of pain that alerts them to a problem. Uh, they go see seeking a solution and, and you know, that may be like they're using spreadsheets or they're just maybe not doing anything at all. Or maybe they're, you know, they're, they're just going through some sort of really crazy workaround that, that seems crazy to us as a visionary founder.
but it may seem routine for them. And so then they, they go looking for a solution and ideally they, they find it and it solves their problem by creating an outcome. And then that changes their life and creates some sort of relief. So it's important to understand that when you're, when you're selling something like that, and you're going to, you're going to be going to market with that product, but you're also looking for traction.
And so you're going to be having early conversations. It's important to understand that that's a story. You're telling a story about, What you can do for somebody, and it's the same with investors. You're going to investors and saying, look, I can do this for a set group of people that are willing to pay for this, and this will create a return on your investment.
And that story for most people, it's better if that story isn't true. It is visual. It's easier to tell that story. So if you're a founder and you have a limited amount of capital, which most do, and, and, and I would say even, even, you know, if you've only got five or 10, 000 to spare, the worst thing you can do is go try to find the lowest bidder to build that product because there's always a cost to, to building a product.
And I would say this, this probably applies to life. Uh, but specifically when building a product, a software product, there's a cost and you will pay that cost no matter what. Sometimes the cost is indirect in terms of, uh, you know, overhead or, um, you know, bad communication in the case of offshoring if you have a bad experience with offshoring.
Uh, but that cost is going to be paid no matter what. So you're not going to get an app that should be made for 50, 000 or 100, 000 or a million dollars. You're not going to get it for 10, from the lowest bidder. So, your next best option is to focus on communicating your story about what you're trying to do, so that then you can go raise the seed capital, or venture capital, or whatever it is that you're trying to do.
Whatever it is you need to solve that problem, you want to be able to tell the story so that you can recruit those, those aspects of putting that puzzle together so that you can create that solution. So that it will be viable and get out the door. So, coming back to your original question, doing mock ups has a couple of advantages.
One, and I would say this is the biggest advantage, it forces you to walk through, in detail, exactly how you're going to solve the problem you're going to solve. And doing that typically reveals that you don't quite have all the answers about what the problem even is. So you have, You have experience with it, but maybe other people see the problem in a different way.
They use different language, or maybe if you're doing B2B, for example, there are, there are many different roles and different people in the value chain who may be making decisions or may be using, using the product and may determine your success or failure. So those people. Um, those people need to, you need to understand what exactly those people need and what, not only what they need, but what they think they need.
Because a lot of times you have to meet people where they are and then bring them along on that journey to figure out exactly, uh, or just to solve their problem, but also for you to figure out exactly what that looks like. So mockups help you define what it is you're trying to do. And then in the process, you're creating something that helps everybody else around you, whether it's your advisors, or whether it's your investors, or your early employees, or especially developers who are going to be writing exact code to do the thing you're trying to do.
It helps specify what's going to be done, and it helps Them understand, uh, what the outcome is going to look like and how that's going to work and therefore you're all on the same page So you avoid So much heartache, but just specking out your product up front.
Lance: Yeah, i've certainly seen that where Very few people have the discipline to write a really complete Specification of the software that they want to build down to all the sort of details that kind of automatically come out when you're building a mock up, uh, like that, where you can't avoid the fact that, oh, yeah, we do need a button to do that.
We need to be able to move from here to there. We need to have something that supports this, you know, minor aspect of what you're doing. But. Yeah, it requires all of that. And you mentioned a couple of times working with the developers and outsourcing, and that's already come up a couple of times. And outsourcing can be a huge complication for a lot of companies.
And often it doesn't go very well. Can you speak to what your sort of best practices and recommendations are around how to make that a successful outcome?
Chad: Yeah. Yeah. And I, before that, I want to actually go back to, to something you said, because I think that was a really good point, which is when you do mock ups, there are all these other things that you didn't think about that happened kind of behind the scenes.
So because software is exact and somebody has to write code to do every single step in the process, if you, if you look at a screen and you say, okay, here's a button, it does something, right? Let's say, let's say you're signing up. It's just the signup form for your app. Well, when you click that button, if you ask the question, what happens, there's multiple things that happen.
Not only are you registered in a system, but you receive an email that confirms that. Or it might be a multi step process where you have an email and maybe you have a payment and what happens if the payment is, doesn't go through. And so there are all these, there are all these nuances that, that complete the picture of how you solve the problem.
And so getting back to your, to your question. Um, one of the things that I find, I would say the biggest problem I see with outsourcing, uh, and this is less of a, this is less of a concern with nearshoring, but more like offshoring when you have, and this is from the perspective of, of, of an American. When you have a cultural difference, a significant cultural difference, and you have, um, a language difference, even though you may be able to both speak English and Uh, a lot of times those nuances get lost and especially, especially when you go outsource something and I'm going to specifically make the differentiation between outsourcing as a as a whole, I think is a good approach because you don't have developers in house and you don't know how to manage developers and you don't have a lot of money.
So you want to go pay somebody who has all of that expertise, you know, already spun up. And they're experts in what they do, and so that's outsourcing. But specifically within outsourcing, you have offshoring and you have nearshoring. Offshoring would be, from an American's perspective, would be halfway around the world.
In India, nearshoring would be more like South America, Latin America, so on your same time zone. And more similar from a cultural perspective. So the, the reason that offshoring, I think, doesn't work for a lot of, uh, a lot of entrepreneurs is that. They don't take into account all of these nuances, so they don't go do mockups.
They go to the offshore developer and they say, and a lot of developers do have ui, people who, who are on staff, who can, who could do UI mockups. But there's a difference between going to, uh, an offshore or an out or an outsource provider who is incentivized to complete that as fast as possible and take short shortcuts on the discovery process of defining what you need.
So there's a difference between doing that. And working with a UI designer to take the time to get your, your, your specs in place and figure out what you're doing. Uh, and then going to a developer and, and potentially using their UI person to, to do more, uh, more downstream tasks like, you know, additional screens or, you know, additional mockups, whatever it may be.
So, I, I think I got a little off track, uh, off track there, but that's, that's the, I think that's it in a nutshell.
Lance: Yeah. How do you, how do you recommend that people work with those teams to make sure that you stay, you know, in alignment? I've certainly heard a lot of cases where, and it often is a cultural thing that the contractors don't want to give you bad news.
They don't want to tell you when things are slipping off schedule or when they're having intractable problems, solving some kind of bug or technical issue. And making sure that you actually get something that, that works well, that delivers the values that you're trying to get, what, what are your suggestions for how to manage that process?
Chad: Yeah. So that comes down to being very careful and very clear about expectations. And so the first thing I would recommend is a cadence. So you want to have some sort of, you know, you can call this agile, you can call it sprints, you can call it whatever you want, but make sure that there's a cadence of checking in and holding your developers accountable.
And this is going to be true whether you find a local freelancer or whether you work with an outsourced provider. Uh, but you want to have That ideally I would say weekly check in and it would be, you know, typically that would be, uh, at the beginning of the week, you, you have a, maybe you review some things that, that happened last week and you set priorities for this week and then at the end of the week you review the progress.
Uh, it, it really just depends. Sometimes you can do one, you could do one check in or, or whatever it needs to be. Uh, but there's a, there's, you know, part of that is understanding that, uh, when you look at, when you look at a lot of situations with. And this is what I was talking about with if you're on a limited budget and you go say, okay, like I need, you know, I need something developed.
I need an app developed for 10, 000 or even 25 or even 50, whatever it may be. The incentive is to quote that price and then you're, you're fixed on that. You don't have any extra money. So, if you quote that price, and then inevitably there are changes along the way. And, and, you know, it just turns into a disaster because you ask for changes and they're incentivized to, to get that done as quickly as possible.
Now, you do want your developers to be incentivized to get things done quickly, but you also want to have room to, to, to pivot and to, to adjust to things on a weekly basis. So going back to the mock ups, I'm not suggesting that you mock up this, you know, this, the world's best solution and you say, this is what it's going to look like in five years because you definitely don't want to do that because you definitely don't know.
What you want to do is you want to get to the essence what it, of the problem that you're trying to solve and the, and the minimum necessary solution to solve that problem. So this is, this is not counter to agile. This is, this is not like, let's, you know, let's do waterfall and let's, let's, uh, spec everything out to the nth degree.
This is what is minimum necessary to solve the problem. Let's spec that out. to the degree necessary to expose, uh, any, any potential things that, that, you know, any gotchas or, you know, any things that we may have missed. And then as you go through this process of development with a developer on a weekly basis or whatever your cadence is, you're going to have the opportunity to say, Oh, well, we actually missed this.
So what does that mean for us? Well, it means that we either take a shortcut here, which, you know, sometimes is necessary. And because we are resource constrained, um, or we take the time to, to do this another way, which may add two or three weeks. But if you're doing that on a, on an incremental basis, on an agile basis, you are able to adjust as you go and you're not fixed to this final outcome for a fixed price.
Lance: Like what you're saying about, Really focusing on that minimum product, right? The minimum viable product. We always talk about that in the startup world, but the fact that. As soon as you get out there, you will discover things. Things are going to change. You'll realize what you got wrong in the first version.
So trying to design that kind of perfect app that you'll have in two years is a fool's errand because you're wrong. That wasn't the perfect app.
Chad: You are definitely inevitably wrong. So
Lance: what's your advice to founders when they're thinking about bringing an in house team or bringing in a technical co founder, assuming they're not able to do it themselves versus working with some kind of a nearshore or outsourced or offshore kind of developer to put together these.
And when does each one of those make more sense?
Chad: Uh, yeah, that's a, that's a tough question. I mean, I would say there's no real easy answer, but I would say it comes down to. It really comes down to your, to your budget and, and kind of resource you can find locally to compare this to. So if you said, I'm going to hire a freelance developer, uh, maybe, maybe, you know, remote in the United States, or maybe I found somebody, maybe you live in Austin and there's an abundance of these kinds of developers.
So now you have a choice. You go, okay, well. I can pay full rate for a freelance developer or I can outsource and there's a whole spectrum of, of outsource or there's a, there's a whole tier of, of, of pricing, right? There's, you know, you could end up paying the same amount you would, uh, for a stateside development company.
Uh, so just because you, you near shore doesn't necessarily mean you're going to get a cost advantage, but typically you do. So when you're, when you're looking at the, uh, the alternative. To outsourcing of hiring a local developer, um, the biggest problem that I've seen is what happens is they're still trying to get that cost advantage.
So they go find a junior developer, and this, and this may be inappropriate. By the way, this may be an appropriate solution. Um, maybe they find a junior developer who's willing to, who's not only at, at the lower end of, uh, the market rates, but also is maybe willing to provide a little bit more of a discount in exchange for equity.
That's a tricky situation, uh, because typically what I see is founders go into that thinking, well, this person will become my CTO. A developer is not a CTO. And we can talk about that more. But there's all kinds of considerations with a CTO that does not just come naturally from, you know, Uh, from a developer's experience.
So if you do find somebody locally, you need to make sure that you are clear about what you're trying to get out of it. If you're just trying to get out of it. a developed solution, that is fine. You know, if you can find a cost effective developer locally, I would say that is your best bet, because you're going to be more closely culturally aligned, no language issues, very minimal time zone issues.
Um, but if you're thinking this person is going to lead the technology side of the business and help me grow, chances are that's not going to actually work out.
Lance: And I really like what you said about the, thinking that they'll be your CTO. And actually a while back did a whole episode talk about the danger of giving some of your early hires and early team members kind of inflated titles that they may or may not be able to, uh, live up to just because they're, they're the only person in there, but why don't you talk just a little bit about, I think, especially for non technical founders who may not be familiar with these roles, you know, what is the difference?
between sort of a lead developer, a senior developer and that CTO role?
Chad: Uh, yeah, so I would say a, so at a minimum, a developer is going to be somebody who has the coding experience. Um, or maybe if you're willing to be patient and handholds, Somebody maybe you, maybe you're just really good at, at identifying talented, hungry people and you find somebody who's young and who's able to build.
So that, that's one aspect of it is can they, can they write code? And like, I'll, I'll tell you for, you know, just as an example, um, for, for me, I always, I always use code as a means to end. I was very creative and I, and I liked to build things. But I'm not the kind of guy who's going to write, I'm not the kind of coder who's going to write the world's best algorithm.
Typically, I, I hear founders talking about things like, they're worried about, well, are we writing something that's scalable and are we writing something that's, you know, robust and, And all of that, and those are, in my opinion, premature, uh, premature concerns. So, uh, uh, there's, there's a spectrum of developers, there's developers who just can write applications, and that's typically what you want to find.
You don't want to find a highly specialized developer who's going to cost you a lot of money. Because, if they are highly specialized and they don't cost a lot of money, then there's something else you're missing there. And yeah, I don't know what that is, but typically that's, that's not going to work out for you.
So, you want to find. Um, a general developer who is familiar with various popular, you know, uh, coding languages and tech stacks. And we can talk about tech stack too, because that's another question I frequently get. So you have a developer there, you have a lead developer. A lead developer is going to have a little bit more people skills, and is going to have the experience to be able to help other developers quickly shortcut their learning curves and make sure that they're not doing anything You know, that could potentially be a problem later, um, or just more importantly providing guidance.
Even, even then, like at such an early stage, you just, you don't need a lead developer and you just never know if a typical, if a junior developer is going to become a lead developer. So then beyond that you have Uh, you might have, and this was as your organizations grow, you might see a VP of engineering.
And this is somebody who has the wherewithal to really think about the business. They're running a business and the technology is secondary to that, but they are also highly skilled in engineering. And so they're helping run the engineering business. So they're making decisions about what, what kind of technology is used based on what the needs of the business are.
And then finally you have a CTO, which is more of a strategic thinker. They are, they are, and, and ideally this CTOs are also have come from a highly technical background. Uh, you know, uh, it's not, it's not always the case, but typically that's what you want. And they're making decisions that they're helping you figure out what's possible and what's going, what's, what's going to be correct and, in the future.
So they are, so they are legitimately the chief technology officer. They are in charge of the vision for the technology and in implementing your vision for the business as a founder, which again, I would say is very premature. So I, you know, I always like to tell founders, you really don't need a CTO as long as you know the right questions to ask because there are no technical requirements.
questions. There are only business questions.
Lance: I like that. That's that's a really good way of putting that. I tend to think of the CTO is being someone who works on the business, whereas the engineering department is working in the business. They're building things, but that CTO needs to keep that meta level cognition going on there.
They're always thinking at that kind of more abstract, higher level systems kind of way. But you just brought up something really important, I think, which is a lot of Non technical founders in particular can get very dear in the headlights when they're working with technical developers, uh, outsourced people.
And they also are, I think, are really worried about getting kind of bamboozled or snowed by them in some ways that the person is going to throw a whole bunch of technical terms at them and they'll just kind of end up agreeing with them or nodding along because they don't want to look stupid and they don't really know how to push back or, or argue with that.
So how do you suggest. especially non technical founders kind of approach that problem.
Chad: Yeah. Well, so one of the big questions that, that I hear is, well, uh, well, first of all, I'm non technical. I, you know, I know I'm not technical. I don't really know the right questions to ask. And so there's a lot of anxiety in it.
And I actually have, I have, uh, Uh, this is one of my favorite clients. I have these two ladies right now who are co founders to a B2C app. And they're both, and they're both just, I can tell they're both just very anxious. They're both highly competent, uh, business professionals in the business world. But when it comes to this, when it comes to the technology, Uh, they, they get, they, they literally get anxious and I, and I can hear it on our phone calls when we're talking to, uh, you know, to, uh, to the developers or about something technical.
So, you know, there's, again, it's helpful to have an advisor or somebody like that that You know, me or you or somebody there to help frame the right questions, but if you don't have that, the first place to start is thinking about, okay, if, if there's a technical decision to be made, let's just, let's walk it down the path until we get So why is this important?
And let's keep asking that question until we get to the point of, of talking about what's important to the business. Because ultimately, anything you're trying to do on the tech is driven by what you're trying to do in the business. So a very common one is, well, I don't know what tech stack to, to use.
And, and I've got, you know, these developers and, or I, you know, I've talked to two or three different development companies and they're all recommending. Different text action, you know, once JavaScript and, you know, I don't know, I don't see dot net in the startup world a lot, but, uh, you know, it could be dot net.
It might be Java. It might be. Well, let's use react to react native or let's make a native app versus a non native app. And, you know, that can be very intimidating. Uh, and, and rightfully so. So, the, the question is, what impact does this have on the business? And since you don't have a going concern yet, because you're a startup and presumably you don't even have traction yet, now ideally by the time you start having these conversations, you have mock ups and you've gone to a lot of your potential customers and you, and you've started to get some sense of, of what your traction is going to look like.
Assuming you've had those conversations, um, the, the, the, the question at hand, for example, would be, what tech stack do I need? Well, what, how does that impact the business in terms of my ability to How does that impact the business in terms of my cost? Because those things are going to be things that stick with you for the next couple of years.
Now you will end up rewriting your tech stack and your product, uh, probably multiple times if you're as successful as I hope you are. But the next couple of years are critical. And especially as you look to start transitioning to, okay, I've used an offshore or an outsource provider. Now I want to bring this, this in, in house.
Thanks. So, you need to be thinking about your ability to find developers. And so, a developer, an easy developer to find would be a developer who has, who has developed expertise in a very common programming language and a very common stack. And so if you go do a search for, you know, top programming languages and top tech stacks, That'll very quickly give you an idea of what the appropriate answers are to that question.
It's well, okay, how easy is it going to be to find developers if it's way down the list and it's something really obscure versus if it's something that, you know, that, that everybody, every developer knows and therefore it's going, you're going to be at a lower price point as well.
Lance: Yeah, it's interesting how obsessed I see a lot of people get with tech stacks, especially technical founders.
They always talk about the tech stack in their pitch deck, as though somehow that was of significance to me as an investor, as opposed to Do you have people who know this? Well, then probably use that because people are already familiar with that. So how do you see this applying to sort of less technical businesses?
So I see a lot of founders who feel that they, they fundamentally don't have a tech business. What do they need to be thinking about?
Chad: Uh, well, the first thing I would say is. If you don't think you have a tech business, then you're probably behind because regardless of if you're just starting out or if you have an established business and you're trying to keep up, technology begets productivity.
The whole point of technology is to be productive. And if you don't have a technological advantage at a minimum, you're just, you're just status quo. So you're using, you know, maybe third party tools. Everybody uses third party tools. Office and Google and, and, and basic, you know, project management and stuff like that.
But you know, there's other things like CRMs and then there's email marketing tools and there's all kinds of stuff. But when you start thinking about what it is that you actually do and you deliver to your paying customers, uh, there is, there is some advantage to be had there in, in how you do that. So there, you imagine you have a pipeline and you go from.
Taking money to delivering, you know, to delivering whatever it is. And, and for example, if you're, if you're a service business, which, you know, a lot of this question applies to a lot of service businesses, uh, especially now with generative AI, there's a lot going on in generative AI. And I will say that I, I think, I think that we definitely are in a massive hype cycle, but I'm also, uh, I, I had a conversation.
I had two different conversations this morning with, with two different established service businesses and they, they understand that their value, their defensible value in what they do ultimately comes down to their relationship. It's not the knowledge they have. However, they do have accumulated knowledge.
That for the time being has not been and is not easily baked into something like a large language model that can basically be like a chat GPT except specifically focused on your topic of expertise. So, at a minimum, you need to be thinking about what it is that I do that, that is routine, that can be replaced immediately.
Or will be, or will be capable of being automated. And the best place to start there, if you're non technical, is to go find technical people and just have a conversation with them. This is what I do. You know, what do you think, uh, what kind of technologies do you think could apply to, to making this better?
And then, you know, eventually you may find an opportunity to build a proprietary product that you can then productize and commercialize and sell and become a technology, a proper technology business.
Lance: So. Are there any final thoughts that you'd like to share with, uh, with this audience regarding kind of the, the, the advice and support and guidance that you provide to the founders you have?
Chad: Um, yeah, I mean, there's, there's quite a few, there, there's quite a few things. Uh, I will say that the, the big one is always that I hear in, in startup land is always like, Oh, go, go fine. Uh, go find traction, prove your product and then, and then go to market. But, um, that's, that's a lot easier said than, than done.
And for the reasons that we've talked about. So for example, if you think I need to, uh, prove traction, well, I need to go build a product and so I don't have much money and so therefore I have to go. You know, take a risk on building a product, a cheap product, and then you're in a worse situation because you're either going to run out of money or you're going to have a lower quality product or, or both.
So you have this half baked product that can't really demonstrate what you're trying to demonstrate. So go back to the beginning, start with the basics and get your story straight, I would say as a number one. The second thing is if there's, if there's areas that you have expertise that you are not an expert in.
Which is a lot. I mean, all of us, no matter how much of an expert we are, go seek out people who can have conversations with you that stimulate that thought process. You, you may not be able to hire, for example, uh, a fractional chief revenue officer to do a go to market strategy. Although I would say that's, that should actually be a priority almost, uh, as much as, as, as mock ups. Go find, go figure out what it is that, that, the roles that will complement what you need to do. So you gotta take a product to market. So you know that you need to build a product and you know that you need to sell a product and to do that you need to market a product.
So there's three things right there you can go find people who are experts in, you know, B2C, uh, apps and scaling those or B2B and. You know, sales and marketing and then a chief revenue officer would be, uh, for, for your, for your go to market strategy. So yeah, I would, I would say that's where I would, would start because you're going to find out all the things you don't know.
And that's ultimately the problem you face is that you don't know what you don't know. And it's the same on the technology side. It's the same on the marketing. It's the same on the, on the sales side.
Lance: That is fantastic advice. Yeah. Being, being humble about that and realizing the, the degree of lack of knowledge that you have.
I mean, most founders are, are brilliant about something and it's usually the thing that caused them to start the business, but most of us are not brilliant about most of the rest of the things that are involved and yeah, having the, the self awareness to reach out. Super, super critical. So is there anything that you want to, uh, promote or share, uh, that you're up to with the audience?
And then also where can they find you?
Chad: Yes. Uh, so this is, this is in the very early stages, but, uh, I, for a long time, I've been thinking about how to solve this problem. of the way I see it of early stage founders, non technical founders in tech, and it's, it's prohibitively expensive typically to hire somebody, you know, like a fractional CTO, even for a couple of hours a month, because you're going to be paying 200, 300, 400 an hour, and it just doesn't make sense.
Um, so what I'm working on, and like I said, this is still in the early stages, Stages is a community for non-technical founders in tech to not only commune and be able to, uh, have peers who have, who have, or who are already going through this process and therefore, you know, share referrals to, to service providers or to partners or advisors or, or whoever.
But also, uh, for me to be in that community and help answer any questions that they may have to host free workshops. Um. So stay tuned for an announcement on that. You can follow me on LinkedIn. Uh, it's linkedin. com slash in slash Perry on fire. My last name P E R R Y on fire. Uh, and then yeah, I'll make an announcement when, uh, when that goes live.
Lance: Fantastic. Yeah. I'll make sure I, uh, put that link to your LinkedIn down in the episode description. And thanks so much for coming on. I think this has been a fantastic conversation. It's been a lot of fun.
Chad: Yeah, likewise. Thanks, Lance.
