Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit “Estimation Essentials” with a fresh AI perspective.
Discover why estimation is more than numbers—it’s about building trust, avoiding burnout, and delivering value. Learn practical frameworks, common pitfalls to avoid, and how to price with confidence in every project.
Key takeaways: • Why honest estimation matters • Hidden costs that derail projects • Time & Materials vs. Fixed Price models • Practical steps to improve estimates • The role of MVP thinking in project success
👉 Subscribe for more episodes on software development, AI insights, and building better businesses.
*Follow-us on:*
* [email protected] * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://x.com/develpreneur * https://www.linkedin.com/company/develpreneur/
Transcript Text
[Music] We're back and we are doing Oh, I got to throw this out to chat GPT. Uh, let's see. So, we are going to do uh where did I put that? That's the Michael one. The other channel estimation essentials. How to nail pricing for development projects. Wow, this is always a fun one. >> Um, >> and always a challenging one. >> This is like I get these questions all the time. Like, how do you do this? How do you price that? And then it's like it's such a personal choice kind of thing almost. It's like I don't know how many times and I I don't know how many times I've talked to people and said, "Okay, this is what you should do." You know, it's not necessarily what I do, but this is my my understanding. This is what you should do. And then they don't do it anyway. So, it's just like, "Okay, so why did you bother? >> Why did you waste my time?" Because I think a lot of times people come back fall back on the I am going to price it to whatever I can do to make sure somebody buys the freaking product or buys my time. Where is you? There is you. So I can paste that here. Uh I need to do this so I've got my crap in front of me this time and I'm not so completely disjointed. And let's see. >> I don't know if you're doing this, but um I found you can pull the chat out of Slack, so it can kind of be full screen if you slide it to the side without having that little dash bar thing in the way. >> Oh, you mean in Zoom or in >> in Slack? >> Oh, yeah. I don't I've done it a couple different ways cuz I that's a that's a my last place I was at there was like I don't know 400 Slack threads or something like that. So I was constantly doing that and organizing and moodling around. It was like, it was funny because there was a system they used and it just got flooded with too much stuff and everybody ignored everything and so they switched everything to email and the emails like I literally got thousands thousands one zero zero plus some of email every single day and a lot of it was stuff that was system this goes back to our prior conversation a bit systems that were saying I'm okay it's like then don't tell me tell me what can you blow up and it would go to everybody. It would go to like groups would be hundreds and hundreds of people. So, it's like nobody's going to do it because somebody's going to fix it, not me. And so, nobody ever did. It was a waste. It was just it just went right away into delete. And it was a it was a waste. And then Slack, they're like, "Okay, we're going to use Slack." And then next thing you know, Slack is just slammed with stuff. And it's just >> So, this is like a good pre- bonus one. uh especially like what Rob's mentioning and one of the things that becomes dangerous with this uh for production support is you become message blind or error blind because you're getting too many notifications or you're getting notifications that yes the system's broken but it's not your problem. So you start to ignore it and you start to not see the messages even though they're coming to you. And then eventually you're going to miss a critical one where the systems are down and at that point your phone's going to start ringing. So it it's better to ask yourself one, what notifications are important? And two, why are we getting so many notifications? Because if you're getting too many notifications, chances are you need to redo what type of notifications you're actually sending out. either start turning off or turning up the uh severity on what is being reported or you need to redo your guidelines as to how you write software and how you send out notifications. A lot of times it is it's stuff that you should be looking at that and you should be regularly going through and if you're getting a lot of like warnings that aren't really that don't rise that level either sooner or later fix it. either that's not really a warning and it's just it's a false positive or it is and go fix the stupid things so that you don't have those and clean it up. I mean it's it is sometimes time timeconuming it is almost always technical debt of some sort but it is worthwhile. It's like going through when you've got like compile errors but you also have warnings is getting it completely clean from the warnings as well which sometimes is useless. It's not like or doesn't help that much, but it is just nice to get everything clean so you don't have to worry about it. All right, speaking of clean so you don't have to worry about it, we have a clean takeoff ready to go. We have been given the go-ahhead and so let's dive right into this. Hello and welcome back. We are continuing our season of building better developers developing our podcast with AI. AI. AI. Okay. Crappy sound effect things that were there. Uh, what we're doing is we're looking at a couple seasons back. We're taking the topics and we're just redoing it. It sounds lazy, but it's actually pretty cool. We're throwing it into AI and saying, "AI, what would you do?" And then we're talking about what AI kicks back out. And it almost always, yes, there's a few things that it covers that we already talked about, but it almost always spurs other conversation points. Now, first off, I'm going to go ahead and introduce myself. I am Rob Broadhead, one of the founders of developer, also the founder of RB Consulting, where we are like a the simplest way to do this is say I help businesses simplify their technology and build clear road maps that fuel growth. That's like one of those like AI kind of answers right there. But that's it's what it is. That's what you want is it's like what do we do? We are sometimes known as a fractional CIO or things along those lines. We're also a boutique business consultancy. What we do is we sit down with our customers. We talk about their processes. Hopefully, they know them. If not, we'll help you work through your process, get some of that stuff that's in your head out of your head. We also know some nice process consultants and stuff like that that can help you get that part of your house straightened out. And then once your house is straighten out, now we can talk about how to do it better, more efficiently. We can simplify, integrate, automate, innovate. We can find ways to do those steps for that process better, faster, higher quality. Now you get to work on your business instead of in your business and your customers love you because that's how the natural order of things is. Check us out at rb-sns.com. We have a whole new website sort of and uh we got old content. It's been around for years, but we've also updated a lot of stuff. So love to hear feedback on that. Uh also matrix.rb-sns rbsns.com. You can go check that tool out. We're soft launching it. I guess maybe this is now a hard launch. However you look at it, uh some of the stuff that we've got to just help people out if you're wondering where you sit in your need for a technology assessment. Good thing, bad thing. Um good thing is that we have downsized and we've got like so many things that we don't worry about anymore. are like we don't worry about if the yard get mo gets mowed because we don't have a yard basically and things like that that we're like we've simplified our life down so that we can we are much more mobile and things like that. Bad side of that is we were in an apartment. We're an apartment. We don't have like you know like we used to have you could go out to the mailbox. You had a front door. So like deliveries that come to the front door. You go to the mailbox. You get your mail. We now have to go somewhere else. And when deliveries come sometimes they don't go to the place that they should. And so a bad example of like what can happen or is we have a restaurant that is attached to where we're at and we had a delivery that got delivered to the restaurant. It disappeared off the face of the earth. At that point, we figured out because they sent us, which is great. We got the typical picture of here's your product being delivered. They they you like a picture of this product being handed off to somebody and that's all we know. And we we got that. It's like, what the heck? That's not not even close to a mailbox, but that's okay. You guys took it to the wrong place. One of those bad things. Uh out there in the middle of nowhere, Michael gets everything to his front door, I am sure. or one of his front doors. Anyways, and he's going to go introduce himself. >> Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of developer. I'm also the founder and owner of Envision QA where we help startups and growing businesses build software that works the way it's supposed to from day one. We make sure that software is what it's supposed to be and make your customers happy. You probably have heard stories of software projects going over budget, launching late, or breaking once users get their hands on it. You know, that's where we come in. At Envision QA, we make sure that your product is tested, stable, and ready for the customer. We handle the behindthescenes quality checks and support development so that you don't have to worry about that. We help you launch faster, avoid costly mistakes, and protect your reputation. In short, we help you build software that doesn't break your business. Check us out at envisionqa.com. Good thing, bad thing, good thing, we are in I guess what's called a false fall. I think it's fall. We're cooling off. Uh bad thing, uh my wife loves her little uh 10 foot pool we put up every year for her to cool off after doing all the yard work since it gets so bloody hot here. Uh unfortunately, we have now hit that point where the pool is now staying so cold, we can't get in it anymore. So, we have to break it down. Uh yes, I was actually just in a lake the other day and it was still uh almost bath warm kind of thing. So, it was like it was nice because it was a little breezy, but I think a little cooler would have been even better. Uh, cooler than that is where we're going now. So, we're going to talk this time around. Uh, the original topic was estimation essentials, how to nail pricing for development projects. Episode flow. Oh, again, this was chat GPT5 and it comes back. It gets like right to business. Um, it gave me it did give me the obligatory perfect title and then it gives me this stuff. It's just like, "Okay, here you go." Episode flow hook. One to two minutes. Open with a common pain point. Ever been asked, "How much will this cost?" And your stomach drops. Estimation is one of the trickiest but most important skills in software development. Tease the payoff. Better pricing means happier clients, less stress, stronger career growth. Uh first uh section here, I guess the second section after the hook. Why estimation matters. 3 to four minutes. It's more than numbers. It builds trust and credibility. Impacts timelines. Client satisfaction and profitability sets the tone for whether a project feels like a success or failure. That h that is it in a nutshell. That is why we estimate. That is why we need to be honest about our estimation. I spent a good deal of time today walking through a uh since it was an RFP that somebody spent a good deal of time putting it together. There's a lot of detail to it. They're they they're merging a couple applications and they talked about that about okay here's the features from this one and this one and this is how they're going to join in and what it's going to look like. Here's some some other things that we want to do. And it was really good. I'm cruising along. I'm like, "Yep, that's going to take x amount of time. That's going to take y amount of time." And I'm just cranking through and then I get to a section that is way open-ended. that is it was it's we want to have integrations with a bunch of payment processors like AB and C like that and we would like to integrate with different accounting systems like this one but there's other systems that they haven't talked about and then there's some other things that they talk that are like integrations and things like that it's like okay and I had to take that section and and that's where you just be honest with them and say I can't give you a valid estimate on this I have no idea idea what it can take. There's not enough details. Nothing is the, you know, some amount does not give me an X amount. So, if I don't know how many things you're going to integrate with, I cannot possibly tell you what it's going to cost to do that. I can't even tell you. If you can't tell me which ones they are, I can't really give you an estimate per because some are going to be easier than others. And depending on what you include and what that integration looks like, I'm not going to be able to help you out. I can't or at least I can't at this point give it to you. Now granted this is something that you start into that conversation. But the reason I bring this up is that I think too often we end up in at least I know I do run into situations where the customer really wants a hard number. They want to say it's going to cost $10 to get this built. Okay. The problem is we can give them a number like that but if you're if you're smart your number is going to be insanely big. If it c if you think it's going to cost $10, you're going to say it's going to cost $100 or something like that. This goes back to setting expectations. And if they b at it, say, "Well, look, I don't know that it's really going to take that much, but I have to do that to be safe because it could because you could change your mind. There could be requirements we haven't talked about. There are requirements that you haven't actually detailed. And I can guess at this stuff, but I'm not the customer. I'm not the one that's building it." So be honest where there's things you're like, "Well, we need to talk about this more." And it's not don't say it can't be done or we can't estimate it or anything like it's just like at this time we can't give you a valid number. We can't give you something that works because we don't have enough information. So instead of us giving you just a something that we've pulled out of thin air, we're going to sit down and talk to you and then we'll give you, you know, a timeline and estimates and things like that. will give you the details that are needed to actually build out that pricing. And last thing before I toss it over is make sure when you estimate that you are honest, like if you're a developer, just always overestimate. If you think you're estimating too high, you're still too low. Developers are horrible about I'm going to get it done in a month and six months later you're still working on stuff. Part of it is our fault because we think we can do everything instantly. Part of it is the fault of the the project managers and the customers because they start with something small and then things start to get added on and the next thing you know it's bigger and bigger takes more time. Don't fall into the trap. I know I said one more. Okay, the last one. The last one more. Don't fall into the trap of a customer that's like, well, you know, we could do it for that, but then they try to, you know, lowball you like, but gosh, we really had a budget at what, you know, 90% of what it was. It's like the value is the value. The cost is a cost. It's like you don't get into a cab with somebody, get halfway through the ride, and say, "Hey, can you shut that flag down and turn the meter off for a while because I don't really want to pay that much for this cab ride." It's sort of the same concept. Your thoughts on this? So, you kind of touched on most of the points on this one. I don't want to beat this too much, but one of the big things is be honest. Don't lie to the customer. Don't overpromise. Although that can still happen, but don't deliberately overpromise and underdel. We want to uh, you know, underpromise and overd deliver. So, like Rob said, you know, if you think it's going to cost $10, charge a hundred. uh if you think there's underlining uh issues that could arise that could have things go off uh you know go off the rails. The best example of this was something I read about the airlines years ago. So airline satisfaction was horrible and down. People were constantly complaining about airlines never being on time, ticket prices being too high and so on. One of the biggest things I heard about how this model changed was what they did was they increased the time of the flights. They decreased uh the cost a little bit but they changed the expectation essentially what how long is it going to take to do something and all of a sudden customer relations went up. Customers were more satisfied. Trips were not taking so long. Flights weren't being cancelled. So it is along those same lines. Make sure that what you are looking at fits within the expectations of the project and your customer's expectations. If you say it's going to be done in a week and you don't deliver within a week, you're going to have an upset customer and that is going to impact your business and your reputation. >> And then we'll go right into the common pitfalls because you actually touched on a few of those. Overpromising, underestimating to win a project, then burning out. ignoring hidden costs, meetings, testing, documentation, forgetting risk buffers, unexpected issues always show up, using gut feeling instead of a res a repeatable process. I'm going to start with the uh underestimating to win a project and burning out because if it's if you're side hustling, I have seen a lot of those. I have struggled with that at times and I have been the beneficiary of that several times where somebody got into a project and then flaked out and disappeared because they just got worn out. The problem is that they screwed over their customer, they are not going to get that customer again. And a lot of times I end up winning that customer because I come in and say, "Okay, we're going to take this to the finish." And yeah, it's nice because they got it 80% there. So now we have a better idea of what's left. But uh particularly with a side hustle, I know you go into it because most of us do where you're like, I have a day job, my bills are paid, blah blah blah. I don't really I'm just doing this for fun. Projects become not fun on a regular basis. There's always going to be something where you're like, ah, I would really like to have a weekend off, but no, I'm still working on this stinking project. And so, be aware of that. Make sure you're setting yourself up for success. not just them but yourself as well. Uh the last part I want to touch on too is the whole uh don't use gut feeling instead of a repeatable process. This is why we estimate. This is why we need to even in our own projects have a feel for like what are we doing? How much time are we spending? How much time are we wasting? Because that commonly is our issue is I don't know how many times somebody's like I was working for 10 hours today. And you figure out that well yeah they were at work they were at their desk for 10 hours but they spent you know three hours like lost in listening to the news or they got caught into something they had to go walk the dogs much time or whatever. It's like find ways to figure out exactly when you're working. I can go back to my favorite pomodoro and things like that because those things really really will help you like know when you're focusing and when you're not because that's a whole focus of I mean that's a whole reason for those is focus do your stuff and then move on and you're going to realize that you're not going to work eight hours a day that 8 hours or 10 hours or 24 hours that you thought you were working if you're doing a focused method like that you're going to realize one you're going to realize that that's not how much you're working but two you're going to get more done when you do it because you're not going to have all of those distractions. Um, you already started so I'll let you just sort of carry on with some of the common pitfalls and what you see. Yeah. So the the one I'll touch on is the hidden costs because you and I have talked about this off uh you know on the side quite a bit because a lot of times we forget there are meetings there you know you have to do testing there's documentation and when you plan out a project especially if you're doing this as a side hustle you're not going to think about these at all you're just thinking about how long does it take to get this done. The problem is if you go in with that mindset and you don't think of this as a whole project. Now, if you're building a website, okay, maybe not as much, but you still have to think about documentation, but testing and meetings when you have larger teams is critical. You need to make sure that you plan for this because if you have, say, 20 hours a week for a budget and you have a team of four, you want to make sure that you're optimizing as much time for development as you can, but you still need to account for those meetings. If you schedule two-hour meetings into that time frame, that's two times four. You've lost time. So either you attack that early, add it to the estimization to your budget, and then you plan for that ahead of time. >> And it adds up. Time adds up really quick. meetings in particular. I I one of the um just to add to that, one of the things I find most often gets lost is once you get to a team is project management kind of stuff, which is meeting with the team, but also meeting with the customer and doing like statuses and things like that. If you meet every day during the week for a half hour, that's 2 and 1/2 hours a week. And if you're saying that we're going to just tack 10% on to the end of the, you know, to the total, that's only 10% means you're for, you know, 10% for project management basically means you're 10% of your week, four hours. That basically means you're budgeting four hours of project management stuff. If you spend two and a half hours just managing the team, then there's not much else you're going to do. If that man project manager is also looking at like creating tickets and chasing down tasks and uh doing statuses and things like you can burn through that very quickly. Uh testing is another one that like don't you know don't think there's going to get away with like a 5% you know upcharge or whatever on top of it for testing. And it does, it gets scary, but it gets real because you're going to go do your, you know, I've got a 200 hour development estimation I put together. And then when you add on, you know, maybe another 5% on top of that for documentation and 20% on top of that for testing and 10% 15% for project management depending on your size. Those things add up really because those percentages just another 40 or 50% sometimes that goes on top of it. But that's where we get hosed because we get to the end of the 200 hours and we still have a 100 hours of work to do cuz we didn't figure it out from the start. We didn't set the the standards. We didn't set expectations and now we're begging for money or saying, "Ah, I'm sorry." Or working for free. None of that is beneficial. None of that is fun. Approaches to estimation. Uh bottom up, break work into tasks. Estimate each piece. Top down use similar past projects to guide estimates. Three-point estimation PR peer t uh optimistic pessimistic most likely time and materials versus fixed price. The pros and cons of each. I will briefly touch on time and materials is almost always the way to go. Fixed price, you can do it, but oh my gosh, you better know exactly what you better have done this a lot of times. You better know exactly what you're talking about. And don't let yourself get caught in the time and materials, but it's actually a fixed price because I have seen that has been used a couple of times to say, "Look, we'll pay you x, you know, we'll pay you by the hour, but we're going to limit the number of hours per week or month or whatever the time, you know, there's going to be a limit to those. There's going to be a cap." And then somewhere down the road, there's a cap to the whole project. So, effectively, they're trying to win on either end of it. If it gets done faster, they don't pay as much for hours. But if it goes beyond, they're not paying for the beyond. It's one or the other. If you're doing, if it's time and materials, more of the risk goes on the customer because they need they want it to get done because the longer it goes, the more you're getting paid. If it is fixed bid, then it is you're holding on to the risk. So, if it's time and material, it should be, you know, more aggressive pricing and things like that. they should be getting their money's worth and then some. If it is fixed, then you should be getting a premium on that. And it's, you know, now if you want to do something where there's, you know, early bonuses or there's going to be penalties if they're late, that's all great. I mean, that that kind of stuff works. I I found several times that one of the best ways to do it is say, "Here's what our rate's going to be. you know, we're going to do $5 an hour, but once it gets past a certain point because we're, you know, we're sure, pretty sure we're going to get it done by this time. If we don't, then we're going to cut it in half or we're going to go to $4 an hour or whatever it is. Is to say, okay, you're getting discounts as a customer because we didn't give you the proper estimate. That means we both hurt and hopefully means that everybody's going to get the stuff done uh as fast as possible. The other methods, you end up working against your customer way too often. Um, I spent enough on that that I'm just going to throw it back over to you. >> Yeah. Uh, so you touched on the one I was going to hit, but uh, I'll start with this one. You know, the three-point estimization, the perk, optimistic, pessimistic, and most likely. Be careful with this one. Well, it is beneficial to what's the best case scenario, what's the worst case scenario, and try to take something in the middle. Sometimes that's not always possible because there are always external or you know additional factors that you just don't account for. You know it could be COVID, it could be oh you know uh the current version of Windows is now obsolete. You know things like that you just have to deal with as they come along. But the that could be the pessimistic approach. However, when you're doing the pessimistic approach, you're probably not thinking that pessimistic. you're probably not thinking that worst case disaster. So, you have to balance the good with the bad. Um, but this goes kind of back to what we talked about before where you need to make sure that you've broken down the requirements for what this project's going to be clearly enough that you can define, okay, this is what this should take. This is if we can't complete this, this is what it should take. If you get to those sections like Rob said where he had like, oh, it could go to this uh, you know, accounting system, it could go to this payer, those things you can't touch because you don't have enough information. So, if you follow this and you get to that point and you're like, wait, optimistically, yeah, if we know who this is, we could possibly do it. But if you have a lot of those questions, that's when you need to go back and solidify that, nail down some of those requirements before you get too far. And if you can't uh because I've had a I had a customer, this reminds me of a customer I had uh a while back and we ended up sideways with each other basically because I gave I did it that I said okay here's the opt and he wanted the optimistic. He really was like I need the optimistic and I was like okay well that's very optimistic and sure that would work if everything falls into place. I said, 'But these are the things that can go wrong and this is what can and any one of them can take us off track. And as we did them, as we were going through, almost everything that he said was like, well, this is great and this is working and this will be fine. And all these optimistic assumptions he made were wrong. They tr they turned out to be untrue. And so as we got through them, I was steadily communicating to him that, okay, we thought this would happen. it didn't. It's going to cost us x amount of time. You know, it's like we thought this was going to take a week. It we can't do it in a week because the things that we assumed are wrong. So now we got to go back and fix those. So now it's going to take a month instead of a week. And even though this is like part of the part of why I'm not a real fan of this anyways is that he got stuck in his head the original optimistic stuff. He kept going back to that be like we should be here. We should be here. We should be here. Even though there was a steady stream of communication, usually people are going to be more realistic and you're going to have that steady stream of communication. They're going to see what's going on. They're going to say, "Okay, we're falling into the problems." And they're either going to like, you know, they may cut the project short or they may change gears or whatever. But that's don't hide it from them because you're worried it's going to get cut short because then your butt should get cut short at the end and when they find out that, you know, you hosed them. give them that information as soon as possible so that your customer can make a intelligent decision and one that's you know now it's setting the proper expectations and sometimes there going to be stuff it's like well can you help us with that how can we find a way we can't really afford that pessimistic but what can we do and there should be options is find like MVPs and things like that to save your customer from the reality of life essentially practical steps to improve estimates uh requirements first clarify what's in scope and what's not. Ask questions before giving numbers. Break it down. Smaller tasks equals more accurate estimates. Add buffers, typically 20 to 30% for risks, unknowns, and scope creep. Validate with data. Track actuals versus estimates. Learn from past projects. Your estimates should improve over time. Communicate clearly. Share not just a number, but assumptions behind it. Example, two weeks assuming APIs are stable and no new features are added. Uh definitely that that's exactly what I was talking about is like wherever you're giving the optimistic, the pessimistic or the mid-range kind of estimate, talk about not only what it is, but why it is. What are the uh the unknowns? What are the risk factors? Ideally, this is a like um you know pro tip or whatever. When you're getting into a project, the high-risk items are the first things you should tackle. Those are the first things that you should start looking into because then you're going to know as soon as possible that yeah, that's going to work out or no, it's not and start finding ways to be able to work around it. If you wait till the end, then you're going to have a lot less way fewer options to do workarounds. Just trust me, it's always giving yourself that time. It gives you more time to redesign, to replan, to adjust and do the things that you need to. Um I would say the MV the uh clarify what's in scope and what's not. That reminds me of like MVPs is saying okay well what is really the minimum viable product. What is it that we like the minimal amount of work that we need to get this done? I am starting to have that conversation with my customers from the very get-go because it is way too easy for things to get added, for things to get moved. And as we're going through the project and we're adding things in and they're like, "Can we do this early on?" It's like, "Yeah, okay. We'll tack that on and we'll tack that on." Especially if it's not fixed bid and it's just like, "Okay, we'll tack it on, but it's going to take another week. We'll tack it on. It's going to take another week. Going to take another week." And the next thing you know, it's 6 months beyond what the original target date is. They're frustrated. they realize that they've got to get it done faster or market changes or there's so many things that can happen that can cause you to get to a point where suddenly the project need goes into like critical mode where we got to get just the things we need and get this thing shipped out the door uh and maybe they run out of funding. There's so many things that can happen. So, I have found that it is much more valuable from the start to have those critical, we'll call them those critical things that are part of an MVP because that provides you your second round of stuff is you get the high-risk stuff. So, you right away just go after those things and figure out are those risks real? Are they imaginary? What are they? And then you go right into this is what we have to have. These are the features that have got to got to got to be there because that's going to protect your customer and the project. So that if things do go squirly, if they do start to you have all kinds of issues and overruns, you do have like a uh a fallback basically so you can get something out the door that still gets them a win and allows you to, you know, f push off some of those bigger issues. Uh thoughts from you? >> So I'm going to go with the break it down and add buffers. So because I like the test-driven approach, you can almost apply that to your estimization. If you can break down the requirements in such a way that you understand what needs to be done in such a way where if A then B, then it's a small enough task that you should fairly easily be able to say, okay, that's about an hour task. Then tack on 20 to 30% on top of that for any unknowns. If you can't quite get it to that, again, get it to the piece to a point where you have at least broken it down to where you have specific enough requirements to where you know what the task needs to be to get it done. If you have those tasks where hey, we want to integrate with accountants or we want integrate with payers, that's not small. That is too open-ended, too vague. And at that point, you can't even track it. You can't even really estimate. So if you can break it down to small enough tasks, you're going to be more accurate with your optimizations. And again, always take on that additional 20 to 30% for the unknown. Well, we have once again run into time constraints and such because these are really good topics that they come up with. Uh who knows, we may have to come back around to this at some point just because or we'll just keep doing these kinds of things and just retread some of our past episodes and uh continually have new content and such. However, I would love for you to send us an email at [email protected] and let us know what you think. What do you like? What don't you like? What would you like us to address? Uh how would you like us to change stuff around? How would you like us to add, delete? All of that kind of stuff. All of the CRUD options that are out there for developer itself. You can also leave us feedback wherever you listen to podcasts. You can give us any kind of rating, one to five, like it, love it, whatever their different rating scales are. More importantly than your rating is your actual word feedback like what did you like? What don't you like? What can we do better? What can we, you know, do to help you become a de better developer? Check us out at developer.com. We got feedback forms and everything there. We got tons and tons of comments. Uh that is probably going to be doing going through a uh a revamp. I've promised that for a while, but I'm actually finally getting to that point. It's like working its way I'm working my way down to that on my to-do list. Uh, also you can check us out on Facebook. You can check it follow us on xdevelopreneur de vel p re neur.com and you can find us there. Also, you can find us here wherever you're watching us or listening us to right now. Come back because subscribe, do all that good stuff because we're not done yet. We are marching on towards 1,000 episodes. We are like 900's in the rearview mirror and we're moving on. talking to somebody today and he was like, "Wow, I remember when you first started it." It was like weird that it's already there. And I was like, I actually remember when I first started it, too, because I was there. But also, and I think he may have been the only person that's like been subscribed all the way through. That being said, all of you, whether you started at episode 1 or episode 911, appreciate all that you do. Appreciate you coming out and spending some time with us. Go out there and have yourself a great day, a great week, and we will talk to you next time. Bonus material. So, let's see. I'll wrap up these career angle. Why this builds better developers? Developers who estimate well are seen as leaders. It shows business awareness, not just technical skills. Builds trust with clients, managers, and teammates. Opens doors to roles like team, lead, architect, or consultant. Call to action. Encourage listeners to review their last project. Did actual time match the estimate. Where did it go off track? Suggest keeping a personal estimation log for reference. Tie back to developer. We don't just code. We build careers by mastering the whole craft. Bonus add-ons. More story segment. Share a time you underestimated overestimated and lessons learned. M uh mini challenge. Estimate a small side project like building a to-do app and then track the actual time. Where do you want to go with your bonus bonus material? So, I'll take that last one, that mini challenge, because um kind of did one like this way back. If you go back into our videos, there's a building a product catalog that we did years ago. This is a that is a perfect one for this mini challenge. Take something that you have like a to-do list, a task list, something that you just do every day, maybe write down, and then try to break it down into its pieces and see how long it would take you to actually automate that uh or build an application for that. This could also then easily become one of those automation things that we talk about all the time, like, hey, automate your tasks. So, I really challenge you, our listeners, to do something like this. Find an everyday task that you do every day. See if you can break it down into a project and then write it or automate it in such a way that okay, how long is it going to take and then do it and then once you're done reflect how long did it actually take you to do it? Were your requirements pretty spot-on or were you off track? You know, if this is something you do every day or something that you know, you shouldn't be off track, but I guarantee you there's going to be something you find that you're like, "Whoops, I didn't think of that." Or you've scope creeped and added things to it. So, kind of track that. Think through that process. I guess I like I want to go with that one too is that when you do that, when you start tracking what you're doing to build an application or to solve a problem, there are areas that we lose time. Um I was complaining to my wife yesterday about getting lost on a rabbit trail with chat GPT. Not workrelated. It was something completely different, but I was like, I had to answer one question and the next thing I know, I had fallen down a pit of asking a lot of other questions and I had great stuff. I mean, I got a lot of information out of it. It was really valuable, but totally took me off track. I will, if you're like me, if you're doing thing like design, it is real easy to lose four or five hours messing around with a couple of buttons and uh moving those around and changing some colors and adjusting some pixels here or there. Uh there's if it's your own app or if it's something that you're able to have some level of uh design or creativity is amazing how often that you're going to do like a refactor or something like that where you're like okay I'm going to go do this I'm going to change that or I want to move this or I want to clean this up or you know there's all these little things but they add up and so I think that is really valuable for you track that stuff because then you're going to figure out where you lose your time because that's probably more important than anything cuz there's going to be times that you're still going to do those tasks, but the good thing is now you're going to be like, "Oh, I have to watch out cuz I can lose a lot of time. So, I need to time box this or I need to set alarms or do something so that I don't end up losing my entire day working on whatever that fat feature or that functionality is. That being said, we have, as we always do, drifted all over the place in our time management and things like that. So, we are not the best at that. But this is different. We're better. I'm going to say we're better when we do it with coding and applications. Maybe we are, maybe we're not. That's something we're still working on. And we do track these kinds of things so we can get better. As always, I would love any kind of feedback you you leave us. Gave you all the places and all the things. So, for now, we're just going to let you have some of your time back. Go out there and have yourself a great day. Thank you so much. We appreciate you for listening and we'll talk to you next time. [Music]
Transcript Segments
[Music]
We're back and we are doing Oh, I got to
throw this out to chat GPT.
Uh, let's see. So, we are going to do
uh where did I put that? That's the
Michael one. The other channel
estimation essentials. How to nail
pricing for development projects. Wow,
this is always a fun one.
>> Um,
>> and always a challenging one.
>> This is like I get these questions all
the time. Like, how do you do this? How
do you price that? And then it's like
it's such a
personal choice kind of thing almost.
It's like
I don't know how many times and I I
don't know how many times I've talked to
people and said, "Okay, this is what you
should do." You know, it's not
necessarily what I do, but this is my my
understanding. This is what you should
do. And then they don't do it anyway.
So, it's just like, "Okay, so why did
you bother?
>> Why did you waste my time?"
Because I think a lot of times people
come back fall back on the I am going to
price it to whatever I can do to make
sure somebody buys the freaking product
or buys my time. Where is you? There is
you. So I can paste that here.
Uh I need to do this so I've got my crap
in front of me this time and I'm not so
completely disjointed.
And let's see.
>> I don't know if you're doing this, but
um I found you can pull the chat out of
Slack, so it can kind of be full screen
if you slide it to the side without
having that little dash bar thing in the
way.
>> Oh, you mean in Zoom or in
>> in Slack?
>> Oh, yeah. I don't
I've done it a couple different ways cuz
I that's a that's a my last place I was
at there was like I don't know 400 Slack
threads or something like that. So I was
constantly doing that and organizing and
moodling around. It was like, it was
funny because there was a system they
used and it just got flooded with too
much stuff and everybody ignored
everything and so they switched
everything to email and the emails like
I literally got thousands thousands one
zero zero plus some of email every
single day and a lot of it was stuff
that was system this goes back to our
prior conversation a bit systems that
were saying I'm okay it's like then
don't tell me tell me what can you blow
up and it would go to everybody. It
would go to like groups would be
hundreds and hundreds of people. So,
it's like nobody's going to do it
because somebody's going to fix it, not
me. And so, nobody ever did. It was a
waste. It was just it just went right
away into delete. And it was a it was a
waste. And then Slack, they're like,
"Okay, we're going to use Slack." And
then next thing you know, Slack is just
slammed with stuff. And it's just
>> So, this is like a good pre- bonus one.
uh especially like what Rob's mentioning
and one of the things that becomes
dangerous with this uh for production
support is you become message blind or
error blind because you're getting too
many notifications or you're getting
notifications that yes the system's
broken but it's not your problem. So you
start to ignore it and you start to not
see the messages even though they're
coming to you. And then eventually
you're going to miss a critical one
where the systems are down and at that
point your phone's going to start
ringing. So
it it's better to ask yourself one, what
notifications are important? And two,
why are we getting so many
notifications? Because if you're getting
too many notifications, chances are you
need to redo
what type of notifications you're
actually sending out. either start
turning off or turning up the uh
severity on what is being reported or
you need to redo your guidelines as to
how you write software and how you send
out notifications.
A lot of times it is it's stuff that you
should be looking at that and you should
be regularly going through and if you're
getting a lot of like warnings that
aren't really that don't rise that level
either sooner or later fix it. either
that's not really a warning and it's
just it's a false positive or it is and
go fix the stupid things so that you
don't have those and clean it up. I mean
it's it is sometimes time timeconuming
it is almost always technical debt of
some sort but it is worthwhile. It's
like going through when you've got like
compile errors but you also have
warnings is getting it completely clean
from the warnings as well which
sometimes is useless. It's not like or
doesn't help that much, but it is just
nice to get everything clean so you
don't have to worry about it.
All right, speaking of clean so you
don't have to worry about it, we have a
clean takeoff ready to go. We have been
given the go-ahhead and so let's dive
right into this. Hello and welcome back.
We are continuing our season of building
better developers developing our podcast
with AI. AI. AI. Okay. Crappy sound
effect things that were there. Uh, what
we're doing is we're looking at a couple
seasons back. We're taking the topics
and we're just redoing it. It sounds
lazy, but it's actually pretty cool.
We're throwing it into AI and saying,
"AI, what would you do?" And then we're
talking about what AI kicks back out.
And it almost always, yes, there's a few
things that it covers that we already
talked about, but it almost always spurs
other conversation points. Now, first
off, I'm going to go ahead and introduce
myself. I am Rob Broadhead, one of the
founders of developer, also the founder
of RB Consulting, where we are like a
the simplest way to do this is say I
help businesses simplify their
technology and build clear road maps
that fuel growth. That's like one of
those like AI kind of answers right
there. But that's it's what it is.
That's what you want is it's like what
do we do? We are sometimes known as a
fractional CIO or things along those
lines. We're also a boutique business
consultancy. What we do is we sit down
with our customers. We talk about their
processes. Hopefully, they know them. If
not, we'll help you work through your
process, get some of that stuff that's
in your head out of your head. We also
know some nice process consultants and
stuff like that that can help you get
that part of your house straightened
out. And then once your house is
straighten out, now we can talk about
how to do it better, more efficiently.
We can simplify, integrate, automate,
innovate. We can find ways to do those
steps for that process better, faster,
higher quality. Now you get to work on
your business instead of in your
business and your customers love you
because that's how the natural order of
things is. Check us out at rb-sns.com.
We have a whole new website sort of and
uh we got old content. It's been around
for years, but we've also updated a lot
of stuff. So love to hear feedback on
that. Uh also matrix.rb-sns rbsns.com.
You can go check that tool out. We're
soft launching it. I guess maybe this is
now a hard launch. However you look at
it, uh some of the stuff that we've got
to just help people out if you're
wondering where you sit in your need for
a technology assessment. Good thing, bad
thing.
Um
good thing is that we have downsized and
we've got like so many things that we
don't worry about anymore. are like we
don't worry about if the yard get mo
gets mowed because we don't have a yard
basically and things like that that
we're like we've simplified our life
down so that we can we are much more
mobile and things like that. Bad side of
that is we were in an apartment. We're
an apartment. We don't have like you
know like we used to have you could go
out to the mailbox. You had a front
door. So like deliveries that come to
the front door. You go to the mailbox.
You get your mail. We now have to go
somewhere else. And when deliveries come
sometimes they don't go to the place
that they should. And so a bad example
of like what can happen or is we have a
restaurant that is attached to where
we're at and we had a delivery that got
delivered to the restaurant. It
disappeared off the face of the earth.
At that point, we figured out because
they sent us, which is great. We got the
typical picture of here's your product
being delivered. They they you like a
picture of this product being handed off
to somebody and that's all we know. And
we we got that. It's like, what the
heck? That's not not even close to a
mailbox, but that's okay. You guys took
it to the wrong place. One of those bad
things. Uh out there in the middle of
nowhere, Michael gets everything to his
front door, I am sure. or one of his
front doors. Anyways, and he's going to
go introduce himself.
>> Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
developer. I'm also the founder and
owner of Envision QA where we help
startups and growing businesses build
software that works the way it's
supposed to from day one. We make sure
that software is what it's supposed to
be and make your customers happy. You
probably have heard stories of software
projects going over budget, launching
late, or breaking once users get their
hands on it. You know, that's where we
come in. At Envision QA, we make sure
that your product is tested, stable, and
ready for the customer. We handle the
behindthescenes quality checks and
support development so that you don't
have to worry about that. We help you
launch faster, avoid costly mistakes,
and protect your reputation. In short,
we help you build software that doesn't
break your business. Check us out at
envisionqa.com.
Good thing, bad thing, good thing, we
are in I guess what's called a false
fall. I think it's fall. We're cooling
off. Uh bad thing, uh my wife loves her
little uh 10 foot pool we put up every
year for her to cool off after doing all
the yard work since it gets so bloody
hot here. Uh unfortunately, we have now
hit that point where the pool is now
staying so cold, we can't get in it
anymore. So, we have to break it down.
Uh yes, I was actually just in a lake
the other day and it was still uh almost
bath warm kind of thing. So, it was like
it was nice because it was a little
breezy, but I think a little cooler
would have been even better. Uh, cooler
than that is where we're going now. So,
we're going to talk this time around.
Uh, the original topic was estimation
essentials, how to nail pricing for
development projects.
Episode flow. Oh, again, this was chat
GPT5 and it comes back. It gets like
right to business. Um, it gave me it did
give me the obligatory perfect title and
then it gives me this stuff. It's just
like, "Okay, here you go." Episode flow
hook. One to two minutes. Open with a
common pain point. Ever been asked, "How
much will this cost?" And your stomach
drops. Estimation is one of the
trickiest but most important skills in
software development. Tease the payoff.
Better pricing means happier clients,
less stress, stronger career growth. Uh
first uh section here, I guess the
second section after the hook. Why
estimation matters. 3 to four minutes.
It's more than numbers. It builds trust
and credibility. Impacts timelines.
Client satisfaction and profitability
sets the tone for whether a project
feels like a success or failure. That
h that is it in a nutshell. That is why
we estimate. That is why we need to be
honest about our estimation. I spent a
good deal of time today walking through
a uh since it was an RFP that somebody
spent a good deal of time putting it
together. There's a lot of detail to it.
They're they they're merging a couple
applications and they talked about that
about okay here's the features from this
one and this one and this is how they're
going to join in and what it's going to
look like. Here's some some other things
that we want to do.
And it was really good. I'm cruising
along. I'm like, "Yep, that's going to
take x amount of time. That's going to
take y amount of time." And I'm just
cranking through and then I get to a
section
that is way open-ended. that is it was
it's we want to have integrations with a
bunch of payment processors like AB and
C like that and we would like to
integrate with different accounting
systems like this one but there's other
systems that they haven't talked about
and then there's some other things that
they talk that are like integrations and
things like that it's like okay and I
had to take that section and and that's
where you just be honest with them and
say I can't give you a valid estimate on
this I have no idea idea what it can
take. There's not enough details.
Nothing is the, you know, some amount
does not give me an X amount. So, if I
don't know how many things you're going
to integrate with, I cannot possibly
tell you what it's going to cost to do
that. I can't even tell you. If you
can't tell me which ones they are, I
can't really give you an estimate per
because some are going to be easier than
others. And depending on what you
include and what that integration looks
like, I'm not going to be able to help
you out. I can't or at least I can't at
this point give it to you. Now granted
this is something that you start into
that conversation. But the reason I
bring this up is that I think too often
we end up in at least I know I do run
into situations where the customer
really wants a hard number. They want to
say it's going to cost $10 to get this
built. Okay.
The problem is we can give them a number
like that but if you're if you're smart
your number is going to be insanely big.
If it c if you think it's going to cost
$10, you're going to say it's going to
cost $100 or something like that. This
goes back to setting expectations. And
if they b at it, say, "Well, look, I
don't know that it's really going to
take that much, but I have to do that to
be safe because it could because you
could change your mind. There could be
requirements we haven't talked about.
There are requirements that you haven't
actually detailed. And I can guess at
this stuff, but I'm not the customer.
I'm not the one that's building it." So
be honest where there's things you're
like, "Well, we need to talk about this
more." And it's not don't say it can't
be done or we can't estimate it or
anything like it's just like at this
time we can't give you a valid number.
We can't give you something that works
because we don't have enough
information. So instead of us giving you
just a something that we've pulled out
of thin air, we're going to sit down and
talk to you and then we'll give you, you
know, a timeline and estimates and
things like that. will give you the
details that are needed to actually
build out that pricing. And last thing
before I toss it over is
make sure when you estimate that you are
honest, like if you're a developer, just
always overestimate. If you think you're
estimating too high, you're still too
low. Developers are horrible about I'm
going to get it done in a month and six
months later you're still working on
stuff. Part of it is our fault because
we think we can do everything instantly.
Part of it is the fault of the the
project managers and the customers
because they start with something small
and then things start to get added on
and the next thing you know it's bigger
and bigger takes more time. Don't fall
into the trap. I know I said one more.
Okay, the last one. The last one more.
Don't fall into the trap of a customer
that's like, well, you know, we could do
it for that, but then they try to, you
know, lowball you like, but gosh, we
really had a budget at what, you know,
90% of what it was. It's like the value
is the value. The cost is a cost. It's
like you don't get into a cab with
somebody, get halfway through the ride,
and say, "Hey, can you shut that flag
down and turn the meter off for a while
because I don't really want to pay that
much for this cab ride." It's sort of
the same concept. Your thoughts on this?
So, you kind of touched on most of the
points on this one. I don't want to beat
this too much, but one of the big things
is be honest. Don't lie to the customer.
Don't overpromise. Although that can
still happen, but don't deliberately
overpromise and underdel. We want to uh,
you know, underpromise and overd
deliver. So, like Rob said, you know, if
you think it's going to cost $10, charge
a hundred. uh if you think there's
underlining uh issues that could arise
that could have things go off uh you
know go off the rails. The best example
of this was something I read about the
airlines years ago. So airline
satisfaction was horrible and down.
People were constantly complaining about
airlines never being on time, ticket
prices being too high and so on. One of
the biggest things I heard about how
this model changed was what they did was
they increased the time of the flights.
They decreased uh the cost a little bit
but they changed the expectation
essentially what how long is it going to
take to do something and all of a sudden
customer relations went up. Customers
were more satisfied. Trips were not
taking so long. Flights weren't being
cancelled. So it is along those same
lines. Make sure that what you are
looking at fits within the expectations
of the project and your customer's
expectations. If you say it's going to
be done in a week and you don't deliver
within a week, you're going to have an
upset customer and that is going to
impact your business and your
reputation.
>> And then we'll go right into the common
pitfalls because you actually touched on
a few of those. Overpromising,
underestimating to win a project, then
burning out. ignoring hidden costs,
meetings, testing, documentation,
forgetting risk buffers, unexpected
issues always show up, using gut feeling
instead of a res a repeatable process.
I'm going to start with the uh
underestimating to win a project and
burning out because if it's if you're
side hustling,
I have seen a lot of those. I have
struggled with that at times and I have
been the beneficiary of that several
times where somebody got into a project
and then flaked out and disappeared
because they just got worn out. The
problem is that they screwed over their
customer, they are not going to get that
customer again. And a lot of times I end
up winning that customer because I come
in and say, "Okay, we're going to take
this to the finish." And yeah, it's nice
because they got it 80% there. So now we
have a better idea of what's left. But
uh particularly with a side hustle, I
know you go into it because most of us
do where you're like, I have a day job,
my bills are paid, blah blah blah. I
don't really I'm just doing this for
fun.
Projects become not fun on a regular
basis. There's always going to be
something where you're like, ah, I would
really like to have a weekend off, but
no, I'm still working on this stinking
project. And so, be aware of that. Make
sure you're setting yourself up for
success. not just them but yourself as
well. Uh the last part I want to touch
on too is the whole uh don't use gut
feeling instead of a repeatable process.
This is why we estimate. This is why we
need to even in our own projects have a
feel for like what are we doing? How
much time are we spending? How much time
are we wasting? Because that commonly is
our issue is I don't know how many times
somebody's like I was working for 10
hours today. And you figure out that
well yeah they were at work they were at
their desk for 10 hours but they spent
you know three hours like lost in
listening to the news or they got caught
into something they had to go walk the
dogs much time or whatever. It's like
find ways to figure out exactly when
you're working. I can go back to my
favorite pomodoro and things like that
because those things really really will
help you like know when you're focusing
and when you're not because that's a
whole focus of I mean that's a whole
reason for those is focus do your stuff
and then move on and you're going to
realize that you're not going to work
eight hours a day that 8 hours or 10
hours or 24 hours that you thought you
were working if you're doing a focused
method like that you're going to realize
one you're going to realize that that's
not how much you're working but two
you're going to get more done when you
do it because you're not going to have
all of those distractions. Um, you
already started so I'll let you just
sort of carry on with some of the common
pitfalls and what you see. Yeah. So the
the one I'll touch on is the hidden
costs because you and I have talked
about this off uh you know on the side
quite a bit because a lot of times we
forget there are meetings there you know
you have to do testing there's
documentation and when you plan out a
project especially if you're doing this
as a side hustle you're not going to
think about these at all you're just
thinking about how long does it take to
get this done. The problem is if you go
in with that mindset and you don't think
of this as a whole project. Now, if
you're building a website, okay, maybe
not as much, but you still have to think
about documentation, but testing and
meetings when you have larger teams is
critical. You need to make sure that you
plan for this because if you have, say,
20 hours a week for a budget and you
have a team of four, you want to make
sure that you're optimizing as much time
for development as you can, but you
still need to account for those
meetings. If you schedule two-hour
meetings into that time frame, that's
two times four. You've lost time. So
either you attack that early, add it to
the estimization to your budget, and
then you plan for that ahead of time.
>> And it adds up. Time adds up really
quick. meetings in particular. I I one
of the um just to add to that, one of
the things I find most often gets lost
is once you get to a team is project
management kind of stuff, which is
meeting with the team, but also meeting
with the customer and doing like
statuses and things like that. If you
meet every day during the week for a
half hour, that's 2 and 1/2 hours a
week. And if you're saying that we're
going to just tack 10% on to the end of
the, you know, to the total, that's only
10% means you're for, you know, 10% for
project management basically means
you're 10% of your week, four hours.
That basically means you're budgeting
four hours of project management stuff.
If you spend two and a half hours just
managing the team, then there's not much
else you're going to do. If that man
project manager is also looking at like
creating tickets and chasing down tasks
and uh doing statuses and things like
you can burn through that very quickly.
Uh testing is another one that like
don't you know don't think there's going
to get away with like a 5% you know
upcharge or whatever on top of it for
testing. And it does, it gets scary, but
it gets real because you're going to go
do your, you know, I've got a 200 hour
development estimation I put together.
And then when you add on, you know,
maybe another 5% on top of that for
documentation and 20% on top of that for
testing and 10% 15% for project
management depending on your size. Those
things add up really because those
percentages just another 40 or 50%
sometimes that goes on top of it. But
that's where we get hosed because we get
to the end of the 200 hours and we still
have a 100 hours of work to do cuz we
didn't figure it out from the start. We
didn't set the the standards. We didn't
set expectations and now we're begging
for money or saying, "Ah, I'm sorry." Or
working for free. None of that is
beneficial. None of that is fun.
Approaches to estimation. Uh bottom up,
break work into tasks. Estimate each
piece. Top down use similar past
projects to guide estimates. Three-point
estimation PR peer t uh optimistic
pessimistic most likely time and
materials versus fixed price. The pros
and cons of each. I will briefly touch
on
time and materials is almost always the
way to go. Fixed price, you can do it,
but oh my gosh, you better know exactly
what you better have done this a lot of
times. You better know exactly what
you're talking about. And don't let
yourself get caught in the time and
materials, but it's actually a fixed
price because I have seen that has been
used a couple of times to say, "Look,
we'll pay you x, you know, we'll pay you
by the hour, but we're going to limit
the number of hours per week or month or
whatever the time, you know, there's
going to be a limit to those. There's
going to be a cap." And then somewhere
down the road, there's a cap to the
whole project. So, effectively,
they're trying to win on either end of
it. If it gets done faster, they don't
pay as much for hours. But if it goes
beyond, they're not paying for the
beyond. It's one or the other. If you're
doing, if it's time and materials, more
of the risk goes on the customer because
they need they want it to get done
because the longer it goes, the more
you're getting paid. If it is fixed bid,
then it is you're holding on to the
risk. So, if it's time and material, it
should be, you know, more aggressive
pricing and things like that. they
should be getting their money's worth
and then some. If it is fixed, then you
should be getting a premium on that. And
it's, you know, now if you want to do
something where there's, you know, early
bonuses or there's going to be penalties
if they're late, that's all great. I
mean, that that kind of stuff works. I I
found several times that one of the best
ways to do it is say, "Here's what our
rate's going to be. you know, we're
going to do $5 an hour, but once it gets
past a certain point because we're, you
know, we're sure, pretty sure we're
going to get it done by this time. If we
don't, then we're going to cut it in
half or we're going to go to $4 an hour
or whatever it is. Is to say, okay,
you're getting discounts as a customer
because we didn't give you the proper
estimate. That means we both hurt and
hopefully means that everybody's going
to get the stuff done uh as fast as
possible. The other methods, you end up
working against your customer way too
often.
Um, I spent enough on that that I'm just
going to throw it back over to you.
>> Yeah. Uh, so you touched on the one I
was going to hit, but uh, I'll start
with this one. You know, the three-point
estimization, the perk, optimistic,
pessimistic, and most likely.
Be careful with this one. Well, it is
beneficial to what's the best case
scenario, what's the worst case
scenario, and try to take something in
the middle. Sometimes that's not always
possible because there are always
external or you know additional factors
that you just don't account for. You
know it could be COVID, it could be oh
you know uh the current version of
Windows is now obsolete. You know things
like that you just have to deal with as
they come along. But the that could be
the pessimistic approach. However, when
you're doing the pessimistic approach,
you're probably not thinking that
pessimistic. you're probably not
thinking that worst case disaster. So,
you have to balance the good with the
bad. Um, but this goes kind of back to
what we talked about before where you
need to make sure that you've broken
down the requirements for what this
project's going to be clearly enough
that you can define, okay, this is what
this should take. This is if we can't
complete this, this is what it should
take. If you get to those sections like
Rob said where he had like, oh, it could
go to this uh, you know, accounting
system, it could go to this payer, those
things you can't touch because you don't
have enough information. So, if you
follow this and you get to that point
and you're like, wait, optimistically,
yeah, if we know who this is, we could
possibly do it. But if you have a lot of
those questions, that's when you need to
go back and solidify that, nail down
some of those requirements before you
get too far. And if you can't uh because
I've had a I had a customer, this
reminds me of a customer I had uh a
while back and we ended up sideways with
each other basically because I gave I
did it that I said okay here's the opt
and he wanted the optimistic. He really
was like I need the optimistic and I was
like okay well that's very optimistic
and sure that would work if everything
falls into place. I said, 'But these are
the things that can go wrong and this is
what can and any one of them can take us
off track. And as we did them, as we
were going through, almost everything
that he said was like, well, this is
great and this is working and this will
be fine. And all these optimistic
assumptions he made were wrong. They tr
they turned out to be untrue. And so as
we got through them, I was steadily
communicating to him that, okay, we
thought this would happen. it didn't.
It's going to cost us x amount of time.
You know, it's like we thought this was
going to take a week. It we can't do it
in a week because the things that we
assumed are wrong. So now we got to go
back and fix those. So now it's going to
take a month instead of a week. And even
though this is like part of the part of
why I'm not a real fan of this anyways
is that he got stuck in his head the
original optimistic stuff. He kept going
back to that be like we should be here.
We should be here. We should be here.
Even though there was a steady stream of
communication, usually people are going
to be more realistic and you're going to
have that steady stream of
communication. They're going to see
what's going on. They're going to say,
"Okay, we're falling into the problems."
And they're either going to like, you
know, they may cut the project short or
they may change gears or whatever. But
that's don't hide it from them because
you're worried it's going to get cut
short because then your butt should get
cut short at the end and when they find
out that, you know, you hosed them. give
them that information as soon as
possible so that your customer can make
a intelligent decision and one that's
you know now it's setting the proper
expectations and sometimes there going
to be stuff it's like well can you help
us with that how can we find a way we
can't really afford that pessimistic but
what can we do and there should be
options is find like MVPs and things
like that to save your customer from the
reality of life essentially
practical steps to improve estimates
uh requirements first clarify what's in
scope and what's not. Ask questions
before giving numbers. Break it down.
Smaller tasks equals more accurate
estimates. Add buffers, typically 20 to
30% for risks, unknowns, and scope
creep. Validate with data. Track actuals
versus estimates. Learn from past
projects. Your estimates should improve
over time. Communicate clearly. Share
not just a number, but assumptions
behind it. Example, two weeks assuming
APIs are stable and no new features are
added.
Uh definitely that that's exactly what I
was talking about is like wherever
you're giving the optimistic, the
pessimistic or the mid-range kind of
estimate, talk about not only what it
is, but why it is. What are the uh the
unknowns? What are the risk factors?
Ideally, this is a like um you know pro
tip or whatever. When you're getting
into a project, the high-risk items are
the first things you should tackle.
Those are the first things that you
should start looking into because then
you're going to know as soon as possible
that yeah, that's going to work out or
no, it's not and start finding ways to
be able to work around it. If you wait
till the end, then you're going to have
a lot less way fewer options to do
workarounds. Just trust me, it's always
giving yourself that time. It gives you
more time to redesign, to replan, to
adjust and do the things that you need
to. Um I would say the MV the uh clarify
what's in scope and what's not.
That reminds me of like MVPs is saying
okay well what is really the minimum
viable product. What is it that we like
the minimal amount of work that we need
to get this done? I am starting to have
that conversation with my customers from
the very get-go because it is way too
easy for things to get added, for things
to get moved. And as we're going through
the project and we're adding things in
and they're like, "Can we do this early
on?" It's like, "Yeah, okay. We'll tack
that on and we'll tack that on."
Especially if it's not fixed bid and
it's just like, "Okay, we'll tack it on,
but it's going to take another week.
We'll tack it on. It's going to take
another week. Going to take another
week." And the next thing you know, it's
6 months beyond what the original target
date is. They're frustrated. they
realize that they've got to get it done
faster or market changes or there's so
many things that can happen that can
cause you to get to a point where
suddenly the project need goes into like
critical mode where we got to get just
the things we need and get this thing
shipped out the door uh and maybe they
run out of funding. There's so many
things that can happen. So, I have found
that it is much more valuable from the
start to have those critical, we'll call
them those critical things that are part
of an MVP because that provides you your
second round of stuff is you get the
high-risk stuff. So, you right away just
go after those things and figure out are
those risks real? Are they imaginary?
What are they? And then you go right
into this is what we have to have. These
are the features that have got to got to
got to be there because that's going to
protect your customer and the project.
So that if things do go squirly, if they
do start to you have all kinds of issues
and overruns, you do have like a uh a
fallback basically so you can get
something out the door that still gets
them a win and allows you to, you know,
f push off some of those bigger issues.
Uh thoughts from you?
>> So I'm going to go with the break it
down and add buffers. So because I like
the test-driven approach, you can almost
apply that to your estimization. If you
can break down the requirements in such
a way that you understand what needs to
be done in such a way where if A then B,
then it's a small enough task that you
should fairly easily be able to say,
okay, that's about an hour task. Then
tack on 20 to 30% on top of that for any
unknowns.
If you can't quite get it to that,
again, get it to the piece to a point
where you have at least broken it down
to where you have specific enough
requirements to where you know what the
task needs to be to get it done. If you
have those tasks where hey, we want to
integrate with accountants or we want
integrate with payers, that's not small.
That is too open-ended, too vague. And
at that point, you can't even track it.
You can't even really estimate. So if
you can break it down to small enough
tasks, you're going to be more accurate
with your optimizations. And again,
always take on that additional 20 to 30%
for the unknown.
Well, we have once again run into time
constraints and such because these are
really good topics that they come up
with. Uh who knows, we may have to come
back around to this at some point just
because or we'll just keep doing these
kinds of things and just retread some of
our past episodes and uh continually
have new content and such. However, I
would love for you to send us an email
at [email protected] and let us
know what you think. What do you like?
What don't you like? What would you like
us to address? Uh how would you like us
to change stuff around? How would you
like us to add, delete? All of that kind
of stuff. All of the CRUD options that
are out there for developer itself. You
can also leave us feedback wherever you
listen to podcasts. You can give us any
kind of rating, one to five, like it,
love it, whatever their different rating
scales are. More importantly than your
rating is your actual word feedback like
what did you like? What don't you like?
What can we do better? What can we, you
know, do to help you become a de better
developer? Check us out at
developer.com. We got feedback forms and
everything there. We got tons and tons
of comments. Uh that is probably going
to be doing going through a uh a revamp.
I've promised that for a while, but I'm
actually finally getting to that point.
It's like working its way I'm working my
way down to that on my to-do list. Uh,
also you can check us out on Facebook.
You can check it follow us on
xdevelopreneur
de vel p re neur.com
and you can find us there.
Also, you can find us here wherever
you're watching us or listening us to
right now. Come back because subscribe,
do all that good stuff because we're not
done yet. We are marching on towards
1,000 episodes. We are like 900's in the
rearview mirror and we're moving on.
talking to somebody today and he was
like, "Wow, I remember when you first
started it." It was like weird that it's
already there. And I was like, I
actually remember when I first started
it, too, because I was there. But also,
and I think he may have been the only
person that's like been subscribed all
the way through. That being said, all of
you, whether you started at episode 1 or
episode 911,
appreciate all that you do. Appreciate
you coming out and spending some time
with us. Go out there and have yourself
a great day, a great week, and we will
talk to you next time.
Bonus material. So, let's see. I'll wrap
up these career angle. Why this builds
better developers? Developers who
estimate well are seen as leaders. It
shows business awareness, not just
technical skills. Builds trust with
clients, managers, and teammates. Opens
doors to roles like team, lead,
architect, or consultant. Call to
action. Encourage listeners to review
their last project. Did actual time
match the estimate. Where did it go off
track? Suggest keeping a personal
estimation log for reference. Tie back
to developer. We don't just code. We
build careers by mastering the whole
craft. Bonus add-ons. More story
segment. Share a time you underestimated
overestimated and lessons learned. M uh
mini challenge. Estimate a small side
project like building a to-do app and
then track the actual time. Where do you
want to go with your bonus bonus
material?
So, I'll take that last one, that mini
challenge, because um kind of did one
like this way back. If you go back into
our videos, there's a building a product
catalog that we did years ago. This is a
that is a perfect one for this mini
challenge. Take something that you have
like a to-do list, a task list,
something that you just do every day,
maybe write down, and then try to break
it down into its pieces and see how long
it would take you to actually automate
that uh or build an application for
that. This could also then easily become
one of those automation things that we
talk about all the time, like, hey,
automate your tasks. So, I really
challenge you, our listeners, to do
something like this. Find an everyday
task that you do every day. See if you
can break it down into a project and
then write it or automate it in such a
way that okay, how long is it going to
take and then do it and then once you're
done reflect how long did it actually
take you to do it? Were your
requirements pretty spot-on or were you
off track? You know, if this is
something you do every day or something
that you know, you shouldn't be off
track, but I guarantee you there's going
to be something you find that you're
like, "Whoops, I didn't think of that."
Or you've scope creeped and added things
to it. So, kind of track that. Think
through that process.
I guess I like I want to go with that
one too is that when you do that, when
you start tracking what you're doing to
build an application or to solve a
problem, there are areas that we lose
time. Um I was complaining to my wife
yesterday about getting lost on a rabbit
trail with chat GPT. Not workrelated. It
was something completely different, but
I was like, I had to answer one question
and the next thing I know, I had fallen
down a pit of asking a lot of other
questions and I had great stuff. I mean,
I got a lot of information out of it. It
was really valuable, but totally took me
off track. I will, if you're like me, if
you're doing thing like design, it is
real easy to lose four or five hours
messing around with a couple of buttons
and uh moving those around and changing
some colors and adjusting some pixels
here or there. Uh there's if it's your
own app or if it's something that you're
able to have some level of uh design or
creativity is amazing how often that
you're going to do like a refactor or
something like that where you're like
okay I'm going to go do this I'm going
to change that or I want to move this or
I want to clean this up or you know
there's all these little things but they
add up and so I think that is really
valuable for you track that stuff
because then you're going to figure out
where you lose your time because that's
probably more important than anything
cuz there's going to be times that
you're still going to do those tasks,
but the good thing is now you're going
to be like, "Oh, I have to watch out cuz
I can lose a lot of time. So, I need to
time box this or I need to set alarms or
do something so that I don't end up
losing my entire day working on whatever
that fat feature or that functionality
is. That being said, we have, as we
always do, drifted all over the place in
our time management and things like
that. So, we are not the best at that.
But this is different. We're better. I'm
going to say we're better when we do it
with coding and applications. Maybe we
are, maybe we're not. That's something
we're still working on. And we do track
these kinds of things so we can get
better. As always, I would love any kind
of feedback you you leave us. Gave you
all the places and all the things. So,
for now, we're just going to let you
have some of your time back. Go out
there and have yourself a great day.
Thank you so much. We appreciate you for
listening and we'll talk to you next
time.
[Music]