Summary
In this episode, we talk to Tyler Dane, a developer who has attempted entrepreneurship three times, and Michael Moulash, co-founder of DevelopNR, Building Better Developers. We discuss the importance of listening to customers and feedback, pivoting and focusing on a specific niche, and the struggle of developers creating tools for themselves.
Detailed Notes
In this episode, we talk to Tyler Dane, a developer who has attempted entrepreneurship three times, and Michael Moulash, co-founder of DevelopNR, Building Better Developers. Tyler shares his experiences and lessons learned from his previous attempts at entrepreneurship, including the importance of listening to customers and feedback, and pivoting and focusing on a specific niche. Michael shares his perspective as a co-founder of DevelopNR, and discusses the challenges of developing tools for developers. The conversation is a great example of how developers can learn from each other and improve their products by listening to customers and feedback. The hosts did a great job of asking follow-up questions and exploring the topics in depth, making this a valuable and informative episode.
Highlights
- Tyler Dane's third attempt at entrepreneurship
- Importance of listening to customers and feedback
- Pivoting and focusing on a specific niche
- The struggle of developers creating tools for themselves
- The need for developers to learn entrepreneurship and business skills
Key Takeaways
- Developers should focus on solving specific problems for a particular niche.
- Listening to customers and feedback is crucial for improving products.
- Pivoting and adapting to new information is important for success.
- Developers should learn entrepreneurship and business skills to complement their technical skills.
- Creating tools for oneself is not enough, and developers should focus on solving real problems for others.
Practical Lessons
- Developers should take the time to listen to customers and feedback.
- Pivoting and adapting to new information is a key part of success.
- Developers should focus on solving specific problems for a particular niche.
- Learning entrepreneurship and business skills is essential for developers.
- Creating tools for oneself is not enough, and developers should focus on solving real problems for others.
Strong Lines
- Developers should focus on solving specific problems for a particular niche.
- Listening to customers and feedback is crucial for improving products.
- Pivoting and adapting to new information is important for success.
- Developers should learn entrepreneurship and business skills to complement their technical skills.
- Creating tools for oneself is not enough, and developers should focus on solving real problems for others.
Blog Post Angles
- How to avoid the common mistakes that developers make when creating tools for themselves.
- The importance of listening to customers and feedback in product development.
- Pivoting and adapting to new information is key to success in entrepreneurship.
- Why developers should learn entrepreneurship and business skills to complement their technical skills.
- How to focus on solving specific problems for a particular niche.
Keywords
- customer feedback
- product development
- pivoting
- entrepreneurship
- business skills
Transcript Text
Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are into our new season of Developer Noir, Building Better Developers, and we are going to talk about quite a few things, talk to quite a few people this time around, as we did in the prior season. But first, let me introduce myself. My name is Rob Brodhead, one of the founders of Developer Noir, also the founder of RB Consulting, where we help you leverage technology to do your business better, whatever that happens to be. Good thing, bad thing. Good thing is, it is, as I'm sitting here, a new year. So got through 2025. It was not a fun year for me. It was a lot of challenge, a lot of work. I am very much ready to look forward into 2026. Bad thing is 2025 is still kicking my butt a little bit. I'm still recovering from that. It's been a little bit of a slow burn getting out of it, but now it's starting to build that momentum and move forward, much like we're going to talk about this season, getting unstuck, getting your momentum, perfect kind of thing as we start a year to start with things like you have your resolutions and all that. And you've come through last year, like maybe I did. I got to the end of the year, got a decent, survived it, but also got some goals and some challenges for the year ahead. Not exactly where I want to be. And maybe that's what you can do. And you'll get some of this from our discussions this year. But first, one who is not stuck because he's going to forward motion himself right into the center. Gosh, I've lost words. Right introducing himself. Michael, go for it. Hey, everyone. My name is Michael Moulash. I'm one of the co-founders of DevelopNR, Building Better Developers. I'm also the founder of Envision QA, where we build and test custom software designed around your business. Good things, bad things. Good things, we are in the new year. Things are off to a better start this year than last year. Bad thing, the weather in Tennessee still is so freaking unpredictable. We're freezing one day, warm in the next. So allergies are already upon me. And today, our guest is Tyler Dane. And I'm going to let you go ahead and introduce yourself. So why don't you stand up and introduce yourself to the crowd there? Yeah, I'm already standing. But I'll tell you, I'm a developer of 10 years officially, but I've been coding for probably 14 or so. And recently, I've been doing more of the entrepreneur stuff. So last year in the fall, quit my job and I'm going all in on the tool I currently have to bring it to market and get it profitable. So day to day, I'm doing a lot of coding, but also marketing and getting it off the ground. And that is a sweet spot. I think there's a lot of people out in the audience that are somehow related to that. We've either done that or are considering doing something like that. I think I'll start with the big question is what prompted you to go ahead and dive fully into this product? What is it that led up to this maybe? Yeah, I've gotten that a few times. And honestly, the completely honest answer is I was just sick of having a full time job. You did not need to go full time on this. I just feel like I don't like having a full time job. I don't like being told what to do. I'm very stubborn. I have a big ego and I had enough financial savings from my full time job of the last two years when I was a lead engineer, when I said, OK, I have enough where I can give myself some padding to do this. But if you were just to be like responsible, I would say just keep moonlighting. Don't go full time and then try it out and see what the market says. But it was honestly I was just so I was so sick of it and nothing against the other job or the other employees. I still stay in touch with them and appreciate them a lot. It's just more of the it just doesn't fit me. And I know that and I had enough savings to allow myself to take another swing and make it work this time. Yeah. And I think that's a that's again, it's a it's one of the things that I think people struggle with a little bit because you there's the love of your product. I think anybody that's building their own product, there's some sort of a love. There's a desire to get that thing out the door. And then there's the responsible side of I've got to pay bills and things like that. And then also there's just whatever sort of loyalty that you have to you to an existing job. And then there's the fear of stepping out and saying, OK, now I'm it sounds really cool. I'm going to be my own boss until day one when you're your own boss. You're like, OK, well, all right. Now what I do is one of the things where sometimes it's very challenging to get out of bed and say, OK, now I've got to go to work when work is not anything that you've you've related to before. So I love that that recommendation. Just say, keep trying out, you know, do a little moonlighting of essentially sort of that side hustle where it's you've got your real job and allow yourself to work your way in. And that leads me to the next question. So you did this. Did you as you were moving to leave your job and go into this full time, did you sort of put together a plan and a road map and say, all right, you know, I'm working towards this day one when I'm my own boss, I'm going to do this. Or did you leave your job and then say, OK, now my own boss, I've got to figure out where I want to go from here. That's that's what I did the first time. So this is like my third time doing this pattern of thing. I get full time job, get financially stable, get sick of it, quit. So this is round three for me. And round one was I'm so great. I don't need to have a plan. I'm just going to quit and do it. I didn't have a product. I didn't know what kind of person I wanted to serve. It was just like open free time and I had no structure. And and I kept the runway low or my expenses low. And so I could extend the runway a lot. And I was in my mid 20s. So it wasn't that tough to live frugally. But then I just never got anywhere. And the long delays and the lack of momentum and doing it yourself. Also, it just wore me down. And this time I do have a plan, a rough plan on who I want to serve, which is software engineers, which is why I was really excited to chat with you guys today and a rough plan about what the product could look like and a couple of problems to solve. And the product is out there now, one version of it. So it's an open source tool and anyone can use it. And we're going to pivot it to make it more more useful. But I have a lot like set up. I have the analytics set up. I have a bunch of users I've talked to. I've got all the CI pipelines and it's all deploying and like I can I can ship something within three minutes if I want to. So there's a lot. The foundation is a lot better. And then also say on a personal side, like I'm a lot more stoic or emotionally stable than I was before. So I don't get knocked off center when someone doesn't like the app or when someone says no to a call or when I can't get the ear of someone. I want to get some feedback from like before that really threw me off. So I think there's also a part of like a character stability that that needs to be there to really go for it. So you don't so I don't go back and forth and like waste too much time. So all that came together. I felt like, OK, this is enough to work with and make something happen. So you say this is your third attempt. So between the three different attempts and in between, you know, taking these jobs to get financially stable, we've all kind of done that. But what's kind of your lesson learned? Why are you doing this a third time? You know, between the first and now, what are some of the steps that you have like lessons learned and what do you think you've improved upon and why you think it's going to work this time? Hmm. OK, I'll tell you why I'm just doing it in general, and I'll say the lessons I learned the first two two attempts. I think some people are. Can just be employees and I have nothing against that, like that's awesome, and I'm jealous of those people. But as I just learned about the benefits of ownership, as I saw myself as a creator, I wanted to have more control over my creation and I wanted to decide what I was creating instead of just signing up for someone else's creation. I think that's one of the double edged swords of being a developer is that you have the skills to create anything. But then to get off your feet, to get your first job, to get your experience, you have to give up all your time creating someone else's thing. And that's a trade off you make. And I felt like if I just stuck in that lane forever of creating someone else's thing and just getting better at the creation part, like the craft of it, I would I would just not be happy. Like I proved that a job after job after job after job. So I just know that about myself. And so now it's just a matter of actually executing better than I did before, which goes to your second question. And the thing I keep coming back to is just speed like I didn't want it to be this conclusion. I wanted to have more balance or to just be really tuned into my judgment where anything I did was the right thing. And I could just do it well. And then I could go a little slower and still outcompete. But now I think it's just doing a lot and seeing what works, doubling down on what doesn't work or on what works. Letting go of what doesn't work. And then just the sheer like violent volume lets you hone your judgment. So you do get to that point where you can decide what is the right thing to do and what isn't. But early on, I just didn't do enough. It took too long to ship. My users saw it. My teammates saw the potential people I was trying to recruit saw it. And I think that was the main thing. I was just not willing to work hard enough or long enough and do enough. So I'm flipping that this time now. I've said it my whole life where it's all simple. All I need to do is have some good food, get some sunlight, do some exercise. And then I work. And that's that's my whole life now. And I'm at peace with that. That it actually gives me a lot of joy living this way. So that's the main thing. Excellent. All right. So you talk about being a creator and you talk about this is your third time and you're working, you know, you're basically putting all your eggs in your basket or, you know, focusing on your application. You're trying to get it out there. How did you come up with your current product? And how are you ensuring that you have a product that has a customer base? Or how did you define the problem that you're solving and, you know, that you actually that is a problem that people want to purchase? Yeah. I was building for myself. So I told you that first time I just quit and went out there without a plan. And I saw when I was doing that, I had no structure around my time. Like I went from having my full days with a bunch of product managers filling up my calendar with meetings and PR reviews and whatever. And then I quit and then I had nothing. And I saw myself just not having any accountability or direction. So I'm like, I need some structure now that I have full control of my time. But what I was seeing was there was the solutions were at the opposite ends of extremes. There is the kind of tools that wanted you to time block every minute of your day and go all out. And then there are tools that were too loose and didn't let you do enough. So I wanted a tool where I can hold myself accountable, but not overdo it and be subservient to the tool itself. So that's what I started building, played around with a lot of different things. But the problem was trying to solve my own problem of not structuring my time well and being accountable, especially when you're solo. You can buy your own BS like so easily. So having some kind of a metric or tool or something to reflect reality back to you was really important. So I built it and what I learned about the market is selling it as a general productivity tool appeals to a lot of people, but it's hard to really cut through there. I had a hard time competing on just that as a selling point. Like here's a productivity app that'll make you more productive because so many other apps are already out there and they have such a rich feature set that to compete with them, I don't have needed to raise a lot of money and have a big team and then get to feature parity with these other tools and then make it cheaper or have some other tweak on it. Whereas when people would come to my app with that in mind, like, oh, it's a Google Calendar clone or it's a Calendly clone, they would just find all these things that Google Calendar could do that mine couldn't or Calendly could do that mine couldn't. So that comes to the pivot and the pivot is just focusing more on a specific person and picking one specific job that that one specific person does. So that's where I'm coming to coders, to developers, software engineers. The problems I'm looking at are either writing the code, helping that workflow get better or planning to write the code, like creating issues and structuring those. But that was a long-winded response. That's what came to mind. So if I were to use your application and say I was your customer, so you just compared this to Calendly or people compared this to Calendly or Google Calendar. How are you going to sell this to me? How is this tool going to make my life better for me if I were to use this tool? What are the expectations from the user that you're now? What are I guess at the end of the day, what kind of metrics and things are you going to be showing me that this is working for me or that this application is actually going to make my day better? Yeah, so I'm pitching it now as like what the product is today since I mentioned the pivot and how we're changing. But today it's out there, it's live. How it helps you now is it's a better UX and it's built for like an engineer sense. So the keyboard shortcuts offline, it just works. It's not too bloated. It's lightweight. So people who like premium tools, people who like taking vitamins, everyone used to say to me like don't build a painkiller, not a vitamins. And I always say like I have vitamins every day. I love vitamins. Vitamins are a huge industry. Some people just love vitamins and some people just love premium tools that feel good. So if you're in your calendar all the time, if you're in your to do app all the time, if you're on your computer, your whole life is there. You want to have the best tools. And so mine is in that category. And that's how I pitch it to people. If you really care about having a really nice, lightweight, premium feeling tool, you might be interested in my app Compass. But if not, just keep using Google Calendar and like that's fine. No worries. Yeah, I think that's often the struggle. And this is there's a lot to unpack in which you've already laid out is that I think especially as developers, we can create just about anything. And it's those of us that make that step into and say, you know what, I've got this itch I want to scratch. And so you build something and then you go, well, everybody should love this because I love it because you build it for yourself. And I think that's often the first hurdle to get over is like, okay, this is how I work. Maybe not everybody else does. Or if there are people to do, I've got to go make sure I'm talking to those people. I'm not talking like you found out. You don't want to talk to everybody that's got a calendar app because everybody's got one on their phone. And you run into exactly what you found is it like if you look like X, then people are going to say, why can't you do the same thing that X does? You know, it's and then and Calendly, I got to, you know, I got to say that where you're at has got to be one of those areas. It's just flooded. Like you said, there's productivity tools out the wazoo every year. There's phone apps, there's desktop apps, there's automated things, there's enterprise level, there's small. But so, you know, that's it is definitely an area that's difficult to to get yourself heard amongst the noise. And it's great to take that and focus and say, this is always people come back to the idea of having your avatar, your ideal customer and saying, this is who I'm serving and focus on that. I think people talk about riches in the niches and some of those kinds of things and in niching down, but it's not about shrinking your your available customers as much as it is, is making sure that you're laser focused on the customer that's going to most benefit from your product. And I've seen that a lot where people sort of go and done it myself. And I think Michael's done as well, where we we go through these iterations of like, OK, we're going to give it a shot. And then we back off because it's not quite what we want to do. So we'll sort of like recuperate, reset and say, OK, now we're going to take a shot. And then we maybe it doesn't succeed. And so we come out. All right. So now we're going to take a shot. But I think each time you learn and that's one of those key things is that incremental, each time you do it, you're further along, you've learned more and you've hit the one of the things that I've often said, which is why development is what it is, is that developing and creating tools is not going to get you everything you need. You have to actually get on the entrepreneur side, the business side of it, and understand that, OK, we've got a product we've got to be able to deliver. We've got to be able to sell it and market it. And we've got to be able to have all of the things that are involved with that. So it's really it's really fascinating to hear you talk about this so much in line with what we talk about very often, turning you into like almost, I guess, you may almost be like our avatar, you know, like our ideal kind of a person out there in the audience that's saying, OK, we're you're going through it. You got some skills. And then now you're out there and doing it on your own. Can I ask you then, since you've talked to more people who are in this kind of same phase, what are some of the skills that great developers or engineers have or are lacking when it comes to the entrepreneurship side so that they don't learn when they're becoming great developers, that they have to learn quickly when they're bringing it all together? I think the biggest one is, honestly, especially senior engineers, and I've even suffered from this in my career a little bit, is actually listening to your customers, finding out who your customer is and listening to them because it is is too easy for us to say this is what needs to be built. These are the requirements. And then you put in front of somebody and you're not listening to what their feedback is where they say, well, yeah, this is great. But these are some things that it would would make it easier to use. And a lot of times we hear this is great. So and then the but just sort of gets lost in the static. And I think that I think you you alluded to earlier is the being personally tied to what we build. We've actually had a lot of people I think almost whole seasons we've talked about some of this where it's it is very hard to be a creator and then have somebody say that your baby is ugly. But that's not you know, we need to not look at it that way. But instead of here, oh, you've built something and somebody cares enough that they're giving you feedback. And so take that and say, OK, I'm going to serve that person by building that feedback back into into my solution. And it's you when you're building it for yourself. That's one thing because you you know if you like it or not and you can iterate through stuff and you can wash away the warts and stuff like that because you say, well, at least it's doing what I want it to do. But if somebody is paying for a product or a service, then they have expectations and you have to remember that that's part of it. And particularly, I think coming out of corporate will call it corporate America. You know, being an employee, I think I think one of the hardest things figuring out how to direct yourself, how to organize your time, how to know what your priorities are, because it's you laid it out like you'll have a project manager or manager that says this is a project you're working on. These are the requirements. This is the design. This is this is how it goes. And we love to complain about that as developers and say, well, nobody does it right. They're not doing this right. They didn't do enough of this. They did too much of that. But when we do it ourselves, now all of those things that we call it got for free now have disappeared. We don't have a team. We don't have other people to ping stuff off of. We don't have software, you know, all the tools and all of that kind of stuff. We don't have the freedom to take a day off unless we like now we're not getting paid when we take a day off. So there's a lot of those things that I think we run into. And it really is. It's just like, so I love the idea of side hustle is like forcing yourself to a schedule even of like, I'm going to spend five hours a week on a Saturday, let's say, and do this work. And I'm going to make sure that I'm making it productive because otherwise it's really easy for it to your backlog to never get addressed. For sure. Well, you might go. The other the other problem with that is and I've run into this multiple times where you have this idea, you build this product and you've got a customer in mind and then you go out to find those customers and you're not finding the right people or you're not getting the right customer set. You're talking to people, yes, but the people you're talking to aren't your ideal customers. So the feedback you're getting can lead you to scope creep or you end up changing your product to serve the wrong customer. And you got to be careful of that, especially this is your third iteration, but really at any iterated process or any time you're doing this, starting a side hustle, starting a business, you have this vision. You have this idea of your application. You may have already written the application. You have to be careful. As Rob mentioned, you have to listen to yes, we like this, but and you do have to pay attention to the but you want to listen to the feedback. You want to listen to that criticism to find out are you in the right niche? Is your product really serving the customer that you're after? But again, you also have to listen to make sure that the customer you're trying to serve that you're talking to those customers and you're not talking to the wrong customer. It's kind of like that old saying, you know, build a better mousetrap and you'll lead the world to your door. The problem is there are too many mousetraps out there. You don't necessarily want to flood a market and be the app of everything because you'll be the app for no one because there's too much competition. You want to make sure that you find that niche, that your software is serving a purpose. It's solving a problem and that you're getting in front of the right people for them, you know, for to solve their problem and make their lives better. And that is where we're going to pause this interview. Oh, don't worry. We are not done. Tyler is going to continue to pick our brains while we continue to pick his. It's just a great little thing going on here. Had a great conversation with them. Really appreciate his time and the questions he asked were excellent and the experience that he's brought that he shared. I really, really appreciate that he's opened up and given us some of that and just sounds like a great guy to follow. So definitely reach out. The links will be in the show notes and things like that. So reach out and say hi and maybe he can help you also be more productive and get to whatever product it is that you are creating. That being said, it's time for us to wrap this one up. We will be back before you know it with our next episode, but go out there and have yourself a great day, a great week, and we will talk to you next time. This was sponsored by RB Consulting, your partner in building smarter, scalable tech from startups to established teams. RB Consulting helps you turn tech chaos into clarity with proven roadmaps and hands-on expertise. Visit RB-SNS.com to start your next step forward. Also sponsored by Envision QA. They help businesses take control of their software by focusing on what matters most, quality, reliability, and support you can count on. Find out more at EnvisionQA.com. Thanks for tuning in to the Develop the Newer Podcast where we're all about building better developers and better careers. I'd love to hear your thoughts or feedback, so drop a note to info at DevelopTheNewer.com. Be sure to subscribe on Apple Podcasts, YouTube, or wherever you listen. And remember, a little bit of effort every day adds up to a great success. Keep learning, keep growing, and we'll see you in the next episode.